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

[Ted Hardie <[e-mail]>]

 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
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 as a best practice
for networks using stateful translation, rather than defining when
stateful translation is best practice.

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

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

Minor Issues:

This draft is currently targeted for BCP.   I do not believe that it
is appropriate to target it for
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.

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 to be on
release 12, and there is
no notice of whether changes between pre-release 9 and the current
release have changed the
topology in a way to eliminate the multiple PDP issue raised.  If the
text means to say that this
is not a 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.