[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?

Markus

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