DHCPv6 and MAC Address inclusion

[perl-list]

see responses inline. 

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

> From: "Ted Lemon" <Ted.Lemon at nominum.com>
> To: "Users of ISC DHCP" <dhcp-users at lists.isc.org>
> Sent: Tuesday, January 24, 2012 6:12:12 PM
> Subject: Re: DHCPv6 and MAC Address inclusion

> On Jan 24, 2012, at 9:27 AM, perl-list wrote:
> > In other words... How could I know that the client that has 1.2.3.4
> > is the same client that has 1234::fffa? The DHCP server has no
> > information available that would allow this determination
> > presently.

> Why do you care?
For subscriber identification. We have the subscribers easily identified in DHCPv4. Short of requiring them to authenticate themselves a second time, I am not seeing how we can identify them in DHCPv6 using their DHCPv4 "knownness" 
> > I just don't understand why it was chosen that mac address (read:
> > link layer identifier) was left out of the DHCPv6 packet. What was
> > the reasoning there? What was the harm in including it? Is it not
> > better to have to much information rather than to little?

> If you can count on the MAC address being there, you can use it as an
> identifier in a non-conforming DHCPv6 implementation. We didn't want
> that, so we couldn't specify it in such a way that that would be
> possible. I've got nothing against an option that includes this
> information, as long as it's not required, and hence can't be
> counted on.
If the MAC were there, how would that break things specifically counting on it? Has the MAC address been deemed something evil? We know they are going to continue to exist as long as devices continue to send ethernet frames... 
> > The link layer identifier can be used to track down the client on
> > the network FAR more easily than either the DUID or IAID both of
> > which can be made up by the client in any way that they see fit
> > (and they are - see windows7 and D-link routers for examples) RFC
> > not withstanding. Further, some have said use the link-local
> > address. That is completely random in the windows7 world. It
> > cannot be decoded back to some useful piece of information.

> If you have a device on the wire talking to the DHCP server, why
> don't you have enough information to track it down from the relay
> agent information?
We could potentially track it down using the IP address, although in the case of some DSLAMS this may not be possible. 
> > If someone has some idea how one might correlate a DHCPv4 and
> > DHCPv6 client who are one in the same please enlighten me and
> > don't read the rant below :)

> Look at the hostname option?
Experience has shown that some clients do not implement the hostname as given by DHCPv4 (specifically, I believe, windows doesn't care about the hostname - as far as I have seen only MacOS and Linux cares about this option). 
> >
> > <rant>
> >
> > Now we are left with a crippled standard that is going to make life
> > VERY difficult for administrators who choose to use DHCPv6. As far
> > as I can tell, in the ISP world, this will not really be a choice
> > that we can make. If we want to do anything other than static
> > assignments, DHCPv6 will be required as Prefix Delegation is
> > necessary due to the purposeful lack of NAT in the IPv6 world. A
> > public network MUST be delivered in some way to a home router.
> > Static or Prefix Delegation via DHCPv6 are your choices. I could
> > be wrong, of course, but that is my understanding.
> >
> > Life has been made difficult for administrators due to this. I
> > imagine some will choose to attempt static assignment. Tech
> > support employment should rise dramatically I suppose. Perhaps we
> > should be thankful for the uptick in the job market.
> >
> > </rant>

> It's not been our goal to make it easy for you to deliver a broken
> network. NAT is a really, really bad thing for the Internet. PD is
> intended to give ISPs the same experience as NAT, without the crappy
> brokenness that NAT causes. There's a spec that defines what a v6
> home gateway ought to look like, that gives you all the security
> that NAT got you, plus some more, and supports prefix delegation.
Please understand - I wasn't advocating a return to NAT. I was just lamenting that we ISPs are going to HAVE to use DHCPv6 is far as I can tell, at least for prefix delegation. We MUST be able to correlate the identity of a client device or allocated subnet to a customer, at least in the USA. 
> I get the sense that you're experiencing a bit of fear, uncertainty
> and doubt about the IPv6 transition. This is entirely
> understandable, but I don't think it's as bad as you imagine. You
> might benefit from hanging out with some people who are actually
> delivering DHCPv6 today and learning how they are doing it. Go to
> the IETF, or NANOG, or find someone to visit. It may be that there
> is something that needs to be fixed that we haven't thought of (I
> happen to know that multihoming is broken, but that's not what
> you're complaining about). If so, it's going to be easier to get
> some clarity on that in a face to face setting at IETF than in a
> conversation on this mailing list.
I am most certainly experiencing as you say FUD mostly because I am attempting to setup a test environment showing how we could move ahead with DHCPv6 rollout ahead of the coming IP exhaustion in 2013. The state of things currently have left me scratching my head and adding to the baldness. I am able to lease IP addresses and delegate prefixes easily enough. I have not been able to find some predictable piece of information, even in packet dumps, that could be used to correlate devices to subscribers consistently in DHCPv6. 

We have an employee who goes to NANOG and ARIN meetings. All of the administrators that he has run into that are actually doing something with IPv6 are not doing so for end users quite yet. Most of them have test environments running , or are providing DHCPv6 on a non-hostile network. The vast majority are doing DHCPv6 (or - egads - SLAAC) directly from the router in an anonymous way. This obviously will not work in a hostile environment such as an ISP. 

Any other ISP administrators out there that have figured this out already and would like to share? 
> _______________________________________________
> dhcp-users mailing list
> dhcp-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/dhcp-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20120124/181e8afb/attachment.html>