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

[Ted Lemon <[e-mail]>]

What's missing here is that we need home routers to reject anything smaller
than a /64 in order for this to be a good solution. And I don't actually
know how to do that at the moment. We could state this requirement in
7084bis, but given that a lot of ISPs are providing home routers to
customers, what we say in 7084bis isn't likely to be followed unless the
ISP wants to follow it.

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