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

Reply via email to