Re: IPv6 "bloat"

[Enno Rey <erey () ernw de>]

Hi,

On Sat, Mar 19, 2022 at 07:11:47PM -0400, Matt Hoppes wrote:
> I misspoke... it's not UUID... It's DUID.
>
> This isn't a backend management issue.  This is a protocol issue.  The 
> MAC of the interface needs to be sent with a DHCP request so that it can 
> be properly authenticated to the physical device.
>
> As long as the client and DHCPv6 server are on the same network 
> interface -- it all works fine.  However, when you relay that 
> information, you now lose the MAC address information.

RFC 6939 solves that, since a long time.
See also: 
https://insinuator.net/2015/02/is-rfc-6939-support-finally-here-checking-the-implementation-of-the-client-link-layer-address-option-in-dhcpv6/


> Further, because the MAC is disconnected in IPv6 it becomes more 
> difficult to make the connection between IPs on a dual-stack client.

Not sure if I agree with that either. That connection can be made by various other means, see
https://theinternetprotocolblog.wordpress.com/2020/03/14/does-one-need-dhcpv6/

cheers

Enno






> Everyone prints the MAC (a unique ID on devices and devices packaging). 
> Almost nobody prints the DUID on a device, so how do you pre-populate 
> your DHCP server?  I can see that it encourages "one interface per 
> network" and so encourages bonding, bridging or whatever, but is being 
> able to differentiate the interfaces of a host really so bad? I can't 
> help but feel that it would have been nice for DHCPv6 to send DUID and MAC.
>
>
>
> On 3/19/22 7:03 PM, Michael Thomas wrote:
> > 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.

-- 
Enno Rey

Cell: +49 173 6745902
Twitter: @Enno_Insinuator