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

[Xipengxiao <[e-mail]>]

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
>