Re: [IPv6] Variable IIDs

[Mark Smith <[e-mail]>]

On Sun, 5 Nov 2023, 18: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
>


Your ISP isn't giving you enough address space, and they're not the common
case either.

https://blog.apnic.net/2016/11/14/ipv6-deployment-survey-results/

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


ISPs need to realise how cheap /48s actually are.

I worked at a mainly residential ISP up until June. One of the things we
did was give all customers of any type /48s for 500K customers at the time.

There can be no errors with a single size, you don't have to spend time and
money developing systems to manage multiple sizes, you don't need to
develop an address plan that facilitates multiple sizes, nor do you have to
ever deal with a customer moving to a different size. The costs of doing
those things will far outweigh the costs of all customers having /48s.

RFC6177 doesn't say you can't give all customers /48s, it just says it
should be up to the operator, rather than the more prescritive advice in
RFC3177.

APNIC don't charge for IPv6 space if your IPv4 space has the greater cost.

APNIC also had no issue with us giving all residential customers /48s.

It didn't take much justification for APNIC to move us from the initial /32
to a /28 when we started our deployment for about 500K customers. Not long
after that they shortened again to a /27.

Regards,
Mark.



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