IID size from a different angle (was: Re: IPv6 Routing & ND vs. Addressing)

[Nick Hilliard]

We've seen how hard it is to wordsmith the exceptions.

Brian,

the whole idea of exceptions may have hit the nail on the head.

We've spent weeks discussing hard-coding or not hardcoding /64 to no
avail, but the issue may not be as important to 4291bis as it may seem.

The reason why is that in practice, the interface ID length depends on
how the interface is configured: no-one is disputing that you can
configure a static IP address with a non-/64 prefix length. This
implies by necessity that the number 64 as an IID length is not an
intrinsic part of ipv6 addressing per-se, but a statement of defaults.

If you split interface addressing down into the different protocols
used, they are:

1. link-local: IID length defined as /64 in rfc4291, section 2.5.6
2. SLAAC: IID length defined in rfc4862
3. DHCP: dependent on SLAAC
4. static addressing: consensus this is variable
5. others (e.g. PPP defines its interface mask length in rfc5072; does
AERO define interface adddressing? Any others?)
6. future protocols

There's consensus on IID length for #1 and #4. #3 depends on #2 (dhcpv6
pulls the netmask from slaac, but if addressing is not handled in slaac,
it uses /128). Other cases (#5) seem to be defined in the individual
rfcs which describe them.

This means that the only substantive issues are SLAAC and whether future
protocols should be /64 by default or whether the prefix length needs to
be explicitly defined in the document which defines it. All the other
cases state the IID length explicitly in the documents which describe
them, with the exception of static addressing, about which there isn't
really any argument to start with.

I would suggest that future protocols need to define what makes sense
for them, and mandating a constant in advance isn't necessary or even
appropriate.

Regarding SLAAC, if there needs to be a definition that its IID size is
hard-coded at /64, then this is a discussion for 4862bis, not 4291bis.

So outside SLAAC, we're left in a situation where either there is
consensus or explicit definition in the individual protocol definitions.

Given this, I'd like to suggest that we drop the sentence from 4291bis
completely and devolve the specification for IID length down to the
individual protocols where it belongs. This may mean updating rfc4862.

Nick

[神明達哉]

At Wed, 12 Jul 2017 18:10:30 +0100,

Post by Nick Hilliard
If you split interface addressing down into the different protocols
1. link-local: IID length defined as /64 in rfc4291, section 2.5.6
2. SLAAC: IID length defined in rfc4862

No, RFC4862 doesn't define IID length. It intentionally leaves the
definition to link-specific specifications with the assumption that
those specifications are consistent with the addressing architecture.
RFC4862 intentionally and very carefully avoids being involved in the
business of defining the size of IIDs.

Post by Nick Hilliard
3. DHCP: dependent on SLAAC

I don't know what you mean here, but at least the IID length for a
DHCP-configured address has nothing to do with SLAAC. Maybe you mean
an on-link prefix that might cover the address is provided via an RA's
prefix information option. If so, it's correct (although, in theory,
this on-link prefix could also be manually configured), but that's
irrelevant to SLAAC. And, if this meant on-link prefix configuration
there's commonly seen confusion between on-link prefix and address
assignment prefix (IID length is a matter of the latter, not the
former). Maybe you want to read David Farmer's summary posted a few
days ago.

Post by Nick Hilliard
Regarding SLAAC, if there needs to be a definition that its IID size is
hard-coded at /64, then this is a discussion for 4862bis, not 4291bis.

Whether or not it should be in 4291bis, it's at least not a matter of
4862bis (see above).

Due to these confusions I'm not sure how to respond to the actual
suggestion below...

Post by Nick Hilliard
So outside SLAAC, we're left in a situation where either there is
consensus or explicit definition in the individual protocol definitions.

...but I tend to agree that the main conflict essentially only exists
in the context of SLAAC in practice. That said...

Post by Nick Hilliard
Given this, I'd like to suggest that we drop the sentence from 4291bis
completely and devolve the specification for IID length down to the
individual protocols where it belongs. This may mean updating rfc4862.

...(first off, again, it's at least not a matter of rfc4862bis) I
doubt this suggestion forms a consensus given how badly one "opposing
camp" wants to keep the hardcoded 64 number in 4291bis. Obviously
people in the other "opposing camp" aren't happy about this position,
but in terms of reaching any rough consensus with any possible
concessions, I suspect it's just not realistic to try to remove it.
Personally, I hope the other camp can accept this reality and allow the
64 to remain in 4291bis as long as any exceptions in the current
(rather than future possibilities) actual practices are clearly
admitted (like in the case of manual address configuration).

--
JINMEI, Tatuya

[Nick Hilliard]

Post by 神明達哉

Post by Nick Hilliard
If you split interface addressing down into the different protocols
1. link-local: IID length defined as /64 in rfc4291, section 2.5.6
2. SLAAC: IID length defined in rfc4862

No, RFC4862 doesn't define IID length.

apologies, my mistake; I wrote this in error and had intended to remove
it before sending the email. The fact that it doesn't define IID length
was the reason I suggested later on in the email that discussion about
IID length for SLAAC should be handled in the context of a 4862bis document.

Post by 神明達哉
It intentionally leaves the
definition to link-specific specifications with the assumption that
those specifications are consistent with the addressing architecture.
RFC4862 intentionally and very carefully avoids being involved in the
business of defining the size of IIDs.

It certainly does that, but one way or another, interface mask lengths
need to be configured on network devices which use SLAAC and the
mechanism for deciding how this should handled needs to be referenced in
rfc4862 either directly or indirectly. The current mechanism is an
indirect reference to rfc4291.

My suggestion is that IID length is not particularly an intrinsic
property of ipv6 addressing, but in practice is the specification of a
default which can be overridden on a per protocol basis, and in the case
of static addressing, actually is overridden.

It's not an intrinsic property of ipv6 because there is no specific
reason why /64 had to be chosen over, say /63 or /60. 64 was chosen
because more it related to EUI64, 8+8 and the fact that we like
byte-aligned constants. It could have been plenty of other values.
Because of this, it's not an intrinsic property of the protocol, but a
statement of policy about what this specific value should be.

Post by 神明達哉
...(first off, again, it's at least not a matter of rfc4862bis) I
doubt this suggestion forms a consensus given how badly one "opposing
camp" wants to keep the hardcoded 64 number in 4291bis. Obviously
people in the other "opposing camp" aren't happy about this position,
but in terms of reaching any rough consensus with any possible
concessions, I suspect it's just not realistic to try to remove it.
Personally, I hope the other camp can accept this reality and allow the
64 to remain in 4291bis as long as any exceptions in the current
(rather than future possibilities) actual practices are clearly
admitted (like in the case of manual address configuration).

If the statement is dropped in 4291bis and instead an explicit statement
of the mask length is added to a new revision of rfc4862, then from a
practical point of view, we will be in the same position as before which
is, I believe, what most people are concerned about: that we don't end
up breaking SLAAC or any other existing protocol.

Nick

[Lorenzo Colitti]

Post by Nick Hilliard
My suggestion is that IID length is not particularly an intrinsic
property of ipv6 addressing, but in practice is the specification of a
default which can be overridden on a per protocol basis, and in the case
of static addressing, actually is overridden.

Did you mean "should" instead of "is"? Because the IID length has been
clearly defined as being 64 bits for two decades now.

Post by Nick Hilliard
If the statement is dropped in 4291bis and instead an explicit statement

of the mask length is added to a new revision of rfc4862, then from a

Post by Nick Hilliard
practical point of view, we will be in the same position as before which
is, I believe, what most people are concerned about: that we don't end
up breaking SLAAC or any other existing protocol.

Actually, I think you'll find that the other side of this discussion is
mostly concerned about *new* protocols and network types, not existing ones.

In practice, we can't really break existing protocols anyway; even if we
were to try, implementers would just ignore us.

[神明達哉]

At Wed, 12 Jul 2017 22:37:14 +0100,

Post by Nick Hilliard

Post by 神明達哉
...(first off, again, it's at least not a matter of rfc4862bis) I
doubt this suggestion forms a consensus given how badly one "opposing
camp" wants to keep the hardcoded 64 number in 4291bis. Obviously
people in the other "opposing camp" aren't happy about this position,
but in terms of reaching any rough consensus with any possible
concessions, I suspect it's just not realistic to try to remove it.
Personally, I hope the other camp can accept this reality and allow the
64 to remain in 4291bis as long as any exceptions in the current
(rather than future possibilities) actual practices are clearly
admitted (like in the case of manual address configuration).

If the statement is dropped in 4291bis and instead an explicit statement
of the mask length is added to a new revision of rfc4862, then from a
practical point of view, we will be in the same position as before which
is, I believe, what most people are concerned about: that we don't end
up breaking SLAAC or any other existing protocol.

I don't disagree on this observation. But I don't think it a
realistic way forward for 4291bis. Unless this update to rfc4862
happens at the same time as 4291bis (which I suspect is quite
unlikely), the immediate result is just the complete drop of the magic
number from 4291bis. I can't imagine one "camp" will accept it.

As someone who is more interested in completing the task of 4291bis so
the wg can work on other important matters, it's quite clear that the
phase of suggesting something that should be right, clean, modern,
ideal, or whatever good in one camp's opinion is now over. The
history of this discussion proves it won't lead to any consensus and
we'll just waste our time, having each camp repeat their opinions
again and again with no indication of listening to the other. In my
view the only realistic next step is to figure out what they can at
least live with while giving them what they definitely can't live
without (as I said in an earlier message I still think this is
possible).

If those camps are not willing to make this kind of compromise, it's
even better to stop the 4219bis work than further time wasting. But I
suspect it would hurt more the camp that doesn't like the current 4291
text, since in that case RFC4291 will remain as the status quo.

--
JINMEI, Tatuya