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

cameron,

Le 2012-02-19 à 16:58, Cameron Byrne a écrit :

> 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 <despres.remi@laposte.net> 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

That's why a lack of consensus is relevant.

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

Well known, but since then a number of comments suggested to send the document to some other WG.

> 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

Fair enough, but it was never closed, and I do believe it is useful to pursue it ("resume it" if you prefer).
There is room I think to include the concept (which BTW I find quite interesting) in the unified stateless solution under study in Softwire.
It seems to find a natural place there. 

> 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

True, little interest was expressed then, but this was when the work on MAP and 4rd-U was really beginning.
The work on these two has now progressed in Softwire, and considering functional requirements of 464XLAT in this context makes in my undesrtsnding a lot of sense.

> and no charter scope within
> Softwires to support further discussion.

Debatable I suppose since 464XLAT was first submitted there.

>> (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.

Well, reading code is AFAIK a way to check that it complies to a spec, but not the right way to understand what a specification means. 
Specifications must be clear by themselves.

In any case, my question isn't about understanding the specification (clear enough IMHO for this level of discussion). It reflects interest for a more complete draft describing the trial configuration, with its configuration parameters. (The specification describes a number of options: with or without DNS64; possibility that an "access networks that does not allow for a dedicated translation prefix"; CLATs that may get /64s via DHCPv6 or by other means; inclusion fragment headers possibly systematic but optional; possibility for some CLATs to get longer than /64 IPv6 prefixes).

I just say that a real "trial deployment report" would be nice to have, but of course no obligation.

>  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.

I agree that it is how confusion started. 

>  But, you will please understand that my
> representation was that the *email* was a trial report of the *draft*
> that describes an architecture.

I do understand this, yes.

>> (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 draft does include SHOULDs and MAYs that belong to standardization vocabulary, e.g.:
"In cases where the access network does not allow for a dedicated translation prefix, the CLAT SHOULD take ownership of the lowest /96 from an attached interface's /64 to source and receive translation traffic. Establishing ownership of the /96 requires that the CLAT SHOULD perform NDP so that no other nodes on the /64 may use the lowest /96." 

> The email i sent
> regarding deployment report confirms the goals of the 464XLAT draft
> can and are achieved.  

"IPv4 access service to mobile AND WIRELINE IPv6-only edge networks"? 
(From the abstract, upper cases added.)

> 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.

Close to that, but not "simply" (see above).

>> (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.  

AFAIK, it adds rigorously nothing to NAT64 (RFC6146).
OTOH, it introduces a new CPE behavior that uses RFC6145, but adds few design choices to it, like MAP-T.
> Please read the draft.

Your suggesting that I didn't read the draft could advantageously have been avoided (IMHO).

>    RFC6145 is not MAP or
> 4RD.

Why you say this is unclear. AFAIK nobody ever suggested that.

>> 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.

The claim that nothing new is specified is the main point that is challenged (see above)
> 
>> 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.

The draft is about mobile AND "wireline" (understood to include DSL).

> 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.

This isn't sufficient to say that the specification is complete for all its use cases.
Besides, I would say that these phones are in some sense dual-stack:
- they are in all cases IPv4 aware, at least for IPv4-only applications
- if acting as routers, they "SHOULD" include IPv4-aware DNS proxies.

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

The idea is quite interesting, and quickly dealing with it in relationship with current work on MAP-T and 4rd-U makes a lot of sense (IMHO).

Regards,
RD

> 
> 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
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops