Re: [IPv6] Variable IIDs

[Lorenzo Colitti <[e-mail]>]

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