Re: a draft about on-link and subnet prefixes

[Alexandre Petrescu <[e-mail]>]

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.

Le 14/03/2017 à 00:14, 神明達哉 a écrit :
> 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.

    We can't require all IIDs be 64bit (for SLAAC) and rely on non-64
    on-link prefixes at times.  There is no recommendation about how to
    make that work, and intuitively it is prone to error.  An example is
    needed picturing how the dichotomy can work.

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.

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

    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.

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

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>

If one tries to bring the LL prefixes in the picture then the
perspective may change.

Let me explain why:

The LL prefix is not present in RA, there is no 'L' nor 'A' bits to
check, yet LL is "on-link" prefix and it is used to auto-configure an
Address.

So, your definition of an "on-link" prefix being "A prefix advertised in
an RA PIO with the L flag being set." is incomplete.

The right definition of an "on-link" prefix should be:
> A prefix advertised in an RA PIO with the L flag being set, or a
> prefix starting with fe81:://10.

and, similarly:
> SLAAC subnet prefix  - A prefix advertised in an RA PIO with the A
> flag being set, or a prefix starting with fe82:://10.

Further, when the draft says:
> It may also be worth noting that an SLAAC subnet prefix is not
> directly related to the "subnet prefix"

it is wrong.  It should say:
> It may also be worth noting that, with the exception of LL prefix, an
> SLAAC subnet prefix is not directly related to the "subnet prefix"
> (i.e. an LL prefix _is_ directly related to the "subnet prefix").

That goes for many other such statements.  Each should be qualified by
LL.  And if we do so, then this dichotomy may appear less obvious.
There is always this LL exception.

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

I agree with this dichotomy.  It is a tool that can be used to do
sophisticated configs in an IPv6 subnet.  Similar configs can be
achieved in IPv4 as well.  (there is equivalency between
1:1::/63   "connected" in rt and 1:1::1/64 on the iface, and
1.1.0.0/23 "connected" in rt and 1.1.0.1/24 on the iface)

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?

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.

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.

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

Also, the administrator should know that same effect (force traffic to 
the defrouter, instead of directly to neighbors) is achieved by using 
ptp links.  This also avoids ICMP Redirect, and thus permanently 
maintain this "through-defrouter" path, instead of momentarily.

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

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

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

Alex