Re: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis

[JORDI PALET MARTINEZ <[e-mail]>]

Below, in-line.

Regards,
Jordi
 

-----Mensaje original-----
De: "STARK, BARBARA H" <[e-mail]>
Responder a: <[e-mail]>
Fecha: miércoles, 16 de agosto de 2017, 23:33
Para: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Asunto: RE: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis

    Inline...
    Barbara
    
    > draft-ietf-sunset4-gapanalysis-09, problems 1-5, refer to the case when IPv4
    > is no longer available.
    
    Yes: Not available (through any means) on the WAN. But still used on the LAN.

[Jordi] The goal of the document, if I read it correctly is to turn off IPv4 “completely” LAN and WAN.

    
    > So, if RFC7084 is an IPv6 only-CE (even if the CE can have an IPv4 stack), then
    > we have those problems when there is no IPv4 connectivity.
    
    Yes: We will have the described problems if there is no IPv4 available on the WAN (through any means).

    
    > If the IPv6-CE supports transition, then you never have those problems,
    > because the goal of the transition support is precisely to avoid them. It is not
    > a matter of IPv4 in the WAN. You can have IPv6-only WAN, but transition can
    > resolve that.
    > 
    > Or I’m missing anything in your opinion?
    
    Please correct me if I'm wrong, but I thought all the described mechanisms require a correlated capability in the WAN. Just because a CE router supports all of these doesn't mean any of them necessarily exist in the WAN, or that configuration of any of them via DHCPv6 is supported by the ISP (WAN may have capability but requires manual CE Router config which many end users won't know how to do). So I think support in the CE Router, by itself, is insufficient to ensure IPv4 WAN availability. Therefore, even if a CE Router supports all of these, it is still possible for there to be no IPv4 WAN connection. IMO, CE Router requirements that explicitly target IPv6-only operation would be a very logical place to include requirements for "what to do when there is no IPv4 in the WAN".

[Jordi] Not really, may depend on the transition mechanism. Let me give you one example. You can have an operator with a completely IPv6-ONLY network. The customer CE can have CLAT (or the OSs), and the NAT64 service and even the DNS64 service can be somewhere else, not necessarily in the operator network (may be a free service, actually there are already some), and it may be automatically configured by the operator even if doesn’t have IPv4 at all, pointing the CEs to the “NAT64 external” provider. Just consider this as the “reverse” situation to the actual IPv6-tunnel-brokers.
    
    > The problem here, in my opinion is that in the actual RFC7084 you “allow” the
    > support of IPv4, so is in that case when, if there is no transition support, the
    > problems 1-5 may be presented in the LANs.
    > 
    > So, one alternative is again considering my proposal of making an RFC7084
    > with is “really” only-IPv6 (removing ALL the IPv4 support in that document),
    > and then it make sense to have other documents with the transition support,
    > etc., and then finding the right one for resolving the problems above.
    
    Because of the existence of the CE Router IPv6 Ready certification program, the many references to RFC 7084 made by external orgs, etc. I continue to be opposed to changing it. That would almost certainly cause confusion, and is unnecessary. Requirements related to IPv6-only WAN connections (with or without the WAN supporting configuration or termination of an IPv4 tunneling mechanism) can all logically go in a single new doc.

[Jordi] I understand that …
    
    > Actually, some of the problems, in my opinion, can be resolved just in the OS,
    > but is not a matter here to discuss one by one. For example, problem 1,
    > some OS may believe there is only “Internet” if there is a DHCP server
    > responding, even if they have IPv6 connectivity, etc., but this can be sorted
    > out in the actual RFC7084 if there is IPv4 stack, and there is no transition
    > support and there is not IPv4 support, by making sure that the DHCPv4
    > server in the CE is not turned on in that case …
    
    That's a bad idea. I expect my home network to operate in the absence of any and all WAN IP connections. I refuse to buy (or sell or recommend) a CE router that does not continue to operate its DHCPv4 server in the absence of IPv4 WAN connectivity. Also, I disagree with putting any LAN-side IPv4 protocol requirements into a 7084bis. 

[Jordi] and I agree with you here, was an example, not really my intend … But as you follow your own rationale, it is very clear that even if we have IPv6-only CEs, we need during many years to go, many IPv4 “functions” support, there are many devices in almost every home/office that will not be replaced in 3-5, maybe 10 years, so we need to offer the IPv4 transition support … to allow operators to go to “IPv6-only” WANs (or complete networks).
     
    > Of course, it can probably be done in one more document to “complement
    > RFC7084”.
    > 
    > Thinking twice, I could, as well, for maybe 1 or 2 of the problems, have some
    > text in the transition doc, but I don’t think all them can be resolved in that
    > doc.
    > 
    > So, to do it correctly I think RFC7084 needs to be updated (and maybe then
    > remove the transition stuff there, so all the transition goes to the transition
    > one).
    > 
    > I’m just thinking loud and trying to heard the WG.
    > 
    > Regards,
    > Jordi
    > 
    > 
    > -----Mensaje original-----
    > De: "STARK, BARBARA H" <[e-mail]>
    > Responder a: <[e-mail]>
    > Fecha: miércoles, 16 de agosto de 2017, 20:50
    > Para: "[e-mail]" <[e-mail]>,
    > "[e-mail]" <[e-mail]>
    > Asunto: RE: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis
    > 
    >     > However, if we don’t want to touch RFC7084, seems to me difficult that
    > we
    >     > can do it in a “transition” only document.
    > 
    >     <bhs> I disagree. I think it would actually be easier in a "transition" only
    > document. Such a document could easily have a requirement along the lines
    > of:
    >     If no WAN IPv4 connectivity is present (native or through one of the
    > technologies in this document), the CE Router MUST ...
    >     I'm not sure what it must do, though.
    >     I don't think the solution involves IPv6 signaling, and putting LAN-facing
    > IPv4 protocol requirements in RFC7084bis would be problematic. But it would
    > not be a problem in a "transition" doc. - Barbara</bhs>
    > 
    >     > So, do we want to re-consider this decision again?
    >     >
    >     > My plan, if time permits, is to update either one or the other document
    > next
    >     > week.
    >     >
    >     > Regarding 6&7, I actually provided text on that to the authors, and one of
    > my
    >     > comments was in the direction of RFC6555-bis can somehow sort out
    > those,
    >     > but the actual text is still based in RFC6555 until RFC6555-bis become an
    > RFC,
    >     > in order to avoid “holding” draft-ietf-sunset4-gapanalysis-09, so all
    > depends
    >     > on how fast we move with one or the other …
    >     >
    >     > Regards,
    >     > Jordi
    >     >
    >     >
    >     > -----Mensaje original-----
    >     > De: v6ops <[e-mail]> en nombre de Lee Howard
    >     > <[e-mail]> Responder a: <[e-mail]>
    >     > Fecha: miércoles, 16 de agosto de 2017, 18:28
    >     > Para: <[e-mail]>
    >     > Asunto: [v6ops] Sunset4 gap analysis: rfc6555bis, ipv6rtr-reqs, rfc7084-bis
    >     >
    >     >     Reading through draft-ietf-sunset4-gapanalysis-09 it seemed to me
    > that
    >     > several problems might be resolvable in documents we currently have
    > open:
    >     >
    >     >     Can problems 1-5 (indicating that IPv4 is unavailable, disabling IPv4 in
    > the
    >     > LAN) be addressed with recommendations in any, some, or all of:
    >     >     draft-ietf-v6ops-ipv6rtr-reqs-00 "Requirements for IPv6 Routers"
    >     >     draft-ietf-v6ops-rfc7084-bis-04  “Basic Requirements for IPv6 Customer
    >     > Edge Routers"
    >     >     Or other drafts under discussion in v6ops now?
    >     >     Or do we need new IPv6 signalling (RA?) that IPv4 is unavailable? That
    >     > would have to go to 6man. Or did we do this, and I’ve forgotten in my old
    >     > age?
    >     >
    >     >
    >     >
    >     >     Are problems 6 & 7 (Happy Eyeballs and getaddrinfo()) addressed with
    >     > draft-ietf-v6ops-rfc6555bis-03,  "Happy Eyeballs Version 2: Better
    >     > Connectivity Using Concurrency”?
    >     >     Can problem 10 be addressed in rfc6555-bis?
    >     >
    >     >     Thanks,
    >     >
    >     >     Lee
    >     >
    >     >     _______________________________________________
    >     >     v6ops mailing list
    >     >     [e-mail]
    >     >     https://urldefense.proofpoint.com/v2/url?u=https-
    >     > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=LFYZ-
    >     > o9_HUMeMTSQicvjIg&r=LoGzhC-
    >     > 8sc8SY8Tq4vrfog&m=uzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN-
    >     > RUZs&s=dAnqF0IWAIbz3_wvZSm5SBJqvGGRswIj4npGtJaP-7M&e=
    >     >
    >     >
    >     >
    >     >
    >     > **********************************************
    >     > IPv4 is over
    >     > Are you ready for the new Internet ?
    >     > https://urldefense.proofpoint.com/v2/url?u=http-
    >     > 3A__www.consulintel.es&d=DwIGaQ&c=LFYZ-
    >     > o9_HUMeMTSQicvjIg&r=LoGzhC-
    >     > 8sc8SY8Tq4vrfog&m=uzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN-
    >     > RUZs&s=NHx1lFPeZQ13ZFQKRHpvNfx1vTbjumaqKvbhuzNebE0&e=
    >     > The IPv6 Company
    >     >
    >     > This electronic message contains information which may be privileged or
    >     > confidential. The information is intended to be for the use of the
    > individual(s)
    >     > named above. If you are not the intended recipient be aware that any
    >     > disclosure, copying, distribution or use of the contents of this
    > information,
    >     > including attached files, is prohibited.
    >     >
    >     >
    >     >
    >     > _______________________________________________
    >     > v6ops mailing list
    >     > [e-mail]
    >     > https://urldefense.proofpoint.com/v2/url?u=https-
    >     > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=LFYZ-
    >     > o9_HUMeMTSQicvjIg&r=LoGzhC-
    >     > 8sc8SY8Tq4vrfog&m=uzccVE3XgWpcpFGMQ9qjF-IGi6Zg7wpOm1T1oN-
    >     > RUZs&s=dAnqF0IWAIbz3_wvZSm5SBJqvGGRswIj4npGtJaP-7M&e=
    > 
    > 
    > 
    > 
    > **********************************************
    > IPv4 is over
    > Are you ready for the new Internet ?
    > https://urldefense.proofpoint.com/v2/url?u=http-
    > 3A__www.consulintel.es&d=DwIGaQ&c=LFYZ-
    > o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=bdfjY-
    > 4BpvpG5rxUtW6ljW7uXcTb06J-
    > waydCKsh30c&s=uAShtvyY8FqLcj3q82uMjYZXWG67_bRkjQ7A3VqeO88&e=
    > The IPv6 Company
    > 
    > This electronic message contains information which may be privileged or
    > confidential. The information is intended to be for the use of the individual(s)
    > named above. If you are not the intended recipient be aware that any
    > disclosure, copying, distribution or use of the contents of this information,
    > including attached files, is prohibited.
    > 
    > 
    > 
    > _______________________________________________
    > v6ops mailing list
    > [e-mail]
    > https://urldefense.proofpoint.com/v2/url?u=https-
    > 3A__www.ietf.org_mailman_listinfo_v6ops&d=DwIGaQ&c=LFYZ-
    > o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=bdfjY-
    > 4BpvpG5rxUtW6ljW7uXcTb06J-waydCKsh30c&s=Rj7C-
    > J_Wmz8I2SWoTJnH0aiik1kCnCbRRUltG69GHRk&e=
    



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.