Re: [IPv6] Variable IIDs

[Alexandre Petrescu <[e-mail]>]

Le 04/11/2023 à 13:00, Lorenzo Colitti a écrit :
> Brian,
>
> If we think /64 is too large, then I think it's OK to change 64 to 
> something else. But making the IID length variable is the wrong 
> solution. If we do that, we will create a race to the bottom that ends 
> up at /128.
>
> Here's why. Today SLAAC only works on a /64, and a /64 guarantees that 
> there will always be enough address space to number unlimited devices. 
> Pretty much every network operator uses that because it's the only 
> thing that works on all devices. Some operators insist on assigning 
> only a /128 to each device using DHCPv6. This is for various reasons, 
> most notably consistency with IPv4, the fact that DHCP clients and 
> servers by default only assign one address, scalability of network 
> entities such as ND caches, desire to charge for more addresses (yes; 
> as the lead of a major OS network stack, we get this depressingly 
> often). It's pretty clear from any reading of RFC 7934 that that is 
> harmful, but those operators don't know or want to do it anyway. 
> Fortunately (well, unfortunately for those operators), this doesn't 
> work on a substantial percentage of devices due to lack of support for 
> DHCPv6, so it's not really a practical solution on most networks. 
> Those operators occasionally complain about OSes that don't support 
> DHCPv6, but on the whole we're generally in a situation where devices 
> can get as many IP addresses as they need, within reason.
>
> However: if we define SLAAC to variable length, as you are proposing 
> here then those operators will pick the minimum length accepted by 
> implementations. Today that's /64. If implementations change to accept 
> fewer addresses (say, /80), then those networks will move to providing 
> the new minimum. And so on. This starts a race to the bottom that ends 
> at /128. If you don't believe this, consider: many residential ISPs 
> provide a reasonably-sized subnet to users, such as a /56. But some 
> provide only a /60. Some - like mine! - only provide a /64. In my case 
> I could only get a /56 by signing up for the business offering, which 
> costs 3 times as much. Now, obviously this example is about prefix 
> sizes, but if we make SLAAC variable, you can bet that operators will 
> do this within subnets as well. Consider even during the v6ops 
> discussion of draft-ietf-v6ops-dhcp-pd-per-device, some participants 
> (Martin, I remember) asserted that the subnet must be made small 
> enough to prohibit devices from extending the network.
>
> Note, I am not saying that most or even many networks will do this. 
> But some will.

Thanks for the description.

We (co-authors of an individual proposal draft) have tried to understand 
you and we agree with you at some points.

Further,  we tried to describe the problem like this:

>   The "race to the bottom problem" - is the problem where allowing
>     prefixes longer than 64 to be used in SLAAC will lead to 65, 66 and
>     so on, up to 127 and 128 allocations.  At that point the bottom would
>     be reached and thus impossible to extend the network further.

Hopefully it is a problem that can be described.

Alex


> The consequence of that is that OS vendors like ours will act in their 
> users' interests, and allow those users to evade those restrictions by 
> implementing NAT66. At that point everybody loses. The networks don't 
> get paid more. App developers have to implement NAT traversal and 
> keepalives. OS vendors have to implement hardware offload APIs for 
> keepalives. Users have to deal with lower battery life and brittle 
> apps due to NAT timeouts.
>
> Why do this? If we really think /64 is too wasteful, then we can 
> change it, once. But we can't make it variable without creating a race 
> to the bottom. The only way to do that is to pick one size.
>
> Cheers,
> Lorenzo
>
> On Sat, Nov 4, 2023 at 2:06 AM Brian E Carpenter 
> <[e-mail]> wrote:
>
>     If anyone wants to turn this into an I-D, please feel free.
>
>     title: Variable Length Interface Identifiers
>     abbrev: Variable IIDs
>     docname: draft-tbd-6man-variable-iids-00
>
>     # Introduction
>
>     The lowest common denominator method of configuration for IPv6
>     nodes is SLAAC {{!RFC4862}}, which is carefully designed to allow
>     any prefix length and any interface identifier (IID) length,
>     provided that they do not total more than 128 bits. Until now,
>     specifications of "IPv6 over foo" mappings, starting with
>     {{!RFC2464}}, have specified an IID length of 64 bits, consistent
>     with the value specified by {{!RFC4291}}.
>
>     This document allows a router to announce an IID length other than
>     64 on a given link, and updates RFC 4291, RFC 2464 (and numerous
>     other "IPv6 over foo" documents TBD), and RFC 4862 accordingly. It
>     extends {{!RFC4861}} by defining a new "IID length" mechanism in
>     RA messages.
>
>     Terminology: a "modified" host or router supports this spec. An
>     "unmodified" host or router supports RFC 4861 and 4862 precisely.
>
>     # Modified procedures
>
>     The predefined IID length specified by RFC 4291, RFC 2464, etc. is
>     used to configure the link-local IPv6 address of a node exactly as
>     described in RFC 4862.
>
>     On a link where variable IID length is not supported, the
>     predefined IID length will continue to be used to configure all
>     other addresses using SLAAC.
>
>     On a link where variable IID length is supported, each modified
>     router will include an "IID length" indication in every RA/PIO
>     message with the A bit set. This will override the value defined
>     in RFC 2464 (etc.) and in RFC 4291, for the prefix concerned.
>
>     Suggestion: put the IID length in 6 bits of the Reserved2 field of
>     the PIO. 0b000000 would mean 64, i.e. no change and backwards
>     compatible. Any other value would define an IID length in bits.
>     Values less than 48 (0b110000) are NOT RECOMMENDED. Values greater
>     than 64 are impossible.
>
>     (Note: Reserved1 is not available - see {{?RFC8425}}.)
>
>     When a modified node receives an "IID length" less than 64, it
>     will use that value instead of the default for all unicast address
>     autoconfiguration under that prefix, except link-local.
>
>     # Deployment issues
>
>       - Unmodified hosts and unmodified routers: no change, all use
>     64-bit IIDs.
>
>       - Modified hosts and unmodified routers: no change, all use
>     64-bit IIDs.
>
>       - Modified hosts and modified routers: configure to use longer
>     prefixes and shorter IIDs if desired.
>
>       - Modified routers and mixture of modified and unmodified hosts
>     on a link:
>
>         - The modified hosts will use a shorter IID and longer prefix
>     if that is announced.
>
>         - The unmodified hosts, according to RFC 4861, MUST ignore the
>     Reserved1 field. So, according to section 5.5.3 clause d) of RFC
>     4862, they will ignore any PIO advertising a shorter IID.
>     Therefore, the operator has two choices:
>
>           1. Decide that unmodified hosts will not be supported (i.e.
>     will not be able to configure an address using SLAAC).
>
>           2. Announce (at least) two prefixes on the link - a /64 and
>     a longer one, with a shorter IID. For that to make sense, we need
>     an extra rule for modified hosts: if a host receives several PIOs
>     from the same router, it prefers all those with the shortest IID
>     and ignores the others.
>
>       - Mixture of modified and unmodified routers on a link: don't do
>     that!
>
>     # IANA Considerations
>
>     Maybe a registry for the Reserved2 field, like RFC 8425?
>
>     # Security Considerations
>
>     Nothing new?
>
>
>     --------------------------------------------------------------------
>     IETF IPv6 working group mailing list
>     [e-mail]
>     Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>     --------------------------------------------------------------------
>
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------