Merge NAT-PT approaches?

[Iljitsch van Beijnum <iljitsch@muada.com>]

Hi Brian (and others),

The NAT-PT discussion pretty much stopped after the v6ops session two  
weeks ago. So let me kick it in gear again:
I think it would be useful to merge our approaches. Mine has the  
benefit that the changes are minimal on the host side and changes on  
the NAT-PT box side are probably unnecessary for a large subset of all  
possible communications. Your approach has the advantage that it can  
provide a complete solution for pretty much every type of  
communication, including a decent chunk that probably can't even be  
supported by IPv4 NAT.
So what I'm thinking is that we come up with something where hosts do  
A record lookups but otherwise use NAT-PT pretty much the way it is  
today. I've had some private feedback on anycast, so I'm thinking the  
top 96 bits would come from either direct manual configuration or they  
are obtained from a magic DNS name in the domain that the host has  
learned through manual configuration or DHCP.
The shim approach would then kick in when the host needs to do more  
advanced communication, for instance, when it needs to know or set the  
source address / source port, it needs incoming connections or when  
there needs to be authentication from the host towards the NAT-PT  
gateway.
We probably want to define some API that applications can use to  
invoke the above but also IPv6 firewall traversal for regular IPv6  
connectivity. (Unless there already is an API we can reuse?)
Iljitsch