Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation]

[Pekka Savola <pekkas@netcore.fi>]

On Sat, 13 Mar 2004, JORDI PALET MARTINEZ wrote:
> Alain's comment was:
>
> "NAT traversal must be supported." This is not true if the tunnel
> ends in the gateway where the NAT function is usually located. I
> think this is important, since the solution to deploy does not need
> to deal with complexity of NAT traversal.

True enough.  However, I have doubts on how useful this case is in 
practice, as a large number of gateways cannot be expected to be 
upgraded -- that is, we will have to support host-centric deployment 
in any case.

However, I guess it might be useful to try to tease these two subcases 
apart to see if there are significant differences, like:

unmanaged w/o ISP support, IPv4 gateway not upgraded
  - NAT traversal or proto-41 forw. required
  - only host addressing OK, site addressing "nice to have"

unmanaged w/o ISP support, IPv4 gateway upgraded
  - host(s) require nothing
  - the gateway requires NAT traversal capability
  - must support getting at least /64

unmanaged with ISP support, IPv4 gateway not upgraded
  - NAT traversal or proto-41 forw. required
  - only host addressing OK, site addressing "nice to have"

unmanaged with ISP support, IPv4 gateway upgraded
  - host(s) require nothing
  - the gateway does not require NAT traversal
  - must support getting at least /64

So, it seems what we get here is one case where NAT traversal is not 
required, and a rather obvious conclusion that when the gateway is 
implementing a transition function, it must implement a mechanism 
which can be used to obtain at least a /64 prefix; e.g., Teredo is not 
sufficient.

This should go into the draft somehow, but as listing these would 
complicate the matrices a lot, I'm not sure whether the matrix is the 
right place to add this result.

Something obvious I missed?
 
> What I understood then is 2 options:
>>
> 1) The NAT box is already the IPv6 end point for the tunnel ?
> Correct if we prefer this instead of 6to4 (because probably the cost
> of implementing 6to4 is the same as a TB client in the NAT)

Tunnel broker is generally much more complex than 6to4, but if you buy
the concept of ND proxying, it could be a lot simpler as well.  If
not, you'll need something like DHCPv6 prefix delegation or custom
mechanisms.

> 2) We don't need NAT traversal IF proto-41-forwarding is working in
> that NAT

Yet, that is an optimization (or at least, cannot be the only
solution) unless we can be assured that sufficiently large percentage
of boxes do that (e.g., over 95% of the market or whatever).
 
> By understanding is that the number of NATs that support proto-41 is
> comparable to the number of NATs that support Teredo (not sure other
> NAT traversal mechanism).

Do you have more precise data than that?  Maybe it would be useful to
write it down -- like draft-jennings-midcom-stun-results-00.txt has
done about some NAT types.  I have a gut feeling that NAT proto-41
forwarding is not as common as non-symmetric NATs.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings