Subject: [BEHAVE] Review of draft-huang-pnat-host-ipv6-01

From: Christian Vogt <[email-masked]>
Date: Sat, 25 Jul 2009 08:36:24 -0700

Bill and Hui -

Interesting proposal.  You are proposing a technique to carry IPv4
traffic over IPv6-only networks, and to translate this traffic if
exchanged with IPv6-only hosts, by using a combination of host- and
network-based protocol translation.  This is interesting, although the
relationship between your proposal and existing solutions for the same
purpose remains to be clarified.

I reviewed the document.  Below are my high-level comments.  The full
review, including these and more detailed comments, is here:

http://christianvogt.mailup.net/reviews/2009/draft-huang-pnat-host-ipv6-01-review-cv.pdf

- Christian

HIGH-LEVEL COMMENTS

- The document should more carefully explain what exactly are the source
   and destination addresses used at application level and at network
   level. This information is currently spread across the document,
   making it difficult for the reader to see the full picture. I
   suggest dedicating a separate section to this topic.  This section
   should also explain how IPv4 addresses are mapped to IPv6 addresses
   and vice versa.

- Is PNAT transparent to applications in the case of IPv4-to-IPv4
   communications?  Transparency here means that the pair of source
   and destination addresses used by a host is the same as the address
   pair used by a peer. Transparency is desirable in the case of
   IPv4-to-IPv4 communications because it rules out incompatibilities
   with applications. But it is unclear whether PNAT provides
   transparency.

- There seems to be an assumption in the document that the IPv4
   addresses seen by an application can be selected autonomously by a
   host-side PNAT component, without coordinating this with the address
   selection of other hosts.  This assumption, if it exists, would have
   the unfortunate consequence of defeating transparency in the case of
   IPv4-to-IPv4 communications.  Transparency could not be guaranteed
   in this case because address translation would be required to deal
   with potential address collisions between two communicating IPv4
   hosts.

- The document should more carefully distinguish the different
   combinations of IP versions in a communication. Section 4 is limited
   to IPv4-to-IPv4 communications, and there is little text about the
   other combinations, even though these would be more complicated.

- There are ways in which a mechanism very similar to PNAT could be
   built using existing solutions. The authors may consider specifying
   PNAT by using existing solutions as building blocks, since this
   would simplify the specification of PNAT significantly. One way of
   doing this is by re-using the combination of Dual Stack Lite and
   Virtual IPv6 Connectivity.  In this, Dual Stack Lite carries IPv4
   traffic over an IPv6-only network, and Virtual IPv6 Connectivity
   enables exchange of such IPv4 traffic with IPv6-only peers.  The
   only difference between PNAT and the combination of Dual Stack Lite
   and Virtual IPv6 Connectivity is that the former uses
   forward/reverse translation to carry IPv4 traffic over an IPv6-only
   network, whereas the latter uses tunneling. Another feasible
   combination of existing solutions may be Dual Stack Lite and
   BIA/BIS. Furthermore, in cellular networks, Virtual IPv6
   Connectivity, or BIA/BIS, may even be sufficient without Dual Stack
   Lite. Cellular networks already support both IPv4 and IPv6 user
   traffic without a dual-stack network because they relay user traffic
   in encapsulated form. The sole difference between the encapsulation
   in cellular networks and the encapsulation in Dual Stack Lite is
   that only the latter supports encapsulation all the way to the host.

- Section 8 describes an alternative way of implementing PNAT. Much of
   this section repeats what was already specified in earlier sections.
   This makes it difficult for the reader to identify the differences
   between the original PNAT implementation and the described
   alternative. To increase clarity and to reduce redundancies, you
   may consider limiting section 8 to only those parts of PNAT that
   change in the alternative implementation.