Re: Merge NAT-PT approaches?

[Brian E Carpenter <brian.e.carpenter@gmail.com>]

I'm sympathetic to the idea. Bringing in the shim action
only when it's actually needed sounds good in principle.
The devil is in the details, of course, but we can
investigate that off-list if people would like us
to follow this up.

(Due to the midsummer break where I now live,  I won't
be on line so much for the next ten days.)

   Brian

On 2007-12-21 00:28, Iljitsch van Beijnum wrote:
> 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