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

[Pekka Savola <pekkas@netcore.fi>]

I've tried to figure out how to close this thread but I haven't had 
much success yet.. :/

On Wed, 22 Sep 2004, Karen E. Nielsen (AH/TED) wrote:
> > 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.
> 
> 
> The tunnel servers are in many respects replacing IPv6 access routers, 
> for which we have explicit requirements in this respect, i.e.,
>  SHOULD perform IPv6 NUD. 
> 
> If I understand you correctly you seem to be saying that not only
> is it up for the individual tunnel mechanism to decide how to perform
> determination of link-failure (with that, I agree completely) 

Yes.

> - but also (?) that it is up to the individual mechanism to determine
> what constitutes indication of link failure, and thus consequently,
> which kind of link failures that it will seek to monitor and report - !!

Yes, this is what I meant.

This stems from the practical point of view that it's a bit difficult 
for us (well, we could create a draft or RFC) to create a "policy" on 
that, to be followed by transition mechanisms to come.  The typical, 
pragmatic approach is to look each proposition and try to figure out 
whether it is justified or not.

> I may not disagree with the latter, but if this is the route that we
> want to take, I would like it us to do it with our "eyes wide open"
> so to speak - saying clearly that in the areas of IPv6 black hole
> detection, tunnel servers may not provide a service comparatively
> with the native IPv6 one.

Black hole detection is indeed a problem, but luckily enough, the
problem is already commonplace, both in v4 (e.g., firewalling without
ICMP transmissions on rejects) and (to a degree) in v6.  Therefore, if
you want to build a very robust application, you'll have to deal with
black holes in any case.  However, the vast majority of apps won't
consider this a sufficiently wide problem.

That being said, I think it would be very useful to try to keep the
original NUD & ICMP characteristics of IPv6 in the tunneling
mechanisms that are specified, if not for other reason than providing
a good and quick indication of network blockage to the apps.  But that
seems to be a tradeoff which needs to be weighted per transition
mechanism.  I'd certainly like to default to specifying similar NUD
processes, unless otherwise justified, though.

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