I think the link-local scope was set to /10 simply to "fit in" better with the other scopes, e.g. site-local (before it was replaced with unique local).
Initially I had thought maybe it was to allow the use of many link-local networks on the same link, but RFC 4291 explicitly states that only fe80::/64 may be used.
ipv6 general-prefix DELEGATED_PREFIX 6rd Tunnel0
This line defines DELEGATED_PREFIX. It automatically calculates the IPv6 prefix based on the 6rd settings of the Tunnel0 interface.
ipv6 address DELEGATED_PREFIX ::/128 anycast (on int Tunnel 0)
This line sets an IPv6 address on the Tunnel0 interface using the DELEGATED_PREFIX defined before. It tells the router to take the prefix, leave the other bits zero (::) and configure it as a single anycast address. The anycast flag tells the router that the address may be used on multiple devices at the same time. It will therefore not perform any Duplicate Address Detection (not really relevant for a tunnel interface) and it will not use that address as a source address (because the return traffic might end up at one of the other anycast nodes).
ipv6 address DELEGATED_PREFIX ::/64 eui-64 (on int Ethernet 0)
This does the same for the Ethernet0 interface. It uses the DELEGATED_PREFIX to give an address to the interface. One problem is that you're using the same subnet on the tunnel interface. You should use separate subnets for different interfaces. The eui-64 flag tells the router to generate the last 64 bits of the interface address based on its MAC address.
An example to (hopefully) make things clearer:
Let's take the 6rd settings from the example:
- 6rd IPv4 prefix: 10.0.0.0/8
- 6rd IPv6 prefix: 2001:db80::/28
Then if your router has IPv4 address 10.0.0.10 you will get IPv6 prefix 2001:db80:0:a000::/52. The /8 in the IPv4 prefix means that the first 8 bits are fixed. So when constructing the IPv6 prefix it will only use the last 24 (32 - 8) bits from the IPv4 address. These have binary value 0000 0000 0000 0000 0000 1010. When written in hexadecimal that is 00 00 0a. This is appended to the /28 IPv6 prefix, giving a /52 (28 + 24).
So DELEGATED_PREFIX will get value 2001:db80:0:a000::/52. Therefore the Tunnel0 interface will get address 2001:db80:0:a000::/128 and the Ethernet0 interface will get something like 2001:db80:0:a000:1234:56ff:fe78:90ab/64 (assuming MAC address 12.34.56.78.90.ab).
It would be better to give the ethernet interface an address from a different subnet, like:
ipv6 address DELEGATED_PREFIX 0:0:0:1::/64 eui-64
That would result in 2001:db80:0:a001:1234:56ff:fe78:90ab/64. And if you don't want to make the address dependent on the MAC address you can also just give it a fixed address:
ipv6 address DELEGATED_PREFIX 0:0:0:1::1/64
That would result in 2001:db80:0:a001::1/64.
Best Answer
The document to which you link claims a specific IOS version. It may be incorrect; that would not be unusual in Cisco documentation.
In reality, having tested this on several IOS 15.X versions, you do not specify a prefix length on a link-local address since it is implicit for the link local address, as you saw in your CLI help (
ipv6 address ?showsX:X:X:X::X IPv6 link-local address, the address without a prefix length). You do specify the prefix length on a non-link-local IPv6 address since there is no implicit prefix length.Personally, I think specifying specific link-local addresses on your interfaces is going to be a giant pain, with little to no gain. Just enabling IPv6 on an interface will assign a unique link-local address, and that is all you really need. There is really no security risk about having the Interface ID being derived from the MAC address, since the address will never be seen off-link, and it won't be tracked across the Internet as a Global Scope address could be.