Re: a draft about on-link and subnet prefixes

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

At Thu, 16 Mar 2017 12:02:54 +0100,
Alexandre Petrescu <[e-mail]> wrote:

> >> 2. The explanation of the dichotomy onlink|SLAAC should be accompanied
> >>     by a recommendation of using the shortest plen of the two (even when
> >>     that plen is not 64) in the Internet routing setup towards that
> >>     subnet.  This is the crux of it.
> >
> > I'm not sure what this means.
>
> It means that in order to have distinct onlink|SLAAC prefixes one has to
> have distinct routing towards that subnet too.

I'm still not sure how to interpret it, but I guess it's related to
the discussion on cases of /64 SLLAC subnet and /80 on-link prefixes,
below.  So I'll defer it to that part.

> >  It's already covered in
> > bit more generalized text:
> >
> >    [...]  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.  On that
point RFC5942 would be a better reference.

> >> However, this dichotomy has very many consequences.
> >>
> >> A number of RFCs and I-Ds misunderstand this dichotomy "on-link"|"SLLAC"
> >> and make wrong recommendations.  Maybe you want this draft to clarify
> >> all these RFCs?
> >
> > Which RFCs are they?  I don't intend to update any existing RFCs in
> > this draft, but I could refer to those RFCs as example cases if and
> > when I revise the draft.
>
> I think of the following: RFC4887 "Home network models with NEMO" (it is
> a stretch, but HA config is impacted), RFC4903 "Multi-Link Subnet
> Issues", RFC7278 "64share", various RFCs of Proxy Mobile IP, and other
> recent Internet Drafts.

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).  Can you be more
specific about specifically which text of RFC7278 misunderstand the
separation?

> But if nobody allocates two distinct prefixes, what are the users of two
> distinct prefixes going to use?
>
> Or is it just theory?

Perhaps.  And I don't mind to see a discussion to challenge the need
for the separation in the first place in case it's really only in
theory.  I didn't intend to defend the current specification - I just
tried to make them correctly understood.

> >>>    An on-link prefix could be longer than an SLAAC subnet prefix.  For
> >>>    example, when the latter is 2001:db8:1:2::/64, the former could be
> >>>    2001:db8:1:2:3:4::/80.
> >>
> >> I agree it could be.
> >>
> >> But in this case, one also must make sure the routing towards that
> >> subnet is the SLAAC's /64 (not the 'onlink's /80).
> >
> > I don't see why.
>
> Because if the routing is not towards the SLAAC's /64 then the following
> bad situation may occur:
>
> A computer configures an address with SLAAC /64, address that is
> actually found on another subnet.  At that point, neighbors in that
> other subnet will not be able to reach this computer - their ND process
> fails and they dont ask their default router.
>
> In this sense the computer in question forms an address that is actually
> not allowed to use, because there is no routing to it.
>
> On another hand, if the routing towards our subnet where this computer
> is found is the /64 then the situation is better.
>
>                                onlink /80
>    Router  -----------Router -------------- Computer
>    /64 in rt            |       SLAAC /64
>                         |
>                         |
>                         +----------(another subnet) ----Neighbor1
>                                                       |
>                                                       +-Neighbor2

In such a case, the admin should not advertise the /80 on-link prefix
in the first place.  If all hosts under a /64 are expected to
communicate directly, the admin should advertise that /64 also as an
on-link prefix (in the above diagram we'd also need something other
fancy stuff like multi-link subnet, ND-proxy, etc, but that's a
different matter).  It's just that using different on-link and SLAAC
subnet prefixes may not meet a particular operational requirement -
it's the admin's responsibility to choose the right tool and configure
it correctly.

> >> In this case, one also must make sure the routing towards that subnet is
> >> the onlink's /48, and not the SLAAC's /64.
> >
> > Implementation specifics (whether it's implemented as a "route") aside,
> > an RFC4861-compliant host implementation should already do so.
>
> What I am asking stems not from implementation specifics (implemented as
> route, or otherwise), but stems from bidirectional reachability
> requirements.
>
> The draft currently talks exclusively what happens on a link, in a
> subnet.  But it misses to tell that whatever happens on a link, or in a
> subnet, must ensure bidirectional rechability to and from the Internet.

This is vague and I'm still not sure if I really understand it.  But,
if you mean that a site using a /48 on-link subnet should advertise
that /48 prefix via a routing protocol or something outside of the
site, then that's correct.  But, to me, that's a totally different
topic.

--
JINMEI, Tatuya