[IPv6]Re: Working Group Last Call for <draft-ietf-6man-pio-pflag>

[Lorenzo Colitti <[e-mail]>]

I much prefer using multiple flags over a combination of flags and DHCPv6
options. It's much easier to specify, implement, configure, and operate.

That said, I'm not sure I understand the rationale. What type of device
would look at E? Existing RFC 7084 routers already run PD unconditionally.
Are you suggesting that once this flag is specified, CE routers should not
run PD if they see an RA with E=0? As Ted said, changing the behaviour for
things that aren't doing pd-per-device seems like a bad idea, and it
wouldn't work anyway, since those devices ask for PD regardless of the
flags they see. Are you saying that what you really want is a way to use PD
with longer than /64 prefixes? Something like:

P=1 - clients should prefer PD over individual addresses, and can expect to
get a /64
N=1 - clients should prefer PD over individual addresses, but can only
expect to receive a prefix longer than /64

If N=1, what prefix would a client expect to get? Is /128 valid? Hopefully
not? How about /127 or /125?

On Wed, Jul 3, 2024 at 10:13 PM David Farmer <[e-mail]> wrote:

> No, the P flag doesn't just indicate that it is available. It also
> indicates that the network prefers PD-per-device and that it should be used
> by all devices supporting it, not just those that want to extend the
> network.
>
> P = All devices capable of using PD-per-device, tethering or not.
> E = Only devices with tethering enabled should use PD-per-device.
>
> The difference is subtle but important. It is one of the things Lorenzo
> wants the P flag to mean: there are enough prefixes to sport all devices.
>
> Thanks
>
> On Wed, Jul 3, 2024 at 2:59 PM Ted Lemon <[e-mail]> wrote:
>
>> It's my understanding that this is precisely what the 'P' flag does. What
>> am I missing? Or do you mean that we should change the behavior of DHCPv6
>> PD for devices that /aren't/ doing PD-per-host? In which case no. That
>> would be a disaster. That already works. Let's not mess with it.
>>
>> On Wed, Jul 3, 2024 at 3:11 PM David Farmer <[e-mail]> wrote:
>>
>>> Okay, if you insist, we can use an E flag instead. But I insist that
>>> there either be a flag telling hosts they can do PD-per-host and not
>>> request prefixes unless the flag is set or that hosts include a DHCPv6
>>> option indicating that they are a host doing PD-per-device to
>>> distinguish them from network infrastructure devices.
>>>
>>> The DHCPv6 option is cleaner, but either option works for me.
>>>
>>> Thanks.
>>>
>>> On Wed, Jul 3, 2024 at 1:51 PM Ted Lemon <[e-mail]> wrote:
>>>
>>>> Any DHCPv6 requirements would have to go in a -bis version of the
>>>> PD-per-device draft.
>>>>
>>>> I get that you want all these things, David, but what real operational
>>>> problem are you solving here? If a site wants to deploy PD-per-device, they
>>>> should assume that every device that connects to the network will want a
>>>> /64 prefix delegation, and plan their address pools accordingly. I don't
>>>> think updating the PD-per-device RFC is in scope for this working group, so
>>>> raising an objection that can only be addressed that way seems out of scope.
>>>>
>>>> On Wed, Jul 3, 2024 at 1:49 PM David Farmer <[e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Jul 3, 2024 at 9:52 AM Lorenzo Colitti <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Personally I think it's OK for them to fall back to SLAAC if
>>>>>> the network signals pd-per-device but is experiencing an outage or other
>>>>>> exceptional condition. IIRC Ted had other opinions (I think he wanted to
>>>>>> treat it as a configuration error) but I don't know if he felt very
>>>>>> strongly.
>>>>>>
>>>>>> That said, I don't think it's OK to design something that relies on
>>>>>> such a fallback, because that will slow down the process of connecting to
>>>>>> networks. In other words, I think it should be a configuration error for a
>>>>>> network to indicate that pd-per-device is in use, but then not hand out a
>>>>>> SLAAC-sized prefix if the device asks for one.
>>>>>>
>>>>>
>>>>> I don't like the way that is worded. We want to rely on SLAAC or
>>>>> DHCPv6 IA_NA as fallback or secondary mechanisms. However, I think I
>>>>> agree with your intent. Also, you are using negative language. Try positive
>>>>> language.
>>>>>
>>>>> I suggest something like this;
>>>>>
>>>>> The P flag indicates that the network prefers devices to use
>>>>> PD-per-device and that it should be used instead of other addressing
>>>>> mechanisms. Further, it indicates that the network intends to provide
>>>>> SLAAC-sized prefixes sufficient to meet the anticipated number of devices.
>>>>> When the anticipated number of devices is exceeded or some other exception
>>>>> occurs, the other addressing flags should be consulted for fallback: the A
>>>>> flag for SLAAC and the M flag for DHCPv6 IA_NA.
>>>>>
>>>>>
>>>>> But I agree a network should not set the P flag if it;
>>>>> 1.  Will not provide SLAAC-sized prefixes, or
>>>>> 2.  Anticipates more devices than it has prefixes for
>>>>>
>>>>>
>>>>>> FWIW, if whatever we build allows signalling something else as well
>>>>>> as pd-per-device (e.g., "PD is available, but don't expect any particular
>>>>>> prefix size"), that's fine by me. I think David already proposed a couple
>>>>>> of options, but they were a bit too complicated (one of them had three
>>>>>> flags, one of them had both flags and a DHCPv6 option).
>>>>>>
>>>>>
>>>>> I think all the other signals should be DHCPv6 Options instead of
>>>>> flags. We need a DHCPv6 Option to signal to the server that PD-per-device
>>>>> is being utilized for the request instead of classic
>>>>> network infrastructure. Devices supporting PD-per-device need to be
>>>>> REQUIRED to set this option. Servers SHOULD support the option and MUST log
>>>>> the presence of the option if it supports it. Servers MAY implement
>>>>> policies based on the option, such as different prefix pools or reserving
>>>>> prefixes for network infrastructure, which would not set the option. DHCPv6
>>>>> PD servers that don't support the option can still service
>>>>> PD-per-device requests, but they ignore the option. This must be specified
>>>>> now to ensure all devices supporting PD-per-device include the option in
>>>>> their requests to the DHCPv6 server.
>>>>>
>>>>> We need another DHCPv6 option, which should be specified separately
>>>>> and indicate whether the Client should also form a Stable or Temporary
>>>>> SLAAC address if a PIO with an A flag is present or only utilizes the
>>>>> provided IA_NA addresses.
>>>>>
>>>>> 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
>>>>> ===============================================
>>>>>
>>>>
>>>
>>> --
>>> ===============================================
>>> 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
>>> ===============================================
>>>
>>
>
> --
> ===============================================
> 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
> ===============================================
>