IPv6 "bloat"

Owen DeLong owen at delong.com
Sun Mar 20 06:34:35 UTC 2022


DHCPv6 includes the DEVICE Unique Identifier (DUID). DUID can be any one of several things.

By far, the most common ones actually do include the MAC address.

Some systems allow you to choose which type of DUID they supply.

Macs use a long string that includes the EUI-64 at the end:
(an expert from a static host entry in dhcpv6d.conf for a Mac host:
	host-identifier option dhcp6.client-id 00:01:00:01:23:d6:92:16:68:fe:f7:07:11:6f;
	hardware ethernet 68:fe:f7:07:11:6f; 
)

Some hosts don’t provide the MAC address, but they provide a device unique identifier which is equally useful for authentication, frankly.
For example, a Raritan KVM:
	host-identifier option dhcp6.client-id 00:02:00:00:35:ae:31:49:54:39:41:30:30:31:34:38 ; 

HP Printers provide yet another format of DUID:
        host-identifier option dhcp6.client-id 00:01:00:01:01:e2:85:23:b8:db:ad:ba:db:ad ;


It’s a little more awkward than DHCPv4, but once you get used to it, it’s really not so bad. It’s a slight challenge for providing hosts reserved addresses, but otherwise, it’s just larger fields in the log entries.

Owen

> On Mar 19, 2022, at 16:20 , Matt Hoppes <mattlists at rivervalleyinternet.net> wrote:
> 
> On a public network (such as WiFi - sure).  On a private network where the only authentication taking place is to the modem which is provided by the service provider, not so much.  It's a closed environment.  The modem demarcs to the end-user and the end-user never touches the switching fabric.
> 
> Interesting about DHCPv6 Option 79.  I had not run across that before. I will look into that more.  Thank you.
> 
> On 3/19/22 7:18 PM, Michael Thomas wrote:
>> Thanks, I didn't think that they'd something that interfered with AAA. Using a MAC address as authentication seems sort of sketch to me in the first place.
>> Mike
>> On 3/19/22 4:14 PM, Tom Beecher wrote:
>>> 
>>>    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.
>>> 



More information about the NANOG mailing list