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