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

["Manfredi, Albert E" <[e-mail]>]

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

> 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.

Bert