Re: [IPv6] Variable IIDs

[Mark Smith <[e-mail]>]

On Sat, 4 Nov 2023, 23:00 Lorenzo Colitti, <lorenzo=
[e-mail]> wrote:

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

I think one of the incentives to do this will be RIR fees.

Internet service is obviously a commodity, which means there are strong
incentives to reduce costs if possible, in particular for residential
Internet services.

So if an ISP can get their minimum assignment of an /32, and then subdivide
with IIDs smaller than 64 bits to fit all of their customers within that
single /32, that's I'm confident that's what many will do to avoid paying
RIR fees for shorter prefixes to suit /64 subnets/64 bit IIDs for their
customer base.

The larger the ISP, the greater the incentive to do this, because the
savings from only using a /32 for all customers will be greater.

Regards,
Mark.





> 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
>> --------------------------------------------------------------------
>>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>