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

Rémi Després <> Tue, 21 February 2012 18:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C8FDC21F88E5 for <>; Tue, 21 Feb 2012 10:42:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.022
X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id B7ffojfmG3Th for <>; Tue, 21 Feb 2012 10:42:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 937E421F88E1 for <>; Tue, 21 Feb 2012 10:42:07 -0800 (PST)
Received: from [] ([]) by mwinf8504-out with ME id cii41i00537Y3f403ii4Bo; Tue, 21 Feb 2012 19:42:05 +0100
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= <>
In-Reply-To: <>
Date: Tue, 21 Feb 2012 19:42:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: Cameron Byrne <>
X-Mailer: Apple Mail (2.1084)
Cc: v6ops WG <>, Russell Housley <>
Subject: Re: [v6ops] draft-464XLAT not a "trial deployment report" - not to be an ietf-v6ops I.D.
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Feb 2012 18:42:16 -0000

Le 2012-02-21 à 18:21, Cameron Byrne a écrit :

> On Tue, Feb 21, 2012 at 7:21 AM, Rémi Després <> wrote:
>>>> 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.

"May emerge" is good enough an answer.

>> Aren't NAT64s always coupled with DNS64s, as seems to be implied by all scenarios of RFC6144?

An answer to this?

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

Was understood.

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

Right, it seems to be new material as far as IETF is concerned.

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

This is why 4rd-U can, with several mapping rules, assign shared addresses that start with prefixes of a fragmented IPv4 space. 

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

So am I.
The number of ports needed for IPv4 should very quickly decrease wherever IPv6 is enabled.

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

(Apologies for having asked a superfluous question.) 

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

There may be some issues about hosts that query the NAT, e.g. with multicast for UPnP.
This is similar to DS-lite, but RFC6333 only says "Discussion of multicast is out of scope for this document." 

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

Sorry, I don't understand what you are talking about.
It sounds like a disapproval of something I do here, but I can't follow what that is.

>>> I tried to have this generic scenario discussion on softwires here
>> Indeed and you did receive several answers, including one from me (
>> 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.

(Apologies for having missed you were talking only about titles.)

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

Well, I suppose it is possible in NAT64s to change the set of IPv4 addresses they use.
Reducing these sets when many customers will cease using NAT64s (because they now use statically shared IPv4 addresses instead), seems to me quite reasonable.

Note that for an operator that hasn't deployed NAT64s, and can go directly the stateless way, the problem is a lot simpler.
With the same numbers of customers and IPv4 addresses, each UE could easily be assigned twice as many ports per CE.

> Please note this section of the draft well

I think I understand your motivations, and hope you can understand those of draft-ietf-softwire-stateless-4v6-motivation.