food for thought on NAT traversal techniques

[Pekka Savola <pekkas@netcore.fi>]

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?

- 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")?

- 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) ?

- 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.)

- 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