Using /126 for IPv6 router links

Steve Bertrand steve at
Wed Jan 27 11:16:49 UTC 2010

Igor Gashinsky wrote:
> On Wed, 27 Jan 2010, Pekka Savola wrote:
> :: On Tue, 26 Jan 2010, Igor Gashinsky wrote:
> :: > Matt meant "reserve/assign a /64 for each PtP link, but only configure the
> :: > first */127* of the link", as that's the only way to fully mitigate the
> :: > scanning-type attacks (with a /126, there is still the possibility of
> :: > ping-pong on a p-t-p interface) w/o using extensive ACLs..
> :: >
> :: > Anyways, that's what worked for us, and, as always, YMMV...
> :: 
> :: That's still relying on the fact that your vendor won't implement
> :: subnet-router anycast address and turn it on by default.  That would mess up
> :: the first address of the link.  But I suppose those would be pretty big ifs.
> Or, relying on the fact that (most) vendors are smart enough not to 
> enable subnet-router anycast on any interface configured as a /127 (and 
> those that are not, well, why are you buying their gear?)..
> If a worst-case situation arises, and you have to peer with a device that 
> doesn't properly support /127's, you can always fall back to using /126's 
> or even /64's on those few links (this is why we reserved a /64 for every 
> link from the begining)..

If this is the case, why not just use /64s from the beginning? Why
bother with hacking it up if it's only going to be reserved anyway?

I'm trying to understand how reserving-and-hacking a /64 makes
administration any easier.

Even if all ptp are coming out of a single /64 (as opposed to reserving
a /64 for each), what benefits are there to that? It seems as though
that this is v4 thinking.

As someone pointed out off-list (I hope you don't mind):

"one could argue a bunch of sequential /127s makes it apparent what your
infrastructure addresses are.  You can just as easily ACL a /48
containing infrastructure /64s as you can ACL a /64 containing
infrastructure /127s."

...amen to that, if I can't figure out a way to sink/drop the null
addresses first.


More information about the NANOG mailing list