Re: [v4v6interim] [BEHAVE] Proposal for new BEHAVE charter

Margaret Wasserman wrote:

...
> > BEHAVE will develop protocol-independent toolkits usable by  
> > application
> > protocols for NAT traversal. The WG has already produced an 
> > update of
> > the binding discovery protocol STUN. It will now produce a relay
> > protocol that focuses on security that is usable with both IPv4 and
> > IPv6, and capable of relaying between the two IP versions.
> 
> Is there a draft available on which this work will be based?  
> I'm not suggesting that you mention it in the charter, I'd just 
> like to know which draft I should be reading for this item.

Yes, they are:

  draft-ietf-behave-turn (nearing completion)
  draft-ietf-behave-turn-ipv6 (expired, but a new version is
                               being submitted shortly that 
                               aligns it with TURN)
  draft-ietf-behave-turn-tcp (will be discussed in Minneapolis)

...
> I would also like to us write (at least) two NAT-related 
> documents that aren't listed here:
> 
> (1) A document that offers advice on how/when to deploy these  
> translation mechanisms vs. other choices.  I think this document 
> would cover topics such as:
> 
> 	- If the infrastructure will support dual stack and you 
> are running out
>            of IPv4 addresses, NAT IPv4 and leave IPv6 alone.

Alain, Dave Thaler, Jari, and I are co-authoring a document
that will discuss when-to-translate and when-to-dual-stack-lite.

I don't know if such a document would belong in BEHAVE or
SOFTWIRES -- it spans between the two WGs.

> 	- The advantages of placing NATs closer to the edges of 
> the network

I don't believe anyone has submitted an I-D that delves into
those advantages or those disadvantages.  Certainly, there is
a lot of experience with NATs close to the edges -- those
are the NATs that Linksys/D-Link/Netgear/etc. have been 
selling for years.

> (2) An explanation of how to do IPv6 <=> IPv6 NAT.  It am 
> convinced that there are some people who will choose to do 
> this for the same reasons that people with plenty of IPv4 
> addresses choose to use IPv4 <=> IPv4 NATs today.  I think we 
> could write a document that says something like:   IPv6
> <=> IPv6 NATs are not really necessary, don't provide any concrete  
> advantages that can't be obtained through less disruptive 
> means, and are not recommended by the IETF, but if you are 
> planning to do this anyway, please do it right (don't
> include port translation, use algorithmic address mapping if 
> possible, instead of state tables, etc.).

NAT44 has been a third rail (*) in the IETF for over a decade, 
and NAT64 and NAT46 have only recently emerged as a way forward 
to help with the eventual transition to IPv6.  

NAT66 is still a third rail.  I don't want to go there.

(*) <http://en.wikipedia.org/wiki/Political_third_rail>

-d

_______________________________________________
v4v6interim mailing list
v4v6interim@ietf.org
https://www.ietf.org/mailman/listinfo/v4v6interim