Are Unnumbered Interfaces Harmful?

A few weeks ago I got into an interesting discussion about the potential harm caused by unnumbered IPv4/IPv6 interfaces.

Ignoring for the moment the vendor-specific or media-specific implementation details, these two arguments usually pop up in the first 100 milliseconds (assuming engineers involved in the discussion have some hands-on operational experience):

  • You cannot do hop-by-hop telnet/SSH in case your routing protocol breaks down;
  • Traceroute will display box addresses (loopback addresses) instead of interface addresses.

The first argument is obviously valid in IPv4 world and no longer true in IPv6 world – link-local addresses are always available on IPv6 interface and you can use them to do hop-by-hop telnet/SSH (admittedly in a bit clunky way but nonetheless). However, do keep in mind that if you use any centralized authentication/authorization scheme and the routing protocol breaks, you won’t get into the box no matter what.

Speaking of traceroute: it might give you wrong interface information any time you happen to have asymmetrical routing or multiple equal-cost paths. Without any additional configuration, in most implementations the source IP address in the ICMP TTL exceeded reply is the IP address of the outgoing interface – the interface the router would use to reach the traceroute prober – and not the IP address of the interface through which the probe was received. Is there a box out there that’s smarter than this? I would love to hear about it!

2016-01-12: RFC 5837 specifies ICMP extensions that would make ICMP replies to traceroute probes way more useful (and accurate). However, it looks like nobody implemented it in almost five years since it was published.

Are there any other reasons to avoid unnumbered interfaces (vendor X doesn’t implement them on interface type Y doesn’t count)? Please write a comment!


  1. I would be happy if I could run my datacenter with only IPv6 link-local addresses (on my transport links) and MP-BGP. IPv4 could be routed just by reusing the next-hop information coming from v6. Although that would require BGP to advertise next-hop-interface instead of next-hop (or the advertiser to send a dummy IP address and the receiver assume the next-hop-interface is the same interface where the peer is located).

    Regarding traceroute, maybe it's time to come with a better set of tools to troubleshoot the network...
    1. You can run IPv6-only control plane with RFC 5549. Here's how Cumulus implemented it:
  2. In the world of IPv4 we do some unnumbered router-router links. Need BFD to support unnumbered interface. Cisco is contemplating this.

    In the world of IPv6, we use link-local router-router plus GUA loopback, BFD, OSPFv3, iBGP. This works well for us.

    We also run host facing IPv6 networks "nd prefix no-onlink".

    Despite the initial knee-jerk reaction, I have found no real downside to using unnumbered/link-local interfaces. Getting router configs down to loopback only is quite nice...
  3. "Is there a box out there that’s smarter than this?"

    Ivan, RFC 1812 ( requires that ICMP messages be sourced from the transmit interface IP (if available). Has that "MUST" been relaxed by subsequent RFCs to allow for "smarter" replies (replies reflecting probe ingress interface) to traceroute probes?
    1. Thanks for pushing me into research mode. Looks like RFC 5837 is the answer (if only someone would take the time to implement it).
    2. Neat!

      Also, sorry! I didn't mean to put you to work!
  4. I, too, am curious what others' experiences have been with this feature. My organization faces design paralysis and refuses to implement it because we are:
    1) Afraid the NOC won't know how to troubleshoot
    2) It might mess with discovery tools (NNMI, etc.)
    At a company that is so large that we have nearly exhausted RFC1918 space, you would think ip unnumbered would be as popular as beer at the beach. Even using /30's, it eats up slightly more than a /22 (v4) to address 4 spines of 9504's.
    "However, do keep in mind that if you use any centralized authentication/authorization scheme and the routing protocol breaks, you won’t get into the box no matter what."
    I was hoping to use this feature on server farms and cloud fabrics, so OOB _should_ save the day there.
    1. "I was hoping to use this feature on server farms and cloud fabrics, so OOB _should_ save the day there." ... in which case hop-by-hop CLI access is also no longer a requirement.
    2. Exactly -- there's little risk to traffic, but there's definitely a real/perceived risk to the tools, support docs, and training regimens that have evolved over the years. Think of all those homebrew SNMP/Expect scripts and all those A+ certified tech school newbies.

      But, in the end, it'll just another academic religious battle, like whether gateways should be .1 or .254, or whether .0 and .255 are valid host IPs on large subnets, and whether /31's are good form. If you like those battles and constantly having to justify and explain yourself, then go for it.
  5. > if you use any centralized authentication/authorization scheme and the routing protocol breaks, you won’t get into the box no matter what

    There's local AAA fallback for AuthA/AuthZ. Am I missing something?
    1. No you're not. Totally out-of-context, but I always wondered whether relying on them is a good or a bad thing ;)... but this is obviously just an unfounded opinion :D
  6. Isn't this discribed in RFC 7404.
    1. I was never happy with the way that draft (now RFC) glossed over some of the details. It also defers to RFC 5837 when mentioning the challenges (and it seems nobody RFC 5837 it so far).

      Anyway, I wanted to see whether there were other considerations, and it looks like there are none (apart from NMS/autodiscovery challenges).
  7. I've talked at some length with vendors about this in the past and there are a list of things which can be implemented to make it work more seamlessly, support tools, etc. but it's never been a high enough priority to get done correctly. It's a real benefit in some environments like dealing with IP/MPLS access rings, and being able to do node insertions with very little work.
  8. No they're not, unless idiots are involved.
  9. I have been thinking to do in our network. But how would "IP unnumbered" work when RSVP-TE ERO configured. We have tactical TE built with static ERP defined.

    Any feedback on this.. I am trying to lab up this scenario and check..
    1. Finally a good caveat! Thanks for the question.

      It _should_ work if you're using loopback addresses in your ERO (might be implementation dependent, test it first), but obviously you can't specify the interfaces you want to have in the path (because they don't have addresses) but only nodes.
    2. RFC 3477 (updated in 6107) covers the use of unnumbered interfaces in RSVP-TE. It uniquely identifies a link by the router ID and a 32-bit interface identifier. I believe Junos at least will advertise the IID for unnumbered RSVP-TE interfaces. However, there is no CLI to configure an ERO based on IID, just IPv4 addresses.

      It's one of those identified things I mentioned, but it really needs customers to drive those enhancements.
Add comment