[Docs] [txt|pdf|xml] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

BEHAVE Working Group                                             D. Wing
Internet-Draft                                                     Cisco
Intended status:  Informational                                 C. Byrne
Expires:  August 28, 2010                                   T-Mobile USA
                                                       February 24, 2010


     Concerns with IPv4 Applications Accessing IPv6 Servers (NAT46)
                  draft-wing-behave-v4app-v6server-02

Abstract

   Bump-in-the-Stack and Bump-in-the-API allow IPv4 applications to
   access IPv6 servers, using an in-host NAT46 translator.  When used in
   conjunction with an in-network NAT64, it is also possible for the
   IPv4 application to access an IPv4 server via an IPv6-only network.
   This document describes how these functions work in detail, and
   discusses some concerns especially around IPv4 applications accessing
   IPv6 servers.  These concerns can be reduced by not having IPv4
   applications access IPv6 servers.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on August 28, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Wing & Byrne             Expires August 28, 2010                [Page 1]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  PNAT Walk-Through  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  FTP  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
       2.1.1.  Outgoing Connection: FTP Passive Mode  . . . . . . . .  4
       2.1.2.  Incoming connection: FTP Active Mode . . . . . . . . .  7
     2.2.  RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
       2.2.1.  IPv4 Client to IPv4 Server (peer to peer)  . . . . . . 11
       2.2.2.  IPv4 client to IPv4 Server (client/server) . . . . . . 12
       2.2.3.  IPv4 Client to IPv6 Server . . . . . . . . . . . . . . 12
     2.3.  XMPP . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     2.4.  IPsec  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     2.5.  SIP  . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     2.6.  email protocols (SMTP, IMAP, POP)  . . . . . . . . . . . . 14
     2.7.  HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   3.  Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     3.1.  Interference with IPv6 Deployment  . . . . . . . . . . . . 15
     3.2.  Troubleshooting  . . . . . . . . . . . . . . . . . . . . . 15
     3.3.  Application Layer Gateways . . . . . . . . . . . . . . . . 16
       3.3.1.  Standardization  . . . . . . . . . . . . . . . . . . . 16
       3.3.2.  Interference with Application Evolution  . . . . . . . 16
       3.3.3.  Encrypted Application Signaling  . . . . . . . . . . . 17
       3.3.4.  ALG interference with IPv6-aware applications  . . . . 17
   4.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  To Do . . . . . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21







Wing & Byrne             Expires August 28, 2010                [Page 2]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


1.  Introduction

   As IPv6 is introduced to networks it is desirable that existing IPv4
   applications continue to function across native IPv6-only networks.
   However, due to exhaustion of IPv4 address space, it is not possible
   to provide a publicly-routable IPv4 address to every host.  Thus,
   some form of IPv4 address multiplexing is necessary.  There are
   several proposals to accomplish this multiplexing in combination with
   IPv6 ([I-D.ietf-softwire-dual-stack-lite], [I-D.ymbk-aplusp],
   [I-D.boucadair-port-range]).  All of these proposals expect the
   applications and host to use IPv4 to communicate with other IPv4
   hosts and to use IPv6 to communicate with other IPv6 hosts.  With
   these techniques, the host sends and receives IPv4 packets and IPv6
   packets on the wire, which are tunneled by some of the techniques.

   Two approaches have been proposed which perform IPv4 to IPv6
   translation.  Both approaches have similar needs for ALG assistance
   to support protocols which contain IP addresses in their payloads
   (e.g., FTP, SIP, XMPP).  One approach does translation in the host
   [I-D.huang-behave-pnat] by extending existing in-host translation
   Bump-in-the-API ("BIA", [I-D.huang-behave-rfc3338bis]) or Bump-in-
   the-Stack ("BIS", [I-D.huang-behave-rfc2767bis]), and uses an in-
   network stateful NAT64 access IPv4 servers.  The other approach,
   Virtual IPv6 Connectivity [I-D.vogt-durand-virtual-ip6-connectivity],
   does DNS manipulation and translation in a CPE device, external from
   the IPv4 host.  Virtual IPv6 Connectivity is not studied in detail in
   this document.

   PNAT provides two features for IPv4 applications, which are analyzed
   in detail in the sections below:

   o  access IPv4 servers over an IPv6-only access network.  This
      achieves the same end result as the dual-stack approaches listed
      in the previous paragraph.  PNAT provides this function by doing
      NAT464.  NAT464 is realized by a combination of NAT46 in the host
      (achieved by extensions to BIA/BIS) and an in-network stateful
      NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] to translate the IPv6
      packets back to IPv4 packets.

   o  access IPv6 servers (or dual-stack servers) over an IPv6-only
      access network.  This is realized by a NAT46 function in the host
      (achieved by extensions to BIA/BIS).  The NAT46 function provides
      a unique advantage, in that IPv4 applications are immediately able
      to connect to IPv6 servers.  However, it also raises some concerns
      described below.






Wing & Byrne             Expires August 28, 2010                [Page 3]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


2.  PNAT Walk-Through

2.1.  FTP

   This section details the operation of PNAT, using an IPv4-only FTP
   client application.  PNAT is a system that combines extensions to
   BIA/BIS in the host and (when necessary to access an IPv4 server) an
   in-network stateful NAT64.

   In some of the following scenarios, the BIA/BIS function in the host
   needs to create artificial IPv4 addresses in order to access IPv6
   servers.  These IPv4 addresses are never exposed outside of the host.
   To clarify the examples, this document assumes the network
   10.127.0.0/16 is used for these artificial IPv4 addresses.

   These walk-throughs detail how outgoing and incoming connections are
   handled with BIA/BIS when IP addresses are contained in application
   payloads.  FTP is a simple, well-understood protocol which supports
   both outgoing data connections (passive mode) and incoming data
   connections (active mode), both of which require communicating IP
   addresses and TCP ports in the application payload.  FTP is a good
   example because its data connection can be outgoing (from the client)
   or incoming (to the client), and FTP is sensitive to the IP address
   family (PASV is needed with IPv4; EPSV with IPv6).  The servers can
   be in another host ("peer to peer"), inside the operator's network,
   or on the Internet.

   The following table summarizes the notes in the subsequent sections:

    +-----------+------------+---------+-------------+----------------+
    | Direction |   Server   |  result | in-host ALG | in-network ALG |
    +-----------+------------+---------+-------------+----------------+
    |  Outgoing |    IPv4    | succeed |      no     |       no       |
    |  Outgoing |    IPv6    |   fail  |      no     |       no       |
    |  Outgoing | dual-stack |   fail  |      no     |       no       |
    |  Incoming |    IPv4    | succeed |   required  |    required    |
    |  Incoming |    IPv6    | succeed |   required  |       no       |
    |  Incoming | dual-stack | succeed |   required  |       no       |
    +-----------+------------+---------+-------------+----------------+

                   Table 1: Summary of PNAT Walk-Through

2.1.1.  Outgoing Connection: FTP Passive Mode

   This demonstrates how an outgoing connection is performed with BIA/
   BIS with an application containing an IP address in the application
   payload.




Wing & Byrne             Expires August 28, 2010                [Page 4]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   Passive mode FTP causes the FTP data connection to be initiated by
   the FTP client.  Passive mode FTP is necessary to operate behind NATs
   (or firewalls) that lack an FTP-aware ALG in the NAT (or firewall).
   FTP passive mode is the default for many standalone FTP clients
   (e.g., WS_FTP Pro) and all major web browsers (e.g., Internet
   Explorer, Firefox, Safari, Opera).

2.1.1.1.  IPv4 Application to IPv4 Server (NAT464)

   An IPv4-only FTP application wants to connect to an FTP server at
   ftp.example.com, which has the IPv4 address 192.0.2.1 and an A
   record, and no IPv6 address and no AAAA record.

       +-----------------+                                +---------+
       |IPv4 FTP  +------| < IPv6  >  +-----+- < IPv4  >  |IPv4 FTP |
       | client   | HBT  +-<network>--|NAT64| -<network>--+ server  |
       | using    |      |            +-----+             +---------+
       | PASV     |      |
       +----------+------+

       Figure 1: FTP, IPv4 client to IPv4 server (FTP passive mode)

   The IPv4 FTP application does a gethostaddr() call for
   ftp.example.com.  This is intercepted by the BIA/BIS in the host, and
   converted to an AAAA query and sent to the DNS server and receives
   'no such host' as the response.  This causes the BIA/BIS in the host
   to send an A query to the DNS server and receive 192.0.2.1 as the
   response.  This address is returned to the application's
   gethostaddr() call.  The FTP application then opens a TCP connection
   to 192.0.2.1, which is intercepted by BIA/BIS in the host which adds
   the necessary IPv6 prefix for the in-network NAT64 device, and sends
   the IPv6 packet towards that address.  The in-network NAT64
   translates the packet to IPv4 and sends it to 192.0.2.1.  The TCP
   connection is established and the FTP client logs into the FTP
   server.  After login, the FTP client sends the PASV command prior to
   its data transfer command.  The IPv4 FTP server responds to the PASV
   command with its IPv4 address and the TCP port for the incoming data
   connection.  The FTP client connects to that IPv4 address and port,
   which is intercepted by BIA/BIS in the host which adds the necessary
   IPv6 prefix for the in-network NAT64 device, and sends the IPv6
   packet towards that address.  The in-network NAT64 translates the
   packet to IPv4 and sends it to the FTP server.

   Notes:

   o  This scenario is transparent to the application.





Wing & Byrne             Expires August 28, 2010                [Page 5]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   o  No Application-Layer Gateway (ALG) is needed.

   o  A requirement is that both the FTP control channel and the FTP
      data channel use the same NAT64, so that the IPv4 FTP server sees
      both connections coming from the same IPv4 address.  This is
      trivially accomplished, as the IPv6 prefix -- which selects the
      NAT64 for this host -- is implemented inside the host's BIA/BIS
      function.

   o  The BIA/BIS function creates no additional state in the host for
      any of the IPv4/IPv6 mappings; the mappings are entirely
      algorithmic.  Also note that a DNS query is not required for the
      BIA/BIS function to work.

2.1.1.2.  IPv4 Application to IPv6 Server (NAT46)

   An IPv4-only FTP application wants to connect to an FTP server at
   ftp.example.com, which has the IPv6 address 2001:DB8::1 and an AAAA
   record, and no IPv4 address and no A record.

                 +-----------------+            +---------+
                 |IPv4 FTP  +------| < IPv6  >  |IPv6 FTP |
                 | client   | HBT  +-<network>--| server  |
                 | using    |w/FTP |            +---------+
                 | PASV     | ALG  |
                 +----------+------+

     Figure 2: FTP, IPv4 client to IPv6-only server (FTP passive mode)

   The IPv4 FTP application does a gethostaddr() call for
   ftp.example.com.  This is intercepted by the BIA/BIS in the host, and
   converted to an AAAA query and sent to the DNS server and receives
   2001:DB8::1 as the response.  The BIA/BIS in the host creates an
   artificial IPv4 address, 10.127.0.1, and a mapping between that
   artificial address and the IPv6 address.  The artificial address
   10.127.0.1 is returned to the application's gethostaddr() call.  The
   FTP application then opens a TCP connection to 10.127.0.1, which is
   intercepted by BIA/BIS in the host and maps this to the IPv6 address
   2001:DB8::1 and sends the IPv6 packet towards that address.  The TCP
   connection is established and the FTP client logs into the FTP
   server.  After login, the FTP client sends the PASV command prior to
   its data transfer command.  The IPv6 FTP server cannot send a useful
   response to the PASV command, because the PASV response can only
   indicate an IPv4 address.

   Notes:





Wing & Byrne             Expires August 28, 2010                [Page 6]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   o  Not transparent to application.

   o  This scenario needs an FTP ALG in the host

   o  There is no in-network translation, and there is no need for in-
      network ALG.

   o  The BIA/BIS function creates additional state in the host for the
      IPv4/IPv6 mappings.

2.1.1.3.  IPv4 Application to Dual-Stack Server (NAT46)

   An IPv4-only FTP application wants to connect to an FTP server at
   ftp.example.com, which has the IPv4 address 192.0.2.1 and A record,
   and the IPv6 address 2001:DB8::1 and AAAA record.

              +-----------------+            +--------------+
              |IPv4 FTP  +------| < IPv6  >  |dual-stack FTP|
              | client   | HBT  +-<network>--|    server    |
              | using    |w/FTP |            +--------------+
              | PASV     | ALG  |
              +----------+------+

    Figure 3: FTP, IPv4 client to dual-stack server (FTP passive mode)

   The IPv4 FTP application does a gethostaddr() call for
   ftp.example.com.  This is intercepted by the BIA/BIS in the host, and
   converted to an AAAA query and sent to the DNS server and receives
   2001:DB8::1 as the response.  From this point forward, the behavior
   is exactly the same as the previous section, Section 2.1.1.2, and has
   the same requirement for an in-host FTP ALG.

   Notes:

   o  The same Notes from Section 2.1.1.2, above, apply to this
      scenario.

   o  This walk-through assumes the application and the host stack both
      prefer IPv6 over IPv4, which is the default ([RFC3484]).

2.1.2.  Incoming connection: FTP Active Mode

   This demonstrates how an incoming connection is performed with BIA/
   BIS with an application containing an IP address in the application
   payload.

   Active mode FTP is the 'normal' mechanism popular before the
   widespread deployment of IPv4 NATs and firewalls.  In this mode, the



Wing & Byrne             Expires August 28, 2010                [Page 7]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   data connection is initiated from the FTP server back to the FTP
   client.  For this to work when the client is behind a typical IPv4
   NAT (NAT44) or a typical firewall, the NAT (or firewall) needs to
   implement an FTP-aware ALG, so that when the FTP client sends its
   PORT command (containing the FTP client's TCP port), the ALG can
   perform the necessary functions.  If a NAT, the necessary ALG
   functions are to map the internal TCP port to an external TCP port
   and rewrite the FTP command to contain the that newly-mapped port.
   If a firewall ALG, the necessary ALG function is to create a
   temporary permission for the incoming TCP connection.

2.1.2.1.  IPv4 Application to IPv4 Server (NAT464)

   An IPv4-only FTP application wants to connect to an FTP server at
   ftp.example.com, which has the IPv4 address 192.0.2.1 and an A
   record, and no IPv6 address and no AAAA record.

       +-----------------+                                +---------+
       |IPv4 FTP  +------| < IPv6  >  +-----+- < IPv4  >  |IPv4 FTP |
       | client   | HBT  +-<network>--|NAT64| -<network>--+ server  |
       | using    |      |            +-----+             +---------+
       | PASV     |      |
       +----------+------+

        Figure 4: FTP, IPv4 client to IPv4 server (FTP active mode)

   The IPv4 FTP application does a gethostaddr() call for
   ftp.example.com.  This is intercepted by the BIA/BIS in the host, and
   converted to an AAAA query and sent to the DNS server and receives
   'no such host' as the response.  This causes the BIA/BIS in the host
   to send an A query to the DNS server and receive 192.0.2.1 as the
   response.  This address is returned to the application's
   gethostaddr() call.  The FTP application then opens a TCP connection
   to 192.0.2.1, which is intercepted by BIA/BIS in the host which
   notices the TCP connection is to the FTP control port (TCP port 21)
   and activates its FTP-aware ALG function.  The BIA/BIS in the host
   adds the necessary IPv6 prefix for the in-network NAT64 device, and
   sends the IPv6 packet towards that address.  The FTP ALG in the in-
   network NAT64 notices the packet is to the FTP control port (TCP port
   21) and activates its FTP ALG function.  The in-network NAT64
   translates the packet to IPv4 and sends it to 192.0.2.1.  The TCP
   connection is established with the FTP server and the FTP client logs
   into the FTP server.  After login, the FTP client wants to accept an
   incoming connection for a data transfer.  It begins listening on a
   TCP port, and sends the PORT command which indicates its own IPv4
   address and the TCP port it is listening on.  The FTP-aware ALG in
   the host modifies the FTP control packet to contain the host's IPv6
   address, and sends it.  The FTP-aware ALG in the in-network NAT64



Wing & Byrne             Expires August 28, 2010                [Page 8]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   sees the PORT command and creates a mapping from a public TCP port to
   the IPv6 address and TCP port, and modifies the FTP control packet to
   contain the public IPv4 address of the NAT64 and that newly-mapped
   TCP port, and sends it to the FTP server.  The FTP server initiates a
   TCP connection to the listening port and the data transfer is
   successful.

   Notes:

   o  As with NAT44, this requires an Application Layer Gateway.

   o  Two Application Layer Gateways are necessary - one in the host (to
      modify the FTP command from containing IPv4 to containing IPv6)
      and another in the in-network NAT64 (to create the necessary TCP
      mapping on the NAT64, and to modify the FTP command to contain the
      NAT64's public IPv4 address and that newly-mapped TCP port).s

   o  A requirement is that both the FTP control channel and the FTP
      data channel use the same NAT64, so that the IPv4 FTP server sees
      both connections coming from the same IPv4 address.  This is
      trivially accomplished, as the IPv6 prefix -- which selects the
      NAT64 for this host -- is implemented inside the host's BIA/BIS
      function.

   o  The BIA/BIS function creates no additional state in the host for
      any of the IPv4/IPv6 mappings; the mappings are entirely
      algorithmic.  Also note that a DNS query is not required for the
      BIA/BIS function to work.

2.1.2.2.  IPv4 Application to IPv6-only Server (NAT46)

   An IPv4-only FTP application wants to connect to an FTP server at
   ftp.example.com, which has the IPv6 address 2001:DB8::1 and an AAAA
   record.  It has no IPv4 address and no A record.

                 +-----------------+            +---------+
                 |IPv4 FTP  +------| < IPv6  >  |IPv6 FTP |
                 | client   | HBT  +-<network>--| server  |
                 | using    |w/FTP |            +---------+
                 | PASV     | ALG  |
                 +----------+------+

     Figure 5: FTP, IPv4 client to IPv6-only server (FTP active mode)

   The IPv4 FTP application does a gethostaddr() call for
   ftp.example.com.  This is intercepted by the BIA/BIS in the host, and
   converted to an AAAA query and sent to the DNS server and receives
   2001:DB8::1 as the response.  The BIA/BIS in the host creates an



Wing & Byrne             Expires August 28, 2010                [Page 9]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   artificial IPv4 address, 10.127.0.1, and a mapping between that
   artificial address and the IPv6 address.  The artificial address
   10.127.0.1 is returned to the application's gethostaddr() call.  The
   FTP application then opens a TCP connection to 10.127.0.1 which is
   intercepted by BIA/BIS in the host which notices the TCP connection
   is to the FTP control port (TCP port 21) and activates its FTP-aware
   ALG function.  The BIA/BIS in the host maps the TCP connection to
   2001:DB8::1 and sends the IPv6 packet towards this address.  The TCP
   connection is established and the FTP client logs into the FTP
   server.  After login, the FTP client wants to accept an incoming
   connection for a data transfer.  It begins listening on a TCP port,
   and sends the PORT command which indicates its own IPv4 address and
   the TCP port it is listening on.  The FTP-aware ALG in the host
   intercepts this information, and changes the PORT command to EPRT
   [RFC2428] containing the host's IPv6 address and the listening TCP
   port, and sends it to 2001:DB8::1.  The FTP server initiates a TCP
   connection to the listening port and the data transfer is successful.

   Notes:

   o  As with NAT44, this requires an Application Layer Gateway (ALG).

   o  One ALG is necessary in the host.

2.1.2.3.  IPv4 Application to Dual-Stack Server (NAT46)

   An IPv4-only FTP application wants to connect to an FTP server at
   ftp.example.com, which has the IPv4 address 192.0.2.1 an A record,
   and the IPv6 address 2001:DB8::1 and AAAA record.

              +-----------------+            +--------------+
              |IPv4 FTP  +------| < IPv6  >  |dual-stack FTP|
              | client   | HBT  +-<network>--|    server    |
              | using    |w/FTP |            +--------------+
              | PASV     | ALG  |
              +----------+------+

     Figure 6: FTP, IPv4 client to dual-stack server (FTP active mode)

   The IPv4 FTP application does a gethostaddr() call for
   ftp.example.com.  This is intercepted by the BIA/BIS in the host, and
   converted to an AAAA query and sent to the DNS server and receives
   2001:DB8::1 as the response.  From this point forward, the behavior
   is exactly the same as the previous section, Section 2.1.2.2, and
   also succeeds.

   Notes:




Wing & Byrne             Expires August 28, 2010               [Page 10]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   o  The same Notes from Section 2.1.1.2 apply to this scenario.

   o  This walk-through assumes the application and the host stack both
      prefer IPv6 over IPv4, which is the default ([RFC3484]).

2.2.  RTSP

   Real Time Streaming Protocol (RTSP [RFC2326]) is most commonly used
   to stream unicast or multicast RTP media from a server to a client.
   RTSP encodes information about the media stream into SDP such as the
   codec, and information about IP address and port of the media stream
   into RTSP's transport headers.  Many existing ALGs, shipping in NATs
   today, modify these payloads.

   However, RTSP 2.0 [I-D.ietf-mmusic-rfc2326bis] includes NAT traversal
   built into the RTSP client and RTSP server itself
   [I-D.ietf-mmusic-rtsp-nat] which uses a technique derived from ICE
   [I-D.ietf-mmusic-ice].  An ALG that mistakenly interferes with these
   components of RTSP signaling will cause failure of the RTSP setup, as
   discussed in Section 4.1.5 of [I-D.ietf-mmusic-rtsp-nat-evaluation]
   but the mitigation suggested in that document (encrypting RTSP
   signaling) also means both in-host and in-network RTSP ALGs cannot be
   used, as discussed in Section 3.3.3.  The general concern of ALG
   interference with application evolution discussed in Section 3.3.2.

2.2.1.  IPv4 Client to IPv4 Server (peer to peer)

   An IPv4 RTSP client might want to stream data from an IPv4 server,
   located on the same network -- that is, peer-to-peer.  With host-
   based translation, both of the IPv4 clients would believe they are
   communicating with IPv4-based servers, but their traffic is
   translated to IPv6 over the network.  This is depicted in the
   following figure.

          +-----------------+                  +-----------------+
          |IPv4 RTSP +------|                  |------+ IPv4 RTSP|
          | client   | HBT  +--<IPv6 network>--+HBT   |  server  |
          |          |w/RTSP|                  |w/RTSP|          |
          |          | ALG  |                  |ALG   |          |
          +----------+------+                  +------+----------+

         Figure 7: RTSP, IPv4 client to IPv4 server (peer to peer)

   To accomplish this, both hosts need an RTSP ALG between IPv4 RTSP
   messages and IPv6 RTSP messages.  This is because they are in
   different IPv4 address domains and their IPv4 addresses may overlap.
   The host operating as an RTSP client uses an IPv4-to-IPv6 ALG, which
   rewrites the RTSP signaling messages from IPv4 to IPv6.  The host



Wing & Byrne             Expires August 28, 2010               [Page 11]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   operating as the RTSP server uses an IPv6-to-IPv4 ALG, which rewrites
   the RTSP signaling messages from IPv6 to IPv4.

   The hosts can avoid an in-network ALG if they realize the
   communication is with a peer that has an integrated RTSP ALG; this
   might be accomplished, for example, by assuming all IPv6 hosts with a
   certain IPv6 prefix have an integrated RTSP ALG, which would be
   somehow configured into the host-based ALG.

2.2.2.  IPv4 client to IPv4 Server (client/server)

   An IPv4 RTSP client might want to stream data from an IPv4 RTSP
   server on an IPv4 network, as depicted in the following figure.

       +-----------------+            +-----+             +---------+
       |IPv4 RTSP +------| < IPv6  >  +NAT64+- < IPv4  >  |IPv4 RTSP|
       | client   | HBT  +-<network>--| with| -<network>--+ server  |
       |          |      |            | RTSP|             +---------+
       |          |      |            | ALG |
       +----------+------+            +-----+

        Figure 8: RTSP, IPv4 client to IPv4 server (client/server)

   To accomplish this, the HBT in the host realizes it is sending
   packets to a NAT64 (e.g., because it matches the network's NAT64
   prefix (NSP or WKP)), and does not invoke its own ALG.  The in-
   network RTSP ALG, implemented in conjunction with the network's NAT64
   device, rewrites the RTSP signaling messages from IPv6 to IPv4.

      Note:  It is almost always the case the RTSP media receiver and
      RTSP client have the same IP address, and the RTSP server and RTSP
      media server have the same IP address.  In the unlikely case this
      isn't true, the dis-association of the ALG from the host's
      translator causes a 3-party referral, which will fail.

      Emerging standards for streaming RTSP media (e.g.,
      [I-D.ietf-mmusic-rtsp-nat]) are using RTSPv2 and RTSP's own NAT
      traversal, would reasonably be expected to use IPv6, and could
      have different IP addresses for the RTSP client/media receiver,
      and the RTSP server/media server.

2.2.3.  IPv4 Client to IPv6 Server

   An IPv4 RTSP client might want to stream data from an IPv6 server, as
   depicted in the following figure.






Wing & Byrne             Expires August 28, 2010               [Page 12]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


                 +-----------------+            +---------+
                 |IPv4 RTSP +------| < IPv6  >  |IPv6 RTSP|
                 | client   | HBT  +-<network>--+ server  |
                 |          |w/RTSP|            +---------+
                 |          | ALG  |
                 +----------+------+

                Figure 9: RTSP, IPv4 client to IPv6 server

   To accomplish this, the IPv4 host needs an RTSP ALG, because it won't
   understand the IPv6 addresses provided by the IPv6 RTSP server.

2.3.  XMPP

   Extensible Messaging and Presence Protocol (XMPP [RFC3920]) is
   commonly used for text-based chat.  In addition to text-based chat,
   XMPP also supports voice and video which is signaled using XMPP
   extensions [ICE-UDP].  This evolution of XMPP to include voice and
   video requires either (a) host-based XMPP-aware ALGs and in-network
   XMPP-aware ALGs are deployed, or (b) XMPP clients are updated to
   natively support IPv6 and support network-based NAT64 translation
   (e.g., by supporting [I-D.wing-v6ops-v6app-v4server] so that XMPP-
   aware ALGs would be unnecessary).  A difficulty with achieving (a),
   above, is that XMPP clients routinely use TLS to encrypt traffic to
   their XMPP servers because text chat messages are often considered
   confidential, which renders ALGs impossible to deploy with XMPP.

   These problems prevent an IPv4-only XMPP application from being
   transparently translated from IPv4 to IPv6 and successfully use voice
   or video chat.  Instead, the XMPP application has to support IPv6 and
   has to support NAT64 translation to communicate with IPv4 XMPP peers.

2.4.  IPsec

   Many residential-grade NATs implement "IPsec Passthru" for a variety
   of reasons.  These create a variety of problems [RFC3715], but some
   of the problems are masked if only one IPsec association to a
   specific VPN concentrator -- as is common for Internet access from a
   coffee shop or hotel.  However, when a large NAT serves a larger
   community of users it becomes more difficult or impossible to mask
   the deficiencies of IPsec Passthru.  Thus, a NAT64 with many IPsec
   associations, especially to the same VPN concentrator, will fail
   sessions whereas dozens of low-end NAT devices, with the same number
   of IPsec associations, will fare better.  This is discussed in detail
   in Section 4.1 of [RFC3715].

   Thus, in a large NAT environment, IPsec applications will need to use
   IPsec-over-UDP [RFC3947] rather than IPsec-over-IP (protocol 50) and



Wing & Byrne             Expires August 28, 2010               [Page 13]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   relying on IPsec Passthru.  This is not unique to v4 applications
   contacting v6 servers, but it does mean that IPsec cannot enjoy
   transparent translation from IPv4 to IPv6 to IPv4; it has to run over
   UDP.

   Traditionally, IPsec is used purely in client/server scenarios for
   corporate PCs to connect to a VPN concentrator.  However, deployments
   of Windows 7's DirectAccess and OSX's Back-to-My-Mac service, and of
   peer-to-peer IPsec [I-D.saito-mmusic-sdp-ike] (which standardizes a
   similar mechanism), means use of IPsec is likely to increase in peer-
   to-peer scenarios.

2.5.  SIP

   Most SIP networks deploy SBCs to assist with IPv4 NAT traversal
   ("media latching", described in Section 5 of
   [I-D.ietf-mmusic-media-path-middleboxes]), IPv6/IPv4 interworking,
   protection of the service provider's network, and peering between
   service providers.  When used with an SBC, a SIP endpoint works fine
   with in-host translation, as shown in the figure below.
         +-------------+                               +---------+
         |IPv4 SIP +---+  < IPv6  >  +---+  < IPv4  >  |IPv4 SIP |
         |endpoint |HBT+--<network>--+SBC+--<network>--+ endpoint|
         +---------+---+             +---+             +---------+

   However, if an SBC is not present, the IPv4-only SIP endpoint would
   need its SIP peer to support ICE [I-D.ietf-sipping-v6-transition], as
   shown in the figure below.
   +-------------+                                 +---------+
   |IPv4 SIP +---+  < IPv6  >  +-----+  < IPv4  >  |IPv4 SIP |
   |endpoint |HBT+--<network>--+NAT64+--<network>--+ endpoint|
   +---------+---+             +-----+             | w/ ICE  |
                                                   +---------+

2.6.  email protocols (SMTP, IMAP, POP)

   SMTP Submission [RFC4409], IMAP [RFC3501], and POP3 [RFC1939] are
   client-initiated protocols and do not contain IP addresses in their
   payload (except Received:  header fields which are only used for
   troubleshooting).  These protocols work fine with in-host
   translation.  Similarly, supporting IPv6 natively in these
   application is a trivial change, as they are typically configured
   with a hostname within the host's mail application.  HTML rendering
   by IMAP and POP clients, especially of external objects, does require
   more effort in the mail client, almost on par with HTTP.  However,
   all major mail clients (e.g., Outlook, Thunderbird, mail.app) already
   support IPv6 including their HTML renderers.




Wing & Byrne             Expires August 28, 2010               [Page 14]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


2.7.  HTTP

   HTTP is a client-initiated protocol.  When an IPv4 address literals
   are contained within the URI, or within a page (such as in Javascript
   or used by a plug-in), the IPv4 server can still be accessed (because
   the host-based translator knows how to convert an IPv4 address into a
   corresponding IPv6 address).

   An HTTP client is more difficult to update to support IPv6 natively.
   However, all major web browsers have supported IPv6 natively
   (Internet Explorer, Firefox, Safari, Opera) for years.  Thus, native
   IPv6 support by HTTP clients has already been achieved and there is
   no need to expect HTTP clients are IPv4-only.


3.  Concerns

3.1.  Interference with IPv6 Deployment

   We assume that BIA/BIS prefer IPv6 addresses over IPv4 addresses, as
   is common today [RFC3484].  With BIA/BIS, a client application will
   experience new behavior as soon as its server adds an AAAA record.
   The addition of an AAAA record changes the operation from NAT464
   (IPv4 application accessing an IPv4 server) to NAT46 (IPv4
   application accessing an IPv6 server).  This new behavior occurs no
   matter if an ALG is necessary for that application or not.  But the
   new behavior is even more severe if an ALG is necessary.  This means
   if a server on the Internet adds an AAAA record it may cause existing
   IPv4 applications to break if an ALG is necessary for those
   applications (see also Section 3.3).

   By comparison, if a dual-stack or IPv6-only with in-network NAT64
   approach ([I-D.ietf-softwire-dual-stack-lite], [I-D.ymbk-aplusp],
   [I-D.boucadair-port-range]) is used, adding an AAAA record to a
   server does not adversely affect existing IPv4 host applications.
   Dual-stack approaches allow a smoother upgrade to IPv6, because AAAA
   records are only used by IPv6-aware applications running on IPv6-
   capable hosts connected to IPv6-capable networks.

3.2.  Troubleshooting

   The in-host interaction of BIA/BIS, and the in-host ALG necessary for
   some scenarios with some applications, requires accessing information
   in the host regarding the state and operation of BIA/BIS and the ALG.
   This increases the complexity of troubleshooting for the network
   operator compared with the common approach of capturing and analyzing
   traffic traversing the network.  Beyond troubleshooting historically
   problematic ALGs, fixing the host-based ALG may require software



Wing & Byrne             Expires August 28, 2010               [Page 15]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   changes to potentially millions of end-points.

3.3.  Application Layer Gateways

3.3.1.  Standardization

   There are implementations of a ALGs for a wide variety of protocols
   for IPv4 to IPv4 translation.  However, NAT464 needs an IPv4 to IPv6
   ALG.  As demonstrated by April 2009 survey of EPSV support on the
   Internet (Section 1 of [I-D.van-beijnum-behave-ftp64]), IPv4/IPv6
   ALGs are more difficult than anticipated for even a simple and long-
   established protocol such as FTP.

   To date, only one detailed specification exists to describe the
   function of an ALG [I-D.van-beijnum-behave-ftp64] for IPv6 clients to
   access IPv4 servers.  Yet for BIA/BIS to be successfully deployed
   with IPv6 servers, the opposite will need to be specified (IPv4
   client accessing an IPv6 server).  Furthermore, an ALG will need to
   be standardized for every protocol that exchanges IP addresses in its
   payload, including applications such as (but not limited to) active-
   mode FTP44, passive mode FTP64 (work in progress,
   [I-D.van-beijnum-behave-ftp64]), H.323, HELD
   [I-D.ietf-geopriv-held-identity-extensions], RTSP, RTSPv2 (see Note,
   below), SAP, SIP (see Note, below), PPTP, IPsec, and XMPP.

      Note:  Although some protocols include their own advanced NAT
      traversal mechanisms (e.g., SIP can use [I-D.ietf-mmusic-ice],
      RTSPv2 can use [I-D.ietf-mmusic-rtsp-nat], H.325 has some NAT
      traversal mechanisms), it is impossible to know if the IPv4
      application running on the host implements those advanced NAT
      traversal mechanisms.  Thus, ALGs for protocols running on the
      same port are probably still necessary.

3.3.2.  Interference with Application Evolution

   An ALG can interfere in undesirable ways with enhancements to
   applications.  For example, both Teredo (Section 3.1 of [RFC4380])
   and STUN (Section 15.2 of [RFC5389]) needed to explicitly encode
   their application payloads to avoid overly-ambitious ALGs.  Thus,
   careful standardization, design, and implementation of ALG behavior
   is critical or else ALGs will interfere with applications.  Even so,
   experience demonstrates that it is unlikely that all interference
   with applications can be avoided; a quick search using your favorite
   search engine for "SIP ALG disable" will yield a treasure trove of
   industry experience with a protocol that embeds IP addresses in its
   payloads.





Wing & Byrne             Expires August 28, 2010               [Page 16]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


3.3.3.  Encrypted Application Signaling

   Some application that carry IP addresses in their payloads are
   encrypted (e.g., FTPS [RFC4217], SIPS [I-D.ietf-sip-sips]), while
   others are routinely encrypted (e.g., XMPP).  This encryption
   prevents an ALG from modifying the application signaling messages,
   which means those IPv4 applications will fail if they attempt to
   communicate with an IPv6 server -- no matter if the ALG is inside the
   host or not.  This is because the application performs the TLS
   encryption using its own TLS library, whereas an in-host ALG is part
   of the IP stack (beneath the application).

3.3.4.  ALG interference with IPv6-aware applications

   The in-network NAT64 device will operate ALGs, for various protocols.
   These ALGs will necessarily rewrite addresses, even for IPv6-aware
   applications.  That may cause problems for those IPv6-aware
   applications. [[need more detail.]]


4.  Recommendations

   Of the concerns outlined in the previous section, the most
   significant is that some protocols need an ALG to function correctly
   when a NAT46 function is performed by BIA/BIS.  Thus, limiting the
   PNAT system to only NAT464 reduces this concern.  This appears
   achievable by having the in-host BIA/BIS function so it only performs
   A queries (and never AAAA) queries.

   If that capability is removed from BIA/BIS, PNAT should be carefully
   compared with other approaches to evaluate the advantages and
   disadvantages of PNAT.


5.  Security Considerations

   TBD.


6.  IANA Considerations

   This document requires no IANA actions.


7.  Acknowledgements

   Thanks to Christian Vogt for his review comments.




Wing & Byrne             Expires August 28, 2010               [Page 17]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   This document was produced using version 1.35pre1 of xml2rfc.


8.  References

8.1.  Normative References

   [I-D.huang-behave-pnat]
              Huang, B. and H. Deng, "Prefix NAT: Host based IPv6
              translation", draft-huang-behave-pnat-01 (work in
              progress), February 2010.

   [I-D.huang-behave-rfc2767bis]
              Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts
              using the "Bump-In-the-Stack" Technique (BIS)",
              draft-huang-behave-rfc2767bis-01 (work in progress),
              February 2010.

   [I-D.huang-behave-rfc3338bis]
              Huang, B., Deng, H., and T. Savolainen, "Dual Stack Hosts
              Using "Bump-in-the-API" (BIA)",
              draft-huang-behave-rfc3338bis-01 (work in progress),
              February 2010.

   [I-D.ietf-behave-v6v4-xlate-stateful]
              Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful
              NAT64: Network Address and Protocol Translation from IPv6
              Clients to IPv4 Servers",
              draft-ietf-behave-v6v4-xlate-stateful-08 (work in
              progress), January 2010.

   [I-D.vogt-durand-virtual-ip6-connectivity]
              Vogt, C. and A. Durand, "Virtual IPv6 Connectivity for
              IPv4-Only Networks",
              draft-vogt-durand-virtual-ip6-connectivity-03 (work in
              progress), October 2009.

8.2.  Informative References

   [I-D.boucadair-port-range]
              Boucadair, M., Levis, P., Bajko, G., and T. Savolainen,
              "IPv4 Connectivity Access in the Context of IPv4 Address
              Exhaustion: Port Range based IP Architecture",
              draft-boucadair-port-range-02 (work in progress),
              July 2009.

   [I-D.ietf-geopriv-held-identity-extensions]
              Winterbottom, J., Thomson, M., Tschofenig, H., and R.



Wing & Byrne             Expires August 28, 2010               [Page 18]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


              Barnes, "Use of Device Identity in HTTP-Enabled Location
              Delivery (HELD)",
              draft-ietf-geopriv-held-identity-extensions-03 (work in
              progress), February 2010.

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [I-D.ietf-mmusic-media-path-middleboxes]
              Stucker, B. and H. Tschofenig, "Analysis of Middlebox
              Interactions for Signaling Protocol Communication  along
              the Media Path",
              draft-ietf-mmusic-media-path-middleboxes-02 (work in
              progress), March 2009.

   [I-D.ietf-mmusic-rfc2326bis]
              Schulzrinne, H., Rao, A., Lanphier, R., Westerlund, M.,
              and M. Stiemerling, "Real Time Streaming Protocol 2.0
              (RTSP)", draft-ietf-mmusic-rfc2326bis-22 (work in
              progress), July 2009.

   [I-D.ietf-mmusic-rtsp-nat]
              Goldberg, J., Westerlund, M., and T. Zeng, "A Network
              Address Translator (NAT) Traversal mechanism for media
              controlled by Real-Time Streaming Protocol (RTSP)",
              draft-ietf-mmusic-rtsp-nat-09 (work in progress),
              January 2010.

   [I-D.ietf-mmusic-rtsp-nat-evaluation]
              Westerlund, M. and T. Zeng, "The evaluation of different
              NAT traversal Techniques for media controlled by Real-time
              Streaming Protocol (RTSP)",
              draft-ietf-mmusic-rtsp-nat-evaluation-02 (work in
              progress), January 2010.

   [I-D.ietf-sip-sips]
              Audet, F., "The use of the SIPS URI Scheme in the Session
              Initiation Protocol (SIP)", draft-ietf-sip-sips-09 (work
              in progress), November 2008.

   [I-D.ietf-sipping-v6-transition]
              Camarillo, G., "IPv6 Transition in the Session Initiation
              Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work
              in progress), August 2007.




Wing & Byrne             Expires August 28, 2010               [Page 19]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   [I-D.ietf-softwire-dual-stack-lite]
              Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee,
              Y., and R. Bush, "Dual-stack lite broadband deployments
              post IPv4 exhaustion",
              draft-ietf-softwire-dual-stack-lite-03 (work in progress),
              February 2010.

   [I-D.saito-mmusic-sdp-ike]
              Saito, M., Wing, D., and M. Toyama, "Media Description for
              IKE in the Session Description Protocol (SDP)",
              draft-saito-mmusic-sdp-ike-06 (work in progress),
              November 2009.

   [I-D.van-beijnum-behave-ftp64]
              Beijnum, I., "IPv6-to-IPv4 translation FTP
              considerations", draft-van-beijnum-behave-ftp64-06 (work
              in progress), October 2009.

   [I-D.wing-v6ops-v6app-v4server]
              Wing, D., "Building IPv6 Applications which Access IPv4
              Servers", draft-wing-v6ops-v6app-v4server-01 (work in
              progress), October 2009.

   [I-D.ymbk-aplusp]
              Bush, R., "The A+P Approach to the IPv4 Address Shortage",
              draft-ymbk-aplusp-05 (work in progress), October 2009.

   [ICE-UDP]  Beda, J., Ludwig, S., Saint-Andre, P., Hildebrand, J.,
              Egan, S., and R. McQueen, "XEP-0176: Jingle ICE-UDP
              Transport Method", June 2009,
              <http://xmpp.org/extensions/xep-0176.html>.

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, May 1996.

   [RFC2326]  Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time
              Streaming Protocol (RTSP)", RFC 2326, April 1998.

   [RFC2428]  Allman, M., Ostermann, S., and C. Metz, "FTP Extensions
              for IPv6 and NATs", RFC 2428, September 1998.

   [RFC3484]  Draves, R., "Default Address Selection for Internet
              Protocol version 6 (IPv6)", RFC 3484, February 2003.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC3715]  Aboba, B. and W. Dixon, "IPsec-Network Address Translation



Wing & Byrne             Expires August 28, 2010               [Page 20]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


              (NAT) Compatibility Requirements", RFC 3715, March 2004.

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 3920, October 2004.

   [RFC3947]  Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
              "Negotiation of NAT-Traversal in the IKE", RFC 3947,
              January 2005.

   [RFC4217]  Ford-Hutchinson, P., "Securing FTP with TLS", RFC 4217,
              October 2005.

   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
              Network Address Translations (NATs)", RFC 4380,
              February 2006.

   [RFC4409]  Gellens, R. and J. Klensin, "Message Submission for Mail",
              RFC 4409, April 2006.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.


Appendix A.  To Do

   Add walk throughs for:

   o  Dual-Stack Application to IPv4 Server

   o  Dual-Stack Application to IPv6-only Server

   o  Dual-Stack Application to Dual-Stack Server


Authors' Addresses

   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email:  dwing@cisco.com







Wing & Byrne             Expires August 28, 2010               [Page 21]


Internet-Draft     Concerns with v4 Apps to v6 Servers     February 2010


   Cameron Byrne
   T-Mobile USA, Inc.


   Email:  cameron.byrne@t-mobile.com














































Wing & Byrne             Expires August 28, 2010               [Page 22]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/