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

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 16 Aug 2017 18:58:04 +0200

Hi Lee,

I’m happy to review draft-ietf-v6ops-rfc7084-bis-04 with possible solutions, but we first, as a WG, need to clarify if still want to update RFC7084 or instead, want to go in the direction of separating the transition requirements as per draft-palet-v6ops-rfc7084-bis-transition-00.

Updating draft-ietf-v6ops-rfc7084-bis-04 could allow what you are asking for.

However, if we don’t want to touch RFC7084, seems to me difficult that we can do it in a “transition” only document.

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 <[email-masked]> en nombre de Lee Howard <[email-masked]>
Responder a: <[email-masked]>
Fecha: miércoles, 16 de agosto de 2017, 18:28
Para: <[email-masked]>
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
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 16 Aug 2017 18:50:08 +0000

> 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>
 
> 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
> 
> 
> De: v6ops <[email-masked]> en nombre de Lee Howard
> <[email-masked]> Responder a: <[email-masked]>
>     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:
>     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”?
>     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=
> 
> 
> 
> 
> 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.
> 
> 
> 
> 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=

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 16 Aug 2017 22:37:08 +0200

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

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 16 Aug 2017 21:32:19 +0000

Inline...
Barbara

> draft-ietf-sunset4-gapanalysis-09, problems 1-5, refer to the case when IPv4

Yes: Not available (through any means) on the WAN. But still used on the LAN.

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

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

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

> 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. 
 
> 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).
> 
>     <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 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>
> 
>     > My plan, if time permits, is to update either one or the other document
> next
>     > week.
>     >
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=bdfjY-
> 4BpvpG5rxUtW6ljW7uXcTb06J-
> waydCKsh30c&s=uAShtvyY8FqLcj3q82uMjYZXWG67_bRkjQ7A3VqeO88&e=
> The IPv6 Company
> 
> o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=bdfjY-
> 4BpvpG5rxUtW6ljW7uXcTb06J-waydCKsh30c&s=Rj7C-
> J_Wmz8I2SWoTJnH0aiik1kCnCbRRUltG69GHRk&e=

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Wed, 16 Aug 2017 23:50:03 +0200

Below, in-line.

Regards,
Jordi

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

    Inline...
    Barbara

[Jordi] The goal of the document, if I read it correctly is to turn off IPv4 “completely” LAN and 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.

[Jordi] I understand that …

[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).

---

From: Lee Howard <[email-masked]>
Date: Mon, 21 Aug 2017 09:50:24 -0400

On 8/16/17, 5:32 PM, "v6ops on behalf of STARK, BARBARA H"
<[email-masked] on behalf of [email-masked]> wrote:

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

Problem 1 applies both to a home router and a LAN client interpreting a
lack of DHCP response as an error. I don’t think this needs to be separate
problems for router and device, do you?
Problem 2 is for when IPv4 is not available on the WAN but the router
advertises DHCP to the LAN.
Problems 3-5 (Section 2.2) "Disabling IPv4 in the LAN” are not about when
it’s still used on the LAN.

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

This makes sense to me, though I might amend it to, "what to do when there
is no native IPv4 or IPv4 transition mechanism in the WAN”

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

I no longer need IPv4 in my home network, except in translation.
Can’t I just turn it off? If I can, even if it’s manual, then what happens?
I realize the fallacy of assuming I’m a typical user, but in three years
when 80% of US connections are IPv6, aren’t we thinking seriously about it?

Lee