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

Alexandre Petrescu <alexandre.petrescu@gmail.com> Sat, 11 March 2017 16:49 UTC

Return-Path: <alexandre.petrescu@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0A129541 for <ipv6@ietfa.amsl.com>; Sat, 11 Mar 2017 08:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.175
X-Spam-Level: **
X-Spam-Status: No, score=2.175 tagged_above=-999 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=1.2, SPF_SOFTFAIL=0.972, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n3tgwYGLl7I for <ipv6@ietfa.amsl.com>; Sat, 11 Mar 2017 08:49:39 -0800 (PST)
Received: from cirse-smtp-out.extra.cea.fr (cirse-smtp-out.extra.cea.fr [132.167.192.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDB8412953F for <ipv6@ietf.org>; Sat, 11 Mar 2017 08:49:38 -0800 (PST)
Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse-sys.extra.cea.fr (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2BGnaA2009377 for <ipv6@ietf.org>; Sat, 11 Mar 2017 17:49:36 +0100
Received: from pisaure.intra.cea.fr (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id B6395207AF2 for <ipv6@ietf.org>; Sat, 11 Mar 2017 17:49:36 +0100 (CET)
Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (Postfix) with ESMTP id AC44C207704 for <ipv6@ietf.org>; Sat, 11 Mar 2017 17:49:36 +0100 (CET)
Received: from [132.166.84.23] ([132.166.84.23]) by muguet2.intra.cea.fr (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2BGnZWG013303 for <ipv6@ietf.org>; Sat, 11 Mar 2017 17:49:36 +0100
Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
To: ipv6@ietf.org
References: <m1clw44-0000I4C@stereo.hq.phicoh.net> <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> <m1cm2pI-0000FsC@stereo.hq.phicoh.net> <CAJE_bqfo9Mje=wgfUW+V1Q5eHwEwpA164R+kHyjrWgD51H_uKg@mail.gmail.com> <DB582F48-22FD-4240-9B78-ECF60FCA68D2@employees.org>
From: Alexandre Petrescu <alexandre.petrescu@gmail.com>
Message-ID: <4bff6311-1b9b-a861-bb11-b8a5b4d44cb8@gmail.com>
Date: Sat, 11 Mar 2017 17:49:32 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <DB582F48-22FD-4240-9B78-ECF60FCA68D2@employees.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/43NLvHtLQSi3YyRj9j7ul-aY0TQ>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Mar 2017 16:49:40 -0000


Le 11/03/2017 à 09:57, otroan@employees.org 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, 神明達哉 <jinmei@wide.ad.jp> wrote:
>>
>> At Thu, 09 Mar 2017 19:30:11 +0100, Philip Homburg
>> <pch-ipv6-ietf-3@u-1.phicoh.com> 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
>> ipv6@ietf.org Administrative Requests:
>> https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>
>>
>>
>
>
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list ipv6@ietf.org Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>