Re: [IPv6] Variable IIDs

[Lorenzo Colitti <[e-mail]>]

But that won't happen. An ISP that gives home networks /64s is already
providing less address space than it should. IETF guidance is a /56, why
are they providing 256 times less?

If we change the minimum prefix length to /80 and all home gateways start
accepting that, then this type of ISP or just start handing out /80s to
their customers.

That's why I say - if we move away from /64, we can only do it once. We
need to pick one number (/80?) that we will never change, and say that
hosts MUST NOT accept anything other than /64 or whatever the new number
is. Let's see what +Gert Doering <[e-mail]> and +Martin Hunek
<[e-mail]> think about that, since they are the most vocal
opponents of the "must handout slaac-sized prefix" text in the PD-per
device draft.


On Sun, 5 Nov 2023, 08:57 Ted Lemon, <[e-mail]> wrote:

> Ironically, this is the best argument I’ve heard against. If isps use this
> to save on rir fees, their customers will get single /80 prefixes, and we
> won’t have gained anything.
>
> To my mind the benefit of a wider prefix is that it lets me take the /64
> my isp gives me and subnet it 65536 times, as was originally intended when
> the recommendation for customer prefix widths was 48 bits. If we don’t get
> that, there is no point in doing this work.
>
> Op zo 5 nov 2023 om 05:56 schreef 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
>>> --------------------------------------------------------------------
>>>
>> --------------------------------------------------------------------
>> 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
> --------------------------------------------------------------------
>