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

[Ole Trøan <[e-mail]>]

Another alternative is that the draft excludes the network extension use case and only focuses on the local addressing of the host.

Which if I understood the authors correctly was the main “problem” they wanted to solve. 

O. 

On 3 Nov 2023, at 11:24, Lorenzo Colitti <lorenzo=[e-mail]> wrote:



Brian,

On Wed, Nov 1, 2023 at 8:07 PM Brian E Carpenter <[e-mail]> wrote:

I think that the model here is RFC4861 and RFC4862, which refer throughout to "prefix length" and never state that 64 is a special value, with one possible exception in 4862 where it mentions "(e.g., EUI-64 for an Ethernet interface)". Obviously your draft can't go quite that far, because it describes real-world deployment and provides examples.

How about a statement that /64 is used in the examples for practical reasons, but that any reasonable prefix length could be used, typically /64 or longer, if the operational scenario requires it? It would fit nicely in the bullet list of design principles before Fig. 1.

 

Are you primarily concerned that this draft does not hardcoding 64 as parameter value? If so, then I think the draft does try very hard to do this already. But we could clarify that the examples use /64 because currently SLAAC only supports /64 (except for prefixes starting with the binary 000). It already says this in section 8 ("At the time of writing the only prefix size that will allow devices to use SLAAC is 64 bits (see also [RFC7421]).") but we can definitely add additional text explaining that to a -05.

If you're suggesting that it should allow prefixes that are not too small to support SLAAC, then section 8 explains why this is not desirable. It would substantially lessen the utility of this draft. For example, it would no longer be possible to plug in a RFC 7084 router or a SNAC router and have them just work. It would no longer be possible to extend the network in a way that guarantees that all IPv6-compliant devices will work. And so on. I don't think we should do this. Perhaps we should refer to the text in RFC 7421 that says, "using an IID shorter than 64 bits and a subnet prefix longer than 64 bits is outside the current IPv6 specifications, so results may vary."?

Cheers,

Lorenzo

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops