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

[Cameron Byrne <[e-mail]>]

Ted,

i have revision to my previous statements

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

I believe you are right that ICE would work at the app level.

Our statement about hub-and-spoke in the I-D was driven by wording set
in http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01#section-8.2

In this way, the NAT64 is a hub for IPv4 communications and IPv4 nodes
via the NAT64 can communicate with other IPv4 nodes.  That is the
basic architecture, if you need IPv4 access, send it via the CLAT and
PLAT where CLAT is the spoke and PLAT is the hub

Our claim that p2p does not work is based on the topological case that
if you are address 2001:DB8:9999::10.1.1.1 and i am address
2001:DB8:8888::10.1.1.1  our ipv4-only nodes behind the CLAT cannot
send packets to each other without something like ICE to force them
via the NAT64 or TURN.

If our addresses were different on the LAN like
2001:DB8:9999::10.1.9.9 and   2001:DB8:8888::10.1.1.1 we could send
IPv4 packets to each other without the need for the hub (PLAT) since
each CLAT would do RFC 6145 translation and remove the first 96 bits
on the  LAN side.  This is great if there is a high chance that the
LAN side IPs are unique, but that is not the case and result would be
ipv4 packets with src = 10.1.1.1 and dst 10.1.1.1

The current wording in question is "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."

The important term is "fit" vs "not fit".  Given that path would go
via a hub and may require ICE in the apps and infrastructure, it would
not really be direct p2p, and therefore the WG settle on this specific
language to error on the side of caution to the reader that this is
not a "fit" design if p2p is an important use-case in ipv4 supporting
ipv4.  The current statement is a caution to the reader and that is
the reason it appears in the introduction.

Alternatively, we can strike this from the introduction all together
and give a more in-depth discussion that reference ICE for the p2p
case.  The WG decided it was best to just punt on p2p and say it does
not work here in the introduction.

CB

>> 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.
>
>> 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
>
>> 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.
>
>> 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.
>
>> 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
> Cameron
> _______________________________________________
> apps-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss