Subject: [dhcwg] DUID+IAID

From: "A. Gregory Rabil" <[email-masked]>
Date: Thu, 29 Mar 2012 10:18:13 -0400

Sorry, forgot to put a subject line...

On Thu, Mar 29, 2012 at 10:11 AM, A. Gregory Rabil
<[email-masked]>wrote:

> Hello DHC WG,
> I am looking for clarification around the IAID.  Some of this stems from
> the several discussions recently regarding the DUID and the lack of a MAC
> address in DHCPv6.
>
> Ted (don't mean to call you out here, but it is prevalent to my question)
> wrote this on the ISC DHCP list:
>
> >DUID+IAID uniquely identifies the interface; DUID uniquely identifies the
> host.
>
> My question is can this be guaranteed?  From RFC 3315:
>
>       Identity association (IA) A collection of addresses assigned to
>                                 a client.  Each IA has an associated
>                                 IAID.  A client may have more than one
>                                 IA assigned to it; for example, one for
>                                 each of its interfaces.
>
> It states "for example, one for each of its interfaces".  So, I don't see
> this as a MUST, or am I missing something?
>
> If the IAID is intended to identify the interface, then I wonder why that
> is not just the MAC address.  If that were the case, then every request
> would contain the DUID identifying the device, and the IAID to identify the
> actual interface in which the request was made.  I guess my concern is that
> if we start putting the MAC address in the DHCPv6 packet (which I am in
> favor of), then we should be sure to specify how it does or does not relate
> to the IAID.
>
> Regards,
>
> Greg Rabil
>
>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg
>
>

---

From: Francis Dupont <[email-masked]>
Date: Thu, 29 Mar 2012 16:34:18 +0200

>  > My question is can this be guaranteed?  From RFC 3315:

=> it is not specified as 1 - 1 relationship: what doesn't make sense
is to use the same DUID+IAID for different interfaces, not the opposite.

Regards

[email-masked]

PS: the hardware address option stuff is very different: the only idea
is to match DHCPv4 and DHCPv6 policies on hosts. BTW I think it is not
neutral to suggest to add it by relays vs by clients as one trusts less
clients than relays...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2012 14:41:34 +0000

> Ted (don't mean to call you out here, but it is prevalent to my question) wrote this on the ISC DHCP list:
>>DUID+IAID uniquely identifies the interface; DUID uniquely identifies the host.
> My question is can this be guaranteed?

No, I was oversimplifying.   The intent was that there might well be more than one IAID per interface.   In practice, I would expect an IA_NA and an IA_TA to use different IAIDs, for instance.   Similarly for IA_PD.   It was also intended that the client could ask for more than one set of IA_NA addresses per interface if it wanted to present more than one identity to the network.

Even if what I'd said weren't an oversimplification, it wouldn't work to use the MAC address as the IAID, because it's unnecessarily big.   I expect it to be rare that a single DHCP request will require 2^48 IAs.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Thu, 29 Mar 2012 13:06:19 -0400

Thanks Ted.

> The intent was that there might well be more than one IAID per interface.

> In practice, I would expect an IA_NA and an IA_TA to use different IAIDs,
for instance.   Similarly for IA_PD.

RFC 3315 states this:

   The IAID number space for the IA_TA option IAID number space is
   separate from the IA_NA option IAID number space.

Based on that statement, I was thinking that a typical implementation might
use the index of an interface as the IAID.  For example, eth0=IAID1.  Then,
if an IA_NA, IA_TA, or IA_PD sent on eth0, would all use IAID=1, and are
distinguished by IA_TYPE as described in the text above.  However, that
obviously would not work if there are more than one IA of the same type on
that interface, as you described:

> It was also intended that the client could ask for more than one set of
IA_NA addresses per interface if it wanted to present more than one
identity to the network.

Yes, and I believe this is further clarified in RFC 3315 with this text:

   A client must associate at least one distinct IA with each of its
   network interfaces for which it is to request the assignment of IPv6
   addresses from a DHCP server.  The client uses the IAs assigned to an
   interface to obtain configuration information from a server for that
   interface.  Each IA must be associated with exactly one interface.

So, each IA is associated with exactly one interface, but not necessarily
the other way around.

> Even if what I'd said weren't an oversimplification, it wouldn't work to
use the MAC address as the IAID, because it's unnecessarily big.   I expect
it to be rare that a single DHCP request will require 2^48 IAs.

Yes, from a implementation standpoint, there is obviously no need for the
whole MAC address to uniquely identify the request.  My point was simply
that since the IAID, at least in some cases (the oversimplified one), may
actually map to an interface, then it would be more useful to know which
interface it maps to.

With that said, I have some questions regarding the
proposed draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.

RFC 3315 mentions this:

   When a client sends a DHCP message to the
   All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
   through the interface for which configuration information is being
   requested.  However, the client MAY send the message through another
   interface attached to the same link

So, would the hardware-addr-option (or link-layer option) identify the MAC
of the interface on which the request was sent, or the MAC of the interface
"for which configuration information is being requested"?

Also, I recall a thread on the mailing list that discussed CPE routers
which may request an address for the WAN-side interface via an IA_NA option
along with an IA_PD request for the LAN-side interface.  I believe the
discussion was focused on the renew behavior.  However, IIRC, some
implementations may send the IA_NA and IA_PD in the same or separate
requests.  Regardless of one or two requests, the packets would
(presumably) be sent over the WAN-side interface.  In the situation where
the client sends the IA_NA and IA_PD in the same request packet, the
proposed link-layer address option would be the MAC of which interface -
WAN or LAN?  In the case of separate requests, would you then expect two
different MACs?  I think were I'm heading with this is that perhaps the
link-layer option needs to be "inside" the IA option, not at the outermost
message level of the packet.

Greg

On Thu, Mar 29, 2012 at 10:41 AM, Ted Lemon <[email-masked]> wrote:

> > Ted (don't mean to call you out here, but it is prevalent to my
> question) wrote this on the ISC DHCP list:
> No, I was oversimplifying.   The intent was that there might well be more
> than one IAID per interface.   In practice, I would expect an IA_NA and an
> IA_TA to use different IAIDs, for instance.   Similarly for IA_PD.   It was
> also intended that the client could ask for more than one set of IA_NA
> addresses per interface if it wanted to present more than one identity to
> the network.
>
> Even if what I'd said weren't an oversimplification, it wouldn't work to
> use the MAC address as the IAID, because it's unnecessarily big.   I expect
> it to be rare that a single DHCP request will require 2^48 IAs.
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 29 Mar 2012 21:52:49 +0000

> "for which configuration information is being requested"?

In practice there's no difference.   But it doesn't identify the interface.  It provides additional information about the interface that can be used as a database key to associate devices to the DUID.   A back-end database initialized by scanning the box a router came in might have four entries for the four hardware addresses of that router.   When a request comes in from that router, the database entry for each hardware address could be updated to refer to the same DUID.   In this way we can tie an existing hardware address-based back-end database to DUID.   That's the point of the exercise.

> Also, I recall a thread on the mailing list that discussed CPE routers which may
> request an address for the WAN-side interface via an IA_NA option along with an
> IA_PD request for the LAN-side interface.  I believe the discussion was focused on
> the renew behavior.  However, IIRC, some implementations may send the IA_NA
> and IA_PD in the same or separate requests.  Regardless of one or two requests
> the packets would (presumably) be sent over the WAN-side interface.  In the
> situation where the client sends the IA_NA and IA_PD in the same request packet,
> the proposed link-layer address option would be the MAC of which interface -
> different MACs?  I think were I'm heading with this is that perhaps the link-layer
> option needs to be "inside" the IA option, not at the outermost message level of the packet.

The problem we are trying to solve is twofold.   First, tying the mac address on a shipping box to a device making a query on the network using DUID.   Second, tying the chaddr field from a DHCPv4 message to the DUID of a DHCPv6 message.   So consider the CPE router--it's sending its DHCPv4 packet on the upstream interface, and it's sending its DHCPv6 packet on the upstream interface.   In both cases, the hardware address we want to send is the hardware address of the upstream interface.   It makes no sense to send the hardware address of any of the downstream interfaces.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Thu, 29 Mar 2012 21:17:05 -0400

> In practice there's no difference.   But it doesn't identify the
interface.
> It provides additional information about the interface that can be used
as a database key to associate devices to the DUID.

I am not sure I understand that.  Why would the proposed
hardware-addr-option not identify the interface?

In DHCPv4, we only know the interface identifier (chaddr), we can't really
identify the device itself.  That is, we can't correlate multiple
interfaces to the same device without resorting to something less than
ideal, such as the hostname.  In DHCPv6 (as it stands now), we can identify
the device (DUID), but not the interface.  My understanding of the proposal
is that the MAC address is *added* to the request as an option, so we would
have both the DUID and the MAC, thus allowing us to identify both the
device and the interface, which is good IMO.

>The problem we are trying to solve is twofold.   First, tying the mac
address on a shipping box to a device making a query on the network using
>DUID.   Second, tying the chaddr field from a DHCPv4 message to the DUID
of a DHCPv6 message.   So consider the CPE router--it's sending >its DHCPv4
packet on the upstream interface, and it's sending its DHCPv6 packet on the
upstream interface.   In both cases, the hardware >address we want to send
is the hardware address of the upstream interface.   It makes no sense to
send the hardware address of any of the >downstream interfaces.

Yes, I believe I understand this use case, and I agree that my example with
the downstream interface may not have been a good choice.  However,
consider a more complicated example where a device has multiple upstream
interfaces.  As I read that snippet from RFC 3315, such a device may send
multiple IAs in one request where, for example, one IA_NA is for upstream
interface A, and a second IA_NA is for upstream interface B.  If this is
possible, then I was simply suggesting that the proposed
hardware-addr-option be an IA-level option rather than a message-level
option, so as to identify each interface.

Greg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 06:22:55 +0000

> I am not sure I understand that.  Why would the proposed hardware-addr-option
> not identify the interface?

Because it is not an identifier.   It is a hint.   If you call it an identifier, someone will start using it as one.

> My understanding of the proposal is that the MAC address is *added* to the request
> as an option, so we would have both the DUID and the MAC, thus allowing us to
> identify both the device and the interface, which is good IMO.

In principle there's nothing incorrect about this statement, but in practice there is no protocol need to identify the interface.   So if you call it an identifier, people are going to confuse it with the DHCPv4 way of identifying *clients*, and not understand that you mean it to be identifying *interfaces*.   So it's better to not put it that way.

> As I read that snippet from RFC 3315, such a device may send multiple
> IAs in one request where, for example, one IA_NA is for upstream interface
> A, and a second IA_NA is for upstream interface B.  If this is possible, then
> I was simply suggesting that the proposed hardware-addr-option be an
> IA-level option rather than a message-level option, so as to identify each interface.

This is a use case that was advocated at the time RFC3315 was written, but I didn't understand at the time under what circumstances this would happen, and as the protocol has evolved, I think it's pretty clear that it isn't a plausible use case.   If you want to configure an interface, you send a DHCP packet on that interface, not on some other interface.

It's possible that you might want to use DHCP to allocate an address for a tunnel endpoint, but in that case there is no physical interface, and the MAC address that the relay agent will add to the packet will be the address of the physical interface, not the tunnel, which has no MAC address.   So this is another reason not to call this an "interface identifier."   It's the MAC address of the interface out which the DHCP packet was sent.

---

From: Tomek Mrugalski <[email-masked]>
Date: Fri, 30 Mar 2012 10:01:45 +0200

On 12-03-29 16:41, Ted Lemon wrote:
> No, I was oversimplifying.   The intent was that there might well be
> more than one IAID per interface.   In practice, I would expect an
> IA_NA and an IA_TA to use different IAIDs, for instance.  Similarly
> for IA_PD.   It was also intended that the client could ask for more
That is not guaranteed. I just checked RFC3315 and it is somewhat
contradictory. Is sending IA_NA and IA_PD legal? Page 11 says that
"Each IA has an IAID, which is chosen to be unique among all IAIDs for
IAs belonging to that client.". This suggest that the same iaid for
IA_NA and IA_PD is not valid. On the other hand, in section 4.2 there
following text "A binding containing information about an IA is indexed
by the tuple <DUID, IA-type, IAID>.". It suggests that IAID number
spaces for different IA types are orthogonal.

Oh well, yet another thing to clarify in 3315bis.

> than one set of IA_NA addresses per interface if it wanted to present
> more than one identity to the network.
Agree. There may be many IA_NA instances (or IA_PD or other IA types) in
a single message.

> Even if what I'd said weren't an oversimplification, it wouldn't work
> to use the MAC address as the IAID, because it's unnecessarily big.
Some implementations use part of MAC. I'm not sure what were the
original reasons for this, but that is mostly valid approach.

> I expect it to be rare that a single DHCP request will require 2^48
> IAs.
I expect it as well. Let's keep iaid as it is now - 32 bit is enough.

And if some brave soul insists on sending 2^48 IAs, he would have to
make sure that his DHCPv6 packets are fragmented properly. Which brings
us to yet another possible 3315bit thing. While I haven't seen any
DHCPv6 messages that are even close to 1280 bytes, it is something that
could possibly be clarified.

Tomek

---

From: Francis Dupont <[email-masked]>
Date: Fri, 30 Mar 2012 10:26:59 +0200

>  hardware-addr-option not identify the interface?

=> I raise here a silly but real concern: the common assumption
a MAC address is unique to a physical interface is *false*:
the IEEE spec is loose and uses the term device, it is commonly
but *not universally* interpreted as NIC, i.e., there is at least
one important vendor which assigns a MAC address to the whole box.

Regards

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 09:27:29 +0000

> I raise here a silly but real concern: the common assumption

Right, that's why we don't want to use it as an identifier.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Fri, 30 Mar 2012 10:04:40 -0400

> Right, that's why we don't want to use it as an identifier.

Okay, so given that the MAC address is not unique, then in order to
"provision" devices (aka static binding, reservation, or manual dhcp), the
administrator must know both the DUID and the MAC of the device to be
provisioned, correct?

Greg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 14:07:27 +0000

> Okay, so given that the MAC address is not unique, then in order to "provision"
> devices (aka static binding, reservation, or manual dhcp), the administrator must
> know both the DUID and the MAC of the device to be provisioned, correct?

If you "provision" you mean "connect to a back-office database that only has the MAC as a key" then yes.   Otherwise no.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Fri, 30 Mar 2012 10:19:02 -0400

In the case where a device only has one interface, then clearly only the
DUID is needed to provision it, or assign a specific address to it in the
case of a static-binding/reservation.  If devices have multiple interfaces,
then the DUID is not enough to uniquely reserve an address for each
interface (wired and wireless, for example).  In that case, you need the
DUID+MAC.

Greg

On Fri, Mar 30, 2012 at 10:07 AM, Ted Lemon <[email-masked]> wrote:

> "provision"
> If you "provision" you mean "connect to a back-office database that only
> has the MAC as a key" then yes.   Otherwise no.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 14:58:36 +0000

> In the case where a device only has one interface, then clearly only the DUID
> is needed to provision it, or assign a specific address to it in the case of a
> static-binding/reservation.  If devices have multiple interfaces, then the DUID
> is not enough to uniquely reserve an address for each interface (wired and
> wireless, for example).  In that case, you need the DUID+MAC.

No, that's what IAID is for.   DUID+IAID provides a unique identifier that allows a client to configure multiple interfaces, or multiple network identities, using a consistent DUID.   MAC address is _not_ related to this.   At all.

---

From: [email-masked]
Date: Fri, 30 Mar 2012 17:02:50 +0200 (CEST)

> administrator must know both the DUID and the MAC of the device to be

The assumption that the MAC address is unique is indeed false. In
addition to the one-MAC-per-box model (Sun at least *used to* have
this), you also have customers cloning a MAC address they have found
on a web page, and similar fun stuff. Providers with a large pool of
DHCP customers are almost guaranteed to have several duplicates.

However, in practice the MAC address is for the most part good enough,
and I see no need for both DUID and MAC for static address assignment.

Steinar Haug, Nethelp consulting, [email-masked]

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Fri, 30 Mar 2012 11:03:10 -0400

If I want to assign a specific address to the wired interface and a
separate, specific address to the wireless interface, how do I know what
the IAID will be for each of them?

On Fri, Mar 30, 2012 at 10:58 AM, Ted Lemon <[email-masked]> wrote:

> DUID
> No, that's what IAID is for.   DUID+IAID provides a unique identifier that
> allows a client to configure multiple interfaces, or multiple network
> identities, using a consistent DUID.   MAC address is _not_ related to
> this.   At all.
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 15:12:19 +0000

> If I want to assign a specific address to the wired interface and a separate, specific address to the wireless interface, how do I know what the IAID will be for each of them?

You find out when you get a DHCP packet from each interface, and each packet contains a DUID+IAID, and also contains the hardware address (assuming that you already know which hardware address corresponds to which interface).

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Fri, 30 Mar 2012 12:39:01 -0400

On Fri, 2012-03-30 at 06:22 +0000, Ted Lemon wrote:
> Because it is not an identifier.   It is a hint.   If you call it an
>  identifier, someone will start using it as one.

It is an identifier, or at least the IEEE tries fairly hard to make it
one.  It's just not an identifier that's guaranteed to be bound to
anything useful to DHCP, and especially not to the client as a whole.

Note that one reason you can't use a MAC address as an identifier _at
the protocol layer_ is because some clients will end up using the same
MAC address on multiple interfaces.  For example, until only a few years
ago, Sun boxes had a single MAC address for the entire machine, and used
that address for every interface.

> In principle there's nothing incorrect about this statement, but in
>  practice there is no protocol need to identify the interface.

True -- the _protocol_ has no such need.  But that doesn't change
whether the hardware address is in fact an identifier.

More importantly, the question of whether this is an "identifier" or not
is a pointless distraction from the original question, which was about
_which interface's_ hardware address the option is expected to contain.

> It's possible that you might want to use DHCP to allocate an address
>  for a tunnel endpoint, but in that case there is no physical
>  interface, and the MAC address that the relay agent will add to the
>  packet will be the address of the physical interface, not the tunnel,
>  which has no MAC address.   So this is another reason not to call this
>  an "interface identifier."   It's the MAC address of the interface out
>  which the DHCP packet was sent.

In fact, it sounds like it's exactly the source MAC address of the
packet as it was received by the relay agent.

---

From: "A. Gregory Rabil" <[email-masked]>
Date: Fri, 30 Mar 2012 14:32:47 -0400

I was considering the case where an administrator wants to configure it on
DHCP server ahead of time.  So, where they might know the MAC (because it
was printed somewhere) of both interfaces, they probably don't know the
IAIDs the device may choose for those interfaces, nor which IAID may
correspond to which interface.  I totally agree with you that from protocol
standpoint, we have all that is needed to uniquely identify things
(DUID+IAID+IA_type).  From an administrative standpoint, however, I believe
they need DUID+MAC to configure a truly unique static binding, because as
you and others have pointed out, the MAC is not unique.

Greg

On Fri, Mar 30, 2012 at 11:12 AM, Ted Lemon <[email-masked]> wrote:

> You find out when you get a DHCP packet from each interface, and each
> packet contains a DUID+IAID, and also contains the hardware address
> (assuming that you already know which hardware address corresponds to which
> interface).
>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 30 Mar 2012 19:10:08 +0000

Greg, this is getting exhausting.   The MAC is not a unique identifier, even for an individual client.   Every request that comes out of an interface will have the same MAC address under this proposal.   This is true even if more than one IAID is presented per interface.   So identifying host interfaces this way won't work.

>From an administrative standpoint, you can use the mac to associate with the client in your administrative database or UI.   You can use the mac to associate DHCPv4 clients with a DHCPv6 client (notice the many-to-one mapping here: a dual-stack device with two interfaces will appear to be two clients to the DHCPv4 server).

So the MAC address is useful, but it does not fit into the box you are trying to shoehorn it into here.