IPv6 "bloat"

Tom Beecher beecher at beecher.cc
Sat Mar 19 23:14:55 UTC 2022


>
> 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 at 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20220319/d13c5420/attachment.html>


More information about the NANOG mailing list