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
