Help with DHCPv6 client-identifiers

[sthaug at nethelp.no]

> > Um, as long as I use routing on more than 64 bits within my own AS,
> > on links I control, how have I broken your ability to use SEND/CGA?
> 
> You're already demanding that we change the DHCP architecture to
> suit your needs, and change the routing architecture, and the host
> requirements, and so on.

Not really. I'm asking for a change specifically to DHCPv6 so that a MAC
address can be transmitted from client to server. I'm perfectly happy if
this is in *addition* to whatever identifier current DHCPv6 standards
mandate. Thus I think an RFC which specifies a MAC address as a form of
"hint" would be just fine. I *do* think this should have been in DHCPv6
from the start.

As for the routing architecture and the host requirements - no, I'm not
demanding anything. I'm saying people *are* routing on longer than 64
bit prefixes today. Have you for instance looked into the popularity of
/128 as a loopback address?

> > I claim that routing on more than 64 bits is already in use in plenty
> > of places on the Internet (not just my own AS), and is not about to
> > disappear any time soon. However, I don't believe this qualifies as
> > the Internet architecture being broken. Others may disagree.
> 
> Routing using /127s is certainly in use.   Is that what you mean, though?

/127 is being used on point to point links. On *Ethernet* point to point
links several other prefix lengths are used also, e.g. /112 seems to be
quite popular. As another example: On the Ethernet point to point links
to our Internet transit providers, two of them use /126 and one uses /64.

Steinar Haug, Nethelp consulting, sthaug at nethelp.no