hey Greg... one thing I'm a little fuzzy on, is why link local addresses using eui-64 sets the 7th bit.... it's link local so why would the 7th bit be set?
I understand why eui-64 sets the 7th bit when using global unicast, but why is this so for link-local?
Message was edited by: Joshua - CCNP R&S---------------- seems a little contradicting that link local is setting the 7th bit to be universal?
Not sure; I haven't read the RFC on that for awhile. I think the universal bit is set based on the expected uniqueness of the hardware address from which EUI-64 is calculated. It's probably just another step to minimize the likelihood of duplicate addresses on auto-addressed links. If one side is calculating EUI based on Ethernet MAC (which should be universally unique), and the other side is being set by an admin, I guess as long as the admin doesn't set the universal bit then there's no chance of duplication.
if im not mistaken flipping of the 7th bit U/L (universal/local flag), validates the link local address. The 7th bit indicates whether the address is Globally or Locally unique, the protocol requires that in EUI-64 format, the value of the 7th bit is reversed to give us 0 for Local and 1 for Global.
Be careful about the terminology you use; "flipping," is inaccurate, even though the ROUTE certification guide uses that terminology I believe. "Flipping" indicates changing the bit whether it's a 0 or a 1.
I agree with you, but my point was that whether it's a link local or a global unciast, the bit is "set" (to 1), which is confusing to me.
Hmmm, looks like I was wrong, which is confusing me even more....
R1#show ipv6 int brief
FastEthernet0/1 [administratively down/down]
R1#show int fa0/0
FastEthernet0/0 is up, line protocol is up
Hardware is Gt96k FE, address is c200.1de4.0000 (bia c200.1de4.0000)
MTU 1500 bytes, BW 10000 Kbit/sec, DLY 1000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Half-duplex, 10Mb/s, 100BaseTX/FX
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:14, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2 packets input, 236 bytes
Received 2 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
17 packets output, 2419 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 unknown protocol drops
Hrm, let me try again. Think back to subnetting, where you divide the address into two parts, the left is the network, and the right is the host.
An address has "link-local" forwarding scope if the network portion is "FE80::...".
In the host part of the address, universal bit doesn't refer to forwarding scope, it refers to the uniqueness of the host part of the address (universally unique, or just locally unique). An Ethernet MAC should be universally unique. When there's no DHCP server to prevent duplicates, auto-configured hosts need their own tricks to minimize potential duplications.
I just found this decent explanation, which may also help:
Yeah, the authors should've called that bit the "unique hardware address" bit. Calling it universal makes it sound geographical like the forwarding scopes (link-local) - makes people think they do similar things, when really they have completely different purposes.
BTW, the IETF deprecated site-local some time ago, because nobody could agree what a "site" really is. http://tools.ietf.org/html/rfc4291#section-2.5.7