[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

BEHAVE Working Group                                             D. Wing
Internet-Draft                                                     Cisco
Intended status:  Informational                                 C. Byrne
Expires:  April 22, 2010                                    T-Mobile USA
                                                        October 19, 2009


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

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 April 22, 2010.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   Bump-in-the-Stack and Bump-in-the-API allow IPv4 applications to
   access IPv6 servers.  This is done by using in-host NAT46 translator.



Wing & Byrne             Expires April 22, 2010                 [Page 1]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  PNAT Walk-Through  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  Outgoing Connection: FTP Passive Mode  . . . . . . . . . .  4
       2.1.1.  IPv4 Application to IPv4 Server (NAT464) . . . . . . .  5
       2.1.2.  IPv4 Application to IPv6-only Server (NAT46) . . . . .  6
       2.1.3.  IPv4 Application to Dual-Stack Server (NAT46)  . . . .  6
     2.2.  Incoming connection: FTP Active Mode . . . . . . . . . . .  7
       2.2.1.  IPv4 Application to IPv4 Server (NAT464) . . . . . . .  7
       2.2.2.  IPv4 Application to IPv6-only Server (NAT46) . . . . .  8
       2.2.3.  IPv4 Application to Dual-Stack Server (NAT46)  . . . .  9
   3.  Concerns . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Interference with IPv6 Deployment  . . . . . . . . . . . . 10
     3.2.  Troubleshooting  . . . . . . . . . . . . . . . . . . . . . 10
     3.3.  Application Layer Gateways . . . . . . . . . . . . . . . . 10
       3.3.1.  Standardization  . . . . . . . . . . . . . . . . . . . 10
       3.3.2.  Interference with Application Evolution  . . . . . . . 11
       3.3.3.  Encrypted Application Signaling  . . . . . . . . . . . 11
   4.  Recommendations  . . . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  To Do . . . . . . . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14















Wing & Byrne             Expires April 22, 2010                 [Page 2]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


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.  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 to provided to 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, but it
   is believed to have similar needs for ALG assistance to support
   complex protocols.

   PNAT provides two features, 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 April 22, 2010                 [Page 3]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


2.  PNAT Walk-Through

   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.  Although FTP is
   shown, other more complex protocols (e.g., SIP, XMPP) also require
   incoming and/or outgoing connections (depending on the sort of
   session being established) and encounter similar issues.  FTP was
   chosen because it is well-understood and because the FTP data
   connection can be outgoing (from the client) or incoming (to the
   client).  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.  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 April 22, 2010                 [Page 4]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


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

   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.

   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.





Wing & Byrne             Expires April 22, 2010                 [Page 5]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


   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.  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, and no IPv4 address and no A record.

   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:

   o  Not transparent to application.

   o  This scenario fails for some applications, unless those
      applications have an Application Layer Gateway 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.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.

   The IPv4 FTP application does a gethostaddr() call for
   ftp.example.com.  This is intercepted by the BIA/BIS in the host, and



Wing & Byrne             Expires April 22, 2010                 [Page 6]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


   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, and fails
   for the same reason.

   Notes:

   o  The same Notes from Section 2.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.  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
   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.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.

   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



Wing & Byrne             Expires April 22, 2010                 [Page 7]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


   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
   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.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 AAA
   record.  It has no IPv4 address and no A record.

   The IPv4 FTP application does a gethostaddr() call for
   ftp.example.com.  This is intercepted by the BIA/BIS in the host, and



Wing & Byrne             Expires April 22, 2010                 [Page 8]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


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

   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.2.2, and also
   succeeds.

   Notes:

   o  The same Notes from Section 2.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]).






Wing & Byrne             Expires April 22, 2010                 [Page 9]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


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.
   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 that 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 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 effect existing IPv4 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
   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].  Yet for BIA/BIS



Wing & Byrne             Expires April 22, 2010                [Page 10]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


   to be successfully deployed with IPv6 servers, ALGs 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), 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.

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


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.




Wing & Byrne             Expires April 22, 2010                [Page 11]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


   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.


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-00 (work in
              progress), October 2009.

   [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-00 (work in progress),
              October 2009.

   [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-00 (work in progress),
              October 2009.

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

   [I-D.vogt-durand-virtual-ip6-connectivity]



Wing & Byrne             Expires April 22, 2010                [Page 12]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


              Vogt, C. and A. Durand, "Virtual IPv6 Connectivity for
              IPv4-Only Networks",
              draft-vogt-durand-virtual-ip6-connectivity-02 (work in
              progress), July 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.
              Barnes, "Use of Device Identity in HTTP-Enabled Location
              Delivery (HELD)",
              draft-ietf-geopriv-held-identity-extensions-01 (work in
              progress), October 2009.

   [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-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-08 (work in progress),
              July 2009.

   [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-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-01 (work in progress),
              July 2009.

   [I-D.van-beijnum-behave-ftp64]
              Beijnum, I., "IPv6-to-IPv4 translation FTP



Wing & Byrne             Expires April 22, 2010                [Page 13]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


              considerations", draft-van-beijnum-behave-ftp64-05 (work
              in progress), July 2009.

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

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

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

   [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 April 22, 2010                [Page 14]


Internet-Draft     Concerns with v4 Apps to v6 Servers      October 2009


   Cameron Byrne
   T-Mobile USA, Inc.


   Email:  cameron.byrne@t-mobile.com














































Wing & Byrne             Expires April 22, 2010                [Page 15]


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