Hi, On Sat, Mar 19, 2022 at 07:11:47PM -0400, Matt Hoppes wrote: > I misspoke... it's not UUID... It's DUID. > > This isn't a backend management issue. This is a protocol issue. The > MAC of the interface needs to be sent with a DHCP request so that it can > be properly authenticated to the physical device. > > As long as the client and DHCPv6 server are on the same network > interface -- it all works fine. However, when you relay that > information, you now lose the MAC address information.
RFC 6939 solves that, since a long time. See also: https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/ > > Further, because the MAC is disconnected in IPv6 it becomes more > difficult to make the connection between IPs on a dual-stack client. Not sure if I agree with that either. That connection can be made by various other means, see https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/ cheers Enno > > Everyone prints the MAC (a unique ID on devices and devices packaging). > Almost nobody prints the DUID on a device, so how do you pre-populate > your DHCP server? I can see that it encourages "one interface per > network" and so encourages bonding, bridging or whatever, but is being > able to differentiate the interfaces of a host really so bad? I can't > help but feel that it would have been nice for DHCPv6 to send DUID and MAC. > > > > On 3/19/22 7:03 PM, Michael Thomas wrote: > > > > On 3/19/22 3:56 PM, Matt Hoppes wrote: > >> > >> > >> On 3/19/22 6:50 PM, Michael Thomas wrote: > >>> > >>> On 3/19/22 3:47 PM, Matt Hoppes wrote: > >>>> It has "features" which are at a minimum problematic and at a > >>>> maximum show stoppers for network operators. > >>>> > >>>> IPv6 seems like it was designed to be a private network > >>>> communication stack, and how an ISP would use and distribute it was > >>>> a second though. > >>> > >>> What might those be? And it doesn't seem to be a show stopper for a > >>> lot of very large carriers. > >> > >> Primarily the ability to end-to-end authenticate end devices. The > >> primary and largest glaring issue is that DHCPv6 from the client does > >> not include the MAC address, it includes the (I believe) UUID. > >> > >> We have to sniff the packets to figure out the MAC so that we can > >> authenticate the client and/or assign an IP address to the client > >> properly. > >> > >> It depends how you're managing the network.?? If you're running PPPoE > >> you can encapsulate in that.???? But PPPoE is very 1990 and has its own > >> set of problems.?? For those running encapsulated traffic, > >> authentication to the modem MAC via DHCP that becomes broken.?? And > >> thus far, I have not seen a solution offered to it. > > > > I was honestly more interested in the bloat angle, but this sounds like > > a backend problem of your own making most likely. But I'm not motivated > > to see if it's actually the case or just a misunderstanding. -- Enno Rey Cell: +49 173 6745902 Twitter: @Enno_Insinuator
