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

[Alain Durand <Alain.Durand@Sun.COM>]

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.