EUI-64 would more correctly be described as a mechanism that is used to generate unique IPv6 addresses. Now this mechanism can be used for global unicast addresses, or link local addresses. Whether or not you require user/administrator intervention or not depends on which of these is being implemented, as well as on the vendor of each particular network device/host.
For the case where you want to configure global unicast IPv6 addresses on the interfaces of a Cisco router, then yes, you will have to put in the command that you mentioned. However, there are situations where no user/administrator intervention is necessary. Some of these include:
the configuration of a link local address on an IPv6 enabled interface of a Cisco Router
the configuration of a global unicast IPv6 address on a TV connecting to a network since it has been preconfigured to autoconfig this address
Whether or not user intervention is required depends primarily on how the vendor has set up the config process. In any case, the EUI-64 is the mechanism that is used. If it has been enabled by default or not depends on the vendor of the device, and on the type of address being assigned.
"An engineer has configured a router to use EUI-64, and was asked to document the IPv6 address of the router. The router has the following interface parameters:
mac address C601.420F.0007
subnet 2001:DB8:0:1::/64
Which IPv6 addresses should the engineer add to the documentation?
Answer: 2001:DB8:0:1:C601:42FF:FE0F:7
âŚ
Itâs an exam question. Why isnât the 7th bit reversed here? (C6)
Yes, you always have to reverse the bit. Remember that this bit simply signifies if the MAC address is hardwired (learned directly from the physical interface) or administratively assigned (such as a virtual MAC or a MAC directly configured by an administrator). The bit is set to 0 if it is hardwired, or 1 if it is configured. The reason we change the bit is explained in RFC 2373 where it says:
The motivation for inverting the âuâ bit when forming the interface
identifier is to make it easy for system administrators to hand
configure local scope identifiers when hardware tokens are not
available. This is expected to be case for serial links, tunnel end-
points, etc. The alternative would have been for these to be of the
form 0200:0:0:1, 0200:0:0:2, etc., instead of the much simpler ::1,
::2, etc.
So the reason we flip the bit is more of a matter of convenience rather than a technical issue.
I have made some research on the topic, and I think that this technique is used for the host mainly.
Do you confirm that taking a router interface as an example is simply an example and in real life this technique is mainly intended for host addressing ?
Typically, EUI-64 is used on hosts. However, it is not a hard and fast rule, nor is it limited to hosts. You can decide to use it wherever it is convenient. It also depends upon the choice of implementation for each operating system. For example, Windows computers by default donât use EUI-64, but generate the interface ID randomly.
On routers, other network devices, as well as on servers, it is best practice to use statically defined IPv6 addresses so that hosts can always reach them. There is no possibility of having those addresses change, even if you replace hardware, and you can choose them in a way that is logical for your particular network requirements. However, EUI-64 may still be useful in some cases on non-host devices, but this is on a per-case basis.
In the context of IPv6 networking, a link-local address and an interface identifier are two different but related concepts.
A link-local address is an IP address that is intended only for communications within the network segment (link) or the broadcast domain that the host is connected to. These addresses are not routable, which means they canât be used to communicate with devices outside of the local network segment. In IPv6, link-local addresses always begin with FE80. For more information, take a look at this NetworkLessons note on the topic.
On the other hand, an interface identifier within the context of IPv6 is actually a component of the IPv6 address. In the same way that an IPv4 address is separated into its network and host portions, their counterparts in IPv6 are the network identifier and the interface identifier. Take a look at this image:
N is the prefix for that particular IPv6 address. So, if we had a /64 prefix, then the network identifier is defined as the first 64 bits of that address, and the interface identifier is defined as the last (128-64) = 64 bits of the address.
If we had a prefix of /96, then the first 96 bits are the network identifier, and the last 32 are the interface identifier.
In the context of EUI-64, this process is used to automatically assign an interface identifier based on the datalink layer address. In the case of Ethernet, thatâs the use of the MAC address.
If using a randomly generated Interface ID as opposed to EUI-64, is SLAAC still only possible with a /64 prefix? If itâs not using the MAC address, couldnât you theoretically use random generation to generate say, a 36-bit Interface ID?
Yes, youâre correct that theoretically, it is possible to generate a 36-bit (or any other size) Interface ID using random generation. However, the SLAAC process in IPv6 is designed to work specifically with /64 prefixes. This is because the /64 prefix divides the address into a network portion and a host portion, each of 64 bits.
The EUI-64 format is used to ensure globally unique addresses, but you could use randomly generated Interface IDs. But in both cases, the /64 division is maintained.
The main reason for this is standardization and simplicity. A /64 division simplifies subnetting and makes route aggregation more efficient. Changing this would require changes to the IPv6 protocol and could lead to compatibility issues. So, even if youâre not using EUI-64 and are using random generation, the /64 prefix is still used.
