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

[Lorenzo Colitti <[e-mail]>]

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
>