RE: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]

"Manfredi, Albert E" <> Fri, 20 January 2017 19:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2AF0C1270B4 for <>; Fri, 20 Jan 2017 11:59:39 -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 UuVCd0ieTsRU for <>; Fri, 20 Jan 2017 11:59:37 -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 6AADE126D74 for <>; Fri, 20 Jan 2017 11:59:37 -0800 (PST)
Received: from localhost (localhost []) by (8.14.4/8.14.4/DOWNSTREAM_MBSOUT) with SMTP id v0KJxaeF014474; Fri, 20 Jan 2017 12:59:36 -0700
Received: from ( []) by (8.14.4/8.14.4/UPSTREAM_MBSOUT) with ESMTP id v0KJxWBj014454 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=OK); Fri, 20 Jan 2017 12:59:33 -0700
Received: from (2002:8988:efdc::8988:efdc) by (2002:8988:efdb::8988:efdb) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 20 Jan 2017 11:59:32 -0800
Received: from ([]) by ([]) with mapi id 15.00.1178.000; Fri, 20 Jan 2017 11:59:32 -0800
From: "Manfredi, Albert E" <>
To: "" <>, David Farmer <>
Subject: RE: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
Thread-Topic: IID length text [was Re: Review of draft-ietf-6man-rfc4291bis-06]
Thread-Index: AQHScqwgjPqNAvQPbkeyQCElQvXC+aFA/wSAgADEgBA=
Date: Fri, 20 Jan 2017 19:59:32 +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: 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: Fri, 20 Jan 2017 19:59:39 -0000

> -----Original Message-----
> From: ipv6 [] On Behalf Of

> Therein lays the paradox. If the IETF were to standardise arbitrary prefix
> length > 64 you end up being charged per address. If implementations don't
> support arbitrary prefix lengths > 64 you end up having to do NAT66, ND
> proxy...
> Which is why all implementations should support arbitrary prefix length, but
> not tell anyone. ;-)

Yes, that is the problem. However, the threat of being given just one address is already the case, is it not? Individuals are not being handed out /48 or even /56. So I don't see a /64 mandate solving anything, in this one respect. It just pushes people to use the same work-arounds as had to be invented for IPv4. 

> That would require extreme waste in the first 64 bits...
> 2^64 number of addresses is an awfully big number.

I keep seeing this stated, but I don't think this is necessarily true. This type of assumption can change drastically, depending how Internet appliances evolve over time. With IPv4, no one predicted that every single hand-help gadget might require its own IP address. And this time around, with developments such as the so-called IoT, there's likely to be zillions of devices that will require their own prefix, and will support multiple internal subnets.

I think that Brian's NEW NEW test is what should be used, because it does NOT imply that all global unicast addresses, minus one subset 000, must use /64 addresses for all time.

And too, the main reason for the specific 64 bit length mentioned, for currently assigned global unicast IIDs, *is indeed* SLAAC. There is no good reason to hide this reality.

RFC 7421:

   The notion of a /64 boundary in the address was introduced after the
   initial design of IPv6, following a period when it was expected to be
   at /80.  There were two motivations for setting it at /64.  One was
   the original "8+8" proposal [ODELL] that eventually led to the
   Identifier-Locator Network Protocol (ILNP) [RFC6741], which required
   a fixed point for the split between local and wide-area parts of the
   address.  The other was the expectation that 64-bit Extended Unique
   Identifier (EUI-64) Media Access Control (MAC) addresses would become
   widespread in place of 48-bit addresses, coupled with the plan at
   that time that auto-configured addresses would normally be based on
   interface identifiers derived from MAC addresses.

I do agree with the one objection, that on any given link, the prefix length only needs to be consistent for that subnet. For instance, a globally unique /80 should be able to coexist with ULAs, or link locals, or other examples of /64s. I do not think we should go back to text that implies /64 is for all unicast addresses, for all time.