Subject: distinction between on-link and subnet prefix for rfc4291bis

From: 神明達哉 <[email-masked]>
Date: Tue, 28 Mar 2017 09:23:41 -0700

On seeing a discussion about this issue at the IEPG meeting,
http://iepg.org/2017-03-27-ietf98/JobSnijders_IPv6_prefix_length_IEPG_Chicago_2017.pdf
it occurred to me that the distinction between on-link and subnet
prefixes may help the "/64" discussion for rfc4291bis.

The presentation shows an example of manual interface configuration on
page 4 of http://iepg.org/2017-03-27-ietf98/JobSnijders_IPv6_prefix_length_IEPG_Chicago_2017.pdf

$ sudo ip -6 addr add 2001:728:1808:1::21/126 dev eth1

as a counter example in the real world operation against the /64
requirement of rfc4291bis:

   [...]  However, the Interface ID of
   all unicast addresses, except those that start with the binary value
   000, is required to be 64 bits long.
(this logically means the subnet prefix is required to be 64 bits long).

Actually, with the distinction between on-link and subnet prefixes,
these can coexist.  The above ip command is actually a short cut of
the following:
- configure a 128-bit IPv6 address (whose IID is 64 bits long)
- configure a /128 on-link prefix (that happens to cover the
  configured address) for that link

In my own draft (draft-jinmei-6man-prefix-clarify-00) I explained it's
already completely valid within the spec of ND and SLAAC: we could
advertise a /126 PIO with L=1, and it doesn't violate the IID
requirement of rfc4291bis (as it's an on-link prefix).  And, we could
have the host configure an IPv6 address that happens to match the /126
prefix via DHCPv6.  The end result is exactly the same as above.

"Architecturally," the configured address is still considered to have
a 64-bit IID, '0:0:0:21', but in practice it shouldn't matter for
operators - the host do not consider addresses to be on-link (and so
not perform ND, for example) unless the address matches the 126-bit
on-link prefix.  After all, that's what the operator using /126 wants,
right?

In the case of manual configuration like the above example of ip
command, it may be still moot as there's no protocol specification
about manually configuring on-link prefixes (and standard protocol
doesn't talk much about manual address configuration).  But I believe
the concept for the ND and SLAAC can be quite reasonably extended to
such cases.

If we can agree on this interpretation, I guess it's easy to resolve
the rfc4291bis row.  Operators who like non /64 prefixes won't have to
be too sensitive about the length of IID, since it doesn't matter for
them in practice.  We might even keep the current text of rfc4291bis,
but it might help if it could also mention the distinction of
(generalized sense of) on-link and subnet prefixes.

One thing I'm not sure is whether this is acceptable to those who want
to keep the hardcoded 64-bit IID length.  If the important part of
this spec for those people is to prevent operators from using
narrower on-link prefixes such as /126 when the IID length is 64 bits
long, then this proposed resolution won't work for them.  If that was
the case, please just ignore this message - I just wanted to help find
a way forward, not intending to add more fuel to the heated debate.

--
JINMEI, Tatuya

---

From: Erik Kline <[email-masked]>
Date: Tue, 28 Mar 2017 09:29:04 -0700

> (generalized sense of) on-link and subnet prefixes.

"it doesn't matter for them in practice": exactly.

I really do not think there was ever any real problem here.  Just (a)
misinterpretations/miunderstandings and (b) people who want to do SLAAC on
/65s, /80s, and so on.

---

From: Job Snijders <[email-masked]>
Date: Tue, 28 Mar 2017 11:52:35 -0500

On Tue, Mar 28, 2017 at 09:29:04AM -0700, Erik Kline wrote:
> > the rfc4291bis row.  Operators who like non /64 prefixes won't have
> > to be too sensitive about the length of IID, since it doesn't matter
> > for them in practice.  We might even keep the current text of
> > rfc4291bis, but it might help if it could also mention the
> > distinction of (generalized sense of) on-link and subnet prefixes.
> 
> misinterpretations/miunderstandings and (b) people who want to do
> SLAAC on /65s, /80s, and so on.

I think (a) is a problem that needs to be addressed.

Kind regards,

Job