host-identifier with IPv6

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 
campuses. 

--------------
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 
address 00-60-08-ff-fe-52-f9-d8.

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) 
is 02-60-08-ff-fe-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 
command.

================================================
=======
David Farmer				     Email:	
farmer at umn.edu
Office of Information Technology
Networking & Telecomunication Services
University of Minnesota			     Phone:	612-626-
0815
2218 University Ave SE			     Cell:		
612-812-9952
Minneapolis, MN 55414-3029		     FAX:	612-626-
1818
================================================
=======