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

otroan@employees.org Sat, 11 March 2017 08:57 UTC

Return-Path: <otroan@employees.org>
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 A40221279EB for <ipv6@ietfa.amsl.com>; Sat, 11 Mar 2017 00:57:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=employees.org; domainkeys=pass (1024-bit key) header.from=otroan@employees.org header.d=employees.org
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 FBw50vKYWEAm for <ipv6@ietfa.amsl.com>; Sat, 11 Mar 2017 00:57:15 -0800 (PST)
Received: from esa01.kjsl.com (esa01.kjsl.com [IPv6:2607:7c80:54:3::87]) by ietfa.amsl.com (Postfix) with ESMTP id B1B3B126D73 for <ipv6@ietf.org>; Sat, 11 Mar 2017 00:57:15 -0800 (PST)
Received: from cowbell.employees.org ([198.137.202.74]) by esa01.kjsl.com with ESMTP; 11 Mar 2017 08:57:14 +0000
Received: from cowbell.employees.org (localhost [127.0.0.1]) by cowbell.employees.org (Postfix) with ESMTP id 755F4D788B; Sat, 11 Mar 2017 00:57:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=employees.org; 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; d=employees.org; 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 h.hanazo.no (77.16.46.37.tmi.telenormobil.no [77.16.46.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: otroan) by cowbell.employees.org (Postfix) with ESMTPSA id 8E39DD788A; Sat, 11 Mar 2017 00:57:13 -0800 (PST)
Received: from [IPv6:::1] (localhost [IPv6:::1]) by h.hanazo.no (Postfix) with ESMTP id 0BBCF9B8161D; Sat, 11 Mar 2017 09:57:08 +0100 (CET)
From: otroan@employees.org
Message-Id: <DB582F48-22FD-4240-9B78-ECF60FCA68D2@employees.org>
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: <CAJE_bqfo9Mje=wgfUW+V1Q5eHwEwpA164R+kHyjrWgD51H_uKg@mail.gmail.com>
To: =?utf-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
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>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/NPamzTBnDqO4MCtuDbkfDeCGl5s>
Cc: james woodyatt <jhw@google.com>, 6man WG <ipv6@ietf.org>
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 08:57:19 -0000

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.

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