RE: Objection to draft-ietf-6man-rfc4291bis-07.txt

"Manfredi, Albert E" <> Thu, 23 February 2017 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D3575129A9D for <>; Thu, 23 Feb 2017 12:15:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.221
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tKsX_ue13whB for <>; Thu, 23 Feb 2017 12:15:35 -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 016A7129853 for <>; Thu, 23 Feb 2017 12:15:34 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v1NKFYBj010174; Thu, 23 Feb 2017 13:15:34 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v1NKFU7h010139 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=OK); Thu, 23 Feb 2017 13:15:30 -0700
Received: from (2002:8988:efdc::8988:efdc) by (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 23 Feb 2017 12:15:29 -0800
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Thu, 23 Feb 2017 12:15:29 -0800
From: "Manfredi, Albert E" <>
To: Brian E Carpenter <>
Subject: RE: Objection to draft-ietf-6man-rfc4291bis-07.txt
Thread-Topic: Objection to draft-ietf-6man-rfc4291bis-07.txt
Thread-Index: AQHSjdpvHMQuOTwVQEa1egjWGUVyuqF3KLmAgABcRwD//3yjkA==
Date: Thu, 23 Feb 2017 20:15:29 +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: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
Archived-At: <>
Cc: IETF IPv6 Mailing List <>
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, 23 Feb 2017 20:15:37 -0000

> From: ipv6 [] On Behalf Of Brian E Carpenter

> Nonsense. The exactly correct time to object is when a document is being
> Last Called for Internet Standard status. Until this point in time, IPv6
> has only been a Proposed Standard.
> Actually it has been very educational for me - not in my understanding
> of how IPv6 works, but in showing how badly this particular aspect has been
> documented for the last 20 years. Mainly, we've had too many words in the
> addressing architecture. I expect the next version to have fewer words
> on this topic.

The fix should be straightforward enough. For one thing, all of the arguments which depended on EUI-64 are deprecated. In RFC 4291, for instance,

   The text representation of IPv6 address prefixes is similar to the
   way IPv4 address prefixes are written in Classless Inter-Domain
   Routing (CIDR) notation [CIDR].  An IPv6 address prefix is
   represented by the notation:



      ipv6-address    is an IPv6 address in any of the notations listed
                      in Section 2.2.

      prefix-length   is a decimal value specifying how many of the
                      leftmost contiguous bits of the address comprise
                      the prefix.

Nothing more is needed in this text, but if people insist, we might add, "prefix length may be any value, including values greater than or less than 64 bits."

   All Global Unicast addresses other than those that start with binary
   000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as
   described in Section 2.5.1.  Global Unicast addresses that start with
   binary 000 have no such constraint on the size or structure of the
   interface ID field.

This should be reworded to reflect reality.


   Global Unicast addresses in the 2000::/3 space are currently
   constrained to 64-bit interface ID field (i.e., n + m = 64),
   formatted as described in Section 2.5.1. Other examples of
   global scope unicast 64-bit interface ID are SLAAC, ULA, ...

This leaves the possibility of future changes even to this rule in 2000::/3.

DHCPv6 and static configuration seem the logical ways of assigning arbitrary length prefixes.