Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

["JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>]

Hi Florent,

I believe that asking the customer to do so is, in the majority of the cases too much. While doing it automatically is very simple and the extra work on the client side implementation pays for the value added. In the worst case it should be an implementation issue (so a SHOULD ?), and the market will decide with product is best ;-)

Regards,
Jordi

----- Original Message ----- 
From: "Florent Parent" <Florent.Parent@hexago.com>
To: "Alain Durand" <Alain.Durand@Sun.COM>; "Pekka Savola" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
Sent: Wednesday, May 05, 2004 12:24 PM
Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt


> 
> (text removed)
> 
> >>>> ==> do we want to test for the presence of a proto-41 forwarding
> >>>> NAT box? That would likely be complicated (would require extra
> >>>> transmission of proto-41 packets)?  If we put that in, it's a
> >>>> "may" at most.
> >>>
> >>> I hadn't thought of that... Is it the case that if proto-41
> >>> forwarding is in place then the communication would be
> >>> un-differentiable from a non nated one?
> >>
> >> It's slightly different: the "internal IP address" set in the packets
> >> to detect whether NAT was on the path or not would tell there is a
> >> NAT, and would result in (an unnecessary) fallback to UDP.
> >>
> >> So, to cater for that situation, the logic would have to be like:
> >>
> >>  1) send the packet to the server with "my own address" set
> >>  2) the server notices that "my own address" and the source address
> >>     are not the same.
> >>   2.1) the server tries to send an IP-proto-41 packet to the source
> >>        address in any case; if it doesn't hear back soon, retry with
> >>        UDP.
> >>   2.2) failing that, just send the packet on UDP.
> >>
> >>   2.3) in both cases, activate the NAT keepalive sequence.
> >>
> >> It seems to me that the fallback in 2.1) might add some substantial
> >> code in case the NAT doesn't forward proto-41, especially if the
> >> negotiation/parameter exchange would otherwise conclude after sending
> >> the packet (i.e., this would require at least 1.5 roundtrips to verify
> >> a host behind a NAT got the information, and if it didn't, at least 2
> >> roundtrips -- using just UDP could be done with 1 roundtrip.)
> >>
> >> Obviously, this kind of "forwarder detection check" could possibly be
> >> implemented separately, and would be indicated as a flag from the
> >> client, but that might have some minor failure modes as well.
> >
> > How widely is IP proto 41 forwarding deployed? If it is not much,
> > I suppose that forcing an extra layer of encapsulation would
> > not be that terrible... and also would allow for more than one
> > tunnel to go through the NAT box.
> > So, I do not think that detecting NAT proto 41 forwarding is
> > an important requirement.
> 
> I think we should keep this simple (no ip-proto 41 fowarding detection). 
> Instead, the end-user can optionally select how the tunnel is established:
> 
> By default, client requests a "wildcard" encapsulation (NAT detection 
> enabled):
> - If no-NAT, proto 41 is used
> - If NAT, IPv6 over UDP is used
> 
> The client can also be configured to request a specific encapsulation (NAT 
> detection is off):
> - If the user knows that its NAT supports proto41 forwarding, then request 
> proto 41 tunneling.
> - The client can also request IPv6 in UDP tunneling, no matter in which 
> environment it is. This may be the case where the overhead is considered 
> insignificant
> 
> Florent
> 
> 
> 


**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.