Subject: [dhcwg] Issues with RFC 4361 reusing option 61

From: Santosh Chandwani <[email-masked]>
Date: Thu, 13 Mar 2008 17:38:29 +0800

Does anyone have experience implementing RFC 4361 for a large installed client base?

RFC 4361 recommends the use of the DUID+IAID as the client identifier (option 61) for DHCPv4. The problem we see is that we have a large installed base of clients that use the link-layer address of the network interface as the client identifier. In many of these deployments, the clients have address/configuration reservations which assume that the clients will send the link-layer address in option 61. Also, many consumers have home wireless routers, etc which assume that the clients will send the link-layer address in option 61.

If we make a change to use the DUID+IAID for option 61, customers who upgrade the OS on their clients in these existing deployments will find that their configuration is no longer valid. Customers will be faced with a migration challenge for all of the existing reservations, etc they have in place. Has anyone faced this problem and resolved it?

IMO, a better way to address these deployment challenges would be to use a new option number for the DUID+IAID. This would allow for more seamless migration and interop between older clients/servers which assume the link-layer address is included in option 61, and newer clients/servers which want to use the DUID+IAID.

Newer clients can then continue to send option 61 with the link-layer address, as well as a new option with DUID+IAID. If the server is capable of interpreting the new option number, it would do so. Otherwise, it can ignore the option and use option 61. This would allow for a better upgrade experience for both clients and servers.

Since RFC 4701 assumes that clients implement RFC 4361, this issue also blocks us from cleanly implementing DHCID-RR support.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Andre Kostur" <[email-masked]>
Date: Thu, 13 Mar 2008 13:43:11 -0700

Which devices assume that 61 contains a link-layer address when there's
a far easier way to get that information, namely the chaddr field?

In every deployment I've seen, if the admin wants to deal with the
link-layer address, then address reservations and other decisions are
all done on the chaddr field, not option 61.  Note that Microsoft RRAS
servers/services are already putting stuff in 61 that isn't a link-layer
address.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Santosh Chandwani
Sent: Thursday, March 13, 2008 2:38 AM
To: [email-masked]
Subject: [dhcwg] Issues with RFC 4361 reusing option 61

Does anyone have experience implementing RFC 4361 for a large installed
client base?

RFC 4361 recommends the use of the DUID+IAID as the client identifier
(option 61) for DHCPv4. The problem we see is that we have a large
installed base of clients that use the link-layer address of the network
interface as the client identifier. In many of these deployments, the
clients have address/configuration reservations which assume that the
clients will send the link-layer address in option 61. Also, many
consumers have home wireless routers, etc which assume that the clients
will send the link-layer address in option 61.

If we make a change to use the DUID+IAID for option 61, customers who
upgrade the OS on their clients in these existing deployments will find
that their configuration is no longer valid. Customers will be faced
with a migration challenge for all of the existing reservations, etc
they have in place. Has anyone faced this problem and resolved it?

IMO, a better way to address these deployment challenges would be to use
a new option number for the DUID+IAID. This would allow for more
seamless migration and interop between older clients/servers which
assume the link-layer address is included in option 61, and newer
clients/servers which want to use the DUID+IAID.

Newer clients can then continue to send option 61 with the link-layer
address, as well as a new option with DUID+IAID. If the server is
capable of interpreting the new option number, it would do so.
Otherwise, it can ignore the option and use option 61. This would allow
for a better upgrade experience for both clients and servers.

Since RFC 4701 assumes that clients implement RFC 4361, this issue also
blocks us from cleanly implementing DHCID-RR support.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Santosh Chandwani <[email-masked]>
Date: Fri, 14 Mar 2008 14:10:15 +0800

The devices don't have to assume that option 61 contains the link-layer address. Also, the fact that we allow other stuff to be sent in option 61 doesn't impact this issue.

The issue is that most clients send the link-layer address in option 61 by default, and many of our customers have made reservations based on option 61. Which implies that they now have reservations based on link-layer address in option 61. Hence, we will have a migration problem if we send the DUID+IAID in option 61, when these customers upgrade their clients.

---

From: Mark Stapp <[email-masked]>
Date: Fri, 14 Mar 2008 09:38:32 -0400

Hi Santosh,

but there are several ways to address the practical problem that you're 
   concerned about, right?

- the database containing the reservations' client-id values could be 
updated programmatically (if there's an algorithm that can convert a MAC 
to a DUID)

- the code in the affected servers could be updated to test chaddr 
instead of the client-id option value (that's the one I'd pick, because 
you already have the database, and this way it'd still work)

- the clients could send the old client-id value in, for example, a 
vendor-specific option, and the servers could test that value if it's 
present

- everyone involved could change to using some other identifier, based 
on the user logged in, or the geographical location, or the 
department+building+floor+power socket+...

none of those requires a _protocol_ change. they're just operational 
steps that'd be part of a migration plan. other than "scrap the RFC," is 
there some protocol change or enhancement that you think would make a 
rollout that changes client-ids work better?

Regards,
Mark

---

From: "H. Peter Anvin" <[email-masked]>
Date: Wed, 19 Mar 2008 06:16:48 -0700

> servers/services are already putting stuff in 61 that isn't a link-layer

Well, anything involving Infinibad devices, for one thing.  (The 
Infinibad link-layer address doesn't fit in the chaddr field.)

	-hpa

---

From: "David W. Hankins" <[email-masked]>
Date: Wed, 19 Mar 2008 07:59:19 -0700

> Infinibad link-layer address doesn't fit in the chaddr field.)

i don't think this WG has standardized DHCP over infiniband, but if it
did, i have a strong suspicion that the consensus would be to create a
'mac address option' relays (and servers) could reference in place of
the chaddr contents, and treat identically to chaddr.  similarly to
the existence of the tftp filename, tftp server name, etc dhcp options
that provide a way to transfer other bootp header contents either more
efficiently (when there is too much space and option overloading can
make use of it) or when there is insufficient space.

it would merely be a field that "means the same thing, but is larger",
and so wouldn't really change defined behaviours (except to seek this
option before inspecting chaddr).

a client would probably be asked to fill in as much as the chaddr
contents it reasonably can, to support older servers as best it can,
and to provide the full mac in this new option.

there are also other link types that have no mac layer address to
speak of, and so i think there is actually a case to be made that
clients should perform the opposing function; generate a DUID/IAID
based client id and downgrade it into the chaddr contents in some
fashion to at least have something to put there.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Mar 2008 11:03:23 -0700

> make use of it) or when there is insufficient space.

It might also make sense for the relay to use a relay agent information option for this purpose.

> fashion to at least have something to put there.

The way we've handled this in the past is to just broadcast the response.   There's an RFC (2855) describing how to do DHCP on Firewire if anybody's deeply interested.   It's a very quick read... :')