Re: [apps-discuss] Review of draft-ietf-v6ops-464xlat-08

[Cameron Byrne <[e-mail]>]

Hi Ted,

Once again, your feedback is very much appreciated. Comments inline

On Mon, Dec 3, 2012 at 10:01 AM, Ted Hardie <[e-mail]> wrote:
> On Fri, Nov 30, 2012 at 7:26 PM, Byrne, Cameron
> <[e-mail]> wrote:
>> Ted,
>>
>> Thanks for taking the time to review our work.  My comments in-line.
>>
>
>
> Hi Cameron,
>
> Thanks for the quick reply; some additional questions/comments in-line
> with yours.
>
> regards,
>
> Ted
>
>>> -----Original Message-----
>>> From: Ted Hardie [mailto:[e-mail]]
>>> Sent: Friday, November 30, 2012 1:15 PM
>>> To: [e-mail]; [e-mail]
>>> Subject: Review of draft-ietf-v6ops-464xlat-08
>>>
>>>  I have been selected as the Applications Area Directorate reviewer for this draft
>>> (for background on appsdir, please see
>>> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
>>> ).
>>>
>>> Please resolve these comments along with any other Last Call comments you
>>> may receive. Please wait for direction from your document shepherd or AD
>>> before posting a new version of the draft.
>>>
>>> Document:draft-ietf-v6ops-464xlat-08
>>> Title: 464XLAT: Combination of Stateful and Stateless Translation
>>> Reviewer: Ted Hardie
>>> Review Date: November 30, 2012
>>>
>>> Summary: This draft is not ready for publication as a BCP, and it may not be an
>>> appropriate candidate for this status.
>>>
>>> Major Issues:
>>>
>>> This document provides a v4/v6 inter-working method using a pair of address
>>> translators that bracket a network region in which there is no
>>> IPv4 routing.  It discusses two different potential deployments.  In the first, the
>>> first address translator is co-resident on the device where the IPv4 address is
>>> assigned; in the second, the the first address translator is resident in a nearby
>>> network device.  In both, the second address translator is at the border of the
>>> internal IPv6 routing domain and a global IPv4 routing domain.
>>>
>>> The document has the following applicability statement:
>>>
>>>    This BCP only applies when the following two criteria are present:
>>>
>>>    1.  There is an IPv6-only network that uses stateful translation
>>>        [RFC6146] as the only mechanism for providing IPv4 access.
>>>
>>>    2.  There are IPv4-only applications or hosts that must communicate
>>>        across the IPv6-only network to reach the IPv4 Internet.
>>>
>>> The first item is problematic.  This document describes a method for using
>>> stateful translation, but it does not justify why this is the appropriate choice; the
>>
>> The choice for using a stateful translator is outside the scope of this document.
>>
>> But, the IETF has published RFC 6146 which is specifies a stateful protocol translator on the standards track.  RFC6146 is necessary but not sufficient to operate an IPv6-only network that is dominated (today) by IPv4 nodes.  The problem of IPv4-referals / IPv4-literals as well as IPv4 sockets APIs is very real.  It would be very unfortunate if the IETF specified stateful NAT64 in RFC 6146 but was no deployable or could only provide an 85% service (15% of Android apps fail to work on NAT64/DNS64 only networks)
>
> I apologize, it appears I did not express this well. I was trying to

I am still a bit unclear on what exactly your concern is, but i will
try to address it below. Sorry for not being able to parse your
meaning, i am bit close to the subject so it hard for me to understand
the gaps you (or any reader) may have in understanding the draft

> get at the question of why using stateful translation in cases where
> there is no IPv4 routing domain is the right idea. My understanding of
> RFC 6146 is
> that is specifies a method for allowing IPv6 only clients to reach a
> v4 Internet host; it does not seem to require the creation of separate
> technique to allow nodes to retain an IPv4 address in networks that do
> not have IPv4 routing.  That may well be justified by something else,
> but I don't personally see how RFC 6146 justifies or requires it.
>

The fact that there must be an IPv6-only routing domain is a function
of IPv4 exhaustion (APNIC is already out). Many large access networks
have more customers than address available in the private / shared
allocations. Just to cite 2 examples, AT&T and Verizon Wireless in the
USA each have over 100 million wireless subscribers.

The fact that a  host within an IPv6-only routing domain requires an
IPv4 address to form sockets is attributed to IPv4-only network APIs,
single stack IPv4 hosts,  and the use of IPv4 referals within
otherwise IPv6 capable systems [Skype on Android]


> You mention that the use of IPv4 referrals or literals are a part of
> this problem.  I understand that, but I'm not
> honestly note sure that I understand how creating a method that makes
> nodes believe that they are part of a
> local IPv4 routing domain when they are actually only part of a v6
> local routing domain (and via that a global
> v4 routing domain) actually helps.  It seems particularly worrisome if
> they have to understand some set of
> limitations (even if you got a 464xlat socket option, it's not stated
> how a node would know over what networks it would have to use it).
>

To make a Skype call, Skype must open an socket from an IPv4 address
to an IPv4 address.

464XLAT on the host provides a TUN interface, for example, that the
local host can bind IPv4 sockets to. That TUN interface then performs
RFC 6145.

So, the host can form the IPv4 socket that it previously could not
form.  Packets generated from that interface are immediately
translated from IPv4 to IPv6 and put on the wire with the destination
set for the NAT64 in the first 96 bits and the last 32 for the IPv4
address.

This is all running code.  Here you will find pointers to the Android
implementation for Nexus S, Galaxy Nexus, as well the open source code
that has been accepted by Android Open Source Project:
http://dan.drown.org/android/clat/

This software "just works" on an IPv6-only network such as T-mobile's.
 Before and after tests are readily reproducible that without this
464XLAT software Skype and Netflix do not work (latest version of both
tested within the last 2 weeks) yet with 464XLAT they do work.


>>
>> Just generally speaking on why stateful is the right choice, many networks already operate stateful NAT44 and the NAT64 is just another feature that is quick to deploy on existing hardware with existing support models.  Furthermore, this architecture is based on the reality that IPv4 address are no longer available in APNIC in blocks larger than an emergency /22 (RIPE and ARIN also have max /22 allocations for the last /8 in the RIR).  That said, stateful multiplex of ports / sessions is absolutely required for any service that must scale to millions of users.  Stateless solutions simply do not scale for new entrants that do not have existing IPv4 resources.
>
>>
>>
>>> encapsulation methods used in something like DS-Lite seem to be an alternative
>>> here, and it is not clear either what constraint prevents encapsulation's use in
>>> these networks or what the advantage is here to using dual translation over an
>>> encapsulation-based method.  In other words, this appears circular--it defines it
>>
>> Encapsulation can break many things including traffic engineering based on IP address (no more hop by hop routing), DPI associated with charging (specifically 3GPP defined Policy and Charging Controls (PCC)).
>>
>> DS-lite also has configuration driven exclusively by DHCP, there is no DHCP in 3GPP networks.
>>
>
> Not to be dense here, but in the case where the CLAT is not node
> resident, how does the
> the node get the RFC 1918 address it uses?
>

Section 8.5 describes the CLAT as a gateway that operates a DHCP server

>
>>> as a best practice for networks using stateful translation, rather than defining
>>> when stateful translation is best practice.
>>>
>>
>> The wording of the document was chosen to state the circumstance that you have this type of network:  IPv6-only with stateful NAT64 as defined here http://tools.ietf.org/html/rfc6144#section-2.1  Given that scenario, there is a practical reality that hosts and software have specific IPv4 dependencies and thus this scenario is defunct without something like 464XLAT. And, that goes origins of 464XLAT.  It is emergent behavior that occurs in my IPv6-only network at T-Mobile USA.  People wanted Skype to work so they put an NAT46 on the host ....and Skype now worked.
>>
>> We track broken Android apps at this list (15% don't work:  Skype, Netflix, Spotify ...), and 464XLAT fixes 100% of the broken apps http://goo.gl/z3j3q
>>
>
> Thanks for the citation.  A quick look at the list shows a number of
> the cited applications are no longer
>  the current version. Is this being maintained as a living document,
> so there are ongoing tests?  If so,
> has the introduction of Skype 3, Google plus 3 et al resolved any of these?
>

It is a living document, i have been meaning to do a complete update
of it.  I can likely have that done in a few weeks.

In any event, within the last 2 weeks i have verified that Skype and
Netflix on the latest version from the Android market do not yet work
on IPv6-only + NAT64/DNS64.  These are both on the top 20 list of most
popular apps, so there is no responsible case for moving forward with
IPv6 and letting them break.

Much to my personal disappoint, a Skype engineer (who i assume you
recognize) went on the record yesterday explaining that there is no
demand and therefore no plan to support IPv6 in Skype
http://mailman.nanog.org/pipermail/nanog/2012-December/053918.html

:(

I would rather not need 464XLAT, but these statements from Skype
reflects a reality that it is easier to change the host than it is the
app.

>
>> 464XLAT allows for the real commercial deployment of IPv6-only networks.
>>
>> The current state of the network at T-Mobile USA today is squat space + NAT44.  This is the same at Rogers and Sprint mobile networks here in North America.
>>
>>
>>> The document also says this in the introduction, which provides an additional
>>> applicability
>>> limitation:
>>>
>>>    The 464XLAT architecture only supports IPv4 in the
>>>    client server model, where the server has a global IPv4 address.
>>>    This means it is not fit for IPv4 peer-to-peer communication or
>>>    inbound IPv4 connections
>>>
>>> If this is true, it is highly problematic, because it provides a constraint on the
>>> semantics of an RFC 1918 address that is not currently present.  It is not entirely
>>> clear, though, that this is true.
>>>
>>> Systems attempting peer-to-peer communication when using RFC 1918
>>> addresses typically must use ICE to handle the artifacts of network address
>>> translation.
>>> I was not able to understand
>>> how ICE would fail here, either in the case where the CLAT was resident on the
>>> node or when it is network resident.  In my naive reading, this would work for
>>> cases where the ICE server was in the IPv4 global routing domain.  Because
>>> PLATs are provisioned with a single IP address, the mapped address attribute
>>
>> What do you mean 1 IP address?  1 IPv4 address?  They will have pools of address for sure.
>>
>
> The figure/chart between section 8.2 and 8.3 says " Global IPv4
> address assigned to IPv4 server";
> I took that to mean that PLATs were generally provisioned with a
> single address.  With a pool,
> the ICE considerations below still apply; it will simply be more
> likely that two hosts within a PLAT-served
> domain are distinguishable by address as well as address/port.
>

Yes, you are right.  I can make it more clear that the NAT64 will use
1 or more addresses.

>>> would always have the same family and address, but it seems it should be
>>> distinguishable by port.  If this is not the case, or there is a different reason why
>>> this mechanism cannot work with ICE, I believe it should be called out in the
>>> draft explicitly.
>>>
>>
>> We make this restriction because of the case where you and I are on the same ISP.  We both have 10.10.10.1  as our local address. Communication fails.
>>
>
> As long as we are assigned different ports by the PLAT, it does not
> fail.  It is suboptimal, but works.
>
>

Yep, assuming the apps are ICE capable.

>> If we have unique address space, are right, it would work.  But, we do not want to push an additional level of complexity to try and coordinate unique LAN side IP addresses.  It is simpler to say this simply does not work.  And, in case of DNS64, users will generally not use IPv4.  IPv4 is only used for the case of IPv4 referals or IPv4-only host and APIs.
>>
>>
>>> An ICE-based peer-to-peer connection would, certainly, provide a severely sub-
>>> optimal path for two devices within the same 464xlat region, as it would hairpin
>>> out and back. But those are not the only potential peer-to-peer connections and
>>> it would work at least to some degree.
>>>
>>> In the case where the CLAT is resident on a device, but that device provides
>>> tethering, the document currently says:
>>>
>>>            The CLAT SHOULD perform router function to
>>>            facilitate packets forwarding through the stateless
>>>            translation even if it is an end-node.
>>>
>>> For proper operation of tethered devices, this would appear to require a MUST,
>>> rather than a SHOULD.
>>> If it is not MUST, then some description of what will happen is desirable.
>>> (Perhaps a statement that CLATs which do not provide this functionality cannot
>>> be used when tethering is in place or whether tethered devices require IPv4?)
>>>
>>
>> I think you are right.  We can do a must here.
>>
>>> Minor Issues:
>>>
>>> This draft is currently targeted for BCP.   I do not believe that it
>>> is appropriate to target it for
>>
>> The rational is that 464XLAT is a best practice for RFC 6144 2.1 network that has IPv4-only apps in it.
>>
>
> If I understand you correctly, it is not simply IPv4-only apps, but
> IPv4-only apps which use IPv4-only
> referrals.  Is that right?
>

Too be clear, the known broken cases that we are trying to fix are
IPv4-only host (ie Windows XP which is at 40% market share IIRC), IPv4
referals (Amazon prime streaming is a well known case), and IPv4-only
network APIs

>
>>> BCP  unless it is preferred over encapsulation-based approaches.  I also believe
>>> that the marketing material which is currently embedded in the text (see, for
>>> example, section 5) should be removed.
>>>
>>
>> I am happy to eliminate section 5, but section 5 has been required during draft formation because there are many solutions in this space.
>>
>>> Nits: The description 3GPP applicability relates to 3GPP "Pre-Release 9", but
>>> there is no citation given.  I also note that 3GPP specifications currently appear
>>
>> See RFC6459
>>
>
> Just to be clear, you are proposing adding a citation to RFC 6459?
>

I can add another citation to RFC 6459 to make this clear

>>> to be on release 12, and there is no notice of whether changes between pre-
>>
>> The most advanced LTE network is Release 8 at Verizon.
>>
>> Most  phones are release 7 or earlier (sold on the market today)
>>
>> New networks like the one T-Mobile will launch next year will be partially Release 10
>>
>>> release 9 and the current release have changed the topology in a way to
>>
>> Current release is not relevant to install base.
>>
>
> The current installed base is not the question I was raising.  If the
> problem you are proposing to solve
> is limited such that it goes away in 3GPP Release 10, 11, or 12, then
> the text should say that in the 3GPP
> applicability section.  If an operator/handset manufacturer/app person
> targeting a release for
> a network can determine whether or not this set of issues will arise
> by knowing the relevant 3GPP
> release, it would be useful to include that.
>


That is not the case.  The 2 PDP in a 3GPP network issue does go away
in Release 9 and onward, but the problem of demand for IPv4 addresses
exceeding supply does not go away in the case of dual-stack network
connections.  In fact, dual-stack does not improve the problem on
insufficient IPv4 addresses at all.  NAT64 works around the problem of
insufficient IPv4 addresses by translating IPv6 to IPv4... thus the
edge of the network does not require an IPv4 as dearly as it does
today.  The 2 PDP issue is a barrier to offering a dual-stack service
in most of the world today, but in the long run it is  private the
public ipv4 scarcity that is the problem to solve.

464XLAT (incuding NAT64) provides IPv4 independence for network
operators at the edge network.  A few IPv4 addresses can be shared
using statistical multiplexing and all known apps will work.  We
cannot move away from IPv4 unless there is service parity with ipv6,
and that is the goal of 464XLAT.  This goal is demonstrated in running
code.

>>> eliminate the multiple PDP issue raised.  If the text means to say that this is not a
>>
>> But it does not remove the dependency on IPv4 address that are not available.... public and private addresses are both exhausted, so we use squat space.
>>
>
> You've twice mentioned the squat space used in your network, but the
> draft doesn't seem to have any specific
> text bearing on this problem.   The most I see is in 7.1, where an
> access network simplifies its operations by running v6 only and
> trusting an upstream to run the PLAT.  If you think the squat space
> use case is important
> for understanding the applicability, you may need more text in the draft.
>

I'd rather not air my ephemeral dirty laundry in an long lived RFC  :)

The -00 had this text, which was weeded out as too verbose

"Now that both global and private IPv4 addresses are scarce to the
   extent that it is a substantial business risk and limiting growth in
   many areas, the mobile network providers must support IPv6 to solve
   the IP address scarcity issue.  It is not feasible to simply turn on
   additional IPv6 PDP network attachments since that does not solve the
   near-term IPv4 scarcity issues and it increases cost in most cases.
   The most logical path forward is to replace IPv4 with IPv6 and
   replace the common NAT44 with stateful translation [RFC6146] and
   DNS64 [RFC6147].  "

CB

>>> problem for any version 9 or later, and that the problem exists for any version
>>> prior to 9 which supports multiple address families, it needs to be reworded.
>>
>> I will review the wording.  Thanks again for your review.  I look forward to more feedback from you, thanks again for taking the time to work with us and sharing your experience
>>
>
> Thanks again for your quick response.
>
> regards,
>
> Ted Hardie
>
>> Thanks
>> Cameron
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss