With the expanded address space, and the introduction of letters (A thru F), it is possible to embed words into an address, making it easier to recognize the source of that address. Facebook is a common example where they have embedded face:b00c into the address
$ host facebook.com
facebook.com has address 157.240.3.35
facebook.com has IPv6 address 2a03:2880:f101:83:face:b00c:0:25deOther common examples are dead:beef or cafe.
Using Vanity Addressing with Link-Local interfaces
A colleague suggested using Vanity Link-Local Addresses, primarily to make pinging the next hop interface easier. A simple use would be the upstream router is ::1, and the downstream router would be ::2. From the downstream router, one would ping:
$ ping fe80::1%eth0
64 bytes from fe80::1%eth0: icmp_seq=1 ttl=64 time=3.97 ms
64 bytes from fe80::1%eth0: icmp_seq=2 ttl=64 time=4.60 ms
Because link-local prefix of fe80:: is on every interface, the address must be scoped with the %eth0.
This certainly makes less typing, and faster troubleshooting than trying to look up the link-local address of the next hop router.
Using Vanity Link-Local Addressing as part of your addressing plan
My SOHO network is probably a little more complex that most. But this technique can also be applied to larger networks.
As you can see there are four basic networks (with some smaller ones not shown) in my network. I have a /56 from my ISP, and for the most part, the networks are divided on nibble boundaries.
| prefix | Use | |
|---|---|---|
| 2001:db8:c011:fd00 | Production network | |
| 2001:db8:c011:fd40 | Testing network | |
| 2001:db8:c011:fd50 | IPv6-only network | |
| 2001:db8:c011:fd80 | DMZ Network |
Creating Vanity Link-Local addresses from the address plan
In the old classful networking days, the IT group would have IPv4 subnets memorized. The 10 network, or the 171 network. With IPv6, it is possible to do this again, but with IPv6 prefixes.
Since, I only have a /56, the last 2 bytes of the address are mine to deploy (e.g. 2001:db8:c011:fd00). I have taken the last two bytes, and applied them to link-local addresses, such that the prefix 2001:db8:c011:fd44:: becomes a link-local address fe80::ea9f:80ff:fef3:fd44.
In a perfect world, it would just shorten this to fe80::fd44, however I run OpenWrt routers which don’t support Vanity Link-Local Addressing.
Vanity Link-Local Addressing and OpenWrt
I like OpenWrt, it is a very powerful, extremely configurable, and extendable routing platform. One can even run bird, an internet routing daemon on OpenWrt, including RIPng.
OpenWrt does use EUI-64 addressing for the Link-Local addresses, and does permit changing MAC addresses on interfaces. With this knowledge, we can embed the vanity address into the MAC address on OpenWrt.
In the LuCI web interface: Network->Interfaces->Devices Tab
I have changed the last two bytes of the MAC address to FD:60
This change can also be made in the file /etc/config/network on the OpenWrt router with the addition of the option macaddr
for OpenWrt 22.03.x
config device
option name 'br-lan'
option type 'bridge'
list ports 'eth1'
list ports 'eth2'
list ports 'eth3'
list ports 'eth4'
option macaddr '74:83:C2:4C:FD:60'
for OpenWrt 19.07.x
config interface 'lan'
option type 'bridge'
option ifname 'eth0.1'
option proto 'static'
option netmask '255.255.255.0'
option ip6assign '60'
option ipaddr '192.168.7.1'
option macaddr '74:83:C2:4C:FD:60'
After rebooting your router, this will yield a pseudo vanity link-local address of: fe80::7683:c2ff:fe4c:fd60
But you say, “fe80::1 is much easier than fe80::7683:c2ff:fe4c:fd60.” And you would be right. But as I said, OpenWrt doesn’t have a facility to create simple link-local addresses like fe80::1.
Vanity Link-Local addressing and RIPng
As many readers know, I have been running RIPng (Routing Information Protocol for IPv6) for several years. RIPng isn’t a perfect routing protocol, there are better/faster protocols out there, but RIPng doesn’t require the administrator to be a router jockey to use it. Therefore I feel that RIPng is an excellent choice for SOHO (Small Office/Home Office) networks.
RIPng advertisements are like other routing protocols and is limited to the link, and will not cross routers. So link-local addresses figure heavily in understanding the sources of RIPng advertisements.
Based on creating vanity MAC addresses (which become vanity link-local addresses) you can now see that RIPng information, such as neighbours (or peers), or even the routing table is easier to understand.
Using the bird CLI utility, birdcl, you can look into what RIPng is doing. For example, looking at neighbours:
# birdcl
BIRD 2.0.11 ready.
bird> show rip neighbor
rip1:
IP address Interface Metric Routes Seen
fe80::7683:c2ff:fe61:fd60 br-lan 1 4 17 #from IPv6-only router
fe80::224:a5ff:fef1:fd11 br-lan 1 2 30 #from DNS service router
fe80::ea9f:80ff:fef3:fd44 eth0.4 1 4 19 #from Test Network router
fe80::c2c1:c0ff:fe01:fda0 eth0.3 1 5 15 #from Wireguard2 router
fe80::290:a9ff:fea6:fd91 eth0.3 1 5 19 #from Wireguard1 router
bird>
As you can see, this router has five neighbours which include routers on the FD11, FD44, FD60, FD91, and FDA0 networks.
The bird folks have changed (in version 2.x) how routes are displayed, which works well for 80 column screens, but I find harder to read than the older 1.6 version.
bird> show route
Table master6:
::/0 unicast [rip1 11:23:21.109] * (120/3)
via fe80::58ef:68ff:fe0d:fd00 on eth0
2001:db8:8011:fd98::/64 unicast [rip1 11:23:21.109] * (120/3)
via fe80::58ef:68ff:fe0d:fd00 on eth0
2001:db8:8011:fd60::/60 unicast [direct1 11:23:25.508] * (240)
dev br-lan
2001:db8:8011:fd80::/64 unicast [rip1 11:23:21.109] * (120/3)
via fe80::58ef:68ff:fe0d:fd00 on eth0
fd10:111:0:8::/62 unicast [rip1 11:23:21.109] * (120/2)
via fe80::58ef:68ff:fe0d:fd00 on eth0
2001:db8:8011:fd44::/62 unicast [rip1 11:39:37.119] * (120/2)
via fe80::58ef:68ff:fe0d:fd00 on eth0
2001:db8:8011:fda4::/64 unicast [rip1 11:23:21.109] * (120/3)
via fe80::58ef:68ff:fe0d:fd00 on eth0
I find it easier to view the routes and where they are from by using the Linux ip -6 route command, which also sorts the routes.
# ip -6 route
2001:db8:8011:fd00::a1b via fe80::7683:c2ff:fe61:fd60 dev br-lan metric 1024
2001:db8:8011:fd00::/64 dev br-lan metric 1024
2001:db8:8011:fd00::/62 via fe80::ca9e:43ff:fe51:c04e dev br-lan metric 1024
2001:db8:8011:fd04::/62 via fe80::ca9e:43ff:fe51:c04e dev br-lan metric 1024
2001:db8:8011:fd08::/62 via fe80::216:3eff:feb7:c2be dev br-lan metric 1024
2001:db8:8011:fd0c::/62 via fe80::9683:c4ff:fe15:f188 dev br-lan metric 1024
2001:db8:8011:fd11::/64 via fe80::224:a5ff:fef1:fd11 dev br-lan metric 1024 #FD11 DNS services
2001:db8:8011:fd40::fb0 via fe80::ea9f:80ff:fef3:fd47 dev eth0.4 metric 1024
2001:db8:8011:fd40::/64 dev eth0.4 metric 1024
2001:db8:8011:fd44::/64 via fe80::ea9f:80ff:fef3:fd47 dev eth0.4 metric 1024 #FD44 Test Network
2001:db8:8011:fd44::/62 via fe80::ea9f:80ff:fef3:fd47 dev eth0.4 metric 1024
2001:db8:8011:fd60::/60 via fe80::7683:c2ff:fe61:fd60 dev br-lan metric 1024 #FD60 IPv6-only
2001:db8:8011:fd80::a6b via fe80::c2c1:c0ff:fe01:fda1 dev eth0.3 metric 1024 #FD80 DMZ
2001:db8:8011:fd80::/64 dev eth0.3 metric 1024
2001:db8:8011:fd88::/62 via fe80::2866:2cff:fe49:d36c dev eth0.3 metric 1024
2001:db8:8011:fd98::/64 via fe80::290:a9ff:fea6:fd91 dev eth0.3 metric 1024
2001:db8:8011:fd90::/60 via fe80::290:a9ff:fea6:fd91 dev eth0.3 metric 1024
2001:db8:8011:fda0::/62 via fe80::c2c1:c0ff:fe01:fda1 dev eth0.3 metric 1024
2001:db8:8011:fda4::/64 via fe80::c2c1:c0ff:fe01:fda1 dev eth0.3 metric 1024
As you can see, not all of the routers in my network have Vanity Link-Local addresses. These are lesser routers, usually Virtual Routers (VRs), OpenWrt running inside Linux Containers (LXD) for testing. But the Vanity Link-Local addresses are there, making it easier to understand where packets are coming from.
Vanity Link-Local Addresses are a good thing
Although OpenWrt doesn’t support Vanity Link-Local addressing, it can be approximated by creating vanity MAC addresses. These address hints will help you in understanding your network topology, and bring more meaning to what would be otherwise random link-local addresses.
Notes:
- Since making the drawing, I have moved the IPv6-only network prefix from FD50 to FD60, since I wanted more address space for the test network. So there will be references to both in this article.
- I am using bird 1.6.6 on my older 19.07.x routers, and bird 2.0.11 in my newer 22.03.x routers, and some of the route displays will not be exactly the same.
- I have added comments to route displays, such as “#FD60 IPv6-only”, to provide clarity, the comments are not displayed as part of the command output.