IETF Logo Mail Archive

RE: Updated IID length text

"Manfredi, Albert E" <albert.e.manfredi@boeing.com> Thu, 19 January 2017 20:30 UTC

Return-Path: <albert.e.manfredi@boeing.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 D391F12956C for <ipv6@ietfa.amsl.com>; Thu, 19 Jan 2017 12:30:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 LdsTVEdbJNVh for <ipv6@ietfa.amsl.com>; Thu, 19 Jan 2017 12:30:41 -0800 (PST)
Received: from phx-mbsout-02.mbs.boeing.net (phx-mbsout-02.mbs.boeing.net [130.76.184.179]) (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 15C03129573 for <ipv6@ietf.org>; Thu, 19 Jan 2017 12:30:40 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v0JKUdw9057583; Thu, 19 Jan 2017 13:30:39 -0700
Received: from XCH15-06-12.nw.nos.boeing.com (xch15-06-12.nw.nos.boeing.com [137.136.239.221]) by phx-mbsout-02.mbs.boeing.net (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0JKUZTN057542 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Thu, 19 Jan 2017 13:30:35 -0700
Received: from XCH15-06-11.nw.nos.boeing.com (2002:8988:efdc::8988:efdc) by XCH15-06-12.nw.nos.boeing.com (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 19 Jan 2017 12:30:34 -0800
Received: from XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) by XCH15-06-11.nw.nos.boeing.com ([137.136.239.220]) with mapi id 15.00.1178.000; Thu, 19 Jan 2017 12:30:35 -0800
From: "Manfredi, Albert E" <albert.e.manfredi@boeing.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, 6man <ipv6@ietf.org>
Subject: RE: Updated IID length text
Thread-Topic: Updated IID length text
Thread-Index: AQHScowEqB5Tp7XZTkyunKSq9IrHHaFAPzhQ
Date: Thu, 19 Jan 2017 20:30:34 +0000
Message-ID: <28102f87f8e043248da16d9273d4c7d7@XCH15-06-11.nw.nos.boeing.com>
References: <148406593094.22166.2894840062954191477.idtracker@ietfa.amsl.com> <F6953234-3F85-4E28-9861-433ADD01A490@gmail.com> <m2wpdzhncn.wl-randy@psg.com> <82245ef2-cd34-9bd6-c04e-f262e285f983@gmail.com> <m2d1frhjfn.wl-randy@psg.com> <18e6e13c-e605-48ff-4906-2d5531624d64@gmail.com> <CAKD1Yr1cvZ8Y3+bHeML=Xwqr+YgDspZGnZi=jqQj4qe2kMc4zw@mail.gmail.com> <m2lguffnco.wl-randy@psg.com> <CAKD1Yr1TrTiPRdyutobmb_77XJ7guNzLrg=H_p7qi4BfQ8V=GA@mail.gmail.com> <m2d1frfm6m.wl-randy@psg.com> <CAKD1Yr2Njjd8_Mr+6TRFF6C5pdcX4yFgpFVyEkykDuytu2B8mg@mail.gmail.com> <2A5073777007277764473D78@PSB> <4596c3d4-a337-f08e-7909-f14270b7085f@gmail.com> <CAN-Dau06R3iYRpYLADhvHox4C9qdsJCuxFsJapRhOQcWT4qk_g@mail.gmail.com> <CAO42Z2weZcoHiBzN94QAQ9WGhWR16PmMMFNg=5YLmr_dhPjjpA@mail.gmail.com> <fcc7f136-b5da-527e-b495-5a2d7f7a3ce8@gmail.com> <55bb8bdbfbf4439da0aa702e5bc03e2c@XCH15-06-11.nw.nos.boeing.com> <bb79ce41f2cc465dab0a7f26466be26f@XCH15-06-11.nw.nos.boeing.com> <ed9fe2df-0dce-0ddc-bdee-561217d089bb@gmail.com> <e8b4d426-55b4-bd2e-ea4f-f8e56e831d44@gmail.com>
In-Reply-To: <e8b4d426-55b4-bd2e-ea4f-f8e56e831d44@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [137.136.248.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/BjXFpFqsrAFNnUj9EInC1ynAo6o>
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, 19 Jan 2017 20:30:44 -0000

Brian, I'm completely on board with your text below. I think that this should satisfy even the objections, by avoiding any "speculation."

Bert 

-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
Sent: Thursday, January 19, 2017 14:41
To: Manfredi, Albert E <albert.e.manfredi@boeing.com>; 6man <ipv6@ietf.org>
Subject: Re: Updated IID length text

On 19/01/2017 16:23, Brian E Carpenter wrote:
> On 19/01/2017 15:55, Manfredi, Albert E wrote:
> ...
>>> I don't think that SLAAC *must* require a single standard IID length, so
>>> that's why I added the word "robust." Now that we have moved away from using
>>> the MAC address for SLAAC, it's not clear to me why a host cannot wait for a
>>> RA, and then decide on how many IID bits to use, based on the prefix
>>> length(s) advertised by the router.
> 
> Not if you want to form a link-local address first. Which you always do,
> because perhaps there *is* no router when you come up after a power cut.
> (In the Anima WG, we are very interested in the behaviour of nodes
> that have absolutely no external information when they come up, because
> it's their job to bootstrap the network out of nowhere.)

I should have added that in the context of promoting the document to
full Standard, we can't introduce new behaviour. But I don't object to the word
'robust'.  I don't think it makes sense to use the word 'standard' inside a
standard, however. And using 'consistent' twice is ugly. So I get to

NEW NEW
   IPv6 routing is based on prefixes of any valid length up to 128 [BCP198].
   For example, [RFC6164] standardises 127 bit prefixes on point-to-point
   links. However, correct use of Stateless Address Autoconfiguration
   (SLAAC)[RFC4862] requires all interfaces on a link to use the same length
   of Interface ID. Furthermore, to guarantee robust interoperability of SLAAC,
   a consistent length of Interface ID is desirable. For this reason, the
   Interface ID of all currently allocated unicast addresses, except those that
   start with the binary value 000, is required to be 64 bits long. Background
   on the 64 bit boundary in IPv6 addresses can be found in [RFC7421].

Any speculation about deviations from /64 is out of scope, IMHO, for
a draft being proposed for full Standard, given that 4291 requires /64.

    Brian

v2.23.0 | Report a Bug | By Email