Subject: (ngtrans) Re: ICMP errors in response to ICMP errors.

From: Mohan Parthasarathy <[email-masked]>
Date: Thu, 17 May 2001 11:56:55 -0700 (PDT)

> 
> > 5) There is no route for this IPv4 packet [which is actually an ICMPv6
> >    error] as determined by the IPv4 routing table. An ICMPv4 error is
> >    generated.
> > 
> > 6) The ICMPv4 error is converted to an ICMPv6 error so that it can
> >    be sent to the original IPv6 sender [router itself].
> > 
> > Note that step (5) and step (6) are the similar to step (2)  and (3) 
> > and will continue forever till the ttl drops to zero.
> >   
> > At step (5) we are generating an ICMPv4 error for the ICMPv6 error.
> 
> no, you're generating an icmpv4 error for an tunnelled ipv6 packet
> 
Agreed. 

> > At step (6) we are generating an ICMPv6 error for the ICMPv6 error.
> > 
> > Should step (5) or step (6) detect this and drop the packet ?
> 
> step (5): no.
> 
> step (6): yes.  you should not send icmp errors in response to icmp
> errors.

I just wanted to point out that you can't convert  ICMPv4 error to
ICMPv6 error blindly. You need to check to see the inner packet.
May be it is very obvious which i missed :-)

-mohan
 
> 
> 					- Bill
> --------------------------------------------------------------------
> 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: Fri, 18 May 2001 04:10:39 +0900

>May be it is very obvious which i missed :-)

	you never need to.  the only case you might need to do this is
	when you are an IPv6-to-IPv4 translator (but is rare, still).

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 18 May 2001 11:14:22 +0200 (CEST)

> 	when you are an IPv6-to-IPv4 translator (but is rare, still).

Itojun,

There is a problem case related to tunneling (whether RFC 2893 or RFC 2473, or
even RFC 2002 enhanced to propagate ICMP errors from the inside of the
tunnel back to the sender).

RFC 2893 specifies in section 3.4 how to construct an ICMPv6 error
from an ICMPv4 error. When doing this you need to avoid creating
an ICMPv6 error in response to an ICMPv6 error and the spec doesn't say
anything about this. (And RFC 2473 has similar text in section 8.)

Here is the example that causes problems in some more detail.

An ICMPv6 error packet arrives at the tunnel entrypoint.
It looks like this 
	IPv6+ICMPv6+IPV6+...

This gets encapsuled in IPv4 (assuming IPv6 over IPv4 for the moment)
i.e. this gets sent into the tunnel
	IPv4+IPv6+ICMPv6+IPV6+...
An IPv4 router generates an ICMP error to the above i.e. it returns
a packet to the tunnel entrypoint.
	IPv4+ICMPv4+IPv4+IPv6+ICMPv6+IPV6+...
The tunneling code following section 3.4 uses this as input to construct
an ICMPv6 error by looking at the initial IPv4+ICMPv4+IPV4.
The result looks like
	IPv6+ICMPv6+IPv6+ICMPv6+IPV6+...

Voila, this is an ICMP error in response to an ICMP error.
We can't allow this since they could cause an infinite number of
packets to be generated.

  Erik

---

From: [email-masked]
Date: Fri, 18 May 2001 20:52:37 +0900

>anything about this. (And RFC 2473 has similar text in section 8.)

	yes, I understand this portion.  Assuming that we are doing IPv6-over-
	IPv4 tunnel, which IPv4 errors do we need to translate into IPv6?
	as far as I understand there's none.  For IPv6, IPv4 tunnels are
	invisible entity outside the packet (just like L2 encapsulations like
	ethernet) and errors on IPv4 layer will be seen to IPv6 layer
	as loss of packets (just like all L2 failures).
	I should have sent more comments earlier to these RFCs.

	Which ICMPv4 do you translate into ICMPv6 on Solaris? (or "would you
	translate")

	Couple of analysis (all IMHO):

	ICMP6 too big messages are not directly converted from ICMPv4 too big,
	either.  B gets ICMPv4 too big from somewhere between B and C for
	encapsulated packet, B would adjust tunnel MTU, and B originates
	ICMPv6 too big toward A.
		A -- B === C -- D

	ICMPv4 time exceeded does not need to be translated, as TTL field on
	outer IPv4 header has nothing to do with hoplimit value on inner IPv6
	header.  B decides IPv4 TTL on its behalf and use that value (RFC2893
	p13), and the tunnel between B and C is a 1-hop path for inner IPv6
	packet.  There's real need to tell time exceeded to A, as there's
	nothing A can do.  The packets will be silently lost just like other
	L2 failures.
	RFC2783 recommends to translate it from IPv4 to IPv6 (p27),
	which I don't really think it useful as there's nothing A can do.

itojun

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 18 May 2001 14:26:11 +0200 (CEST)

> 	as far as I understand there's none.

Too big at a minimum.
Others you probably want to translate as well so provide more information
to the sender. (It seems a bit better to get an ICMP unreachable from
the tunnel entrypoint than just a black hole.)

>  For IPv6, IPv4 tunnels are

When L2 deliver fails on Ethernet an IPv6 node will send
address unreachable (this happens after NUD has discarded the neighbor cache
and the subsequent address resolution fails.)
Thus L2 failures are not completely hidden fro L3 endpoints in IPv6.

> 	encapsulated packet, B would adjust tunnel MTU, and B originates

If there is enough of the packet included to translate the ICMP
then it is better to both adjust the path MTU and do the translation.
If you only adjust the path MTU it will take another packet drop
(with an ICMPv6 packet too big from the tunnel entrypoint) before the
IPv6 sender sees the path MTU. If you do both (when the ICMPv4 packet
included sufficient headers) then a single packet drop is sufficient
to notify the IPv6 sender of the path MTU.

 Erik

---

From: [email-masked]
Date: Fri, 18 May 2001 21:30:54 +0900

>to notify the IPv6 sender of the path MTU.

	I guess we are talking about the same behavior with different wording.

itojun

---

From: [email-masked]
Date: Fri, 18 May 2001 22:01:04 +0900

>	I guess we are talking about the same behavior with different wording.

	oops, you right.
	"translation" - send ICMPv6 as soon as B gets ICMPv4
	normal behavior - learn PMTU, and then send ICMPv6 on next bigger packet

	if you don't turn on DF bit on outer IPv4 header, you can avoid this
	whole translation thing for too big messages, btw.

itojun

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 May 2001 12:06:44 -0500

>         whole translation thing for too big messages, btw.

Yes. If you remember, RFC 2529 (6over4) says
   However, the IPv4 "do not
   fragment" bit MUST NOT be set in the encapsulating IPv4 header.
but we agreed in a subsequent discussion that this should be downgraded
to SHOULD NOT, and RFC 3056 (6to4) has SHOULD NOT.

RFC 2893 doesn't make a general recommendation - maybe it should?

    Brian
-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM 
On assignment for IBM at http://www.iCAIR.org 
Board Chairman, Internet Society http://www.isoc.org

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 21 May 2001 09:25:03 +0200 (CEST)

> >         if you don't turn on DF bit on outer IPv4 header, you can avoid
this > >         whole translation thing for too big messages, btw.

Yes, but as stated in the RFC this implies that the other tunnel endpoint
might need to reassemble. I don't know the performance impact (processing
as well as memory for the fragments) this will have. Clearly it is better
if we can avoid lots of reassembly in routers.

> to SHOULD NOT, and RFC 3056 (6to4) has SHOULD NOT.

There is a BIG technical difference. RFC 2529 encapsulates in IPv4 MULTICAST
packets and path MTU discovery doesn't work for IPv4 multicast.
I thought the RFC actually was made to state the reason for this.
Sigh.

  Erik

---

From: [email-masked]
Date: Mon, 21 May 2001 17:27:41 +0900

stripped off some of cc:s.

>if we can avoid lots of reassembly in routers.

	I'm a bit concerned with scenarios like below:
	- a bad guy transmits fake ICMPv4 too big packet
	- tunnel router translates it into ICMPv6 without care
	i'd need to think this through.

itojun