[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: food for thought on NAT traversal techniques
> Hi,
>
> Find below a bit food for thought on designing NAT traversal mechanisms.
> I think it would be useful to consider a bit more on what we NEED.
>
> - Should we send a clear signal to NAT vendors what kind of deployment
> model we think is best, and what are the goals they should try to work
> towards?
I think it would be useful for the IETF to try write up something which
shows the path to IPv6 for small and home networks. Without this
we have this collection of mechanisms and the danger that some
are told "implement 6to4" and others are told "implement proto 41"
when in fact what we really want is native IPv6 where the NAT becomes
a leaf IPv6 router with prefix delegation etc.
Currently there is a danger that the various short term approxes overshadow
the final goal which would be bad.
> - Should we try to leverage existing IPv4 NAT traversal mechanisms if
> possible (there seem to be a plenty of them, like STUN, TURN, etc.), and
> even avoid all IPv6 work we can? Would that be of value in itself ("A
> particular kind of NAT breaks this IPv_4_ solution we'd like to use to
> traverse NATs")?
My opinion is that when the endpoint is IPv4 the best general approach is to
use the IPv4 NAT (by having the IPv6 nodes really being dual-stacked with a
private IPv4 address). That way the above techniques can be used, with all
their benefits and downsides, without writing one extra line of code.
Thus the key thing v6ops needs to worry about in this space is the
case when the endpoint is IPv6 but
there exists some IPv6-unaware IPv4 NAT box in the path.
Being able to construct some form of IPv6 tunnel over that NAT box
would allow e2e IPv6 communication.
> - What is the expected lifetime of our NAT traversal mechanism
> (e.g. a few years, until most NAT vendors have started deploying 6to4 or
> native) ?
The v6overNAT would naturally go away once the NAT box is v6 aware, whether
using native or 6to4.
> - What features are critical for the NAT traversal mechanism?
> For example:
> * simplicity (spec and the protocol)
> * ease of use (easy to turn on/configure)
> * interop with NATs (works with all NAT boxes or close enough)
> * robustness (is otherwise failure-proof with few things that could go
> wrong)
> * route optimization (traffic between different IPv6 nodes behind
> NAT's as direct as possible)
> * security (doesn't make unexpected holes, minimizes DoS attacks etc.)
My list includes simplicity, robustness and security.
I understand the desire to optimize things, but I'm concerned about
sending the signal that v6overNAT is the new Internet when in fact
we want the new Internet to be IPv6. Thus wanting the v6overNAT solution to
be good enough to be confused with native IPv6 would make sense
if we don't want the users to know the difference but this implies
that the users will never know to ask for native IPv6 from the ISP.
The alterantive would be to send the message that v6overNAT is a temporary
measure to provide global addressability, but that ISP support of
native IPv6 is needed to get better performance.
I'm not surprised that different participants make different
tradeoffs on this point. Perhaps we should try to discuss this
tradeoff explicitly instead of discussing it implicitly when talking
about some proposed mechanism.
Erik
> - What are the properties of the solution(s) we would like to use/develop
> considering these issues? How much work we should we should use on
> mechanisms which are likely to:
> * be quite low in our "preferred solutions list",
> * have a limited lifetime, and hopefully soon replaced by a
> better-working mechanism,
> * are something other WG's have had to specify as well, and
> * be something we may not even be able to specify implement correctly,
> simply and reliably?
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>
>
>