Re: a draft about on-link and subnet prefixes

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

At Tue, 14 Mar 2017 09:47:49 +0100,
Alexandre Petrescu <[e-mail]> wrote:

> I suggest adding the following upfront:
>
> "The onlink|SLAAC dichotomy MAY be applied; if it is applied, then the
>   routing towards that subnet MUST use the shortest plen of the two"
>
> E.g. if the on-link prefix is 48 and the SLAAC prefix is 64 then the 48
> (not the 64) must be in the rt tables of routers with routes towards
> that subnet.

Thanks for the feedback.  I'm not sure how to interpret this, but in
any event, adding a new MAY or MUST is clearly out of scope of this
draft.  It only intends to explain what the current specifications try
to specify in case it may no be very clear.

> > I've submitted a new individual draft on the separation between
> > on-link and (SLAAC) subnet prefixes, at the risk of stating the
> > obvious:
> > https://datatracker.ietf.org/doc/draft-jinmei-6man-prefix-clarify/
>
> I have read the draft.  It was a good read, thank you.  It clarifies the
> difference between on-link prefixes and SLAAC prefixes.
>
> Here are my comments in summary:
>
> 1. It does not resolve the question of whether or not the 64bit IID
>     should be required in the IPv6 Addressing Architecture.

No it doesn't, and it's intentional.

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

>     This recommendation should acknowledge that when that plen is larger
>     than 64, SLAAC/Ethernet can not work.

There's no recommendation in this draft; it only talks about facts.
Anyway, it's true that if (SLAAC subnet) plen is larger (or shorter)
than 64 SLAAC over Ethernet does not work.  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.

>     This recommendation should acknowledge that when that plen is smaller
>     than 64, SLAAC/Ethernet can work by using 64 for SLAAC and plen for
>     on-link determination.

I'm not sure what this means.  But, as long as the current
specifications go, SLAAC doesn't work on Ethernet if the subnet prefix
is smaller (or larger for that matter) than 64.  If you are trying to
propose loosening it, that's fine - please write a proposal in a
separate draft.  But that's out of scope of this draft, which only
talks about what current standards state.

> 3. The draft would benefit from dealing with LL addresses too.

Perhaps, but I intentionally made it more focused to avoid
distraction, at least for the 00 version.

> Details below:
>
> > Although this misunderstanding would normally not cause troubles in
> > practical deployments, it can be a source of operational surprise or
> >  interoperability problems once an administrator wants to exploit the
> >  idea of this separation more "creatively".
>
> This needs the administrator to have ability to set distinct routes
> towards presumably distinct 'on-link' and SLAAC prefixes.
>
> > For brevity, this document focuses on global unicast prefixes.
> > Discussions on any other types of prefixes, including unicast link-
> > local prefixes, are out of scope of this document.
>
> <LL>

I'll skip any LL-specific discussion to avoid distraction.  If and
when we see the need to cover this topic within this draft, I'll come
back to these points.

> </LL>
>
> > [RFC4861] and [RFC4862] intentionally separate the concept and
> > handling of on-link prefixes and SLAAC subnet prefixes, even when
> > they are specified in the same single PIO.
[...]
> 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.

> One of the worst consequence is the allocation of single /64 prefix for
> an end user.  Many drafts and their respective deployments only give a
> /64 to the end user: it is used both for SLAAC _and_ for on-link
> determination.  If they agreed the dichotomy then they would give at
> least two distinct prefixes to the end-user: one for SLAAC and one for
> on-link determination.

Perhaps, but such a discussion is out of scope of this draft.

> Another consequence is the possibility to make wrong configurations.
>
> A wrong configuration is the following: in a subnet where plen1 is for
> on-link determination and plen2 is for SLAAC, it is easily possible to
> make a Host believe a Neighbor is on-link whereas the routing system to
> which that subnet is connected routes to another subnet for same Neighbor.
>
> If somebody plays too much with this plen1 and plen2 configurations
> (onlink|SLAAC) on a subnet one can easily make mistakes.  There is no
> recommendation how to avoid these mistakes.
>
> Recommendations about how to play with this onlink|SLAAC dichotomy will
> need to take into account how routing is based on longest-prefix match.
>
> Also these recommendations must make sure that allocating a
> single /64 to an end user does not get into widespread use.

Ditto.

> > Perhaps the administrator of the link wanted to force most of on-link
> > communication to 2001:db8:1:2::/64 to be first sent to a default
> > router, while allowing a particular set of hosts (those using the
> > address that match the on-link prefix) to communicate directly.
>
> I agree with the use-case.
>
> But maybe the administrator should know too that the default router will
> reply back with an ICMP Redirect leading to an end result where the
> on-link prefix is same as the SLAAC prefix in the rt table.

Yes (although the admin would disable sending redirects if this is
really the operation they want and their router supports the knob),
that's why the draft says "first sent to a default router".  Anyway,
as admitted this is an imaginary use case.  I didn't intend to insist
that's necessarily realistic.

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

> >    An on-link prefix could also be shorter than an SLAAC subnet prefix.
> >    For example, when the latter is 2001:db8:1:2::/64, the former could
> >    be 2001:db8:1::/48.
>
> I agree it could be.
>
> 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.

> Lacking of saying so leads to the undesirable situation of operators
> allocating a /64 for a ptp link.
>
> To combine the two, a recommendation would be:
>
> "The onlink|SLAAC dichotomy may be applied only if the routing towards
>   that subnet uses the shortest plen of the two; that could be a value
> less than 64."

(Aside from whether this makes sense or not) again, there's no
recommendation in this draft.  It only explains what current protocol
specifications state, just more explicitly.

--
JINMEI, Tatuya