Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis

[Alexandre Petrescu <[e-mail]>]

Le 11/03/2017 à 09:57, [e-mail] a écrit :
> Jinmei,
>
> Is there anything here that isn't covered by 5942?
>
> And creating an artificial separation of prefixes used for address
> assignment (SLAAC) and prefixes used for on-link determination seems
> fraught with dangers. E.g. from a router perspective you need a
> connected route aka an onlink prefix for the prefix used for address
> assignment, otherwise you have no reachability.

Further, I disagree that a distinction between on-link prefix and SLAAC
prefix favors continuation of the 64bit IID, and of the 64bit limit for
that matter.

A situation can be created where a SLAAC prefix is /64 and  a distinct
on-link prefix is of plen /65 on that same link.  But this situation is
not desirable.

Because a Host that configures itself an address within the /64 may in
some cases not be visible to the ND of another Host on that same link;
that other Host used on-link determination with a /65 to find out
whether it is on link or not.

This problem of visibility is very clear especially if a default router
is absent on that link (subnets isolated from the Internet).  If a
default router is present, then this visibility problem may not be that
obvious.

This is why the distinction between the plens of an on-link prefix and
of a SLAAC prefix on same link is not something good.  These two plens
should be the same.

And when they are the same (the prefix for on-link determination, and
the prefix for SLAAC), they must have the same plen.  And that plen can
be anything from 1 to 128.

Finally, yes, it is possible to have multiple prefixes on same link.
But these prefixes should be paired: on-link prefix1 and SLAAC prefix1,
onlink prefix2 and SLAAC prefix2, and so on.

Alex


>
> O.
>
>> On 9 Mar 2017, at 22:11, 神明達哉 <[e-mail]> wrote:
>>
>> At Thu, 09 Mar 2017 19:30:11 +0100, Philip Homburg
>> <[e-mail]> wrote:
>>
>>> If your use of the term 'subnet prefix' only refers to
>>> (stateless) address configuration and not to being onlink or
>>> not, then I agree about the concept (but not the term).
>>>
>>> However, where IPv6 clearly separates address configuration from
>>> being onlink, calling a prefix that is only used for (stateless)
>>> address configuration 'a subnet prefix' is very confusing.
>>>
>>> At the same time, calling some onlink prefixes 'subnet prefixes'
>>> and others 'other unicast routing prefixes' is also very
>>> confusing if they are announced using the same L flag in a PIO
>>> option in a router advertisement. I.e, whether or not the A flag
>>> is set in PIO option, should not have an effect on what we call
>>> an onlink prefix. Or on how we describe onlink prefixes and what
>>> their properties are.
>> [...]
>>> So if we want to say that prefixes used for stateless address
>>> configuration MUST/SHOULD be 64 bits long, whereas onlink
>>> prefixes can be of any length, then we should at least use clear
>>> terminology that separates prefixes for stateless address
>>> configuration from other uses.
>>
>> +1.  I've also been feeling that one source of seeming confusion in
>> this discussion may be confusion between "subnet prefixes" and
>> prefixes for on-link determination as described in RFC4861.  In
>> fact, the latter (I'll use the term "onlink prefix" in this
>> message) has nothing to do with "subnet prefixes" - it simply
>> specifies a set of addresses that should be supposed to be on-link
>> for the corresponding link.  Whether or not we adopt
>> "conservative" or "liberal" view of the length of IIDs or "subnet
>> prefix" in the context of addressing architecture, an onlink prefix
>> can be longer or shorter than a subnet prefix even if these two
>> share some leading bits.
>>
>> So, for example: - if we adopt the "conservative" address
>> architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 must be
>> 2001:db8:1:2::/64. - if we adopt the "liberal" address
>> architecture, The subnet prefix for 2001:db8:1:2:3:4:5:6 can be
>> 2001::/16, 2001:db8::/32, 2001:db8:1::/48, 2001:db8:1:2::/64,
>> ...2001:db8:1:2:3:4:5:0/120, etc. and, in either case, - onlink
>> prefx in this link advertised via an RA with L=1 can be 2001::/16,
>> 2001:db8::/32, 2001:db8:1::/48, ...2001:db8:1:2:3:4:5:0/120, etc.
>>
>> In particular, the fact that onlink prefix can be of any length
>> doesn't mean it violates the conservative address architecture.
>>
>> Perhaps one source of confusion is the fact or expectation that RA
>> PIO often both sets A and L bits on.  So, in the above example, if
>> we have a PIO for 2001:db8:1::/48 or 2001:db8:1:2:3:4:5:0/120 with
>> both L and A bits on, these are valid on link prefix.  But they
>> can't be used for SLAAC (assuming its link-layer spec specifies
>> the consistent IID length with the "conservative" address
>> architecture, i.e., 64).  That is, for the same PIO, - if we
>> consider it as on-link prefix, it can coexist with any of the
>> address architecture - if we consider it for SLAAC, it can only
>> coexist with the conservative architecture, or liberal one with an
>> exception of requiring 64-bit subnet prefix length specifically
>> for SLAAC
>>
>> BTW while writing this message I saw a warning from Brian:
>>
>>>> Isn't it time we all shut up and wait for the document editor
>>>> to propose text?
>>
>> I don't want to contribute to making this thread even longer, so I
>>  promise I'll stop here.  But I wanted to make this one remark
>> since I believe it's important to clarify that ("on-link prefix" is
>> irrelevant to the address architecture discussion) and I see why
>> this can be so confusing.  Even if this attempt of mine fails,
>> I'll shut up now (maybe I should write a separate draft just
>> focusing on this particular confusion).
>>
>> -- JINMEI, Tatuya
>>
>> --------------------------------------------------------------------
>>
>>
>>
IETF IPv6 working group mailing list
>> [e-mail] Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>>
>>
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list [e-mail] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>