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

[Cameron Byrne <[e-mail]>]

On Feb 20, 2012 7:05 PM, "Satoru Matsushima" <[e-mail]>
wrote:
>
> On 2012/02/21, at 5:34, Brian E Carpenter wrote:
>
> > On 2012-02-20 20:11, Satoru Matsushima wrote:
> > ...
> >> I can see a strong statement that double protocol translation is an
architecture which is not recommended by the IETF.
> >> (http://tools.ietf.org/html/draft-ietf-behave-v4v6-bih-09)
> >>
> >> I'd like to hear from chairs that does v6ops consent to be opposed to
that statement.
> >
> > Well, that's for the WG as a whole to say, not the chairs.
> >
>
> It can be done by wg last call that is a chair's role.
>
>
> > I hate translation, and I've hated it since RFC 1671. Therefore,
> > I hate double translation more. However, we are going to get
> > double translation anyway - via CPE NAT and CGN, or via 464XLAT.
> > It is a consequence of running out of IPv4 before the universal
> > deployment of IPv6.
> >
> > I don't see one being more evil than the other, so it makes sense
> > to document the mechanisms.
> >
> >   Brian
>
> 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.
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.

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

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)


CB