> > 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. >
DHCPv6 Option 79 https://datatracker.ietf.org/doc/html/rfc6939 > > On Sat, Mar 19, 2022 at 6:58 PM Matt Hoppes < mattli...@rivervalleyinternet.net> 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. > > > Secondly - and less importantly to deployment, IPv6 also provides a > layer of problematic tracking for advertisers. Where as before many > devices were behind a PAT, now every device has a unique ID -- probably > for the life of the device. Marketers can now pinpoint down not just to > an IP address that identifies a single NAT interface, but each > individual device. This is problematic from a data collection standpoint. > >
