Re: RFC 2461 : Neighbor Discovery

[Iljitsch van Beijnum <iljitsch@xxxxxxxxx>]

On 15-apr-04, at 9:17, Subramonia Pillai - CTD, Chennai wrote:

> I am looking for “Router to Router” connected by PPP links (POS) 
> running
> IPV6CP.

> Since ND is a union of (ARP, ICMP Rotuer Discovery, ICMP Redirect and
> others), which part of ND is needed (or has to be implemented) in both
> Routers.

The use of these types of mechanisms with PPP is already less than 
clear with IPv4. The whole address negotiation thing is there so a 
router or dial-up aggregator can assign an address to a dial-up user. 
When PPP is used on a fixed link between two routers, this 
functionality isn't really needed, as generally this information is 
configured on both ends. Now in IPv4, it is necessary that the routers 
on both ends of a (PPP) link agree on the address range (subnet) that 
is used for this link, as routing protocols won't work if the routers 
have different ideas about the addresses on the link. However, in IPv6 
this isn't necessary, as routing protocols can simply use link local 
addresses. Or routers may learn from other routers what additional 
address ranges are on-link. Note though that these mechanisms are 
clearly intended (at least in RFC2461) to be used by hosts.

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).)

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