Re: [v6ops] Implementation Status of PREF64

[David Farmer <[e-mail]>]

On Sun, Oct 10, 2021 at 10:35 PM Lorenzo Colitti <lorenzo=
[e-mail]> wrote:

> On Mon, Oct 11, 2021 at 9:16 AM Owen DeLong <owen=
> [e-mail]> wrote:
>
>> Agreed, but the device manufacturer, OTOH, is somewhat in control of what
>> their device will or won’t do and if Lorenzo/Google want to impose that
>> limitation on their implementation, the IETF shouldn’t be able to stop them
>> any more than it should be able to dictate that they must do so.
>>
>> Guess what, Lorenzo… That’s the current situation. The IETF is mute on
>> how many devices must be provided via IA_NA or whether or not you can
>> implement some minimum acceptable number or disable the IPv6 stack as a
>> result.
>>
>> Therefore, you are not prohibited from doing so.
>>
>
> Ok, but would that solve the issue in this thread?
>
> Suppose an OS developer ships a DHCPv6 implementation that requires N
> addresses and does not enable the IPv6 stack unless it receives all of
> them. How does that do anything to address statements such as, "my network,
> my rules" that have been made on this thread? Any operator that wants to
> assign only one address per device still cannot use such hosts on their
> network, and can still criticise the implementation for not doing what they
> want.
>
> What I think David was suggesting is: if we reach consensus on some
> reasonable value of N, then the IETF could write a BCP to that effect. That
> would help to some extent, because if an operator complains that the
> implementation does not work on a network that has N=1, the OS developer
> could point to the BCP as justification for why.
>

I think additional guidance on DHCPv6 deployment is clearly needed,
probably including the trade-offs (pro and cons) and other details related
to such deployments in various contexts. It’s not clear to me if this is
best accomplished through a BCP or an Informational document. Furthermore,
I believe the most important BCP of N>1 has already been made in RFC7934. I
have an open mind on whether or not additional BCP recommending a
particular value of N for DHCPv6 IA_NA and/or IA_TA will be useful.
However, at the very least I think a discussion of these issues in an
Informational document is called for.

I will add, there are two values of N to consider; The first being, what is
a reasonable limit, if any, for a DHCPv6 server to impose on the number of
IPv6 address it will provide to a client, this is likely a
larger number, maybe even 64 or larger. Second, what is a reasonable limit,
if any, for a DHCPv6 client to impose before configuring GUA IPv6
addresses, this is likely a smaller number, maybe even as few as 2 or 3.
Also, do these apply to IA_NA or IA_TA, or a combination of the two?

Thanks.
-- 
===============================================
David Farmer               Email:[e-mail]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota
2218 University Ave SE        Phone: [phone]
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================