[ppml] PPML Digest, Vol 28, Issue 51

[mack]

> -----Original Message-----
> From: Brian Dickson [mailto:briand at ca.afilias.info]
> Sent: Monday, October 22, 2007 4:58 PM
> To: mack
> Cc: ppml at arin.net
> Subject: Re: [ppml] PPML Digest, Vol 28, Issue 51
>
> 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.

Auto-configuration is only one set of RFCs.
There was a list posted to the mailing list.
Not sure what the conflict has to do with implementation but that is discussed later.

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

Some current implementations will support auto-configuration with lengths other than /64.
A sufficient number will not.  Your proposal does not make allowances for that.

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

Yes, all of those are effected as well.
Any address that contains data in the effected bits is effected.
EUI-64 and link local constructed from MAC addresses do not contain
useful information in those bits.

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

It is an unfortunate side effect of the ACL TCAM implementation used.
You can either have ACLs with full IP information and not port information
Or port information and lose 16 bits of the address.
As a major portion of the internet runs on this hardware it is a major issue.

Your proposal does not address the issue.

>
> Brian Dickson