IETF Logo Mail Archive

Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00)

JINMEI Tatuya / 神明達哉 <jinmei@wide.ad.jp> Mon, 19 June 2017 17:27 UTC

Return-Path: <jinmei@wide.ad.jp>
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 B364D131604 for <ipv6@ietfa.amsl.com>; Mon, 19 Jun 2017 10:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.12
X-Spam-Level:
X-Spam-Status: No, score=-6.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 08fewCwBHaDp for <ipv6@ietfa.amsl.com>; Mon, 19 Jun 2017 10:27:12 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9F471316DF for <ipv6@ietf.org>; Mon, 19 Jun 2017 10:25:39 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id CD9C13493A2; Mon, 19 Jun 2017 17:25:36 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id BABFE160048; Mon, 19 Jun 2017 17:25:36 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id A2C4116006D; Mon, 19 Jun 2017 17:25:36 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SyhYkaSBN2_l; Mon, 19 Jun 2017 17:25:36 +0000 (UTC)
Received: from jmb.localhost (unknown [104.129.198.81]) by zmx1.isc.org (Postfix) with ESMTPSA id 3BC57160048; Mon, 19 Jun 2017 17:25:36 +0000 (UTC)
Date: Mon, 19 Jun 2017 10:25:36 -0700
Message-ID: <m2r2yfrisv.wl%jinmei@wide.ad.jp>
From: JINMEI Tatuya / 神明達哉 <jinmei@wide.ad.jp>
To: Job Snijders <job@ntt.net>
Cc: Erik Kline <ek@google.com>, 6man WG <ipv6@ietf.org>
Subject: Re: RFC4862 and 64-bit IID (Re: draft-bourbaki-6man-classless-ipv6-00)
In-Reply-To: <20170619164512.hbysyxqfps7jh7rc@Vurt.local>
References: <CAKD1Yr0ZZwRar6D-2bkXBKPYehqqW99+BMtDOjyovR8WDXKzxw@mail.gmail.com> <CAD6AjGTjikAWutcenW8qn7OW8kPM9c_x_yDUy5vQxJmXKL85dg@mail.gmail.com> <91c3c0f4-eb8b-cdf7-b9c9-7d1eecb7fe64@gmail.com> <CAKD1Yr0_WR_TB+OC0U1Qt2h6WzUp9EGvrqC1ZKW2mwFeBd3bCQ@mail.gmail.com> <4021a559-5b6d-b3fb-19cd-afbe9041e8f2@gmail.com> <34A29D4D-3670-40BC-B62E-85C4EABC55D5@employees.org> <426b1b86-575f-77e5-67d6-9b1fef55d074@gmail.com> <04CE008D-7A07-468B-A8AB-5A00C70C68AA@employees.org> <m2h8znsvb4.wl%jinmei@wide.ad.jp> <CAAedzxp3JFwu=9CF=k=W2r2z_X9_Yd1kcwtWjn7zhNCoxSCEww@mail.gmail.com> <20170619164512.hbysyxqfps7jh7rc@Vurt.local>
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/rHsLXYXR0Be3nNwxsYBiehzQWwE>
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: Mon, 19 Jun 2017 17:27:15 -0000

At Mon, 19 Jun 2017 18:45:12 +0200,
Job Snijders <job@ntt.net> wrote:

> > > I'd also note once again that this discussion has nothing to do with
> > > the fact that we can perform 'ifconfig en0 2001:db8::1/120'.  This
> > > operation configures a 128-bit IPv6 address with 120-bit on-link
> > > prefix.  On-link prefixes have always been variable, and they have
> > > nothing to do with IID length or SLAAC.  We don't have to update
> > > addr-arch or RFC4862 because of this.  (draft-bourbaki-6man-
> > > classless-ipv6-00 seems to be confused on this point, and I suspect
> > > it increases the confusion and controversy in this whole thread).
> > 
> > Agreed.
> 
> Is there a document that states that IPv6 routers and hosts must support
> on-link prefixes of all sizes? 

In my own draft draft-jinmei-6man-prefix-clarify-00 I tried to explain
that's at least the case for configuring on-link prefixes on a host
advertised via Router Advertisements.  RFC4861, or any other RFCs that
I know of, doesn't have an exact phrase like "a host MUST support
on-link prefixes of all lengths", but I believe I provided sufficient
evidences that that's the reasonable interpretation of the current
specification and it matches what's currently implemented.

For manual configuration on hosts and routers, I don't think there is
an RFC that has this exact phrase or equally strong evidence as the
host autoconfiguration case.  But at least for host implementations I
believe it's quite natural to extend that interpretation to manual
configuration.  And same for routers - after all, it's a router to
advertise an on-link prefix of arbitrary lengths via RA PIO.  So, it
shouldn't be unreasonable to assume it should be able to use that
prefix for its own on-link determination.

And, perhaps more important in the context of
draft-bourbaki-6man-classless-ipv6-00, (as far as I know) no one,
even strong 64bit-IID advocates, disagrees on this interpretation.

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email