[ppml] PPML Digest, Vol 28, Issue 51

[Brian Dickson]

mack wrote:
> This is not workable for a number of reasons.
> 1) It is in direct conflict with current RFCs.
>   
Hogwash. The current implementations fully support non /64 prefix usage.
They simply dictate behavior that is not very useful.
They say, if you get a non-64-bit prefix via RA, ignore it.

*Implementations* must support auto-configuration.
Nowhere does it say everyone must *use* auto-configuration.
And I know lots of folks who plan never to touch the darned thing.
> 2) It is in direct conflict with current auto-configuration implementations.
>   
No - if you read the proposal, it is a set of *recommendations*, not 
*requirements*.
Any end-site should still be able to justify a /64 if they intend to use 
auto-configuration.

The corresponding proposal to the IETF, is to *allow* auto-configuration 
to respond to non-64-bit RA announcments, by constructing appropriate 
hardware-based II's, e.g. EUI-48 (MAC-48) for Ethernet.

This would be backward-compatible for /64 prefixes, and would allow for 
use of other prefix lengths, e.g. /80, for auto-configuration.
> 3) It breaks under at least one major vendors implementation of IPv6 when certain functionality is used.
>
> Quote from vendor documentation:
> If the compress mode is on, the IPv6 address is compressed similarly to the EUI-64 compression method (removal of bits [39:24]) to allow for the Layer 4 port information to be used as part of the key used to look up the QoS TCAM, but Layer 3 information is lost.
>
> In practice the loss of data in these bits is inconsequential as they are a specific value (0xFFFE) or manually configured.  Manual configuration can set these to a known constant. I personally use (0x0000 or 0xFFFE).
>
> Any change that significantly breaks current hardware under a common configuration is a very bad idea.
>   
Does said hardware do this *only* when auto-configuration is used?
What about when static configuration is done?
What about when DHCPv6 is used?
What about when crypto-v6 II's are used? (random II's based on 
cryptography).

All of these do *not* use EUI-64 for their IPv6 address. They *do* use 
it for their Link-Local address.

And my proposal does not in any way alter the use of EUI-64 for Link 
Local addressing - only for auto-configuration.

So, what if a vendor's implementation is already broken, in that it 
violates the end-to-end principal for IPv6 addresses which are not 
auto-configuration generated?

Brian Dickson