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

[Brian E Carpenter <[e-mail]>]

Very much +1 to David's message. With only two choices, we've done all right with the rule that all hosts MUST support SLAAC and the rather vaguely defined M flag. With three choices, we need something better.

Regards
    Brian

On 13-Jun-24 03:22, David Farmer wrote:
> 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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
>             Administrative Requests:
>             --------------------------------------------------------------------
> 
> 
> 
>         -- 
>         ===============================================
>         David Farmer Email:[e-mail] <mailto:[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] <mailto:[e-mail]>
>         Administrative Requests:
>         --------------------------------------------------------------------
> 
> 
> 
> -- 
> ===============================================
> David Farmer Email:[e-mail] <mailto:[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:
> --------------------------------------------------------------------