Subject: [dhcwg] DHCPv6 Lease Query question

From: Bud Millwood <[email-masked]>
Date: Thu, 9 Dec 2010 12:11:47 +0100

I have a question about Lease Query for DHCPv6 - a simple question, I think,
but since I have little experience with v6LQ in practice, maybe someone can
enlighten me.

How is it possible for a layer 2 edge device to use the result of any DHCPv6
LQ to 'backtrack' to the hardware address being queried for?

For example, if a device has an IP already, and the edge system reboots, the
device is now only attempting to transmit IP packets (not DHCP packets). The
edge system needs to query the server, but all it really knows is the mac
address (from the frames) and the ip address the device is using. How can it
verify that the IP address actually belongs to this particular mac address?

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 9 Dec 2010 10:02:42 -0500

Yes this is an issue. DOCSIS solved this using vendor options that the relay adds and then can get back. That may be the only choice at present?

We were discussing a media address type option at one point that would have solved this but it kind of died when CableLabs decided to use the Vendor options.

I think the concept was to use something like the ND media data for this.

The relay (and client?) could add this option to incoming requests (relay could asked for it back using echo option, and would get it back in relay data for LQ).

I'll see if we still have something from a previous draft, but may require new work.

Sent from my iPad

On Dec 9, 2010, at 6:11 AM, "Bud Millwood" <[email-masked]> wrote:

> I have a question about Lease Query for DHCPv6 - a simple question, I think, but since I have little experience with v6LQ in practice, maybe someone can enlighten me.
> 
> How is it possible for a layer 2 edge device to use the result of any DHCPv6 LQ to 'backtrack' to the hardware address being queried for?
> 
> For example, if a device has an IP already, and the edge system reboots, the device is now only attempting to transmit IP packets (not DHCP packets). The edge system needs to query the server, but all it really knows is the mac address (from the frames) and the ip address the device is using. How can it verify that the IP address actually belongs to this particular mac address?
> 
> - Bud
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 10 Dec 2010 12:57:36 -0600

I think I indicated both could be possible.

The only reason why the client supplying this is, IMHO, less interesting
is that you can replace your relay agent software way before you can fix
all clients. Also, client may lie (I'm not saying they generally will,
but they could). So, trusting a client is not the best idea. I do agree
that having this option be available to both clients and relays is the
best - any LQ device would use the relay's information if available and
fall 'back' to the clients if needed.

I should add though that this information *IS* available today to LQ
devices. Simply use the EUI from the peer-address in the relay data.

-          Bernie

From: David Hankins [mailto:[email-masked]] 
Sent: Friday, December 10, 2010 1:46 PM
To: Bernie Volz (volz)
Subject: Re: [dhcwg] DHCPv6 Lease Query question

On Thu, Dec 9, 2010 at 7:02 AM, Bernie Volz (volz) <[email-masked]>
wrote:

We were discussing a media address type option at one point that would
have solved this but it kind of died when CableLabs decided to use the
Vendor options.

There are a lot of non-DOCSIS networks that will need to update existing
infrastructure that's heavily reliant on maps of hardware addresses.
They can of course massage this into other formats - 8 to 16 bits of
HTYPE is easy, but they can't necessarily terminate the use of mac
addresses as forms of hardware registration and identification (so,
Thomas' DUID-UUID is not complete).

I see their current practice - modifying a DHCPv6 relay to capture the
source hardware address of client requests - to also be incomplete, a
temporary transition technology, chiefly because it denies the existence
of earlier relays in these environments (the source IPv6 address and
source MAC at the hardware level are then changed).

The appropriate long-term change is for DHCPv6 clients to start
advertising their hardware address(es).