Using /126 for IPv6 router links

Igor Gashinsky igor at
Thu Jan 28 21:19:54 UTC 2010

On Wed, 27 Jan 2010, Dale W. Carder wrote:

:: On Jan 27, 2010, at 3:19 PM, Igor Gashinsky wrote:
:: > you face 2 major issues with not using /127 for
:: > PtP-type circuits:
:: >
:: > 1) ping-ponging of packets on Sonet/SDH links
:: >
:: >  Let's say you put 2001:db8::0/64 and 2001:db8::1/64 on a PtP
:: >  interface, and somebody comes along and ping floods 2001:db8::2,
:: >  those packets will bounce back and forth between the 2 sides of
:: >  the link till TTL expires (since there is no address resolution
:: >  mechanism in PtP, so it just forwards packets not destined for
:: >  "him" on).
:: Following this, IPv4 /30 would have the same problem vs /31?

As has been said before, IPv4 has a concept of broadcast, and "no ip 
directed broadcast" (or simmilar) to prevent it -- IPv6 does not.

:: > 2) ping sweep of death
:: >
:: >  Take the same assumption for addressing as above, and now ping
:: >  sweep 2001:db8::/64... if the link is ethernet, well, hope you
:: >  didn't have any important arp entries that the router actually
:: >  needed to learn.
:: Wouldn't this affect *all* /64's configured on a router, not
:: just point to point links?  Time for glean rate limiting.

While I don't disagree on smarter ARP gleaning, rate limiting by itself is 
not an answer (rate limiting means that legit requests get limited too), 
so a better approach is to prioritize arp/NDP refresh for anything already 
in cache, as opposed to new requests, which we've suggested to our 

Also, for a "core" network, you don't really need /64's in most places, 
and, if you do need them, their numbers are quite small compared to the 
number of PtP links.. (how many lan/host segments do you have connected to 
core routers, as compared to number of PtP links, and then, how many of 
those show up in a traceroute?)

:: If you were really concerned, you could hard code static NDP
:: entries, as I think someone else pointed out.

Or, you can use /127's -- to me, that's operationally easier (especially 
if you have to replace hardware in the future) :)

Like I said before, using /127's is our suggestion of what has worked best 
for us in both architectural and operational roles, and since my network 
isn't the same as yours, YMMV, just sharing our experience..


More information about the NANOG mailing list