Re: [IPv6] Variable IIDs

["Philipp S. Tiesel" <[e-mail]>]

Hi Mark, 

i guess you ask the right question … the original problem for prefix per host was that we have two camps here in the WG both want IPv6 to replace IPv4 rather sooner than later  but have conflicting interests:

- Enterprise people that have one (or hundreds) of address plans that settled with a /64 per link and have a safety margin of factor 4 to 100 based of that
- People that see ISPs handing out the bare minimum prefix size and killing use-cases that need a bunch of addresses per node.

While the first camp sees that a /64 per host blows up every of their existing IPv6 deployments (unless they stay with SLAAC), the other fears a race to the bottom if we make any prefix smaller than a /64 practically useable.

If we just focus on these two arguments, we could easily settle with a /80 for a physical host and stop the race to the bottom right there.

Given the above, why should we still standardise smaller IIDs? 
Because we want to be able to use parts of your /64 or /80 on a virtual network inside your physical host and have SLAAC work there. Here, we are not dealing with abandoned IoT-devices we need to support, but stuff to come once we got sufficient IP address space to physical hosts.  

> On 7. Nov 2023, at 01:20, Mark Smith <[e-mail]> wrote:
> 
> If the problem to be solved is some people handing out a single /64s, because a /64 is the smallest unit they can hand out, I don't think /80s (48 bit IIDs) will solve that problem.
> 
> It'll just mean their new single smallest unit to hand out will be become a /80, because it is consistent with their "hand out the smallest unit" mindset.
> 
> Those people are stuck in "IPv4 addresses are precious, so we need to be conservative with IPv6 addresses too.", because they don't know any better (and haven't experienced IPv4 when it wasn't precious, or any other layer 3 protocols like IPX, CLNS etc. that also didn't have a layer 3 addressing preciousness problem.)
> 
> If they have that mindset then they don't at all understand the fundamental problem IPv6 is trying to solve - many orders of magnitude more IP address space - and that IPv6 addresses are not precious resources. (We of course need to be mindful about how we use them, however we don't have to optimise for their scarcity.)
> 
> You don't change people's minds by  accommodating and endorsing their beliefs, which is what I think /80s would be perceived to be doing, you educate and inform them that we don't have to be conservative with IPv6 addressing like we have needed to be with IPv4 since the mid-1990s.
> 
> More technology isn't always the best and right solution. 
> 
> I'm not sure about other RIRs, however APNIC are running lots of training courses including ones on IPv6.
> 
> As developers of the technologies the IETF could also organise training on new technologies, or it could be something that ISOC as the parent body of the IETF could organise or sponsor.
> 
> Regards,
> Mark.
> 
> 
> On Tue, 7 Nov 2023, 04:00 David Farmer, <farmer=[e-mail] <mailto:[e-mail]>> wrote:
>> I agree with Lorenzo. It isn't a good idea to allow IIDs shorter than 48 bits, but a variable length between 64 and 48 bits would be acceptable.
>> 
>> I prefer two new one-bit PIO flags from Reserved1. Call the first one the V-flag. It would be similar to the A-flag, which would be left unchanged for backward compatibility, and support remains REQUIRED. However, the V-flag would allow a variable IID length for SLAAC between 64 and 48 bits for new nodes supporting this capability. The other is the I-flag, which can be used with the A-flag to tell new nodes supporting this capability not to generate an address for the A-flag and presumably use another PIO with the V-flag instead. Support for the V and I flags would be RECOMMENDED.
>> 
>> - A /64 PIO with only the A-flag, or both the A and V flags, both new and old nodes generate an address.
>> 
>> - A /64 PIO with both the A-flag and the I-flag, only old nodes generate an address.
>> 
>> - A /65 to /80 PIO with the V-flag, only new nodes generate an address. If the A-flag were set, it would be ignored.
>> 
>> - If the I-flag is set on a /64 PIO without the A-flag or a PIO of any other length, it is ignored.
>> 
>> - If you added L=0, you could have a /65 to /80 PIO with the V=1 and L=0 and an overlapping /64 PIO with the A=1, I=1, and L=0 without needing ND-Proxy.
>> 
>> Otherwise, overlapping PIOs would require ND-Proxy support in the routers.
>> 
>> Just my 2 cents.
>> 
>> On Fri, Nov 3, 2023 at 9:06 PM Brian E Carpenter <[e-mail] <mailto:[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] <mailto:[e-mail]>
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> 
>> --
>> ===============================================
>> David Farmer               Email:[e-mail] <mailto:[e-mail]>
>> Networking & Telecommunication Services
>> Office of Information Technology
>> University of Minnesota   
>> 2218 University Ave SE        Phone: [phone]
>> Minneapolis, MN 55414-3029   Cell: 612-812-9952
>> ===============================================
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> [e-mail] <mailto:[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
> --------------------------------------------------------------------



AVE!
   Philipp S. Tiesel

--  
Philipp S. Tiesel
https://philipp.tiesel.net/