Subject: RE: nonexisting destination on p2p link

From: "Richard Draves" <[email-masked]>
Date: Thu, 26 Apr 2001 23:14:00 -0700

> 	when there's no link layer address (imagine tunnel interfaces),
> 	there's no proper NS (packets go out without NS-NA 
> exchange), however,
> 	NUD hapens.  is my understanding right?

The MS implementation works that way. For a p2p interface, we create the
neighbor cache entry in the stale state (since we know the link-layer
address a priori), but then NUD can operate.

Here's another scenario along these lines: assign a /64 to a p2p link
between two routers. Now someone sends a packet to an address in the
/64, but the address is not assigned to either router. The routers will
forward the packet back & forth until the hop limit hits zero. This will
happen before NUD has a chance to kick in.

I agree with itojun, better to generate a
destination-unreachable/address-unreachable error instead of forwarding
a packet back out the p2p interface from which it arrived.

Rich
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: [email-masked]
Date: Tue, 01 May 2001 09:24:18 +0900

>> 	there's no proper NS (packets go out without NS-NA exchange), however,

	once we can make some agreement on the error code, i can write up
	a draft/a fragment to be added to the existing draft.
	at this moment kame test code uses ICMP6_DST_UNREACH/
	ICMP6_DST_UNREACH_NOROUTE, but i think ICMP6_DST_UNREACH_ADDR is
	better.

itojun

---

From: Ole Troan <[email-masked]>
Date: 01 May 2001 03:00:00 +0100

> a packet back out the p2p interface from which it arrived.

I'm inclined to disagree.
when pinging a local interface address for a p2p link, some IPv4
implementations send the ping out the link, and gets it back from the
remote router, as a way of verifying connectivity.

implementing your suggestion prevents the option of doing something
similar for IPv6.
let the packets bounce between the two routers for a while, in the end
you'll get a time exceeded message anyway.

/ot

---

From: [email-masked]
Date: Tue, 01 May 2001 11:19:11 +0900

>remote router, as a way of verifying connectivity.

	i mentioned this in very early message on this thread.  my
	question is, (1) is it really a good idea to do it, and
	(2) are there IPv6 implementation doing this.

>you'll get a time exceeded message anyway.

	do you think it okay even if outsiders (bad guys) can chew your
	bandwidth?  i think not.

itojun