Re: [v6ops] Chair decision on WGLC for draft-ietf-v6ops-dhcp-pd-per-device-04

[Lorenzo Colitti <[e-mail]>]

Well, but if you think about it, all Android devices (and many devices as
well) already extend the network, if the user chooses to do so. They just
do so via NAT44 (or NAT4464) and not via native IPv6. It's true that with
this mechanism they can also extend the native IPv6 network. But for as
long as the overwhelming majority of services support IPv4, "extending the
network via IPv4 only" and "extending the network via IPv4 and IPv6" aren't
really that different. Even if a network chooses to implement this
proposal, they are not giving the device any functionality that it does not
already have.

Think about it this way: what we are doing is trying to reach parity with
IPv4 and DHCPv4. In IPv4, devices can always address the network via NAT44.
And network administrators can always assign and track IP address space
given to the client. It's just that the assignment is a whole a prefix
instead of a single IPv4 address. This brings the advantage of being able
to extend the network with end-to-end connectivity as well.

Also, I'd point out that in many cases, extending the network within a
device is implemented in similar ways to extending the network to other
devices. A good example is Chrome OS, which uses SLAAC and ND proxying to
provide connectivity to various containers (Android, Linux, ...) running
within the device. This is almost identical to how you'd extend the network
to other devices. In fact, that's one of the motivations for the draft -
Chrome OS broke on the Google enterprise network because it was using too
many IPv6 addresses for the wireless APs to handle. Once this draft is
published, I hope that Chrome OS will implement DHCPv6 PD as well.

On Tue, Nov 7, 2023 at 8:04 PM David Farmer <farmer=[e-mail]>
wrote:

> While I agree with allowing "network extension" by using SLAAC with
> DHCPv6-PD and anticipate using it on my network. Nevertheless, not everyone
> sees "network extension" as a good thing. And effectively, since Android
> doesn't support DHCPv6 address assignment, you are forcing "network
> extension" upon those who only want a mechanism to do DHCPv6 with Android.
>
> You have said your objection to DHCPv6 is that a network can limit the
> number of addresses the host can have, which is also slow.  DHCPv6-PD,
> without SLAAC and presumably a /80 prefix, would allow the local assignment
> of a virtually unlimited number of IPv6 addresses for the host, resolving
> your objections to DHCPv6. However, now you are adding a requirement to
> allow "network extension" to do DHCPv6 with Android. To many, this seems
> like bait-and-switch tactics.
>
> Thanks.
>
> On Tue, Nov 7, 2023 at 4:49 AM Lorenzo Colitti <lorenzo=
> [e-mail]> wrote:
>
>> Remember that the draft doesn't require a /64. It requires a prefix of a
>> length that allows SLAAC. That's very important because a SLAAC-sized
>> prefix allows extending the network to any number of IPv6 stacks (either
>> within the device, or connected to another interface, e.g., tethering). If
>> we just allow /80 without making SLAAC work on /80, then we lose that
>> ability.
>>
>> On Tue, Nov 7, 2023 at 11:06 AM Philipp S. Tiesel <[e-mail]>
>> wrote:
>>
>>>
>>> On 7. Nov 2023, at 10:24, Ted Lemon <[e-mail]> wrote:
>>>
>>> It's definitely true that we can't force enterprises to do that. But we
>>> aren't proposing to force them to do that, so what's the issue?
>>>
>>>
>>> Enterprise security people hate SLAAC.
>>> The issue is that many enterprise network teams are reluctant to deploy
>>> SLAAC for several reasons.
>>> They started to plan with a /64 per link anyway with DHCPv6 IA-NA.
>>>
>>> Using dhcpv6-pd-per-device would be a really elegant drop-in solution if
>>> it worked with a /80 – also on Android.
>>>
>>> I guess the document recommending /64, but stating implementations
>>> should also support /80 would not have met no opposition at all.
>>>
>>> I am somewhat happy with the document going it forward as it is and
>>> taking the momentum to moving SLAAC to /80 to make it a fit for already
>>> (half-way) deployed IPv6 networks.
>>>
>>> Still, it would be much more honest to sattle on
>>> - pd-per-device can use something between /56 and /80.
>>> - /64 is recommended
>>> - Everything smaller than /80 is unsupported for physical devices and
>>> should result in an error.
>>> - We look each other in the eyes and enforce the above point in working
>>> code to prevent a race to the bottom.
>>>
>>>
>>> Secondarily, what's the tearing hurry to make corporations switch to
>>> IPv6? I know we all have put a lot of work into specifying IPv6, but if
>>> they don't see a value proposition in enabling it, why the rush? They will
>>> switch when they see a value proposition. Trying to get them to switch
>>> "because it's better" is a recipe for generating blowback.
>>>
>>>
>>> On Tue, Nov 7, 2023 at 10:22 AM Philipp S. Tiesel <[e-mail]>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>> I totally agree that we have enough addresses on the cellular site for
>>>> that.
>>>>
>>>> What we can’t afford is forcing all enterprises that settled their IPv6
>>>> deployment on a /64 per link to start over from scratch and re-request
>>>> enough address space from the RIRs to implement a /64 per host while the
>>>> RIR polices have also been based on a /64 per link. This would punt IPv6
>>>> deployment for many enterprises that are already half-way in for another 10
>>>> years.
>>>>
>>>> > On 6. Nov 2023, at 22:06, Delong.com <owen=
>>>> [e-mail]> wrote:
>>>> >
>>>> > If we can provide a /64 to all the smart phones in the world for a
>>>> /28, I call that a non-problem.
>>>> >
>>>> > Owen
>>>> >
>>>> >
>>>> >> On Nov 5, 2023, at 06:36, Martin Huněk <[e-mail]> wrote:
>>>> >>
>>>> >> Hi,
>>>> >>
>>>> >> To be honest, I don't know from the top of my head.
>>>> >>
>>>> >> However, we don't see approx. 3.6 billion Android smartphones are
>>>> all asking for their own /64 yet, do we? If all of those were in a single
>>>> network, we would need /32 just for them. If Apple is to join the club, we
>>>> will be on approx. /30. In reality, where there are multiple networks and
>>>> where every single one of them had to somehow solve the higher demand, how
>>>> much address space would this draft cost?
>>>> >>
>>>> >> Most of the time, /64 is useless for the phone. So much lost for a
>>>> very little gain ...
>>>> >>
>>>> >> Best Regards,
>>>> >> Martin
>>>> >>
>>>> >> Dne čtvrtek 2. listopadu 2023 22:06:42 CET, Xipengxiao napsal(a):
>>>> >>> Hi Martin,  by the following statement, are you saying that this is
>>>> the first draft/RFC that proposes assigning a /64 (or shorter) to a host?
>>>> XiPeng
>>>> >>>
>>>> >>>>> This draft is misleading and the most address-space-hungry
>>>> document that ever passed WGLC. Because of that, it is dangerous to the
>>>> addressing architecture of the IPv6.
>>>> >>>>> The address space has been effectively reduced by it from 2^128
>>>> to 2^64.
>>>> >>>
>>>> >>> -----Original Message-----
>>>> >>> From: Martin Huněk <[e-mail]>
>>>> >>> Sent: Thursday, November 2, 2023 9:09 PM
>>>> >>> To: [e-mail]
>>>> >>> Cc: V6Ops Chairs <[e-mail]>; Xipengxiao <xipengxiao=
>>>> [e-mail]>
>>>> >>> Subject: Re: [v6ops] Chair decision on WGLC for
>>>> draft-ietf-v6ops-dhcp-pd-per-device-04
>>>> >>>
>>>> >>> Hi,
>>>> >>>
>>>> >>> This draft is misleading and the most address-space-hungry document
>>>> that ever passed WGLC. Because of that, it is dangerous to the addressing
>>>> architecture of the IPv6.
>>>> >>>
>>>> >>> The address space has been effectively reduced by it from 2^128 to
>>>> 2^64. IETF v6ops just says to Google and others that it is fine for every
>>>> phone to have /64. Because of that, operators would be forced to provide
>>>> that due to the critical mass of Google devices. Informational or not,
>>>> Google is a big vendor that has already forced network operators not to
>>>> depend on DHCPv6 IA_NA by intentionally ignoring it. I'm not looking
>>>> forward to round two. Worst case scenario - IPv4 only network - it is
>>>> contra-productive to allow network extension in an enterprise network
>>>> environment by every single device. Also, mandatory /64 for everyone makes
>>>> it almost useless for most.
>>>> >>>
>>>> >>> SLAAC support is a weak argument as every device that extends the
>>>> network and is routing is, in fact, a router. Routers could use DHCPv6-PD
>>>> even before this document. This document makes it OK for every device to
>>>> get /64, not just for routers but also for hosts that do not extend the
>>>> network. Actual size is not written there explicitly, but is there
>>>> implicitly. The intention hasn't been modified since the initial version of
>>>> the draft; only more explanation has been added.
>>>> >>>
>>>> >>> There would have been an easy fix, just to mandate clients to set
>>>> prefix-length hint for an among client really needs for its operation.
>>>> Instead, we have there implicit /64, abusing method required for legitimate
>>>> notes for extending the network - routers. Client behaviour is not defined
>>>> explicitly in the draft - it is missing this critical part. Should we start
>>>> working on IPv7 with 256b or 512b long addresses so we can throw out half
>>>> of it more easily?
>>>> >>>
>>>> >>> When this document progresses into RFC the following shall be done:
>>>> >>> - Strictly define a mandate for DHCPv6-PD clients to use
>>>> prefix-length hint. (So the missing part of this draft is solved)
>>>> >>> - Mandate every DHCPv6-PD client to also support IA_NA. (So when
>>>> there are not enough prefixes, the device can, is forced to, function at
>>>> least somehow)
>>>> >>> - Maybe allow SLAAC with shorter IID - but there would still be
>>>> legacy clients supporting only /64. So implementations based on this draft
>>>> would still require /64 just to be sure that every imaginary device
>>>> connected to the host/client can use SLAAC. This is circulus vitiosus.
>>>> >>>
>>>> >>> If anyone like to cooperate on any of these ideas, please reach out.
>>>> >>>
>>>> >>> I'm sorry for the tone, but I really think that this draft in its
>>>> current state is the road to hell paved by the good idea. The idea of
>>>> giving one prefix instead of multiple IPs is not bad, and it makes sense.
>>>> Undefined client behaviour implying /64 for every host is the hidden evil
>>>> in it. This would not quite cut the proportionality test - effectively
>>>> losing 2^128 - 2^64 addresses and forcing network administrators to change
>>>> their address plans so a few clients can theoretically extend the network,
>>>> not worth it in my book. Such drastic changes in addressing architecture
>>>> are disruptive and can be seen as immaturity of the whole protocol.
>>>> >>>
>>>> >>> This is why *I'm against this draft moving forward*. If it mandated
>>>> a client to ask for the minimum it needs to perform its function, I would
>>>> be all for it.
>>>> >>>
>>>> >>> Sincerely,
>>>> >>> Martin Hunek
>>>> >>>
>>>> >>> Dne středa 1. listopadu 2023 15:27:11 CET, Xipengxiao napsal(a):
>>>> >>>> Hi folks,
>>>> >>>>
>>>> >>>> Seeing the hot discussion on
>>>> draft-ietf-v6ops-dhcp-pd-per-device-02/03/04, the chairs have let the WGLC
>>>> run longer than originally designated to let people fully express their
>>>> view.  But the chairs must also make a decision at some point.
>>>> >>>>
>>>> >>>> Going through the mails, the chairs counted the following opinions:
>>>> >>>> •       For: Jen L., Lorenzo C., Joel H., Nick B., Erik K., David
>>>> F., Owen D., Brian C.
>>>> >>>> •       Against: Pascal T., Eduard V., Martin H., Ole T., Gert D.
>>>> >>>>
>>>> >>>> It’s clear that there is no clear consensus.  Due to a large
>>>> number of emails and some people not expressing their For/Against opinion
>>>> clearly, the chairs may have missed 1-2 opinions. But even if so, “no clear
>>>> consensus” remains the case.
>>>> >>>>
>>>> >>>> In general, the draft is in good shape.  The remaining debate
>>>> focuses on prefix size.  The chairs would like to point out that there is
>>>> no need for a draft to solve all problems to pass WGLC - It only needs to
>>>> solve the problems in the intended scenarios and make no harm in other
>>>> scenarios.  This draft points out that many existing hosts only support
>>>> SLAAC with /64 prefixes, and in order not to require changes to such
>>>> hosts,  /64 or shorter prefixes must be delegated.  This is a practical
>>>> choice.  For other scenarios where unique /64 (or shorter) prefix per
>>>> client cannot be afforded, people can choose not to take this approach so
>>>> this draft makes no harm.  With this consideration and acknowledging that
>>>> it's a "rough consensus", the chairs declare this draft has passed WGLC.
>>>> Thanks to all the people who provided reviews and comments.
>>>> >>>>
>>>> >>>> Ron and XiPeng
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> v6ops mailing list
>>>> >>>> [e-mail]
>>>> >>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>> >>>>
>>>> >>>
>>>> >>>
>>>> >>
>>>> >> _______________________________________________
>>>> >> v6ops mailing list
>>>> >> [e-mail]
>>>> >> https://www.ietf.org/mailman/listinfo/v6ops
>>>> >
>>>> > _______________________________________________
>>>> > v6ops mailing list
>>>> > [e-mail]
>>>> > https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>>
>>>
>>> _______________________________________________
>>> v6ops mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>>>
>> _______________________________________________
>> v6ops mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/v6ops
>>
>
>
> --
> ===============================================
> David Farmer               Email:[e-mail]
> Networking & Telecommunication Services
> Office of Information Technology
> University of Minnesota
> 2218 University Ave SE        Phone: [phone]
> Minneapolis, MN 55414-3029   Cell: 612-812-9952
> ===============================================
>