Subject: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Thu, 9 Sep 2004 14:40:15 +0200

Dear All,

An issue of general character has been brought up in connection with the zero-conf work. 
The issue is the following:

MUST Ipv6-in-Ipv4 tunnel servers, as routers, support NUD-like mechanisms that enables
them to send ICMP destination unreachable messages back to origin ?

The initial feedback received in this respect is that - "yes, they MUST".

As some RFCs previously has been silent about this, e.g. 6to4 - RFC 3056,
and the working group currently is standardising a mechanism which also seems
to be silent about this (Teredo) I would very much like to hear if the above is the
general sentiment of the work group.

I should be stressed that adding this to the goals of the zero-conf requirements
document isn't believed to severely limit the solution space - but it requires
implementation of a mechanism which is know to scale very badly and
which in addition is susceptible to the DoS attack described in Section 4.3.2 of RFC 3756.

BR, Karen

> 
> 
> On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote:
> > Normally last hops routers performs NUD so that they can send ICMPs
> > back to origin to notify of black holes/unreachability.  Personally
> > I am not sure that this is a MUST requirement on the Tunnel Servers.
> > I have actually thought that we could avoid this, especially since
> > we have no explicit goals as to the nodes being registered as
> > reachable in the DNS using the Ipv6 address - wherefore we are first
> > and foremost looking to support the situation where communication is
> > initiated by the tunnel clients and not from the outside.
> 
> This seems short-sighted to me, because the actual *advantage* of IPv6
> is realized only when *incoming* connectivity is enabled (if it was
> just about outbound connectivity, v4 would work as well). 
 If this
> would imply that the communication between two nodes inside the 3GPP
> network or communication originating from IPv6 internet and coming to
> a 3GPP node could just silently fail.. this would seem to be very 
> undesirable.

Note this is not about the connectivity silently failing, it
is about the node no longer being there/no longer being active. 

But what you're saying is that the destination unreachable ICMPs are a MUST
to support at a Ipv6-in-Ipv4 Tunnel Server ?

- BTW, with the risk of bluring the difference in between
solution space and requirement space - I suppose this in particular applies
to the v6ops accepted "tunnel server" mechanisms, 6to4 and Teredo border routers ?

> 
> -- 
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
>

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 09 Sep 2004 15:12:28 +0200

> general sentiment of the work group.

What happens, afaik, is the following:
Remote Box (A) = 2001:db8::1
tunnelendpoint @ Tunnel Server (Ts) = 2001:db8:1000::1
tunnelendpoint @ Tunnel Client (Tc) = 2001:db8:1000::1
R? = Routers in between.

Thus schematically:
A -> Ra -> Rb -> Rc -> Ts -(6in4/proto41 tunnel)-> Tc

The packet will arrive at Ts, which will stick it into a 6in4 packet and
actually forward it to Tc.

Following situations could arise:
 a) IPv4 path works and Tc accepts the packet
    -> no problems
 b) IPv4 path works, Tc doesn't accept packet
    -> it should return with a proto-41 unreach icmp
 c) IPv4 route is broken between Ts and Tc
    -> it should return a unreach host

In case of b and c when Ts gets a icmp route/port/host unreach they can
send a IPv6 unreach route/host back to the Remote Box A.
This is, what I noticed, is what the current Linux, KAME and XP
implementations do.

> I should be stressed that adding this to the goals of the zero-conf
> requirements document isn't believed to severely limit the solution
> space - but it requires implementation of a mechanism which is know to
> scale very badly and which in addition is susceptible to the DoS
> attack described in Section 4.3.2 of RFC 3756.

The point where this can be DoS'd is by sending the Tc IPv4 unreachables
for the Tc. Thus if you know the endpoints you can simply send a few
icmp's and if the Ts remembers the state, which it hopefully does not
do, then you can effectively disable the tunnel.

The real way to fix this is doing egress/ingress filtering on IPv4...
But many ISP's do not do any filtering at all, so tough luck.
For that matter, the not so many IPv6 ISP's that are out there don't
filter on IPv6 either, at least most of them, so most are repeating the
same problem again, but all has to do with the router not being able to
do filtering or something on linerate...

Greets,
 Jeroen

---

From: Soohong Daniel Park <[email-masked]>
Date: Fri, 10 Sep 2004 13:32:46 +0900

> them to send ICMP destination unreachable messages back to origin ?

(Sorry if I am missing anything on this thread because I didn't
fully follow up that so far.)

When I saw this draft, below sentence was to cover the above concern.
 
6.8. Tunnel End-Point Reachability Detection

   The tunnel protocol must allow for means for one tunnel end-point to
   verify the reachability of other tunnel end-points towards which it
   intends to send packets.

   The unicast neighbor reachability discovery functions provided by
   IPv6 Neighbor Discovery ([13]), i.e., unicast NS/NA exchanges, should
   be supported on the tunnel link.

NUD-like sounds good for me, however ICMP message exchange is not
only available to verity a reachability between two endpoints. So don't limit 
this goal to the ICMP. 

When I implemented IPv6-over-IPv4 tunnel using DHCP, I used TCP/UDP
port assigned by admin in advance between them, and it works well.

Hope this helps.

     Daniel (Soohong Daniel Park)
     Mobile Platform Lab. Samsung Electronics.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 13 Sep 2004 14:40:45 +0200

> general sentiment of the work group.

To be clear, are you asking about ICMPv4 or ICMPv6 responses?

    Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 22 Sep 2004 10:48:18 +0300 (EEST)

Hi,

I'm not sure if there was a conclusion/resolution to this thread.

As for my personal take -- hopefully I've understood the arguments 
properly..

If you receive IPv4 ICMP error messages relating to an IPv6-in-IPv4
tunnel, one should probably do something if it's possible, because
that will be an indication that IPv6 link layer has failed (and that
particular error can be propagated the same way as any other IPv6 link
failure, or by direct ICMP message conversion).

What and whether the implementations must treat IPv4 ICMP error 
messages somehow depends on the mechanism in question.  
draft-ietf-v6ops-mech-v2-06.txt does not mandate it for static MTU
discovery, but it's obviously required for dynamic MTU discovery.  
6to4 spec (section 7) doesn't require it either, but seems to imply 
that it can be done.

So, as to the issue whether tunnel servers need to be able to send
back ICMPv6 error messages if the implementation thinks that the link
has failed, I'd say "yes, it probably should" because shouldn't all
IPv6 nodes be supposed to be able to do something like that.  The
issue then is what constitutes good indication for "link failure"  
(e.g., in this case, IPv4 tunneling failing).  Specifying what that
must or should include is probably mechanism-dependent.