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

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Mon, 13 Sep 2004 15:23:11 +0200

Hi Brian,

I probably wasn't very clear because I wasn't thinking about
translation of ICMP proto-41 unreachable messages. Let me try to clarify
my question.

A tunnel server, which IPv6-in-IPv4 encapsulates
packets to dual stack end-hosts, acts as a last hop IPv6 router at the
IPv6 level.

Examples of such a server is a Teredo server, and Isatap server as well
as a 6to4 tunnel server (when the server-to-host 6to4 case is supported)

Now a standard last hop IPv6 router on a lan monitors the reachability of its 
lan hosts using NUD and notifies of black holes by sending IPv6 destination unreachable 
back to origin. (Actually the ICMP is generated when a NUD cache times out and 
address resolution cannot be performed anew, but in this context that's a detail.)

My question is:

What are the requirements on tunnel servers in this respect - that is, is it required
that a tunnel server performs IPv6 reachability monitoring comparatively to the above, 
meaning something which results in it being able to send IPv6 ICMPs back to origin 
when a packet doesn't reach an end-host (at the IPv6 level) ??

Ultimatively that would mean that some IPv6 NUD like mechanism would have to be glued
on top of the tunnelservice.

Given the answer from Jereon about translation of IPv4 ICMP proto-41 - 
it could be that the answer to the question is - "NO that is not required. It suffices
that the tunnel server aims to translate all proto-41 unreach IPv4 ICMP's into
IPv6 destination unreachables which are sent back to origin."

This also means that whether black holes are detected or not, relies on the benevolence
of the end-hosts to generate proto-41 unreach ICMPs (and large enough such messages, i.e. messages which includes original Ipv6 header) and not on (stateful) mechanisms implemented
by the tunnel server.

My new question is then  - is the proto-41 translation scheme the general mech
adopted for (and accepted for) this purpose by the WG ?

BR, Karen

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, September 13, 2004 2:41 PM
> To: Karen E. Nielsen (AH/TED)
> Cc: 'Pekka Savola'; V6OPS WG; 'Radhakrishnan Suryanarayanan';
> [email-masked]; 'Soininen Jonne (Nokia-NET/Helsinki)'
> Subject: Re: Unreachability detection at tunnels servers WAS: RE:
> Comments on zeroconf draft
> 
> 
> Karen E. Nielsen (AH/TED) wrote:
> > 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.
> 
> To be clear, are you asking about ICMPv4 or ICMPv6 responses?
> 
>     Brian
> 
> > 
> > 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: Mon, 13 Sep 2004 17:06:04 +0200

> Hi Brian,

<SNIP>

> adopted for (and accepted for) this purpose by the WG ?

You mean that errors in IPv4 space should be converted to errors in IPv6
space?

Greets, 
 Jeroen

---

From: Radhakrishnan Suryanarayanan <[email-masked]>
Date: Tue, 14 Sep 2004 11:54:32 +0530

Hi Karen,

> adopted for (and accepted for) this purpose by the WG ?
IMHO, the transition mechanisms should provide handling ICMPv4 errors and
their translation.
"Basic Transition Mechanisms for IPv6 Hosts and Routers"
<draft-ietf-v6ops-mech-v2-06.txt> section 3.4 is doing it. Isnt this a good
indicator?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 15 Sep 2004 11:45:16 +0200

Karen,

Thanks for the clarification. One comment below..

> as a 6to4 tunnel server (when the server-to-host 6to4 case is supported)

And that is not described in RFC 3056, so isn't part of standardized
6to4. A 6to4 router, as described in RFC 3056, is like any other IPv6
router as far as NUD and ICMPv6 is concerned - there is nothing
special for the 6to4 decapsulator to do in this respect. The router
function does what any router does.

A host which claims to support RFC 3056 really needs to behave like
a 6to4 router. To be clear, it acts as its own last hop router.
It's forwarding the decapsulated IPv6 packets to a local IPv6 stack.
If that forwarding action fails it should generate an ICMPv6 unreachable
response. (It's a very bizarre error condition though, and probably can
never happen in reality. Why would there be a 6to4 decapsulator operating,
if there is no local IPv6 stack?)

A 6to4 encapsulator can only detect IPv4 unreachability, which in IPv6
terms is a link failure and should obviously be handled like any other
link failure.

6to4 was designed to be orthogonal to everything else; generic tunnel
servers are different and your questions below certainly apply to them.

    Brian