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

[Cameron Byrne <[e-mail]>]

inline

On Mon, Feb 20, 2012 at 9:23 AM, Rémi Després <[e-mail]> wrote:
> Cameron,
>
> Thanks for the additional information below.
> More comments in line.
>
> Le 2012-02-20 à 16:32, Cameron Byrne a écrit :
>> On Mon, Feb 20, 2012 at 1:52 AM, Rémi Després <[e-mail]> wrote:
> ...
>>> 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
>
> OK.
> Could you clarify then what justifies that "It does not require DNS64".
>

464XLAT works fine without DNS64.

Meaning, the CLAT may do stateless RFC 6145 NAT46 to the IPv6-only
access network destine for RFC 6146 NAT64 towards the Internet

This is a complete solution for any IPv4-only hosts behind the CLAT.

For me, DNS64 is advantageous to use for the following reasons in *my* network

1.  DNS64 is already deployed in my network as part of the NAT64/DNS64
service i offer today

2.  DNS64 allows for the discovery of the Pref64 using
draft-ietf-behave-nat64-discovery-heuristic

3.  DNS64 allows for single translation in cases where the host and
application are capable of doing IPv6 but the server does not have a
AAAA record.  This is a very common case for my scenario.

Regarding discovery of the Pref64, the draft discusses that Pref64 may
be discovered through others means.  DHCP options in the future,
manual configuration, proprietary methods ... are all possible in the
future... Today i have draft-ietf-behave-nat64-discovery-heuristic
working but i do not want to constrain implementations to just those
that 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.
>
> Why, then, say "In the best case, the CLAT will have a dedicated /64"
>

It just seems cleaner to me to have a dedicated /64 if it is
available.  Operationally, aside from the NDP claiming the /96, there
is no difference to have dedicated or not dedicated.

>>  This is how all IPv4 and IPv6
>> addresses are assigned to UEs in my network.
>
> Is this with a standard format (if yes, a reference would make it clear).
>

I was mistaken before, here is the reference for SLAAC being used for
address configurations.

http://tools.ietf.org/html/rfc6459#section-5.2

>> 3.  The UE, which is also the CLAT, received a single /64 of IPv6 from
>> the network
>
> OK.
>
>> and no IPv4.
>
> (Already understood, otherwise nothing new would be needed)
>
>
>>  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.
>
> Then why to add a section which describes two variants.
> Besides, I didn't understand this sentence "In the 464XLAT environment, the PLAT and CLAT SHOULD include an IPv6 Fragment Header, *since IPv4 host does not set the DF bit*" (asterisks added).

I think it may be wise to remove that language.  Let me check with my
co-authors.

>>
>> 5.  Pref64/n was discovered using draft-ietf-behave-nat64-discovery-heuristic
>
> OK.
>
>
>>> 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.
>
> There is some of this of this above, thanks.
>
> ...
>>> 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,
>
> I am not as much experienced in IETF procedures as you seem to believe.
> Like yourself, I try to understand and apply BCPs.
>
>> but i believe informational I-D may use this language.
>>
>> Just looking, RFC6092 is informational and uses this language.
>
> Personally, I find it confusing in RFC6092, but this is another subject.
>
>> 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".
>
> My point is that it includes some behavior specification (464XLAT compliance is more than just compliance with RFCs it refers to).
>
> ...
>
>>
>>>>    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.
>
> I don't know about off-list, but to say differently what think:
> - abandoning the new idea expressed in the 464XLAT would be a very bad idea
> - OTOH, dealing with it in the context of 4rd-U seems to me a good idea (unify stateless UE behaviors so that they can work consistently both in networks using stateful NAT64s and those using using with stateless ISP nodes)
> - working together for this to happen in Softwire would be welcome on my side.
>
> BTW, if you can take the time to read the 4rd-U draft, your questions and comments will be most welcome.
>
>>  It seems the softwire
>> folks see 464XLAT as a competing technology.
>
> I am an active Softwire guy, and don't see it that way.
>
>> IMHO, MAP-T and 4RD-U do
>> not solve *my* problems.
>
> 4rd-U isn't frozen yet.
> I see solving your problem as an objective.
>
>>  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).
>
> I never did, I hope, but I think I rather asked about real order of magnitudes of your problem.

Publicly available information is that T-Mobile USA has 30+ Million
subscribers and about 100,000 IPv4 addresses, total.  Not just for
subscribers, 100k IP addresses to run the whole business (data
centers, web sites, DNS servers, ...).

About 1/3 of those subscribers are actively attached to the data
network and consuming an IPv4 address, data network attachment is
growing

You can assume we are ~100% utilized on our IPv4 addresses, and that
nearly all subscribers reside behind existing 19 /25 public IPv4
pools.

My own Android phone has ~20 active TCP sessions at steady-state (push
updates from email, twitter, facebook, ...).  When i do tethering, it
goes up substantially.

As you can see, things are pretty tight.  They are going to get more tight.

We chose stateful NAT64 as a path forward since it was a simple
feature add that leverages the existing NAT44 hardware and /25 ipv4
NAT blocks.  This means that deploying NAT64 required no new IPv4
public addresses.  Going to 4RD-U and MAP-T would require a
substantial re-work of the network to provide a suitable pool of IPv4
addresses for the stateless translation.

We want 464XLAT since it enables us to make IPv6-only a feasible
service option to our subscribers in the near term, the only missing
piece from generally available code (shipping products) is the CPE /
UE to do the CLAT functions of RFC6145 and Pref64 discovery.  The
functions have been submitted to the Android Open Source Project.

That said, please don't try to re-engineer this network scenario on
the list.  This is a real scenario, lets not make it a diversion.

I tried to have this generic scenario discussion on softwires here
http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html

> Didn't get it yet.
> Ideally that would include the number of simultaneous devices to be supported, and the size of the IPv4 space available, with lengths of IPv4 prefixes that compose it.
> In any case, your requirement is yours,  and some other operators do have different requirements (tools.ietf.org/html/draft-ietf-softwire-stateless-4v6-motivation-00.html).
> That's why some coordination makes sense.
>
>>  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 share this view on current MAP documents.
>
> OTOH, I do think that making UEs that would support a 4rd-U, completed with permitted RFC1918 addresses in customer sites, would largely increase their applicability with a limited enough added complexity.
>
>
>> I hope you see that 464XLAT is an operational solution without any
>> novel technology.
>
> In my understanding, 464XLAT does introduce a quite useful technology that is almost completely based on existing pieces, like 6rd,  but this doesn't exclude these two from being NEW technologies.
>
>
> Regards,
> RD
>
>