[AusNOG] OSPFv3 / EIGRPv4 - Link local addresses

[Mark Smith]

Regarding more user/operator friendly link-local addresses, here is an idea.

The domain or scope of reachability for link-local addresses is only a single link, however the domain or scope of uniqueness of a link-local address can be more than a single link, even though it is only required to be unique within a single link.

In other words, you don't have to duplicate link-local addresses within your network, and if you're using global MAC address derived ones - the default - you already probably have not only network-wide unique link-local addresses, but also world wide unique link-local addresses. They are of course also unique within the links they appear on. This is all possible because of the use of 64 bit Interface Identifiers (IIDs) in IPv6 (which is what makes the default prefix length a /64).

So here is a method that takes advantage of 64 bit IIDs to provide more operator friendly link-local addresses, and avoids them being bound to the MAC address of the underlying interface.

For each router interface in your network, you configure a static link-local address, with *no* duplicates anywhere within your network, and disable the default MAC address derived ones. For example, assuming you deployed routers in the following sequence, connecting them together in a hub-and-spoke topology, with rtr1 at the hub (the topology doesn't matter, it just makes the example easier):

rtr1, eth0: fe80::1/64
rtr2, eth0: fe80::2/64

rtr1, eth1: fe80::3/64
rtr3, eth0: fe80::4/64

rtr1, eth2: fe80::5/64
rtr4, eth0: fe80::6/64

rtr1, eth3: fe80::7/64
rtr5, eth0: fe80::8/64

The values of the IIDs isn't that significant, other than it'd be convenient to assign them sequentially and it ensures uniqueness as you deploy new routers or bring up new interfaces on existing routers. There are plenty of other schemes you could use, and with 64 bits to play with, you could give some of those bits meaning e.g. the top one or two octets of the IID represents the geographic region where the router resides.

The next thing to do is to put those now network-wide unique link-local addresses in your authoritative DNS for your domain and your 8.e.f.ip6.in.addr.arpa. domains (which you should have, because of RFC6303), with both forward and reverse RRs e.g. 

eth0.rtr1.example.com.        IN      AAAA      fe80::1

1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN PTR eth0.rtr1.example.com.


eth0.rtr2.example.com.        IN      AAAA      fe80::2

2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN PTR eth0.rtr1.example.com.

eth1.rtr1.example.com.        IN      AAAA      fe80::3

3.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN PTR eth0.rtr1.example.com.

eth0.rtr3.example.com.        IN      AAAA      fe80::4

4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.e.f.ip6.arpa. IN PTR eth0.rtr1.example.com.

So now, although you won't be able to telnet, traceroute or ping to the link local address, you can resolve it to a specific interface and router using any application which will resolve addresses (like ping, traceroute or telnet). Alternatively, you can resolve an interface and router name to a network unique link-local address. Being disciplined about creating DNS RRs will also help ensure you maintain the network-wide uniqueness of your link-local static addresses. If you now want to see if the link-local address is reachable, you telnet/ssh to the router it is configured on, or one of its direct neighbours.

Finally, if you want to capture even more information about the interface and router, you can use a DNS TXT RR e.g.:

eth0.rtr1.example.com.        IN      TXT"eth0, mac address 56:8f:a8:67:ae:65, Cisco AGS+ running IOS 8.2, Asset# 0008"


(Of course, LLDP/CDP and IS-IS (and perhaps OSPF in the future) can also provide information about what is connected to what)

Regards,
Mark.