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

[David Farmer <[e-mail]>]

Maybe we can take another step back. We are talking about how networks and
devices negotiate with each other about addressing. You seem to be
expressing it only as an all-or-nothing question, "Can the network provide
a /64 per host for every possible host on the network?" I think it is much
more complicated than that.

I want to point out that we are creating a third host address allocation
mechanism. I think we need a more sophisticated mechanism to express how
networks would like hosts to address themselves. Some hosts will be able to
use all three mechanisms. Which should they use first, second, and third?
Other hosts can only use two of the three. Others will only have the legacy
two options. Which should they use first and second? Different networks are
going to want different orders. How does that get communicated to hosts?

Let's explore a few possible deployment scenarios;

First, a network that requires managed address assignment.

   1. Many hosts support DHCPv6 IA_NA and don't need to expand the network.
   If these hosts support IA_NA, that could greatly reduce the number of /64s
   a network might need
   2. Then, the only devices that need a /64 are those that need to expand
   the network or don't support DHCPv6 IA_NA.

Second, a network is willing to provide SLAAC but also wants to allow
on-demand expansion of the network.

   1. All hosts can do SLAAC
   2. Only hosts that want to expand the network get a /64.

Third, a network has plenty of /64 and only uses SLAAC as a backup. This
seems to be the only deployment scenario you are thinking of.

   1. Please use a /64 first
   2. Then, fall back to SLAAC

For now, I will only mention the possibility of a fourth mechanism. There
seems to be interest in DHCPv6 PD to a host without SLAAC, using longer
than /64 prefixes. This will create even more permutations.

Right now, we have two very crude ways for networks to communicate with
hosts: the M/O flags and the PIO A flag. I think the M-Flag is mostly
irrelevant. If it weren't already defined, I wouldn't define or use it, but
leaving it defined and using it or not doesn't hurt anything. However,
there are no hints for the host as to which to do first. Currently, a
network either has an A flag PIO or it doesn't. If it doesn't, it only
supports DHCPv6 clients, and if it does, DHCPv6 clients have both DHCP and
SLAAC addresses.

I've been thinking about this problem. We probably need to define multiple
new PIO Flags or find a better mechanism.

Thanks

On Tue, Jun 11, 2024 at 10:38 AM Lorenzo Colitti <lorenzo=
[e-mail]> wrote:

> David,
>
> I think you're missing an important point here: to make pd-per-device
> deployable, we don't need a way to signal that _PD is available_. We need a
> way to signal that it's _OK to ask for a /64***_. This is because:
>
>    1. Many devices already ask for /64 (e.g., CPEs).
>    2. Many networks already provide a /64 when asked (e.g., home
>    networks).
>    3. Many of these networks do not have enough space to provide a /64 to
>    every client.
>
> I think we all agree that the desired outcome on these networks is: CPEs
> will continue to get /64s, and devices that can do pd-per-device do *not*
> get /64s, because if they did, the network would run out of space.
>
> Assuming we agree on this, then how do we achieve it?
>
>    - We can't do as you suggest and define a flag that says, "PD is
>    available". By that definition, these networks should set the flag: after
>    all, PD is available, and devices will even get a /64 if they ask. But that
>    doesn't help, because if all clients ask for a /64, the network will run
>    out of space. This is a bad outcome: devices that would be OK with SLAAC,
>    like phones, might get a prefix, but devices that need a /64, like CPEs,
>    might not.
>    - We cannot say "the networks should switch to handing out /123 or /99
>    or /80", because that will break devices that need a /64.
>    - We cannot say, "the network should give /64s only to devices that
>    really need it", because there is no way for the network to know whether
>    something is a CPE that needs a /64 or a phone that is OK with just SLAAC.
>
> That's why the draft is written the way it is. To be sure, it's probably
> not the only solution. But it's likely the simplest solution that solves
> the problem and is also per-prefix (which I think we agree is necessary).
>
> I agree that there are possible deployment models where devices get
> prefixes longer than /64. But because of the above, I don't think we can
> use the same flag to signal both pd-per-device and these other possible
> deployment models. And if we have to pick between solving for pd-per-device
> and solving for these other possible deployment models, then we should pick
> pd-per-device, because that's a deployment model that is defined and
> documented by the IETF. Additionally, because these other possible
> deployment models do not create any address space issues, they can simply
> be deployed without a flag to signal them.
>
> Cheers,
> Lorenzo
>
> *** More precisely, "SLAAC-sized prefix". I'm just going to use "/64" for
> brevity.
>
> On Tue, Jun 11, 2024 at 10:06 PM David Farmer <farmer=
> [e-mail]> wrote:
>
>> One argument for the second defintion below is if the network isn't
>> willing to give out a /64, why bother with the DHCPv6 PD query?
>>
>> However, even if the network says it is willing to give out /64 or
>> shorter prefixes, you still have to make the PD request to see if the
>> DHCPv6 server has a prefix available for you. There is no guarantee a
>> prefix will be available for you or that the DHCPv6 server will not limit
>> prefix delegation to certain known devices, leaving unknown devices to use
>> SLAAC.
>>
>> So, if the PIO tells you PD is available, regardless of whether /64 is
>> part of the flag's definition, you still have to make the DHCPv6 request to
>> determine whether you will get a prefix suitable for your purposes. "No, I
>> don't have a /64 for you." Isn't that much different than, "Here is a /80
>> prefix you can't use." The result will be the same: Do SLAAC with the PIO
>> prefix.
>>
>> Now, suppose we make /64 or shorter prefixes part of the flag's
>> definition. Then do we burn a new flag for DHCPv6 PD for prefixes longer
>> than /64?
>>
>> So, I support the first definition below.
>>
>> Thanks
>>
>> On Tue, Jun 11, 2024 at 7:02 AM Ole Troan <otroan=
>> [e-mail]> wrote:
>>
>>> Jen,
>>>
>>> I think it comes down to how you view the P-flag and how that should be
>>> specified.
>>> That is up to this working group to determine.
>>>
>>> If the flag means:
>>> - “If PD capable, use the delegated prefix to assign addresses instead
>>> of SLAAC for this PIO”
>>>
>>> or if it means:
>>> - “If PD capable, use the delegated prefix to assign addresses to
>>> yourself, instead of SLAAC for this PIO,
>>>    but only if the size of the prefix is /64 or bigger.
>>>
>>> Cheers,
>>> Ole
>>>
>>>
>>> > On 11 Jun 2024, at 10:39, Jen Linkova <[e-mail]> wrote:
>>> >
>>> > Hi Ole,
>>> >
>>> > Thanks for suggesting the text.
>>> > A few comments:
>>> >
>>> > On Tue, Jun 4, 2024 at 5:09 PM Ole Troan
>>> > <otroan=[e-mail]> wrote:
>>> >> There is a simple fix to the document to achieve that I belive.
>>> >> Simply remove the following:
>>> >>
>>> >> OLD:
>>> >> "If the host does not obtain any suitable prefixes via DHCPv6 PD that
>>> >> are suitable for SLAAC, it MAY choose to disable further processing
>>> >> of the P flag on that interface, allowing the host to fall back to
>>> >> other address assignment mechanisms, such as forming addresses via
>>> >> SLAAC (if the PIO has the A flag set to 1) and/or requesting
>>> >> individual addresses via DHCPv6.
>>> >> “
>>> >> NEW:
>>> >> —
>>> >
>>> > So you are suggesting to remove 'MAY stop processing P flag'. I'm not
>>> > sure it's a good idea: this text provides optional guidance for hosts
>>> > on how to deal with DHCP-PD failures. Removing it would not prohibit
>>> > such behaviour indeed, but IMHO it's still worth mentioning it
>>> > explicitly.
>>> >
>>> >> OLD:
>>> >> "If the delegated prefix is too long to be used for SLAAC, the host
>>> >> MUST ignore it. If the prefix is shorter than required for SLAAC,
>>> >> the host SHOULD accept it, allocate one or more longer prefix
>>> >> suitable for SLAAC and use the prefixes as described below.”
>>> >> --
>>> >
>>> > This specific draft focuses on providing a mechanism to enable
>>> > pd-per-device. It doesn’t signal availability of DHCPv6 PD - the host
>>> > can discover that by sending a PD request and seeing if it gets an
>>> > answer. The flag is indicating that the network can provide a prefix
>>> > suitable for SLAAC w/o running out of space and the device can use
>>> > that prefix for SLAAC/sending downstream in PIOs etc.
>>> > As David has pointed out, we shall make it much more clear in the
>>> > abstract/introduction.
>>> >
>>> > If a device can use a long prefix (such as /120 or /80) it can just
>>> > ask for it all the time, it doesn’t need the flag - at least *this*
>>> > flag.
>>> > Therefore if we delete this text, it would basically render the flag
>>> useless.
>>> >
>>> >> OLD:
>>> >> "When a host requests a prefix via DHCPv6 PD, it MUST use the prefix
>>> >> length hint Section 18.2.4 of [RFC8415] to request a prefix that is
>>> >> short enough to form addresses via SLAAC.”
>>> >>
>>> >> NEW:
>>> >> "The host MAY indicate as a hint to the delegating
>>> >> router the size of the prefix it requires. If so, it MUST
>>> >> ask for a prefix large enough to assign one /64 for each of
>>> >> its interfaces, rounded up to the nearest nibble, and SHOULD
>>> >> be configurable to ask for more."
>>> >
>>> > That makes sense but I'd suggest a few modifications:
>>> > - replace '/64' with 'a prefix suitable for SLAAC' - we shall not be
>>> > hardcoding 64 anywhere.
>>> > - maybe we shall not be saying 'each interface' - my laptop has a
>>> > number of interfaces which might not even have IPv6 enabled or there
>>> > is no need to extend the network connectivity there (e.g. loopback).
>>> > So maybe smtj like 'to assign a prefix suitable for SLAAC to each
>>> > interface the host is extending the network connectivity to'?
>>> >
>>> > --
>>> > Cheers, Jen Linkova
>>> >
>>>
>>>
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> [e-mail]
>>> Administrative Requests:
>>> --------------------------------------------------------------------
>>>
>>
>>
>> --
>> ===============================================
>> 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
>> ===============================================
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail]
>> Administrative Requests:
>> --------------------------------------------------------------------
>>
>

-- 
===============================================
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
===============================================