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

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

Hi Barbara,

draft-ietf-sunset4-gapanalysis-09, problems 1-5, refer to the case when IPv4 is no longer available.

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.

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?

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.

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 …

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 ?
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.