[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,
Thanks.
>
> I'm not sure if there was a conclusion/resolution to this thread.
>
I am still looking for one...
> 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)
- 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 - !!
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.
BR, Karen
> 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
>
>
>
>