Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis Sat, 11 March 2017 08:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A40221279EB for <>; Sat, 11 Mar 2017 00:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key); domainkeys=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FBw50vKYWEAm for <>; Sat, 11 Mar 2017 00:57:15 -0800 (PST)
Received: from ( [IPv6:2607:7c80:54:3::87]) by (Postfix) with ESMTP id B1B3B126D73 for <>; Sat, 11 Mar 2017 00:57:15 -0800 (PST)
Received: from ([]) by with ESMTP; 11 Mar 2017 08:57:14 +0000
Received: from (localhost []) by (Postfix) with ESMTP id 755F4D788B; Sat, 11 Mar 2017 00:57:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; s=selector1; bh=ETh3qLU1U6kiV1bkquZJg+0WSmY=; b= n+bNmYW247NOKe1thadnM/LAUus+2Ul/ztPlQHxaErN7WRHtdL95g3wurXBjh3TB ZpsHLySTfNpYSwItfcwArguS7/6kGu/QkvVhSDi//IJO6LPsiv4+zaH/edVXdOIx YXB1HCVJ6YNiVYsr1tOxTs1/r8URXGUJBiEj4Nm2nwY=
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=from :message-id:content-type:mime-version:subject:date:in-reply-to :cc:to:references; q=dns; s=selector1; b=jCsfKL+5HGiKu2Pc7uRPKRX JJYcvH/XF1bdnDgUbKI4geVRExRwaV7p7f+Uc2lsoyZpMEtS7aSl/zAhtSJs7tv5 zhbWL5baQ1iFGyv1hKEhGUUJ/asNpNMwoC1HC15VKymteU8NOYpbT/kM8XEgp3Gt DOmAwFyXzDfq5FOnwFhQ=
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by (Postfix) with ESMTPSA id 8E39DD788A; Sat, 11 Mar 2017 00:57:13 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by (Postfix) with ESMTP id 0BBCF9B8161D; Sat, 11 Mar 2017 09:57:08 +0100 (CET)
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_13BA574D-0299-452B-8DD2-EB79C833DA1D"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
Date: Sat, 11 Mar 2017 09:57:07 +0100
In-Reply-To: <>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <>
References: <> <> <> <>
X-Mailer: Apple Mail (2.3259)
Archived-At: <>
Cc: james woodyatt <>, 6man WG <>
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 08:57:19 -0000


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.


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