[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 Brian,
Thanks a lot for your comments.
Left is how to get an answer to the general question, though.
A few comments below.
> -----Original Message-----
> From: Brian E Carpenter [mailto:brc@zurich.ibm.com]
> Sent: Wednesday, September 15, 2004 11:45 AM
> To: Karen E. Nielsen (AH/TED)
> Cc: 'Pekka Savola'; V6OPS WG; 'Radhakrishnan Suryanarayanan';
> juha.wiljakka@nokia.com; 'Jeroen Massar'
> Subject: Re: Unreachability detection at tunnels servers WAS: RE:
> Comments on zeroconf draft
>
>
> Karen,
>
> Thanks for the clarification. One comment below..
>
> Karen E. Nielsen (AH/TED) wrote:
> > 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)
>
> 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.
>
Agreed.
> 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.
>
Well, an 6to4 encapsulator could perform NUD on the IPv6 level even on the
router-to-router links.
RFC 3056 even has a reference to RFC 2893 in this respect, only the reference,
in my mind, isn't clear (and furthermore it is quickly becoming deprecate).
But going into that discussion is of-topic and different from the issue
that I wanted to raise with this thread.
> 6to4 was designed to be orthogonal to everything else; generic tunnel
> servers are different and your questions below certainly
> apply to them.
>
Good.
Thanks,
Karen
> Brian
>
> >
> > 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:brc@zurich.ibm.com]
> >>Sent: Monday, September 13, 2004 2:41 PM
> >>To: Karen E. Nielsen (AH/TED)
> >>Cc: 'Pekka Savola'; 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
> >>
> >>
> >>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
> >>>>
> >>>>
> >>>
> >>>
> >
>