Hi Ole, My apologies for the delayed response - apparently the authors were not subscribed to the last-call@ list. Adding the authors alias to Cc for visibility. On Wed, Feb 7, 2024 at 9:58 PM Ole Troan <otroan=40employees.org@xxxxxxxxxxxxxx> wrote: > 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. The draft explicitly says that client behaviour is out of scope for this draft. I’m not sure we should add this, because v6ops is not really the right place to specify host behaviour, Instead, draft-ietf-6man-pio-pflag, which is adopted by 6man, seems like a better place to have this discussion. > 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”. We didn’t mean to imply that it can be easily achievable on all networks anytime soon. There are corporate networks which do not set the A bit even today. Such networks could benefit from this proposal. Also, enterprise networks where dedicated network segments exist for corporate-managed devices can ensure that all devices on a given network support the mechanism. > 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. Actually Section 11 already provides an example of a node which can benefit from this proposal without a new flag. The text says: “ It should be noted that the deployment model described in this document does not depend on [I-D.collink-6man-pio-pflag] and can be implemented without deploying that PIO flag. For example, devices acting as [RFC7084] compatible routers would be able to receive prefixes via DHCPv-PD.” Would you like to add more text there? > 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? This is an informational document, networks which do not benefit from the proposed solution are not required to implement it. Documenting a specific deployment scenario is useful even if that scenario is not universally applicable. The draft doesn’t imply that each virtual system gets /64. Actually, quite the opposite: a physical node receiving a single /64 might be able to extend the network connectivity to virtual systems (for example, using SLAAC, see Section 8). Because client behaviour is out of scope, this draft is not the best place to discuss that topic, but we can discuss it in 6man. > 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? First of all this document does not invent a new way of providing IPv6 addresses to clients. It uses the already standardized mechanisms (DHCPv6-PD and SLAAC). The document describes how the existing mechanism (DHCP-PD) can be deployed in the networks which traditionally do not utilize it. >From the implementation perspective, many/most nodes already have DHCPv6 clients to support DHCPv6 IA_NA or IA_PD, so adding DHCPv6 pD support does not greatly increase complexity. > 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.) It should be noted that the deployment problems addressed by this draft are much more likely to manifest in large networks. So small networks which are not affected by scalability problems described in the draft, might not need to deploy this solution. This proposal does not require any more address space than RFC 8273. The authors believe that this draft allows the network administrators to benefit from DHCPv6 accountability and unlimited number of address provided by SLAAC, combining benefits of both. > > 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 -- Cheers, Jen Linkova -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
