This document proposes to repurpose a mechanism designed to delegate prefixes between administrative entities, to do prefix assignment within a network. The proposal is fairly comprehensive. 1) Host behaviour is underspecified. For example a host that implements this proposal must follow the weak host model. Since it will not have a GUA on the outgoing interface. Add a reference to WAA-9 in RFC7084. Come to think of it it’s what’s specified in this proposal is essentially proposing that nodes implementing this proposal behaves just like specified in RFC7084. Perhaps just say that. 2) The document suggests that a PIO with A-flag can be disabled when it is known that all nodes support this mechanism. It’s unclear how that can be achieved in practice, especially in the context of “large broadcast networks”. 3) While the document states this mechanism can be used without a new P-flag it’s not specified how a node should function in that scenario. As in still getting the benefits described in the proposal. 4) How a node should behave regarding extending the network is underspecified. The authors seem also to indicate that this mechanism for network extensions are only available in large networks. The document recommends a /64 assigned to each entity to support SLAAC. If that means a node with 5 VMs needs 5 /64s, then the address space considerations in section 8 seem optimistic. The consequences for address space usage needs to be further evaluated. Do we really want to standardize a mechanism for extending the network that is available only to large corporations? 5) Additional host complexity. Having two ways of configuring addresses in IPv6 (SLAAC and DHCPv6 IA_NA/TA) has been a long thorny path. The meaning of the M/O-flags in the RA message have led to mailing list threads of hundreds of messages. Is multiplying the combinations of addressing configuration by adding yet another mechanism and another “hint” flag helping IPv6 deployment? 6) While this mechanism has the benefit over RFC8273, that it supports (at least theoretically) extending the network, if it only does so for large networks with ample address space, is the additional complexity on all nodes worth it? (Network extensions can relatively easily be accommodated into a smaller address space by supporting address assignment mechanisms different than SLAAC.) Best regards, Ole > On 29 Jan 2024, at 22:25, The IESG <iesg-secretary@xxxxxxxx> wrote: > > > The IESG has received a request from the IPv6 Operations WG (v6ops) to > consider the following document: - 'Using DHCPv6-PD to Allocate Unique IPv6 > Prefix per Client in Large > Broadcast Networks' > <draft-ietf-v6ops-dhcp-pd-per-device-06.txt> as Informational RFC > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > last-call@xxxxxxxx mailing lists by 2024-02-12. Exceptionally, comments may > be sent to iesg@xxxxxxxx instead. In either case, please retain the beginning > of the Subject line to allow automated sorting. > > Abstract > > > This document discusses an IPv6 deployment scenario when individual > clients connected to large broadcast networks (such as enterprise > networks or public Wi-Fi networks) are allocated unique prefixes via > DHCPv6 Prefix Delegation (DHCPv6-PD). > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-v6ops-dhcp-pd-per-device/ > > > > No IPR declarations have been submitted directly on this I-D. > > > > > > _______________________________________________ > v6ops mailing list > v6ops@xxxxxxxx > https://www.ietf.org/mailman/listinfo/v6ops > -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
