[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC 2461 : Neighbor Discovery

> However, there is one other thing you should consider. In IPv6, we're 
> supposed to use /64s for pretty much all subnets. So it's not 
> inconceivable that router A sends a packet to one of those 2^64 
> addresses belonging to the PPP subnet that _isn't_ an address for 
> router B. A naive implemenation may result in such a packet being 
> returned to router A by router B and a routing loop (that attackers can 
> use to attack the routers because of the multiplication effect) is 
> born. Since it's unlikely a router only has PPP interfaces, the full ND 
> code must be in there anyway, so it makes sense to use regular neighbor 
> discovery / unreachability to avoid this situation. On the other hand, 
> discovering the addresses on both sides using IPV6CP and then 
> blackholing the other 2^64-2 addresses may be preferable as this makes 
> it impossible for attackers to cause ND storms. (Using a /127 would do 
> this too, but this clashes with some anycast addresses (that nobody 
> uses anyway).)

If there is an implementation choice to use or not use the NS/NA
mechanism on PPP interfaces, that sounds like a recipe for
interoperability problems to me. If one implementation sends a NS and
expects to see a NA before sending the first message to the neighbors
address but the other implementation doesn't use NS/NA messages on the
PPP link, there is a problem.

Is there any plan to address this in the upcoming PPP spec
revision (and how)? Or do you think there is no interop issue?


IETF IPv6 working group mailing list
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6