atom feed63 messages in org.isc.lists.dhcp-usersRe: DHCPv6 and MAC Address inclusion
FromSent OnAttachments
9 earlier messages
John HascallJan 23, 2012 2:05 pm 
scot...@trendmicro.comJan 23, 2012 4:22 pm 
Ted LemonJan 24, 2012 12:06 am 
sth...@nethelp.noJan 24, 2012 12:33 am 
scot...@trendmicro.comJan 24, 2012 1:34 am 
Simon HobsonJan 24, 2012 3:09 am 
perl-listJan 24, 2012 6:27 am 
Walter Andrew ScottJan 24, 2012 6:49 am 
perl-listJan 24, 2012 6:53 am 
Casey DeccioJan 24, 2012 9:33 am 
James JalbertJan 24, 2012 9:47 am 
perl-listJan 24, 2012 10:10 am 
Walter Andrew ScottJan 24, 2012 1:43 pm 
Ted LemonJan 24, 2012 2:48 pm 
Ted LemonJan 24, 2012 2:52 pm 
scot...@trendmicro.comJan 24, 2012 2:55 pm 
scot...@trendmicro.comJan 24, 2012 3:01 pm 
Ted LemonJan 24, 2012 3:12 pm 
scot...@trendmicro.comJan 24, 2012 3:25 pm 
José QueirozJan 24, 2012 4:42 pm 
perl-listJan 24, 2012 6:39 pm 
Alex BlighJan 25, 2012 12:18 am 
sth...@nethelp.noJan 25, 2012 1:58 am 
Simon HobsonJan 25, 2012 2:05 am 
perl-listJan 25, 2012 5:51 am 
José QueirozJan 25, 2012 6:22 am 
Ted LemonJan 25, 2012 8:38 am 
perl-listJan 25, 2012 9:26 am 
Simon HobsonJan 25, 2012 10:21 am 
Michael Dean PughJan 25, 2012 12:00 pm 
scot...@trendmicro.comJan 25, 2012 12:22 pm 
scot...@trendmicro.comJan 25, 2012 12:23 pm 
perl-listJan 25, 2012 12:35 pm 
Ted LemonJan 25, 2012 12:36 pm 
Ted LemonJan 25, 2012 12:38 pm 
perl-listJan 25, 2012 12:44 pm 
Ted LemonJan 25, 2012 12:44 pm 
Ted LemonJan 25, 2012 12:50 pm 
perl-listJan 25, 2012 12:54 pm 
Ted LemonJan 25, 2012 12:55 pm 
Ted LemonJan 25, 2012 1:02 pm 
Rudy ZijlstraJan 25, 2012 1:23 pm 
scot...@trendmicro.comJan 25, 2012 4:11 pm 
Michael Dean PughJan 25, 2012 5:56 pm 
Ted LemonJan 25, 2012 9:11 pm 
Ted LemonJan 25, 2012 9:12 pm 
scot...@trendmicro.comJan 25, 2012 9:20 pm 
perl-listJan 26, 2012 9:53 am 
Ted LemonJan 26, 2012 2:57 pm 
Bjørn MorkJan 27, 2012 12:48 am 
4 later messages
Subject:Re: DHCPv6 and MAC Address inclusion
From:perl-list (perl@network1.net)
Date:Jan 25, 2012 5:51:53 am
List:org.isc.lists.dhcp-users

----- Original Message -----

From: "Simon Hobson" <dhc@thehobsons.co.uk> To: "Users of ISC DHCP" <dhcp@lists.isc.org> Sent: Wednesday, January 25, 2012 5:05:29 AM Subject: Re: DHCPv6 and MAC Address inclusion

Lets face it, there are still plenty of ways to make a non-compliant implementation - such as splitting an LL or LLT identifier to extract the hardware address, something that is now encouraged by it not being present in the request packets in it's own field/option.

Simon - thank you for your comments as always they are quite refreshing.

The above assumes that the DUID will actually contain the MAC address. In my
experience, it does not on all systems.

We are left with attempting to identify a client based on information that is
not necessary for the client to transmit and receive on the network. Letting the
client make up bits of information that are to be used to identify them
certainly doesn't sound like a good foundation for good security practice. I
realize that the RFCs say that the client must make up the DUID in one of three
ways. In practice however there is no way to enforce this. A DUID could be made
up based on the current astrological positions as long as it follows the correct
format (and I'm not even sure how loosely the format is restricted).

With DHCPv4 we could identify the client with two pieces of information that
were necessary to transmit on the network not only one (IP Address). Further, we
could decide to allow them on the network based on one piece of information that
they needed to talk on the network prior to receiving the second bit of
information - the IP Address. The DUID? Well ... since it is not necessary for
any sort of communication, it cannot be enforced.

I understand where some of this is coming from. Academic vs. Operational
philosophy . Academics are nice, but if the system that is cooked up is not
useable by the operational people, it will not be used. If the academics are
resistant to suggestion from the operational people, then we will have to wait
until some large operational people such as Microsoft or Cisco come up with a
solution and use their clout to push it through.

BTW: people on the NANOG list are advocating splitting the mac from the LL or
LLT identifier as mentioned above for subscriber identification as they, being
operational, recognize the importance of identifying that the DHCPv6 and DHCPv4
client are one in the same. We have pointed out to them that this will not work
in all cases and there is much renewed head scratching.