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

[Cameron Byrne <[e-mail]>]

On Mon, Feb 20, 2012 at 1:52 AM, Rémi Després <[e-mail]> wrote:
> 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 <[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
>
> 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).
>

Glad to clarify this here.  My trial required no change to the
IPv6-only DNS64/NAT64 network beta service that i have offered to by
customers for close to 2 years now.  Adding 464XLAT was purely a CPE
function layered onto that existing network "as is".

1. Yes, we use DNS64

2. A dedicated translation prefix was not used.  Since my 3GPP Release
7 network does not support DHCP at all, the address is pushed to the
UE as part of PDP setup in the PCO IE.  This is how all IPv4 and IPv6
addresses are assigned to UEs in my network.

3.  The UE, which is also the CLAT, received a single /64 of IPv6 from
the network and no IPv4.  This is the only address scheme that was
used or can be used in my network

4.  There was no change to the RFC 6146/6145 behavior, fragment
headers were included.

5.  Pref64/n was discovered using draft-ietf-behave-nat64-discovery-heuristic


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

I am attempting to operate as transparently as possible.  Please feel
free to query me further.

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

Correct.  The authors, including myself, are not as experience as you,
but i believe informational I-D may use this language.

Just looking, RFC6092 is informational and uses this language. Also,
we are open to changing the document type to BCP or Standard Track if
that is a better fit.  It has been recommended on list that this draft
go standards track.  So, i believe there is an open discussion here.
We can adjust as the WG sees fit.  Right now, i feel most comfortable
with informational.  I don't think experimental is helpful to network
operators that trying to solve a near term problem with "no new
technology".

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

CPE is not an IETF standard.  So, changing its behavior to include
RFC6145 should not be controversial.

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

Agreed.


>>    RFC6145 is not MAP or
>> 4RD.
>
> Why you say this is unclear. AFAIK nobody ever suggested that.
>

I keep getting the feeling like 464XLAT should be abandoned and the
use cases should be folded into MAP-T by the MAP-T author or 4RD-U
from the 4RD-U authors, both on and off list.  It seems the softwire
folks see 464XLAT as a competing technology. IMHO, MAP-T and 4RD-U do
not solve *my* problems.  We took time to document how 464XLAT is
unique in the draft.

I have brought to softwires the concern that stateless core NAT64 is
not acceptable given the address efficiency issues (please don't blast
me about how my issues are non-issues).  On the softwire list, i
brought this up and was told a /14 of IPv4 was probably needed to meet
a mid to large size wireless operator.  Unfortunately, these address
are not available in APNIC today and will not be available in ARIN or
RIPE in the very near future.... considering the timeline scope the
IETF operates at.  That said, the stateless solutions have an audience
with network operators that already have large allocations and wish to
be more efficient.  That's great, live and let live.

Also, the MAP family is quite complicated for me and lack of trial
deployment at scale is a concern since the IPv4 exhaustion issue is
pressing.

I hope you see that 464XLAT is an operational solution without any
novel technology.

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

I am still unclear on your overall concerns with 464XLAT.  Are these
your concerns?

1.  We add RFC6145 functions to a "CPE"

2.  We use SHOULD and MAY in an informational document?


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

Yes, i was commenting on my validation work in mobile.  It works in
wireline as well.

CB

>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/v6ops
>