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

Hi Brian,

On Oct 19, 2008, at 4:45 PM, Brian E Carpenter wrote:
>> NAT66 is still a third rail.  I don't want to go there.
>
> Yep. As Margaret well knows, RFC4864 was written to try to avoid
> stepping on that rail, and includes a gap analysis of what's
> needed to avoid it. I'd rather the IETF put effort into those
> gaps.

As I said in my last message, I don't _want_ people to deploy NAT66.   
I would be extremely pleased if we could find an architecturally  
cleaner solution to meet the provider-independence requirements  
described in RFC 4864 and get people to actually deploy that solution...

However, I've talked to many enterprise network administrators who are  
very happy with their NAT-based network architectures.  The IETF has  
yet to offer a more effective or easier-to-deploy solution for  
provider independence, and I haven't seen anything that would  
incentivize network administrators to move away from their current NAT- 
based architecture as they move from IPv4 to IPv6.  So, I believe that  
there will be widespread deployment of NAT66.  I wish it were  
otherwise, but wishing doesn't make it so.

So, I believe that it is important that we encourage people who plan  
to implement and deploy NAT66 to do it in ways that will be far less  
damaging to the IPv6 Internet than a direct port of their IPv4 NATs to  
IPv6.  Using 1:1 NAT, we should be able to eliminate the port mapping  
mess.  Also, by advocating the option of algorithmic mapping (of ISP / 
48s straight into ULA /48s, for example), we can help people to avoid  
the need for per-connection state, thus eliminating the brittleness  
that NAT introduces into the network.  We could try to get people to  
separate the concept of a NAT and a stateful firewall, making it  
easier for administrators to enable peer-to-peer applications if/when  
their business needs require such applications.  Even little things,  
like encouraging NAT vendors to build NATs that will generate a random  
ULA prefix for the customer if configured to so, may help to avoid  
some of the pitfalls we've suffered with NAT44 and redundant net 10  
addressing.

I understand that you might not be interested in working on a NAT66  
document, instead choosing to focus on developing better solutions to  
the problems described in RFC 4864.  But, don't you think there is  
some good that we could do with a NAT66 document in the meantime?

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