Re: a draft about on-link and subnet prefixes

[Alexandre Petrescu <[e-mail]>]

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

The explanation may be better if it also illustrated some of the 
side-effects.  One side-effect of using distinct on-link|SLAAC prefixes 
is that the routing towards that subnet has a particular plen.

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

Ok, this is good to know.

It is the most important point why I got in this discussion.

So, it is not because the onlink|SLAAC prefixes may be distinct that the 
4291 would recommend 64bit IIDs.  There may be other reason.

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

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

Ok

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

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

Noted.

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

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

But if nobody allocates two distinct prefixes, what are the users of two 
distinct prefixes going to use?

Or is it just theory?

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

Well... ok.

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

Ok.

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


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

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.

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

Ok, noted.

Alex