host-identifier with IPv6
farmer at umn.edu
Tue Mar 3 16:39:25 UTC 2009
On 3 Mar 2009 David Farmer wrote:
> On 3 Mar 2009 Chuck Anderson wrote:
> > On Tue, Mar 03, 2009 at 02:19:33AM -0600, David Farmer wrote:
> > > The following is my IPv6 link local address, fe80::208:74ff:fe24:ac0a, my
> > > mac address is 0008:7424:ac0a, this is the simple transformation defined in
> > > RFC 2464. Therefore a DHCP server can be assured to get the EUI-64
> > > version of the MAC address. Transforming that back to a 48-bit MAC and
> > > allowing operations in the DHCP server based on the MAC address should
> > > be possible without modification of DHCPv6 clients or DHCPv6 relay agents.
> > > 64 address rather than leaving it up to the client through SLAAC to use its
> > > EUI-64 or a privacy address.
> > What about clients using privacy addressing (RFC 3041)? It isn't
> > clear to me from reading the RFC if this affects link local addresses,
> > but if it does, they won't have a MAC address embedded in their link
> > local address.
> I haven't seen any implementations of RFC 3041 that use privacy extensions on
> the link local address, but I haven't exhaustively looked either. I'll note that RFC
> 3041 is an extension to SLAAC, which technically occurs after the link local
> address is assigned and uses the link local address to communicate with the
> local routers. Also, in my quick reread of RFC 3041, it seems to be limited to
> "global-scoped addresses"
> But, I agree, I don't technically see any reason that you couldn't use RFC 3041
> like privacy for a link local address, and that would break this assumption. But, I
> think it is a valid assumption, at least for now. If that changes in the future, I
> think I'm ok with that. I see this as a short-term crutch. Longer term, we all need
> retool and redo our processes and procedures to move to DUIDs. I do like some
> of the ideas behind DUIDs. But, asking everyone to do that now, just creates a
> barrier to adoption of IPv6. And as I said in another post, we have enough of
> those already.
It looks like Vista by default uses a random address even for
link local. GRRR! You can turn it off that feature, but this
needs to work no matter how a host is configured.
Anyone know if it is more than just Vista that uses a random
link local address?
Anyone know if you can do a group policy or something of the
kind to turn-off the random link local address? Maybe you can
use IPv4 connectivity to get IPv6 configured correctly.
If that works you could refuse to give out an IPv6 address from
the DHCPv6 server unless you have a EUI-64 based link local
address, with "FF:FE" is not in the middle two nibbles.
Another option from the DHCPv6 server side; Maybe you look
at the link local address first. If you can't get the MAC address
there, then try to decode the DUID for the MAC address. I
know it violates the RFC where it says the DUID is suppose to
be opaque, but I'm not sure there is much of a choice here. If
both fail, then maybe don't give out an IPv6 address.
I think we need these kind of options, I don't think any of this
should be the default behavior. But a MAC address based
option is absolutely necessary in the short run for most
Q. How is the link-local address derived?
A. The link-local address is a combination of the link local
prefix FE80::/64 and a 64-bit IPv6 interface identifier (ID).
In Windows XP and Windows Server 2003, the IPv6 interface
ID is derived from the Extended Unique Identifier (EUI)-64
address. The EUI-64 address is either assigned to a network
adapter or derived from the 48-bit media access control (MAC)
address of a network adapter. To create the EUI-64 address
from the 48-bit (6-byte) Ethernet MAC address, the hex digits
0xff-fe are inserted between the third and fourth bytes of the
Ethernet MAC address.
For example, for the MAC address 00-60-08-52-f9-d8, the hex
digits 0xff-fe are inserted between 0x08 (the third byte) and
0x52 (the fourth byte) of the MAC address, forming the EUI-64
To obtain an IPv6 interface identifier from an EUI-64 address,
the Universal/Local bit, the second low-order bit of the first byte
of the EUI-64 address, is complemented (if it is a 1, it is turned
to 0, and if it is a 0, it is turned to 1). For example, for the EUI-
64 address of 00-60-08-ff-fe-52-f9-d8, the second low-order bit
of 0x00 is 0, which, when complemented, becomes a 1. The
result is that for the first byte, 0x00 becomes 0x02. Therefore,
the IPv6 interface identifier corresponding to the EUI-64
address of 00-60-08-ff-fe-52-f9-d8 (corresponding to the
Ethernet media access control address of 00-60-08-52-f9-d8)
Because the link-local address is the combination of the prefix
FE80::/64 and the 64-bit interface identifier expressed in IPv6
colon-hexadecimal notation, the link-local address of this
example node, with the prefix FE80::/64 and the interface
identifier 02-60-08-ff-fe-52-f9-d8, is fe80::260:8ff:fe52:f9d8.
In Windows Vista and Windows Server 2008, the interface ID
by default is randomly derived, rather than based on the EUI-
64 address. You can disable random interface IDs with the
netsh interface ipv6 set global randomizeidentifiers=disabled
command or enable random interface IDs with the netsh
interface ipv6 set global randomizeidentifiers=enabled
David Farmer Email:
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota Phone: 612-626-
2218 University Ave SE Cell:
Minneapolis, MN 55414-3029 FAX: 612-626-
More information about the dhcp-users