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

[Cameron Byrne <[e-mail]>]

Remi,

I am sorry there has been confusion.  Allow me to attempt to clarify

On Sun, Feb 19, 2012 at 6:29 AM, Rémi Després <[e-mail]> wrote:
> Russ, Jari, Ralph, Fred,
>
> On February 15, tools.ietf.org/html/draft-mawatari-v6ops-464xlat-00.html was re-posted as a v6ops WG document (tools.ietf.org/html/draft-ietf-v6ops-464xlat-00.html).
> Interpreting past v6ops discussion as a consensus for this to happen is AFAIK quite excessive (see in particular www.ietf.org/mail-archive/web/v6ops/current/msg11979), and besides that is inappropriate in view of WG charters and other existing drafts.
>

The 464XLAT draft was posted as WG draft on Feb 15 at the direction of
the v6ops co-chairs

Please note the draft was first brought to v6ops for review on Jan 16,
link below

http://www.ietf.org/mail-archive/web/v6ops/current/msg11830.html

>
> Reasons AGAINST making it a v6ops document include AFAIK:
>
> (1) There is an active 464XLAT draft IN SOFTWIRE (tools.ietf.org/html/draft-mawatari-softwire-464xlat-02.html), very similar, and still being discussed in this WG.
>

I believe there is an active discussion in v6ops, not in Softwires.

On v6ops 464XLAT appears in email titles 55 times from today back till
December 1

There have been ZERO emails with 464XLAT in the title during the same
period softwires

In consultation with the co-chairs, we have moved the 464XLAT from
softwires to v6ops.  If you think the discussion is still going on in
softwires despite 3 months of silence where 464XLAT was in the title,
then i can send an email to softwiress making it clear that 464XLAT
has moved due to lack of interest and no charter scope within
Softwires to support further discussion.

> (2) Although the draft was presented in v6 pops as a "trial deployment report" (www.ietf.org/mail-archive/web/v6ops/current/msg11907.html), its only reference to a deployment is "Incidentally, Japan Internet Exchange(JPIX) is providing 464XLAT trial service since July 2010" (it doesn't say how IPv6 /96 prefixes were assigned to customers, whether tested UEs included routers or not, whether they included DNS proxies or not, etc. etc.). On the contrary, it essentially includes specification of a NEW SOLUTION (in particular a new IPv6 address format).
>

You seem to have some technical questions about address assignment
that are all clear in the draft, and if not clear in the draft then
clear in the code.  I won't address them hear since they have already
been discussed in the draft and v6ops archive.  Feel free to start
another thread on specific technical clarifications after reviewing
the draft and discussion archive.

Allow me to clarify again the evolution of some of this.

I sent this email as a report on my trial of the 464XLAT draft.

http://www.ietf.org/mail-archive/web/v6ops/current/msg11906.html

The *draft* is not a trial report, the draft describes an architecture
that has been deployed in the USA and Japan.  That much is clear in
the first few lines of the draft.

The *email*  describes a trial that i have done where 464XLAT resolves
the 15% persistent brokenness for Android phones in an IPv6-only
NAT64/DNS64 network due to IPv4 referrals and so on.

I understand that became unclear as the v6ops discussion evolved.
Specifically, Fred forwarded the trial report email and asked for WG
consideration of the draft.  But, you will please understand that my
representation was that the *email* was a trial report of the *draft*
that describes an architecture.

> (3) The v6ops charter does say  "Solicit input from network operators and users to identify operational issues with the IPv4/IPv6 Internet, and determine solutions or workarounds to those issues", BUT it also says "This work should PRIMARILY be conducted by those areas and WGs which are responsible and best fit to analyze these problems."
>

Agreed, that is the v6ops charter.  464XLAT does not define any new
standards.  It is an informational document that simply describes how
to use RFC6145 and RFC6146 to achieve the desired result of making
IPv6-only network acceptable for subscribers today.  The email i sent
regarding deployment report confirms the goals of the 464XLAT draft
can and are achieved.  We have running code, it is open source, and
all code has been contributed upstream pending acceptance.  This is
all live and working today because no new technologies are used.  It
is simply reusing existing capabilities.

> (4) Softwire's charter has "Developments for stateless legacy IPv4 carried over IPv6".
> 464XLAT introduces in user devices a  new stateless behavior, but one that is based on private IPv4 addresses like DS-lite, and one that uses IPv4 packet formats like those of MA-T or 4rd-U (three Softwire designs). SOFTWIRE therefore continues to be the right WG to pursue this work.
>

This is NOT a stateless solution, it uses stateful RFC6146 AND
stateless RFC6145.  Please read the draft.    RFC6145 is not MAP or
4RD.

>
> To conclude, a rectification of the situation would be to:
> - cancel the ietf-v6ops-464xlat draft
> - continue to work on the Softwire 464XLAT, in relationship with other stateless user-device solutions (hopefully with an updated draft version reflecting recent additions made in the v6ops draft)
>

I hope my clarification has made it clear that nothing needs to be
retracted and that Softwires is not the right place since no new
technology is being created and that 464XLAT is indeed both stateless
on the CPE/UE and stateful in the network, therefore Softwires is not
the right place. 464XLAT is an operator focused solution created and
deployed already by operators using existing IETF standards.

> Besides, and authors are willing to, a real "trial deployment report", with more deployment information, would be very welcome as an individually submitted draft.
>

My hope is that the trial deployment email was clear enough and yet
another ID would not be helpful.  The email on the trial deployment
report of 464XLAT referenced nearly 200 tested applications and all
the code and functions are open source, so anyone can repeat and
validate them.  For folks with a T-Mobile USA SIM and a Nexus S phone,
the steps are as simple as flash the provided images or compile from
source yourself.

Please accept that this draft is running code, open sourced,
validated in deployment, and solves a VERY REAL problem for network
operators that do not have IPv4 addresses and MUST continue to grow
their networks.  RIR exhaustion is real in Asia today and will be real
in North America this year.  The trial deployment has made clear, i
hope, that 464XLAT enables a mobile wireless provider to deploy
Android phones as IPv6-only and have service parity with existing
IPv4-only phones.

>From my perspective, this is a substantial achievement that the IETF
should support and expedite instead of slow.

I once again call on folks to read the draft and contribute to make it better

http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00

If you can, also please review and trial the code yourself

http://dan.drown.org/android/clat/

CB

> Regards,
> RD
>
>
>
>
>
> _______________________________________________
> v6ops mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/v6ops