Re: IPv6 "bloat"

[Michael Thomas <mike () mtcc com>]

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.


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

I guess you've not heard of privacy addresses. Or DHCPv6.

Mike