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

[Rémi Després <[e-mail]>]

Cameron,

Thanks for these answers,
More questions and comments below.

 Le 2012-02-20 à 19:44, Cameron Byrne a écrit :
...
>>>   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.

Well,  the discovery heuristic that you used implies DNS64 (ref. the quote just below from draft-ietf-behave-nat64-discovery-heuristic).
Without DNS64, some more assumptions seem to be needed for IPv4 hosts to get A records, but I couldn't figure out which ones on my own. 
  "When sending AAAA query for the known name a host MUST set "Checking Disabled (CD)" bit to zero, as otherwise the DNS64 will not perform IPv6 address synthesis hence does not reveal the IPv6 prefix(es) used for protocol translation."


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

Aren't NAT64s always coupled with DNS64s, as seems to be implied by all scenarios of RFC6144?
 
> 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.

Understood, but:
- Claiming a /96 on a link seems new to me (is there an existing reference?)
- Avoiding the need to do it is AFAIK an improvement, proposed in 4rd-U thanks to the V-octet discriminator of 4rd addresses.
- If DNS64s are parametrized to synthesize addresses that have the V octet, finding IPv4 addresses in IPv6 addresses can become deterministic instead of heuristic. 


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

Thanks.


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

OK

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

Renewed statement.


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

I suppose that these 19 prefixes were derived by you from a smaller number of shorter allocated prefixes, right?
That is these shorter prefixes that are relevant.  

> My own Android phone has ~20 active TCP sessions at steady-state (push
> updates from email, twitter, facebook, ...).

A key complementary information is the proportion of these that will work in IPv6 where IPv6 is available.
Any idea of this proportion?

>  When i do tethering, it
> goes up substantially.

BTW, did the trial include tethering?
In the model, is tethering to be supported with a NAT44 in the UE? 
If not, how?  

> 
> As you can see, things are pretty tight.

Agreed, but not impossible, see near the end of this email.

> They are going to get more tight.

Not so sure as far as IPv4 is concerned: as IPv6 gets really deployed, less and less sessions will consume IPv4 ports.


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


How substantial this rework is does depend on each operator's starting point, but AFAIK it is quite feasible (see the example near the end of this email)


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

Right, there is _little_ to add to what exists,  but still _something_.
That much has to be rigorously specified (the Devil is in details).

>  The
> functions have been submitted to the Android Open Source Project.

Well done.


> That said, please don't try to re-engineer this network scenario on
> the list.

I just try to understand what you mean, and which part has been validated.
I am also interested in simplifications that result from unifying good designs.

Suggesting I try to re-engineer is something that could have been avoided (IMHO).


>  This is a real scenario,

No doubt about this.

> lets not make it a diversion.

There is no intent to divert, only to work for progress.
 
> I tried to have this generic scenario discussion on softwires here
> http://www.ietf.org/mail-archive/web/softwires/current/msg03402.html

Indeed and you did receive several answers, including one from me (http://www.ietf.org/mail-archive/web/softwires/current/msg03406.html).

Note that this contradicts your previous assertion that there was no discussion about 464XLAT in Softwire in the last 3 months (9 e-mails in early February do contain "464XLAT")

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

Your reasons are obviously legitimate in _your_ environment. 

Yet, it is IMHO interesting to note that, with figures you gave above (30+ million subscribers, 1/3 active, 100k IPv4 addresses), static address sharing a la 4rd-U might realistically be introduced:
- Move a fraction of the IPv4 addresses from dynamic to static sharing  say 32K addresses, i.e. 33%. (NAT 64 usage will naturally be reduced as UEs start using their statically assigned shared addresses instead of NAT64s).
- Choose a sharing ratio of 512, in order to support 32K*5124= 16,777,216 UEs (more than 1/3 * 30+ millions)
- Thus, without losing the benefit of NAT64 for UEs that don't support 4rd-U, each UE gets a shared public IPv4 address, with 120 reserved ports for sessions that can't be IPv6.

Please consider that there is no aggressiveness in pointing this out, just the wish to see realities as they are.
My wish is cooperation, not useless competition without understanding valid points others have made.

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

What is important is the total size of the available IPv4 space, not the length of the shortest prefix. 

Regards,
RD




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