Re: [IPv6] Variable IIDs

[Martin Huněk <[e-mail]>]

Hi Lorenzo,

Dne sobota 4. listopadu 2023 13:00:10 CET, Lorenzo Colitti napsal(a):
> 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.
> 
> 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.

So, do I understand it correctly that you are actually saying It is OK to force your ideas and design choices by a "substantial percentage of devices" onto other people's networks? I would call it taking network administrators hostages. Not OK at all. It negatively impacted our network at the university, and I'm not happy about it.

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

Yeah, there might be some operators that would decrease assignment size, sure. But those reasonable would still maintain /56s, at least for legacy hosts' reasons. At the ISP I'm working for, we give /56 for residential and /48 for business clients (or residential after request when there is a technical reason for it). I'm not planning to change that.

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

Not really. In my case, it is not desirable to extend our university network by any host without approval. This is due to the network policy based on local law. So, I would gladly provide any device with a prefix that would not allow network extension, but I cannot allow /64 PDs, so the host could become routers easily.

This is a special case of the network whose policy does not allow network extension, and all users had to agree with a policy before joining. Not even an IETF document should force any network to allow such an extension if it is forbidden by network policy, much less any OS vendor engineer.

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

We do it because we must. We are required to do so by law. We are required to be able to identify any user connected to our network by IP + port and keep those records for 6 months. So it is either IEEE 802.1x or WPAx-EAP on the border of a network with user identity (and not allowing to extend the network). Or to do DPI to extract the user identity from its traffic. I would not want to do the latter as it is more intrusive.

Stop playing God, the ultimate arbiter of good/bad, and pretend that all you do is in the best interest of your user. We all know that this is hardly the case. Network policy is made by the organization running the network, by the law of the country it is running in, and enforced by the network administrator. There is no place for OS vendors to decide if it is good or bad practice and if it should or should not be done. In the same way, I, as a network administrator, have no place in what law should be obeyed.
> 
> 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.

Personally, I have no preference considering this idea. It was your idea of "draft-ietf-v6ops-dhcp-pd-per-device" that is causing the pressure on addressing architecture to accommodate it. Variable IID length doesn't necessarily mean only SLAAC, as it could also mean local address generation in the host itself (from the PD prefix - for example). Then it would make sense. For an SLAAC, it would take several years until all the legacy hosts and routers would disappear, and we could see the results. It would be far more practical to mandate DHCPv6 IA_NA support for all OS vendors that claim IPv6 support.

Regards,
Martin
> 
> 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
> > --------------------------------------------------------------------
> >
>