RE: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

"Manfredi, Albert E" <> Thu, 16 February 2017 22:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 00448129713; Thu, 16 Feb 2017 14:39:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IkRBJEHlqMqX; Thu, 16 Feb 2017 14:39:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F17212970A; Thu, 16 Feb 2017 14:39:02 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1GMd17h062601; Thu, 16 Feb 2017 15:39:02 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1GMctUA062561 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 16 Feb 2017 15:38:55 -0700
Received: from (2002:8988:efdc::8988:efdc) by (2002:8988:efdd::8988:efdd) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 16 Feb 2017 14:38:55 -0800
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Thu, 16 Feb 2017 14:38:55 -0800
From: "Manfredi, Albert E" <>
To: james woodyatt <>, IETF-Discussion Discussion <>
Subject: RE: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Thread-Topic: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard
Date: Thu, 16 Feb 2017 22:38:55 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_8767e370398045af989467a63747b29eXCH150611nwnosboeingcom_"
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
Cc: "" <>, 6man WG <>, "" <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Feb 2017 22:39:04 -0000

RFC 7421 is informational. And many considerations are not so critical anymore, on a specific stateful format.

I don’t think we need to reinforce the notion that IPv6 must have 64-bit prefixes, since that is not true now, and should not even be made to apply to the currently unused address space. So, I’m opposed to text that implies any such restriction, with the exception of (a) currently used unicast  address space, (b) SLAAC, (c) ULA, possibly other exceptions.

In other words, exceptions belong to requiring the 64-bit IID. Any RFC that implies otherwise, IMO, ought to be subject to a –bis version.


From: ipv6 [] On Behalf Of james woodyatt
Sent: Thursday, February 16, 2017 17:21
To: IETF-Discussion Discussion <>
Cc: 6man WG <>rg>;;
Subject: Re: Last Call: <draft-ietf-6man-rfc4291bis-07.txt> (IP Version 6 Addressing Architecture) to Internet Standard

On Feb 16, 2017, at 13:25,<> wrote:
On Feb 13, 2017, at 14:32, David Farmer <<>> wrote:

I have concerns with the following text;

   IPv6 unicast routing is based on prefixes of any valid length up to
   128 [BCP198].  For example, [RFC6164] standardises 127 bit prefixes
   on inter-router point-to-point links. However, the Interface ID of
   all unicast addresses, except those that start with the binary value
   000, is required to be 64 bits long.  The rationale for the 64 bit
   boundary in IPv6 addresses can be found in [RFC7421]

The third sentence seems to limit exceptions to 64 bit IIDs to exclusively addresses that start with binary vale of 000.  There are at least two other exceptions from standards track RFCs, that should be more clear accounted for in this text. […]

The challenge is to find text that enforces the 64-bit boundary policy (ignoring the technical arguments for a moment), and at the same time ensures implementors do the right thing and make their code handle any prefix length. Of course these are interdependent and doing the latter makes it harder to enforce the first.

I propose the following:

IPv6 unicast routing is based on prefixes of any valid length up to 128 bits [BCP198]. However, as explained in [RFC7421], the Interface ID of unicast addresses is generally required to be 64 bits in length, with exceptions only provided in special cases where expressly recognized in IETF standards track documents.

Trying to help out here.

--james woodyatt <<>>