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