Router R1 connects to Router R2 over an Ethernet LAN with both routers using their F0/0
interfaces. R1 learns a route from R2 using EIGRP for IPv6. That route lists F0/0 as the
outgoing interface with R2 as the next hop. The configuration excerpt shows all relevant
configuration on R2’s F0/0 interface. Which of the following is true about R1’s route?
interface f0/0
mac-address 1111.1111.1111
ipv6 address 2000::/64 eui-64
ipv6 address 2001::1/64
A.
The next hop is 2000::1311:11FF:FE11:1111
B.
The next hop is FE80::1311:11FF:FE11:1111
C.
The next hop is FE80::5111:11FF:FE11:1111
D.
The next hop is 2001::1
Explanation:
EIGRP uses the link local address as the next hop for routing protocols. Based on
R2’s MAC address, R2’s link local address on F0/0 will be
FE80::1311:11FF:FE11:1111. This value is derived by splitting the MAC, inserting
FFFE, and flipping bit 7, making the initial hex 11 become hex 13.
http://www.rfc-archive.org/getrfc.php?rfc=7136
Gee….wonder why so few people out there in the real world have adopted ipv6?
it seems SO simple to einstein over here.
The Modified EUI-64 format preserves the information provided by two
particular bits in the MAC address:
o The “u/l” bit in a MAC address [IEEE802] is set to 0 to indicate
universal scope (implying uniqueness) or to 1 to indicate local
scope (without implying uniqueness). In an IID formed from a MAC
address, this bit is simply known as the “u” bit and its value is
inverted, i.e., 1 for universal scope and 0 for local scope.
According to [RFC 4291] and [RFC 7042], the reason for this was to
make it easier for network operators to manually configure
local-scope IIDs.
In an IID, this bit is in position 6, i.e., position 70 in the
complete IPv6 address (when counting from 0).
o The “i/g” bit in a MAC address is set to 1 to indicate group
addressing (link-layer multicast). The value of this bit is
preserved in an IID, where it is known as the “g” bit.
In an IID, this bit is in position 7, i.e., position 71 in the
complete IPv6 address (when counting from 0).
This document discusses problems observed with the “u” and “g” bits
as a result of the above requirements and the fact that various other
methods of forming an IID have been defined independently of the
method described in Appendix A of RFC 4291. It then discusses the
usefulness of these two bits and the significance of the bits in an
IID in general. Finally, it updates RFC 4291 accordingly.