[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
Hi Alan,
Is difficult to say, but my survey (obviously not a precise one, lack of resources, lack of replies from vendors, and lack of chances to test myself all the models in the market !), indicates that 80-85% of the products there support proto-41-forwarding.
So I think is a MUST.
Regards,
Jordi
----- Original Message -----
From: "Alain Durand" <Alain.Durand@Sun.COM>
To: "Pekka Savola" <pekkas@netcore.fi>
Cc: <v6ops@ops.ietf.org>
Sent: Wednesday, May 05, 2004 3:09 AM
Subject: Re: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt
>
> On May 4, 2004, at 1:35 PM, Pekka Savola wrote:
>
> > in-line... omitting the parts where we agree..
>
> I'm glad we are converging. See inline response were there is still
> discussion.
>
> >> If the ISP deploy the 'registered' mode and it has not been
> >> implemented in the client, it does not work. That's why I think all
> >> implementations would have to support both and the operation mode
> >> would be decided by the ISP.
> >
> > It would be beneficial to support both, yes, but if this was to be
> > applied e.g., in 3GPP or mobile environments (just to take an
> > example), I'd guess that there might be some interested in simplifying
> > the client.
> >
> > Similarly, as providing service over a tunnel is more or less a
> > "tryout" service in any case (I don't think many ISPs would see that
> > as "production"), my personal view is that the most who would want to
> > deploy something like this in the first place would actually want the
> > simple mode. (And if they're OK with all the registration etc.
> > _process_ and procedures, many could use L2TP or deploy dual-stack in
> > any case.)
> >
> > The simple form is also something that could be implemented and turned
> > on by default on hosts (when v6 is turned on, if not on by default,
> > that is).
> >
> > That's why I think "simple" form is criticial, and the registered mode
> > interesting for "power users" but not necessarily for all that many
> > ISPs for production use.
>
> I'll take this discussion to a separate thread.
>
>
> >>> However, as
> >>> NAT traversal usually requires an extra layer of encapsulation,
> >>> the
> >>> tunnel set-up protocol must be able to detect automatically the
> >>> presence of one or more NAT boxes in the path.
> >>>
> >>> ==> s/must/should/ (this is what 4.3 and 5.3 have at least, and IMHO
> >>> a
> >>> should is sensible.)
> >>
> >> Not sure. I think the protocol and its implementation MUST
> >> support the detection, but the deployment MAY turn it off.
> >> i should clarify this.
> >
> > This is a bit in odds with 4.3 and 5.3 then, as those seem to be
> > closer to a 'should'.
> >
> > My own view is that in some environments it might be acceptable to
> > just always use UDP, to avoid certain hassles of toggling between
> > proto-41 and UDP -- but as this causes overhead, we should try to
> > avoid the overhead if feasible. Hence a (strong) should.
>
>
> I honestly do not believe that checking the presence of a NAT
> and firing UDP encapsulation if it is there is such a big deal...
> So I believe it is worth a MUST, as the payoff is important
> by reducing the overhead.
>
>
> >>> ==> 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.
>
>
>
**********************************
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.