Subject: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2011 01:50:31 -0500

I have been at Interop 2011 working as part of the InteropNet team as
Cisco is a sponsor/provider of the network.

The one DHCPv6 issue that came up, which isn't new, is that there were
incidences of duplicate IPv6 address assigned from the DHCP Server
(Cisco Network Registrar) - this was obvious from the DHCPv6 DECLINE
messages which like DHCPv4 DHCPDECLINEs should generally NOT occur. This
was because one of the vendors that supplied PCs for A/V needs, attendee
use, and conference operations had cloned a Windows 7 machine and not
wiped out the Dhcpv6DUID registry key. (I suspect more than one vendor
might have been involved given the number of different DUIDs but it
could also have been different images for different system types.)

I suspect that this will be a reoccurring issue and I figured it was
worth highlighting, at least to the DHC WG mailing list. The more people
that know about this requirement, the better - both in reducing its
occurrence in the first place, and understanding what it is and how to
resolve it should It happen.

It was pretty easy to resolve on a machine-by-machine basis (in some
cases, IPv6 was disabled; in others the registry key was deleted and
machine rebooted).

Incidentally, between 33% and 40% of the DHCPv4 devices (visitors,
exhibitors, conference operations) likely support DHCPv6 which was, to
me at least, a surprisingly high percentage (this figure is based on the
percentage of active leases - DHCPv6 count / DHCPv4 count). But this is
good news for DHCPv6 and IPv6 in general.

-          Bernie

---

From: "Brzozowski, John" <[email-masked]>
Date: Wed, 11 May 2011 11:55:03 +0000

Bernie,

Are there any more details available, specifically what OSes or devices
supported DHCPv6 and IPv6?

Apologies for uninformed questions, I am not familiar with how Interop is
run.  Will they issue any sort of report or paper outlining the
activities/testing?

Thanks,

John
=========================================
John Jason Brzozowski
Comcast Cable
e) mailto:[email-masked]
o) 609-377-6594
m) 484-962-0060
w) http://www.comcast6.net
=========================================

On 5/11/11 2:50 AM, "Bernie Volz (volz)" <[email-masked]> wrote:

>The one DHCPv6 issue that came up, which isn¹t new, is that there were
>incidences of duplicate IPv6 address assigned from the DHCP Server (Cisco
>Network Registrar)  this was obvious from the DHCPv6 DECLINE messages
>which like DHCPv4 DHCPDECLINEs should generally NOT occur. This was
>because one of the vendors that supplied PCs for A/V needs, attendee use,
>and conference operations had cloned a Windows 7 machine and not wiped
>out the Dhcpv6DUID registry key. (I suspect more than one vendor might
>have been involved given the number of different DUIDs but it could also
>have been different images for different system types.)
> 
>that know about this requirement, the better  both in reducing its
>exhibitors, conference operations) likely support DHCPv6 which was, to me
>at least, a surprisingly high percentage (this figure is based on the
>percentage of active leases  DHCPv6 count / DHCPv4 count). But this is
>_______________________________________________
>dhcwg mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2011 08:23:05 -0400

On May 11, 2011, at 2:50 AM, Bernie Volz (volz) wrote:
> The one DHCPv6 issue that came up, which isn’t new, is that there were incidences of duplicate IPv6 address assigned from the DHCP Server (Cisco Network Registrar) – this was obvious from the DHCPv6 DECLINE messages which like DHCPv4 DHCPDECLINEs should generally NOT occur. This was because one of the vendors that supplied PCs for A/V needs, attendee use, and conference operations had cloned a Windows 7 machine and not wiped out the Dhcpv6DUID registry key. (I suspect more than one vendor might have been involved given the number of different DUIDs but it could also have been different images for different system types.)

Ouch.   This is a problem we were concerned about; it's unfortunate to see that it is prevalent in practice and not just something to worry about.

Doesn't Windows have a post-clone mechanism for wiping information that needs to be configured on a per-machine basis?   (I assume Windows because you mentioned the registry).

Thanks for bringing this up here!

---

From: Bud Millwood <[email-masked]>
Date: Wed, 11 May 2011 16:51:13 +0200

>
> The one DHCPv6 issue that came up, which isn’t new, is that there were
> Network Registrar) – this was obvious from the DHCPv6 DECLINE messages which
> like DHCPv4 DHCPDECLINEs should generally NOT occur. This was because one of
> the vendors that supplied PCs for A/V needs, attendee use, and conference
> operations had cloned a Windows 7 machine and not wiped out the Dhcpv6DUID
> registry key. (I suspect more than one vendor might have been involved given
> the number of different DUIDs but it could also have been different images
> for different system types.)
>
>
> Ouch.   This is a problem we were concerned about; it's unfortunate to see
> that it is prevalent in practice and not just something to worry about.
>
> Doesn't Windows have a post-clone mechanism for wiping information that
> needs to be configured on a per-machine basis?   (I assume Windows because
> you mentioned the registry).
>

We agree that this is not something to "fix" with DHCPv6, right? This is
equivalent to cloning a machine that has a static address and leaving the
same configuration.

That said, relay agents that add hardware address to option 82 could make
this easier to detect when relays are present. Just sayin'. :)

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2011 14:33:08 -0500

>We agree that this is not something to "fix" with DHCPv6, right? This

>is equivalent to cloning a machine that has a static address and
leaving

>the same configuration.

Correct. Just something that is important for the "world" to know about
... when cloning a system, make sure to 'reset' the DHCP DUID.

People seem to understand that one must change the hostname, etc, but
they may not be as aware of this issue.

-          Bernie

From: Bud Millwood [mailto:[email-masked]] 
Sent: Wednesday, May 11, 2011 10:51 AM
To: Ted Lemon
Cc: Bernie Volz (volz); [email-masked]; Kim Kinnear (kkinnear); Ralph
Droms (rdroms); Brzozowski, John
Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011

		The one DHCPv6 issue that came up, which isn't new, is
that there were incidences of duplicate IPv6 address assigned from the
DHCP Server (Cisco Network Registrar) - this was obvious from the DHCPv6
DECLINE messages which like DHCPv4 DHCPDECLINEs should generally NOT
occur. This was because one of the vendors that supplied PCs for A/V
needs, attendee use, and conference operations had cloned a Windows 7
machine and not wiped out the Dhcpv6DUID registry key. (I suspect more
than one vendor might have been involved given the number of different
DUIDs but it could also have been different images for different system
types.)

	Ouch.   This is a problem we were concerned about; it's
unfortunate to see that it is prevalent in practice and not just
something to worry about.

	Doesn't Windows have a post-clone mechanism for wiping
information that needs to be configured on a per-machine basis?   (I
assume Windows because you mentioned the registry).

We agree that this is not something to "fix" with DHCPv6, right? This is
equivalent to cloning a machine that has a static address and leaving
the same configuration.

That said, relay agents that add hardware address to option 82 could
make this easier to detect when relays are present. Just sayin'. :)

- Bud

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2011 14:56:23 -0500

Interop is big trade show and provides network access to attendees, exhibitors, and the show infrastructure (registration, etc). See http://www.interop.com/lasvegas/.

These were Windows 7 PCs.

This is just an issue in the cloning process - just as they changed the host name after cloning, they have to assure they wipe out the DHCP DUID so that a new one will be generated. I would assume that Microsoft's "SYSPREP" does this (I really don't know much about SYSPREP but as I understand it, it is supposed to be used in the cloning process to fix up the registry, etc for the new system after it is cloned; indications are that this might not have been run).

We found no issues with normal clients (i.e., those from attendees or exhibitors).

- Bernie

-----Original Message-----
From: Brzozowski, John [mailto:[email-masked]] 
Sent: Wednesday, May 11, 2011 7:55 AM
To: Bernie Volz (volz); Ralph Droms (rdroms); dhc WG
Cc: Kim Kinnear (kkinnear)
Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011

Bernie,

Thanks,

John

---

From: Ted Lemon <[email-masked]>
Date: Wed, 11 May 2011 18:53:12 -0400

On May 11, 2011, at 10:51 AM, Bud Millwood wrote:
> That said, relay agents that add hardware address to option 82 could make this easier to detect when relays are present. Just sayin'. :)

Huh?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2011 18:15:14 -0500

Bud ... Wrong protocol ... you are thinking DHCPv4 not DHCPv6 ...
Relay-Forward is used in DHCPv6.

Yeah, I was thinking the peer-address might have been useful but at
least in some cases it was not. This seemed very odd to me (it was also
odd that the DUID the Windows system created was not based on the mac
address of the interface). But I just didn't have the time to diagnose
it further.

I might have some additional data to help but it will be a while before
I can fully analyze it.

-          Bernie

From: Ted Lemon [mailto:[email-masked]] 
Sent: Wednesday, May 11, 2011 6:53 PM
To: Bud Millwood
Cc: Bernie Volz (volz); [email-masked]; Kim Kinnear (kkinnear); Ralph
Droms (rdroms); Brzozowski, John
Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011

	That said, relay agents that add hardware address to option 82
could make this easier to detect when relays are present. Just sayin'.
:)

Huh?

---

From: Andre Kostur <[email-masked]>
Date: Wed, 11 May 2011 16:46:14 -0700

At least on my Windows machine, the DUID is based on the MAC address.
 DUID-LLT.

On Wed, May 11, 2011 at 16:15, Bernie Volz (volz) <[email-masked]> wrote:

> Bud … Wrong protocol … you are thinking DHCPv4 not DHCPv6 … Relay-Forward
> is used in DHCPv6.
>
>
>
> Yeah, I was thinking the peer-address might have been useful but at least
> in some cases it was not. This seemed very odd to me (it was also odd that
> the DUID the Windows system created was not based on the mac address of the
> interface). But I just didn’t have the time to diagnose it further.
>
>
>
> I might have some additional data to help but it will be a while before I
> can fully analyze it.
>
>
>
> -          Bernie
>
>
>
> *From:* Ted Lemon [mailto:[email-masked]]
> *Sent:* Wednesday, May 11, 2011 6:53 PM
> *To:* Bud Millwood
>
> *Cc:* Bernie Volz (volz); [email-masked]; Kim Kinnear (kkinnear); Ralph
> *Subject:* Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011
>
>
>

-- 
Andre Kostur
Senior Software Design Engineer
P: 604-678-2864  SIP: [email-masked]
<http://www.incognito.com/uc>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 11 May 2011 18:57:21 -0500

Yes, exactly. That was why it was rather odd that deleting the registry
key and rebooting didn't generate one based on the MAC (it was a
DUID-LLT but not based on the MAC of the NIC card).

The NIC OUI was 00-21-86. The "bad" DUID had 01-1e-37. New DUID used
01-1a-6b in the case where I recorded the information.

All 3 of these OUI's belong to "Universal Global Scientific Industrial
Co., Ltd".

-          Bernie

From: Andre Kostur [mailto:[email-masked]] 
Sent: Wednesday, May 11, 2011 7:46 PM
To: Bernie Volz (volz)
Cc: Bud Millwood; [email-masked]; Ralph Droms (rdroms); Kim Kinnear
(kkinnear)
Subject: Re: [dhcwg] FYI - A note regarding DHCPv6 from Interop 2011

 

On Wed, May 11, 2011 at 16:15, Bernie Volz (volz) <[email-masked]>
wrote:

-          Bernie

Huh?

-- 
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 May 2011 14:21:03 -0400

On May 11, 2011, at 7:46 PM, Andre Kostur wrote:
> At least on my Windows machine, the DUID is based on the MAC address.  DUID-LLT.

Yes, but it's based on the mac address of the machine at install time.   If you then clone the machine, the DUID-LLT will be cloned from the original, so it won't contain the mac address of an interface on the clone.

---

From: Andre Kostur <[email-masked]>
Date: Fri, 13 May 2011 12:19:48 -0700

Sorry.. I should have said "based on _a_ MAC address".  Happens to be my
current MAC address.  DUID-LLT's were intentionally designed to survive the
changing of a NIC (or multiple interfaces for that matter).

On Fri, May 13, 2011 at 11:21, Ted Lemon <[email-masked]> wrote:

> Yes, but it's based on the mac address of the machine at install time.   If
> you then clone the machine, the DUID-LLT will be cloned from the original,
> so it won't contain the mac address of an interface on the clone.
>
>

---

From: Bud Millwood <[email-masked]>
Date: Tue, 17 May 2011 14:14:02 +0200

Yeah, drives me crazy when I have to switch back and forth often. I was
referring to adding mac address to the relay forw msg, of course. I recall
someone on the list last year, from UC Davis maybe?, that wanted hwaddr in
DHCPv6, and he asked about writing a proposal to allow it to be added to
relay forward messages. The response was not great IIRC, which was why I was
throwing it out there and ducking. I think he wanted to assign leases using
hwaddr.

But peer address is along the same lines, I think: something that indicates
that although the DUID appears to have been serviced before, the server may
want to throw in question whether or not it's looking at the device it
thinks it's looking at. The idea was if the relay hands you the hardware
address of the device, you could check that against the DUID you've serviced
and make some assumptions.

I'm not recommending any of this, though, just considering the
possibilities.

- Bud

---

From: Tim Chown <[email-masked]>
Date: Tue, 17 May 2011 13:18:02 +0100

On 17 May 2011, at 13:14, Bud Millwood wrote:

> Yeah, drives me crazy when I have to switch back and forth often. I was referring to adding mac address to the relay forw msg, of course. I recall someone on the list last year, from UC Davis maybe?, that wanted hwaddr in DHCPv6, and he asked about writing a proposal to allow it to be added to relay forward messages. The response was not great IIRC, which was why I was throwing it out there and ducking. I think he wanted to assign leases using hwaddr.

It was Chuck, who I've copied explicitly.  I had heard the same from staff locally and at other universities.
> 
> But peer address is along the same lines, I think: something that indicates that although the DUID appears to have been serviced before, the server may want to throw in question whether or not it's looking at the device it thinks it's looking at. The idea was if the relay hands you the hardware address of the device, you could check that against the DUID you've serviced and make some assumptions.
> 
> I'm not recommending any of this, though, just considering the possibilities.

We now have the new DUID-UUID method.

Tim

> Bud … Wrong protocol … you are thinking DHCPv4 not DHCPv6 … Relay-Forward is used in DHCPv6.
> 
>  
> Yeah, I was thinking the peer-address might have been useful but at least in some cases it was not. This seemed very odd to me (it was also odd that the DUID the Windows system created was not based on the mac address of the interface). But I just didn’t have the time to diagnose it further.
> 
>  
> I might have some additional data to help but it will be a while before I can fully analyze it.
> 
>  
> -          Bernie
> 
>  
> Cc: Bernie Volz (volz); [email-masked]; Kim Kinnear (kkinnear); Ralph Droms (rdroms); Brzozowski, John

---

From: Bud Millwood <[email-masked]>
Date: Tue, 17 May 2011 14:48:28 +0200

> We now have the new DUID-UUID method.

Nice, I hadn't seen that. Is it generally desirable, then, to enforce
policies based on DUID *type* at the DHCP server?

- Bud