Subject: RE: RFC 2461 : Neighbor Discovery

From: "Subramonia Pillai - CTD, Chennai" <[email-masked]>
Date: Thu, 15 Apr 2004 12:47:05 +0530

Hi JINMEI and Hesham,

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. 

Thanks in advance,
Subu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, April 15, 2004 12:26 PM
To: Soliman Hesham
Cc: Subramonia Pillai - CTD, Chennai; [email-masked]
Subject: Re: RFC 2461 : Neighbor Discovery

>>>>> On Wed, 14 Apr 2004 06:17:18 -0400, 
>>>>> "Soliman Hesham" <[email-masked]> said:

>> From router point of view, global address can be get from 
>> Configuration. So
>> I am still thinking, for router case do we need ND?

> => Do you think hosts connected to your router 
> will need the information I mentioned in the last 
> email? If yes, they will send RSs. 

> I don't know what you're using the router for but
> I don't know of any case where I can categorically
> say don't implement RFC 2461. I think that it's 
> basically always needed. If for nothing else, a host
> might want to use NUD for reachability confirmation.

I think the original question is rather vague:

>>>>> On Wed, 14 Apr 2004 11:01:37 +0530, 
>>>>> "Subramonia Pillai - CTD, Chennai" <[email-masked]> said:

> My doubt is "Should I run ND on PPP links in addition?"  Can any one
please
> tell me with the reason?

about which part of ND the question is asking (RFC2461 or RFC2462,
which part of each spec, etc).

Additionally, from the latter part of this thread, there seems to be
another confusion on whether we are only concentrating on routers,
only on hosts, or on both.

For further constructive discussion, these points should be clarified
in the first place, IMO.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 15 Apr 2004 10:30:27 +0200

> others), which part of ND is needed (or has to be implemented) in both

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

---

From: Markus Jork <[email-masked]>
Date: Fri, 16 Apr 2004 02:22:08 -0400

> this too, but this clashes with some anycast addresses (that nobody 

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

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 16 Apr 2004 14:21:25 +0200

On 16-apr-04, at 8:22, Markus Jork wrote:

> interoperability problems to me.

That's not good.

> revision (and how)? Or do you think there is no interop issue?

I think you're right and there is an issue. So I guess we should let 
the PPP people know in case they didn't think of this themselves.

Iljitsch