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

神明達哉 <jinmei@wide.ad.jp> Thu, 09 March 2017 21:11 UTC

Return-Path: <jinmei.tatuya@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 5841C129549 for <ipv6@ietfa.amsl.com>; Thu, 9 Mar 2017 13:11:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.369
X-Spam-Level:
X-Spam-Status: No, score=-2.369 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 VySZ2596tnPa for <ipv6@ietfa.amsl.com>; Thu, 9 Mar 2017 13:11:40 -0800 (PST)
Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99B1512953E for <ipv6@ietf.org>; Thu, 9 Mar 2017 13:11:40 -0800 (PST)
Received: by mail-qk0-x22f.google.com with SMTP id p64so140398642qke.1 for <ipv6@ietf.org>; Thu, 09 Mar 2017 13:11:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=cVI5XM9LHxAHXW3gejr/GntRASirPsK04NrXu+459BI=; b=QQ9aja45h6v2mNXVypCO+M9Jb7+SHvL65BYCz5oM/4HVQqsLUNpQX5if9th2M09u+d mpE7WOqSL5m23gln6mNMXT8pzVIfR6LXdgcvaoGkM7PeC9i1TppOkitEp7ZDjcpGM+up 1TpCevCSbXejL6NfhiV+wTxO70dv4t8vcHulvk3U8l9ygtcNk4Rdpc39nfa4pTr1skbn iqLHkARIQVZf0goSDa4j8+1zlkLd9KxwlU8rN6IGgnmuF04zyvssy0odtahqAYrancAK fi14VF+C02cKPf9OpTy2pr2gRZ2eeFuzzqo8EZ1ka96teGBGSGFRruPqbCQmNPYzQjTu 8KPA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=cVI5XM9LHxAHXW3gejr/GntRASirPsK04NrXu+459BI=; b=uisMmGGbdyw/lPGg2vCV92XXAkdxLnuwgsyXx+IgvRosRjfnc4ingh3UasVDcqfvhK oE/xxcf/aYmQvj/R7+b6etHFvqqfF5oRd4jqFw8xuRqL0Q5f9zQx2MCqtvbWKdhCWSzz kJgiu05PUPEMr7ApGEMk2OnlLh5aG/91IQXoREQILlM/aoGPiHmZ0UhBjSAhkWki9EV4 EX5rU4KsZ2DPs5CV3F39NS9wionWCCyjEzfmjLLrSRAPKk6TQMo3n/6v2AYlj0YhtuG6 l8Ch481ApSUybAbI3aIval8nv62fSg/j+3qhZA6iQWiF8EYlpgHVXUd2HOr6u4JMZh0V pmCA==
X-Gm-Message-State: AFeK/H1Bt+fUZQMt05A8WYKrAeEea2RbKRcugabcEF7n3HI7XEnD1MZ71qt0v0svz212FmVAtgJUGfggVs+WWQ==
X-Received: by 10.55.104.134 with SMTP id d128mr13131519qkc.86.1489093899531; Thu, 09 Mar 2017 13:11:39 -0800 (PST)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.61.204 with HTTP; Thu, 9 Mar 2017 13:11:39 -0800 (PST)
In-Reply-To: <m1cm2pI-0000FsC@stereo.hq.phicoh.net>
References: <m1clw44-0000I4C@stereo.hq.phicoh.net> <904F4D77-1266-4A05-B0ED-D211E38FFC0F@google.com> <m1cm2pI-0000FsC@stereo.hq.phicoh.net>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Thu, 9 Mar 2017 13:11:39 -0800
X-Google-Sender-Auth: _KRk62mpgecBgJBCofjX8JkV0Ew
Message-ID: <CAJE_bqfo9Mje=wgfUW+V1Q5eHwEwpA164R+kHyjrWgD51H_uKg@mail.gmail.com>
Subject: Re: Proposal to further clarify prefix length issues in I-D.ietf-6man-rfc4291bis
To: Philip Homburg <pch-ipv6-ietf-3@u-1.phicoh.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/LJfvqwL735QrNiyHjeUjqjKfBt0>
Cc: james woodyatt <jhw@google.com>, IPv6 IPv6 List <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: Thu, 09 Mar 2017 21:11:42 -0000

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