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

[Pekka Savola <pekkas@netcore.fi>]

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.

On Thu, 9 Sep 2004, Karen E. Nielsen (AH/TED) wrote:
> 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
> > 
> > 
> 

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