[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation]
Hi Pekka,
See below, in-line.
Regards,
Jordi
----- Original Message -----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "JORDI PALET MARTINEZ" <jordi.palet@consulintel.es>
Cc: <v6ops@ops.ietf.org>
Sent: Saturday, March 13, 2004 9:13 PM
Subject: Re: proto-41 forwarding vs NAT traversal [Re: Tunneling scenarios and mechanisms evaluation]
> 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.
I don't agree. In general is in the other way around. Is more and more often that the routers, gateways, etc., are updated from time to time, with new firmware or software.
>
> 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.
>
Agree.
> 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.
I think if we are trying to approach to a more complete solution, we need to include these options in the draft/matrix. As I indicated in the meeting, I'm sure there are 100% perfect solutions, but they will take long time to be ready; but at the same time, completing the matrix, even when complicating it a little bit, is mandatory, to cover as much as possible the real market situation, and consequently provide the needed transition tools, to facilitate how the deployment can happen (in the real market).
>
> 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.
I meant that the NAT can be the end-tunnel point (for a TB, and if possible automatically configured, but we don't have this right now), OR the NAT box is upgraded to support 6to4. Note that this is already happening. I read a couple of weeks ago about an upgrade for an existing router (IPv4 only previously) to support 6to4.
>
> > 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).
Our testing, considering not just the number of models and manufacturers in the market, but also how many units there are in the market from each manufacturer, shows about 85% supporting proto-41, but I guess this will improve. I'm not sure if is good to mention here specific brands and models, but in any case is simple to understand. We can have a market with 100 models (just an example), but one of the models has 60% of the market sharing and supports it. That means that we have already 60% of the market supporting this feature, just add the others from the pool of 100, and you have the 85%.
>
> > 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.
You feeling is wrong ;-), see my previous reply. We have gathered this information from different sources for months. Just an example, only one of the products being sold/installed in Spain by the xDSL provides, didn't supported proto-41-forw., and by the way, is not the one that has the bigger market sharing.
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
**********************************
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.