Re: [v6ops] Reasons not to endorse NAT66/6to4(ref draft-kuarsingh-v6ops-provider-managed-tunnel-00)

[Rémi Després <[e-mail]>]

Hi, Victor,

Le 31 oct. 2010 à 19:31, Victor Kuarsingh a écrit :

> ...
> At this point many operations will need to apply either RFC1918 or (key
> issue) public Space (either from their own pool as overlap, from RIR special
> block, camped space etc).  In the second case, NAT is now unavoidable for
> such customers (in IPv4 space).  So we are in a "bad" scenario either way.

Yes, this scenario is than what we have today, but ONLY for IPv4.
If hosts are dual-stack, and if native IPv6 addresses are made available to them, problems are avoided.
For this there are helpful transition tools to bring native addresses to hosts even if dual-stack routing is difficult to deploy:
- 6rd if CPEs can be upgraded and hosts are dual-stack
- 6a44 if CPEs can't be upgraded but hosts are dual stack and support a 6a44 add-on. 

> ...
> An additional NAT66 will enter the the Internet world, one way or the other
> (i.e. Dual homing enterprises),

Re-discussing this point should be useful  after you have looked at draft-despres-softwire-sam-01, in particular  sec 3.3.
It describes a multi-homing solution, without any NAT66,  while NAT66 has remaining problems in multihoming sites if they have PA prefixes  and separate CPEs.

Regards,
RD