> > 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 [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
