[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Unreachability detection at tunnels servers WAS: RE: Comments on zeroconf draft
Hi Pekka,
It seems that we are converging against a resolution, which is:
In the area of IPv6 black hole detection, tunnel servers may
not provide a service comparatively with the native IPv6 one.
Ideally, IPv6 transition/tunnelling mechanisms should provide black hole
detection mechanisms similar to original IPv6 NUD processes.
Whether such are provided, however, will for the individual
transition mechanism be a tradeoff weighting the implementation aspects and
the anticipated deployment environment aspects against the added value of such IPv6 NUD like
processes.
(-??)
I can live with that.
BR, Karen
> -----Original Message-----
> From: Pekka Savola [mailto:pekkas@netcore.fi]
> Sent: Monday, September 27, 2004 11:27 AM
> To: Karen E. Nielsen (AH/TED)
> Cc: V6OPS WG; 'Radhakrishnan Suryanarayanan'; juha.wiljakka@nokia.com;
> 'Soininen Jonne (Nokia-NET/Helsinki)'
> Subject: RE: Unreachability detection at tunnels servers WAS: RE:
> Comments on zeroconf draft
>
>
> 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
>