Re: [IPv6] Variable IIDs

[Ted Lemon <[e-mail]>]

There are a fair few home gateways that implement ipv6 badly, and that are
provided by isps. We can’t assume that isps will behave sensibly: even if
they mean well, which I suspect is the case in the situation I’m aware of,
they can still misunderstand.

We could, in 7084bis, say that a prefix delegation with a mask wider than
some limit MUST NOT be used, or something, but I wonder how much arguing
that would involve…

Op zo 5 nov 2023 om 10:13 schreef 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
>> --------------------------------------------------------------------
>>
>