Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.

[Satoru Matsushima <[e-mail]>]

First, I'd like to see that the authors request wg last call.

On 2012/02/21, at 13:47, Cameron Byrne wrote:

> [--snip--]
> >
> > The mechanisms are well known already, I'm interested in that the document elaborate how the past IETF(IESG) statement doesn't make sense which statement should be disappeared consequently.
> >
> 
> That decision might be best fit for draft-weil 
> 
> http://tools.ietf.org/html/draft-weil-shared-transition-space-request-15
> 
> That draft is nat444 space allocation, does not require any ipv6 strategy, and it is in last call.  In the IESG notes I read, double translation was not the core issue the IESG was concerned with. MAP-T also fits the double/triple translation profile.

I won't argue that which statement is best fit to which document.


> 1.  464XLAT is not the first nor the last to use double translation. That said, double translation is only a corner case in 464XLAT when DNS64 is used.  See section 7.3 of 464XLAT draft for traffic treatment scenarios.

One clarification. Is it true that double translation is a corner case in 464XLAT _when DNS64 is used_?

> 2.  464XLAT explicitly evolves to remove double and single translation where possible, more v6 capable software and content as time goes on.

BIH and MAT-T are same on that aspect.

> 
> 3.  464XLAT enables IPv6-only deployment in cases that would otherwise be NAT444, including squat space usage.  
> 4.  On my network, after World IPv6 Launch, over 50% of the traffic delivered to the average user on a mobile will be IPv6 end-to-end, if the subscriber is IPv6 enabled.  They cannot be IPv6 enabled until 464XLAT is implemented (see motivations for draft-464XLAT on reasons why dual-stack and tunnels do not work for my scenarios) 
> 
> 

Great. Good lack to see that at June 6.

cheers,
--satoru