Re: draft-bourbaki-6man-classless-ipv6-00

神明達哉 <jinmei@wide.ad.jp> Tue, 06 June 2017 21:49 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 AFCCA1271FD for <ipv6@ietfa.amsl.com>; Tue, 6 Jun 2017 14:49:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 MVIHSj6K4ZLO for <ipv6@ietfa.amsl.com>; Tue, 6 Jun 2017 14:49:48 -0700 (PDT)
Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 020A1128BB6 for <ipv6@ietf.org>; Tue, 6 Jun 2017 14:49:47 -0700 (PDT)
Received: by mail-qt0-x231.google.com with SMTP id w1so145954733qtg.2 for <ipv6@ietf.org>; Tue, 06 Jun 2017 14:49:47 -0700 (PDT)
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=fgz8CYSPM3Fcmztdd3VwKvPbyucwOkvdOZygU1vrWZc=; b=f2OpeeOmu7DANZw6pNc/eFNzzFRL8JYqm7aw8fGX3omHwrNCYs2ihZeNr9YWLf7XRE ZC1fPkdhi7Axf6enAzvkeLXsoz+euNmee4aJ4JW1LZIws4442ZlBSIkff0x9NjcUtUSe ac89BCTjgh4L1jUoVReUpsM4u7FZW9rIL4qGJwPthBOW1kcSMCkOb/+H201tnZY5J5nB QoouRdkVJbrv8x5R/mDWE4TRso0Brm77h6fpdwb7N4wSU7qTBQ0sk3jU70q8M3pAVwOK jPoH2Tb3QJrnB3WFOWpm3I95yFKHz9n6iA9kc2YYQPuGr6qNYJPAAPdmt10Sb5oissJl gejQ==
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=fgz8CYSPM3Fcmztdd3VwKvPbyucwOkvdOZygU1vrWZc=; b=uUYcoygmbKVgKsQA4LynPTe1wis7BXBlpEHE4NCfZuuN5kT+NJxLm/ncKVoZyXN1bR iAbMRMraREgeX3o6VfuhGajjrxkybFvi6ijIcX3gmff5SxKPIhrFm2juMXVsNNA2spo6 V4kIJ5IlhQGnCaSrDYjyK6M5AvqwL57hfvrTFLEoo/DOl4+lcEyxTV4WtThZB7zVYVu/ CDV39uuHBHq9K1C+Qb2hta5BZaxr5VwxiQhvw48H5XI74yhXecMD/PmQBdMkLhx5iyki d7kvMJPE8qcY4kagP8mVu899X2DJcIiM82emme+tVu34/Uxw+XY1Wy2K2tHiXrFULK76 6vzg==
X-Gm-Message-State: AODbwcDrbQokfcGuL9kKGd/G0/lUto5BmSiG6FaUenYAUAJAX+Lni+ae kr447KSXuLwPRRgxy7SCb1NbQixEkQ==
X-Received: by 10.200.44.186 with SMTP id 55mr33919732qtw.173.1496785786838; Tue, 06 Jun 2017 14:49:46 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.60.53 with HTTP; Tue, 6 Jun 2017 14:49:46 -0700 (PDT)
In-Reply-To: <bd62fecf-a1c7-1623-a9dd-ec8bc3ff5a5a@gmail.com>
References: <20170602141112.x64nleqclygz7dwd@Vurt.local> <CAJE_bqfuTbEm-8Uy5a+n85LCf7-pVGck8ccapGaCEqy1EpCFNQ@mail.gmail.com> <bd62fecf-a1c7-1623-a9dd-ec8bc3ff5a5a@gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Tue, 06 Jun 2017 14:49:46 -0700
X-Google-Sender-Auth: 2yIc19F2w5GXzYwDmCcQwS-iVLY
Message-ID: <CAJE_bqfoVXbt3N8LG0_QXn4BBpBpJQ5SFo=nw0g1Or6dxcRmeg@mail.gmail.com>
Subject: Re: draft-bourbaki-6man-classless-ipv6-00
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: 6man <ipv6@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/DI5UzVg_GjH88GM-NKZwW4e-a-w>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 06 Jun 2017 21:49:50 -0000

At Wed, 7 Jun 2017 08:27:45 +1200,
Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:

> Thanks for those careful comments. Can I just ask one question to be
> sure I understand:
>
> > The draft (perhaps unintentionally) conflates
> >   "on-link prefixes" and "(SLAAC) subnet prefixes".
>
> Am I correct in thinking that this distinction *only*
> applies when SLAAC is in use?

This is indeed a subtle point and I intentionally didn't go into it in
my comments to avoid introducing further confusion (so I'm glad you
asked it separately).  As it's subtle I'm not sure if I can explain it
well, but let me try...(and therefore it can't be a simple answer like
"yes, you're right" or "no, it's not correct").

First, an "on-link prefix" is only about on-link determination in the
Neighbor Discovery protocol.  It's independent from SLAAC or any other
way to configure addresses.  In that sense, the separation between
on-link prefix and (SLAAC) subnet prefix always applies, whether or
not SLAAC is in use.  So the answer to the above question would be
"no, you're not correct".

Secondly, "SLAAC subnet prefix" is by definition only meaningful when
SLAAC is in use.  In that sense, "this distinction only applies when
SLAAC is in use" obviously.  But in this context we should actually
extend it and only consider "subnet prefix".  Purely from the
addressing architecture point of view, a subnet prefix could be
defined as the leading bits of an IPv6 address immediately followed by
the interface identifier.  This definition has no conflict with the
definition of "SLAAC subnet prefix" as introduced in
draft-jinmei-6man-prefix-clarify-00 (where it's defined as a prefix
advertised in an RA PIO with A flag on, and its only use is for SLAAC,
and in SLAAC this prefix is immediately followed by the interface
identifier).

With this extended definition, the question is whether "on-link
prefix" is distinct from "subnet prefix" only when SLAAC is in use.
Admittedly I don't think an existing standard document answers this
question.  But IMO the answer is still "no".  That's simply because
the concept of "on-link" prefix is independent from how an address is
configured at all, as explained two paragraphs above.

And then:

> If the nodes on a link
> (including a point-to-point) are configured without use
> of SLAAC, surely there is only a "prefix", without
> distinction.

(again in my understanding/opinion), no, an on-link prefix is still
different from a subnet prefix in this case (they can happen to be the
same, but don't have to be so).

Now, another related subtle point is that if we accept this
separation, the "subnet prefix" for an address configured without
SLAAC is almost meaningless except in the formal definition of the
addressing architecture: a host uses an on-link prefix for on-link
determination, and uses the full 128 bits to identify L3 end points.
It doesn't matter for the host which part of the address is the subnet
prefix and which part is the interface identifier.  To this end, your
original question:

> Am I correct in thinking that this distinction *only*
> applies when SLAAC is in use?

could also be answered with "yes" since in this case only the "on-link
prefix" matters in practice.

Does this answer your question?

--
JINMEI, Tatuya