Subject: nonexisting destination on p2p link

From: [email-masked]
Date: Thu, 26 Apr 2001 08:45:43 +0900

we observed certain packets goes ping-pong on p2p link.
	it depends on:
	- how p2p links are implemented on the stack
	- how routes to p2p links are configured
		(this highly is implementation dependent)
	but anyway, i would like to have your second opinion.

	KAME code has a special code (disabled by default) for this case, like
	- suppose I am a router.  if the packet comes in from interface Ix,
	  and goes out again to Ix, and interface Ix is a p2p link, I do not
	  forward the packet.  instead, I'd emit ICMPv6 no route to host.

	questions:
	- is my scenario make sense?  or do we have some implementation mistake?
	- is the KAME special behavior look legal?
	- are there any implementation that chokes with it?  for example,
	  are there implementation that do not check the local address on p2p
	  link, and expect the packet to come back again?
	- if it looks legal, what ICMPv6 type/code should be used? 
	  timexceeded?
	- how should we document?

	(if you are curious about the source, see #ifdef PROHIBIT_P2PREDIRECT
	in sys/netinet6/ip6_forward.c in KAME tree).

itojun

scenario:

suppose we have routers "A" and "B", and they are connected by some
p2p link (tunnel, ATM, whatever).

case 1: consider link local address (La and Lb).

	A (La) --- (Lb) B

A has fe80::/10 (or fe80::/64 depending on your implementation)
route pointed to the p2p link.  if A emits a packet with Lx (!= Lb) as a
destination, it will reach B.  then B forwards it back to A.  then A forwards
it back to B, ... until hoplimit field goes 0.  also, they would emit
ICMPv6 redirect to the peer, since the packet gets forwarded back again to the
incoming interface.

case 2: consider non-link local address (Ga and Gb).  Ga and Gb shares a
single /64 prefix, P::/64.

	A (Ga) --- (Gb) B

A has P::/64 route pointed to the p2p link.  if A emits a packet with
Gx (P::x, and Gx != Gb) as a destination, it will reach B.  now, the same
story as above.  note that, as P::/64 is global or sitelocal prefix,
remote node can generate the ping-pong packet and chew up the bandwidth
on the p2p link (so it may be a security issue).
NOTE: gated models p2p links differently.
--------------------------------------------------------------------
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: Alain Ritoux <[email-masked]>
Date: Thu, 26 Apr 2001 08:14:18 +0200

Hi, 

I think theorically REDIRECT should be sent over the p2p link, but
dropping the packet is a better sanity check !!
> ICMPv6 redirect to the peer, since the packet gets forwarded back again to the

Well if Lx is link-local, it should not bie forwarded at all ?

> on the p2p link (so it may be a security issue).

A way to avoid this may be to have only /128 prefixes for non-local
adresses for p2p interfaces, on A, p2p interface dump  will have
something like
   p2p_if:
      (La) / 64
      (Ga)/128 --> (Gb)
so only Gb will be reachable through the link.
Is it considered too restrictive ? or what is the use of a P::/6' on a
p2p link ?

Alain.

-- 
--------------------------------------------------------
Alain RITOUX   
Tel +33-1-39-30-92-32   Fax +33-1-39-30-92-11
Address :  6WIND
           1 place Charles de Gaulle
           Immeuble Central Gare
           78180 MONTIGNY LE BRETONNEUX
           FRANCE
web site : www.6wind.com
--------------------------------------------------------
--------------------------------------------------------------------
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: Thu, 26 Apr 2001 15:15:30 +0900

>Well if Lx is link-local, it should not bie forwarded at all ?

	in the existing RFCs, there's no wording that forbids forwarding
	packets to link local address, **given that we forward it back to the
	same link**.  A and B are forwarding packets back to the same link.

	we cannot forward packets with linklocal address across different
	links.  this part is clear but we are not talking about this.

	attached is hypothetical example I made to bill.

>Is it considered too restrictive ? or what is the use of a P::/6' on a

	as mentioned earlier on the email, this really depends on how you
	model p2p interfaces.  from IPv4 practice, gated uses /128 (err, /32)
	routes to p2p interfaces.  cisco uses /64 (err, /24 or whatever)
	routes to p2p interfaces.  we cannot say which one is right and
	which one is wrong.  my original queestion is, "if we are taking
	cisco model, (P::/64 points to p2p interfaces), what is the right
	behavior for us?"

itojun

Subject: Re: nonexisting destination on p2p link
From: [email-masked]
To: [email-masked]
Date: Thu, 26 Apr 2001 08:58:34 +0900

>Why would you ever want to forward a packet with a link-local
>destination address?

	  A
	  |
	==+=======+==
	  |	  |
	  B	  C

	hypothetical example - if B has misconfigured and throws packets toward
	C's link local address to A, A may want to forward it to C and throw
	icmp6 redirect.  (yes, B is broken)

	was there any spefic wording that we shouldn't?  i guess not, so
	we do not have any special "forbid from forwarding" rule yet.  if the
	packet is addressed to someone else, we forward it.

itojun

---

From: Robert Elz <[email-masked]>
Date: Thu, 26 Apr 2001 16:14:36 +0700

Date:        Thu, 26 Apr 2001 15:15:30 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	which one is wrong.  my original queestion is, "if we are taking
  | 	cisco model, (P::/64 points to p2p interfaces), what is the right
  | 	behavior for us?"

Just forward the packet.

If there is a mis-config, and a routing loop happens, the packet will
ping pong till the hop count expires, then be trashed.   Other than
deliberate DoS attacks, there shouldn't be many of these.  Where there's
no response, apps will try again for a short while, then generally they
give up, and eventually some human debugs .. seeing the ping pong from
a traceroute is a dead easy way to identify the problem - much easier
than having to try to figure out why that other router over there is
claiming there's no route (especially when I can see the route in its
routing table when I look).

Further, forwarding the packet allows the behaviour of nodes that
deliberately send packets to themselves in order to test correct
functioning of the link.

It's relatively harmless, eliminates the need for a special case test,
and actually easier to diagnose.

So, just send the packet (send a redirect if you want as well).

kre

---

From: [email-masked]
Date: Thu, 26 Apr 2001 18:23:28 +0900

>deliberate DoS attacks, there shouldn't be many of these.  Where there's

	oops, I was not clear enough.
	I'm asking this because there are a lot of these, because of some
	applications that specifies wrong outgoing interface for linklocal
	address.  once we have a neighbor cache entry for nonexisting peer,
	NUD packets will be emitted repeatedly (NUD is mandatory for p2p too)
	and chew traffic.  DoS attack is also our concern.

itojun

---

From: Robert Elz <[email-masked]>
Date: Thu, 26 Apr 2001 21:47:39 +0700

Date:        Thu, 26 Apr 2001 18:23:28 +0900
    From:        [email-masked]
    Message-ID:  <[email-masked]>

  | 	I'm asking this because there are a lot of these, because of some
  | 	applications that specifies wrong outgoing interface for linklocal
  | 	address.  once we have a neighbor cache entry for nonexisting peer,
  | 	NUD packets will be emitted repeatedly (NUD is mandatory for p2p too)
  | 	and chew traffic.  DoS attack is also our concern.

Oh, you mean where the address you're sending to on the P2P link is bad?

In that case you'll never get an answer from an NS, so you'll never be
transmitting the data packets in the first place, right?   That is, you
should never get to the stage of needing to start NUD, which doesn't make
sense until after you have initial reachability.

While you're in that state, packets that arrive are normally just dropped
(retaining one in the queue to send if the NS receives a response).  I
see no problem in generating an ICMPv6 (no route) once you have determined
that the address is bad (no-one ever responds to the NS).

This is also just what I'd do on an ethernet, or fddi, or anything else.
In general, I don't think you should special case link types, unless there's
a very good reason.

kre

---

From: [email-masked]
Date: Fri, 27 Apr 2001 09:24:42 +0900

>sense until after you have initial reachability.

	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?

itojun