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

Alexandre Petrescu <> Sat, 11 March 2017 16:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 57F0A129541 for <>; Sat, 11 Mar 2017 08:49:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0n3tgwYGLl7I for <>; Sat, 11 Mar 2017 08:49:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDB8412953F for <>; Sat, 11 Mar 2017 08:49:38 -0800 (PST)
Received: from ( []) by (8.14.7/8.14.7/CEAnet-Internet-out-4.0) with ESMTP id v2BGnaA2009377 for <>; Sat, 11 Mar 2017 17:49:36 +0100
Received: from (localhost []) by localhost (Postfix) with SMTP id B6395207AF2 for <>; Sat, 11 Mar 2017 17:49:36 +0100 (CET)
Received: from ( []) by (Postfix) with ESMTP id AC44C207704 for <>; Sat, 11 Mar 2017 17:49:36 +0100 (CET)
Received: from [] ([]) by (8.15.2/8.15.2/CEAnet-Intranet-out-1.4) with ESMTP id v2BGnZWG013303 for <>; Sat, 11 Mar 2017 17:49:36 +0100
Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
References: <> <> <> <> <>
From: Alexandre Petrescu <>
Message-ID: <>
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: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Mar 2017 16:49:40 -0000

Le 11/03/2017 à 09:57, 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

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.


> O.
>> On 9 Mar 2017, at 22:11, 神明達哉 <> wrote:
>> At Thu, 09 Mar 2017 19:30:11 +0100, Philip Homburg
>> <> 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
>> Administrative Requests:
>> --------------------------------------------------------------------
> --------------------------------------------------------------------
>  IETF IPv6 working group mailing list Administrative
> Requests:
> --------------------------------------------------------------------