Using /126 for IPv6 router links

Steve Bertrand steve at ibctech.ca
Wed Jan 27 01:16:45 UTC 2010


Igor Gashinsky wrote:
> On Mon, 25 Jan 2010, Matt Addison wrote:
> 
> :: You're forgetting Matthew Petach's suggestion- reserve/assign a /64 for
> :: each PtP link, but only configure the first /126 (or whatever /126 you
> :: need to get an amusing peer address) on the link. 
> 
> 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...

As always, I'm looking for better ways to do things. I've been using /64
eui-64 on P-PE PtP Ethernet links (and /64 static on PE-CE) since I
first delved into IPv6, as (for me) it makes hardware replacement/link
relocation very easy, and documentation simple.

 ip address x.x.x.x 255.255.255.252
 ipv6 address 2607:F118:x:x::/64 eui-64
 ipv6 nd suppress-ra
 ipv6 ospf 1 area 0.0.0.0

I've found that this setup, in conjunction with iBGP peering between
loopback /128's works well.

I don't think I'm quite grasping the entire security concern here.

Actually, I'd like to re-word that...

I do grasp the attack vector to a certain degree, but there *must* be a
way to use entire /64's on ptp links without having to use manual ACL
management.

Personally, I am all for using /64s for this purpose, as that's how I
understand the intention of the protocol. Whether I use a complete /64
within a ptp (particularly Ethernet), or lob off a /127 (or /126) for
the purpose, I'll always keep that entire /64 'specifically reserved for
that purpose' either way.

Would be interesting to hear ideas on how this particular /64 on ptp
attack vector could be nullified by using existing known solutions. I'm
thinking blackhole, but can't (at this time) think how that could be
done by default with existing configuration within the scope of a ptp link.

Steve






More information about the NANOG mailing list