Re: [IPv6] Variable IIDs

[Brian E Carpenter <[e-mail]>]

On 05-Nov-23 17:20, Mark Smith wrote:
> Hi,
> 
> What problem is this trying to solve? Is the IPv6 address space running out?

No. But that is not the only reason we might want classless addressing throughout the address. And in response to your point about teachability, anyone who reads the addressing architecture comes to that bit about

~~~
different addresses may have different values for
    n:

    |          n bits               |           128-n bits            |
    +-------------------------------+---------------------------------+
    |       subnet prefix           |           interface ID          |
    +-------------------------------+---------------------------------+
~~~

and thinks "that's nice". And then on the next page, this vanishes
and n==64 for ever. Very confusing.
> 
> 
> IPv4's original address format was nice and simple - N.H.H.H - see RFC 760.

And broken. The variable "n" above was introduced to fix that.

     Brian

> 
> Network numbers were running out, so IPv4 address classes were introduced in RFC 791.
> 
> Then classes weren't efficient enough (for some people Class C was too small yet Class B was too big) so subnets were introduced in RFC 950.
> 
> Then VLSM, and then CIDR.
> 
> When you've had to teach IPv4 addressing enough times, and all of the above complexity, the struggle to explain it, and the struggle for people to get it right, you eventually ask the question, "Why is this so complex?" and "Why would anybody design something so complex on purpose?"
> 
> Well they didn't, as can be seen from RFC 760 and its ancestors. Classes, subnets, VLSM and CIDR are all work arounds to the original RFC 760 N.H.H.H format not being big enough.
> 
> 
> So if variable length subnets/IIDs are now required in IPv6, is that saying we're at a similar point of IPv6 address space exhaustion that occurred between RFC 760 and RFC 791 for IPv4, and we now have to introduce similar addressing complexity into IPv6 addresses to conserve them?
> 
> Regards,
> Mark.
> 
> 
> On Sat, 4 Nov 2023, 13:06 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 <https://www.ietf.org/mailman/listinfo/ipv6>
>     --------------------------------------------------------------------
>