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

[David Farmer <[e-mail]>]

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