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

Cameron Byrne <cb.list6@gmail.com> Tue, 21 February 2012 17:21 UTC

Return-Path: <cb.list6@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F8A321F86DB for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 09:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.259
X-Spam-Level:
X-Spam-Status: No, score=-3.259 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WgZfHTGKdLFU for <v6ops@ietfa.amsl.com>; Tue, 21 Feb 2012 09:21:31 -0800 (PST)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 38B8C21F85F9 for <v6ops@ietf.org>; Tue, 21 Feb 2012 09:21:31 -0800 (PST)
Received: by pbcwz7 with SMTP id wz7so7915015pbc.31 for <v6ops@ietf.org>; Tue, 21 Feb 2012 09:21:31 -0800 (PST)
Received-SPF: pass (google.com: domain of cb.list6@gmail.com designates 10.68.213.232 as permitted sender) client-ip=10.68.213.232;
Authentication-Results: mr.google.com; spf=pass (google.com: domain of cb.list6@gmail.com designates 10.68.213.232 as permitted sender) smtp.mail=cb.list6@gmail.com; dkim=pass header.i=cb.list6@gmail.com
Received: from mr.google.com ([10.68.213.232]) by 10.68.213.232 with SMTP id nv8mr69872436pbc.155.1329844891136 (num_hops = 1); Tue, 21 Feb 2012 09:21:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=smoHppT56JMQyr6K9KVN5BC9bWAMjTYNDzyqqrt0Eco=; b=hXTL5yAhMdBOTN1+fhKPAmzAzxM+r6lY/VlQVWcVGo6Ee1feCA076g7rfUiTR8yTwb r9WQuPhGZzsHmf6dh7CVnzmyrlXiqpXWWXfWK0SwEnuTUZCqjApV8iz0Mrtak7sTsuC/ vCZievHCYj4FLw2sp0q6lYqnPGyOakKVuEqRw=
MIME-Version: 1.0
Received: by 10.68.213.232 with SMTP id nv8mr58135333pbc.155.1329844891050; Tue, 21 Feb 2012 09:21:31 -0800 (PST)
Received: by 10.142.99.12 with HTTP; Tue, 21 Feb 2012 09:21:30 -0800 (PST)
In-Reply-To: <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net>
References: <BB119B6D-FC99-4637-988D-D17FBB50597A@laposte.net> <CAD6AjGTdfGz1egdp3MpWPYBdzCM56aZejfG98pe+bWS4zf6cvA@mail.gmail.com> <824829E9-2221-401B-8781-FEF9745B946B@laposte.net> <CAD6AjGQSTE1VQyme50aY+Ki5_o57joay03KV=s7nDvm=gtm6Ag@mail.gmail.com> <36DEED71-AC8D-457D-B361-CED38F9E8F8F@laposte.net> <CAD6AjGR=bJ7jL6NQjbFPLw_MeEAx-N3Aj6wKzRsi-eYEQYxiEA@mail.gmail.com> <76642356-84CB-4AC9-AFB2-155A29A2E08A@laposte.net>
Date: Tue, 21 Feb 2012 09:21:30 -0800
Message-ID: <CAD6AjGSahYF3MPi-V1NXnNrjs3TYNCa1a+u15aCb=uxutNfTag@mail.gmail.com>
From: Cameron Byrne <cb.list6@gmail.com>
To: =?ISO-8859-1?B?UultaSBEZXNwculz?= <despres.remi@laposte.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: v6ops WG <v6ops@ietf.org>, Russell Housley <housley@vigilsec.com>
Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2012 17:21:35 -0000

On Tue, Feb 21, 2012 at 7:21 AM, Rémi Després <despres.remi@laposte.net> wrote:
> Cameron,
>
> Thanks for these answers,
> More questions and comments below.

Remi, thanks again for you rigorous review.

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

I don't really understand the below clearly, I will try to answer the best i can

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

Without DNS64, the draft-ietf-behave-nat64-discovery-heuristic is not
used to discover Pref64. Some other means must be used.
draft-ietf-behave-nat64-discovery-heuristic is a known working case
today, others may emerge.

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

It does not need to claim the /96 as a whole.  The CLAT will do NDP
with the idea that each /128 in the /96 is owned by the CLAT as a
virtual address.

I have seen this behavior in NAT-PT deployments, but i do not see it
specifically declared in the NAT-PT RFC.


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

IPv4 allocations are frequently fragmented as they are assigned piece
meal. So yes, there are shorter prefix, but it is a fragmented set of
prefixes.


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

No, but i am optimistic.

>>  When i do tethering, it
>> goes up substantially.
>
> BTW, did the trial include tethering?

No, that is a feature that is still lacking in the code.  I hope to
have it covered soon.

> In the model, is tethering to be supported with a NAT44 in the UE?
> If not, how?
>

>From the draft:

   CLAT:   CLAT is Customer side translator(XLAT) that complies with
           [RFC6145].  It algorithmically translates 1:1 private IPv4
           packets to global IPv6 packets, and vice versa.  The CLAT
           function is applicable to a router or an end-node such as a
           mobile phone.  CLAT SHOULD perform router function to
           facilitate packets forwarding through the stateless
           translation even if it is an end-node.  In addition to
           stateless translation, the CLAT as a common home router or 3G
           router is expected to perform gateway functions such as DHCP
           server and DNS proxy for local clients

I hope this makes it clear why NAT44 on the tethered phone / mobile
router is not required.  The PC that is tethered passes IPv4 packets
that are immediately translated on the CLAT using 6145 to the
IPv6-only access network.  This is the same in the case for wireline
CPE.

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

Agreed, since you are going to change the inputs substantially
regardless of my request.


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

No contradiction, i said 464XLAT appeared in 0 email titles.

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

I said that 100% of the IPv4 addresses are utilized in place, and you
are suggesting above that 32% of my total IPv4 address holdings can be
made available for a stateless BR.  That is not realistic.

Please note this section of the draft well
http://tools.ietf.org/html/draft-ietf-v6ops-464xlat-00#section-4

CB

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