Re: a draft about on-link and subnet prefixes

[神明達哉 <[e-mail]>]

At Fri, 17 Mar 2017 14:34:35 +0100,
Alexandre Petrescu <[e-mail]> wrote:

> >>> [...]  This means that, for example, if the length of interface
> >>> identifiers for the link is specified as 63, 64, or 65, then the
> >>>  SLAAC subnet prefix length must be 65, 64, or 63, respectively;
> >>>  otherwise the PIO is ignored for the purpose of SLAAC.
> >>
> >> But this text does not say what is the plen of routes towards that
> >>  subnet.
> >
> > If "routes towards that subnet" means the SLAAC subnet prefix is to
> > be considered on-link, that's not what the current specs allow.
>
> By "routes towards that subnet" I mean the entries in a routing table of
> a Router that is in the path from the Internet towards that link.

I now understand you're more concerned about those configuration
matters.  But I have to say that's out of scope of my draft.  It
basically talks about host behaviors regarding on-link and subnet
prefixes.  You may not like the scope, but I have no plan to broaden
it to that direction (I basically want to keep it focused).  If you
think that's an important topic, my last word on that point in this
thread is this famous phrase: feel free to write your own draft on
that topic.  (Below I'm basically skipping points relevant to this
particular point.)

> > I just took a quick look at RFC7278 (just as an example), but I
> > don't find anything obvious in it that misunderstands the separation
> > of on-link and SLAAC subnet prefixes (it certainly does something
> > awkward if not non-compliant, like re-advertising a prefix learned
> > from a 3GPP interface to a LAN interface, but such oddity is
> > irrelevant to the separation of on-link and SLAAC subnet prefixes).
>
> I agree.
>
> I would say that using 64share is incompatible with the capability of
> providing separation between onlink and SLAAC prefixes.  A prefix that
> is '64shared' can not be further separated into 'onlink' and a 'SLAAC'
> prefix.
>
> Whereas a /63 prefix (not a 64shared prefix) could be divided into a /64
> prefix for SLAAC, and another /64 for onlink determination.
>
> Moreover, a prefix allocated with DHCPv6-PD could be divided into a
> prefix for SLAAC and another for onlink determination.

I don't see how this is relevant to this draft.

> > Can you be more specific about specifically which text of RFC7278
> > misunderstand the separation?
>
> For example this from RFC7278:
> > The LAN link is configured as a /64 and the 3GPP radio interface is
> > configured as a /128.

This behavior (using an RA on an interface/link than the received one,
re-advertising a received RA on the other link) itself is already
quite peculiar, but I still don't see confusion between on-link and
SLAAC subnet prefixes here.

> Which one of those two prefixes is the on-link and which is the SLAAC?
> Maybe neither?

Ignoring the peculiarity, the UE performs SLAAC with the received /64
prefix and generates a 128-bit IPv6 address
2001:db8:ac10:f002:1234:4567:0:9.  So this /64 is an SLAAC subnet
prefix.  The /128 notation simply means it's a 128-bit IPv6 address.
When re-advertising the /64 to the LAN interface, while it's not
really clear from the RFC text itself, but I guess it usually has both
the L and A flags set, so they would be used both as an SLAAC subnet
and on-link prefixes.

> Another example is this:
> > The gateway routes the entire /64 to the UE and does not perform ND
> > or Neighbor Unreachability Detection (NUD) [RFC4861].
>
> What kind of prefix is that for which there is neither NUD nor ND
> overall, yet an address is formed on the interface?  Is it SLAAC?  Is it
> onlink?  Is it neither?

neither.

> _If_ we said that the dichotomy onlink|SLAAC was the possibility to have
> /48 as onlink and /60 as SLAAC, then the people making routes would take
> the smallest (/48) and make a /48 route towards the subnet.
>
> That comes down to the following paragraph in your draft:
> > If a link-type specification defines the interface identifier length
> > to be 64 bits, the SLAAC subnet prefix must be 128 - 64 = 64 bits.
>
> should rather say "the SLAAC subnet prefix could be for example 63bit".

It couldn't, unless we update RFC4862 as such.  I don't even
understand how the external route setup affects the length of
interface identifiers, but even if there's some sensible explanation
of it, that doesn't change the fact that RFC4862 doesn't allow an
SLAAC subnet prefix to be other than 64 when the length of IID is 64.
If you don't like the current protocol limitation, that's fine -
please write a new proposal to update RFC4862.  But that's out of
scope of this draft: it only explains what's current specified without
stating that's good or bad.

--
JINMEI, Tatuya