Internet DRAFT - draft-wing-v6ops-v6app-v4server

draft-wing-v6ops-v6app-v4server






BEHAVE Working Group                                             D. Wing
Internet-Draft                                                     Cisco
Intended status:  Informational                         October 26, 2009
Expires:  April 29, 2010


          Building IPv6 Applications which Access IPv4 Servers
                   draft-wing-v6ops-v6app-v4server-01

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 29, 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

   When an application runs on a host or network that only supports IPv6
   ("IPv6-only"), it is sometimes necessary that the application
   communicate with IPv4 peers.  When that communication involves DNS,



Wing                     Expires April 29, 2010                 [Page 1]

Internet-Draft       IPv6 Application to IPv4 Server        October 2009


   DNS64 and a 6/4 translator works well without any changes to most
   applications.  However, when that communication does not involve DNS,
   it can require additional features be configured on or programmed
   into the IPv6 application.  This document explains why this
   functionality is important and describes mechanisms for applications
   to provide such functionality.


Table of Contents

   1.  Applicability . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Mechanism to Communicate with IPv4 Hosts  . . . . . . . . . . . 4
     3.1.  Address Parsing . . . . . . . . . . . . . . . . . . . . . . 4
     3.2.  Operating Differently with IPv4 or IPv6 Peers . . . . . . . 5
     3.3.  Determining IPv4 Peer . . . . . . . . . . . . . . . . . . . 5
       3.3.1.  Transmitting a Packet . . . . . . . . . . . . . . . . . 5
       3.3.2.  Receiving a Packet  . . . . . . . . . . . . . . . . . . 5
     3.4.  Sending an IPv6 Packet to an IPv4 Peer  . . . . . . . . . . 6
       3.4.1.  Using Application-Specific Mechanism  . . . . . . . . . 6
       3.4.2.  Using 6/4 Translation Mechanism . . . . . . . . . . . . 6
   4.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   6.  Informative References  . . . . . . . . . . . . . . . . . . . . 7
   Appendix A.  HTTP IPv4 Address Literals on the Internet . . . . . . 8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 9

























Wing                     Expires April 29, 2010                 [Page 2]

Internet-Draft       IPv6 Application to IPv4 Server        October 2009


1.  Applicability

   This document applies to IPv6 hosts operating in scenario 1 ("an IPv6
   network to IPv4 Internet") and scenario 5 ("an IPv6 network to an
   IPv4 network") [I-D.ietf-behave-v6v4-framework].

   The mechanisms described in this document are *not* necessary for
   most IPv6-aware applications, but are necessary for *some* IPv6-aware
   applications.  For example, if DNS is always used to connect to
   hosts, the DNS64 function [I-D.ietf-behave-dns64] provides access to
   IPv4 hosts without pain or effort by the IPv6 application.  However,
   if IPv4 address literals are used by the application the IPv6-only
   host will need to use the described mechanisms to communicate with
   the IPv4 peer.

   Said another way, applications which never use DNS (and thus do not
   use the DNS64 function), or applications which sometimes do not use
   DNS, will find value in the mechanisms described in this document.
   If an application always (or 'almost always') uses DNS, the
   mechanisms in this document are not necessary.

   Currently, between 0.38%-2% of the Internet's HTTP traffic would
   benefit from the mechanisms in this draft Appendix A.  The need by
   other protocols are subject to further study.


2.  Introduction

   Historically, clients and servers were expected to run as dual-stack
   hosts so that IPv4 could be used to communicate with IPv4 hosts and
   IPv6 could be used to communicate with IPv6 hosts.  One subtle
   feature of a dual-stack host is that IPv4 is available whenever IPv4
   is necessary.  IPv4 is necessary when communicating with IPv4 hosts
   using IPv4 address literals.  IPv4 address literals occur in some
   application protocols naturally (e.g., FTP, SIP) or because for some
   reason DNS wasn't used (e.g., HTTP
   [I-D.wing-behave-http-ip-address-literals]).

   Thus, the function of an IPv4-only, dual-stack, or IPv6-only
   application running on a IPv4-host, dual-stack, or IPv6-only host
   might be summarized as:

      If an application needs to communicate with an IPvX peer, the
      application uses IPvX application syntax and transmits IPvX
      packets.

   needs to be extended to work well in an IPv6-only environment.  This
   extension can be summarized as:



Wing                     Expires April 29, 2010                 [Page 3]

Internet-Draft       IPv6 Application to IPv4 Server        October 2009


      If the application needs to communicate with an IPvX peer, the
      application uses IPvX application syntax and transmits IPv6
      packets.

   The significant difference is that applications used to determine
   which application syntax to use based on the IP address family.  With
   IPv6-only clients accessing IPv4 servers across an IPv6/IPv4
   translator, such short-cuts will often -- but not always -- work as
   desired.

   If the IPv6 application cannot be extended (for whatever reason), an
   Application Layer Gateway function needs to be implemented in the
   host, in CPE, or in the 6/4 translator.  Such an ALG would need to
   perform most of the same functions described in this document.  ALGs
   are best avoided because of the problems they cause (need to be on-
   path with both signaling and data traffic, require signaling traffic
   be unencrypted and non-integrity protected, interferes with
   development of new application features and functions, impossible to
   build an ALG for every application, complicates debugging and
   troubleshooting, and so on).


3.  Mechanism to Communicate with IPv4 Hosts

   In order to provide full access from an IPv6-only host (client) to an
   IPv4 peer, the application must:

      1.  Be capable of parsing an IPv4 address, AND

      2.  Determine if the applications needs to operate differently
      with an IPv4 peer versus an IPv6 peer, AND

      3.  Determine if packet needs to be sent to (or was received from)
      an IPv4 peer, AND

      3.  Send an IPv6 packet to an IPv4 peer.

   These are detailed in the following subsections.

3.1.  Address Parsing

   This requirement is easily achieved, because IPv4 address parsing is
   already implemented in today's applications.  Applications are
   reasonably expected to parse IPv4 address literals (e.g.,
   http://192.0.2.1).  Unless that code is purposefully removed or
   disabled when the application is running on an IPv6-only host, the
   application will still be able to parse IPv4 address literals.




Wing                     Expires April 29, 2010                 [Page 4]

Internet-Draft       IPv6 Application to IPv4 Server        October 2009


3.2.  Operating Differently with IPv4 or IPv6 Peers

   Some protocols operate identically over IPv6 or IPv4 (e.g., NTP).
   Other protocols operate differently over IPv6 or IPv4, either due to
   IPv4 address literals appearing in the application payload or because
   different commands are used with IPv4 peers compared with IPv6 peers.

   The operation of HTTP has been examined and IPv4 address literals
   occasionally appear, requiring some support in the application.
   Alternatively, a workaround may be a reasonable approach as discussed
   in [I-D.wing-behave-http-ip-address-literals].

   The operation of FTP has been examined and different commands are
   used for IPv6 peers (EPSV) than with IPv4 peers (PASV)
   [I-D.van-beijnum-behave-ftp64]).

   Analysis of other protocols is for future study, but the basic
   analysis is much the same:  determine if the application needs to use
   different commands, semantics, or syntax because of the different IP
   address family.

3.3.  Determining IPv4 Peer

3.3.1.  Transmitting a Packet

   If an IPv6 application has parsed an application payload packet and
   found an IPv4 address and wants to communicate with that IPv4 peer,
   the decision is simple:  the application needs to use a translator to
   send the packet to that IPv4 peer.  Section 3.4 describes how the
   applications transmits such a packet.

3.3.2.  Receiving a Packet

   If an IPv6 application might receive a packet directly (via an IPv6
   translator) or via an application proxy.  If the packet was received
   via an application-specific proxy, an application-specific mechanism
   determines if the peer is IPv4 or IPv6.

   If the packet was received has an IPv6 packet via a 6/4 translator it
   can examine the IPv6 prefix to determine if the peer is an IPv4 peer.
   If the network is using the well-known prefix, the comparison is
   straightforward.  If the network is using the NSP prefix the
   application first needs to learn the network's NSP prefix (using
   [I-D.wing-behave-learn-prefix]) and do its comparison.







Wing                     Expires April 29, 2010                 [Page 5]

Internet-Draft       IPv6 Application to IPv4 Server        October 2009


3.4.  Sending an IPv6 Packet to an IPv4 Peer

   Once the above steps are performed, the application has two basic
   mechanisms to send an IPv6 packet to an IPv4 peer.  It can use an
   application-specific mechanism or it can use the general 6/4
   translation mechanism.

3.4.1.  Using Application-Specific Mechanism

   Some applications can use a application proxy to provide access to
   IPv4 servers.  For HTTP, this is described in
   [I-D.wing-behave-http-ip-address-literals].  This HTTP proxy can be
   deployed an IPv4-only HTTP proxy and placed on the far side of the
   6/4 translator, such that any host on the Internet could provide the
   service, as in:

     [IPv6-only client]---[6/4 translator]---[HTTP proxy]---[IPv4 peer]

   The HTTP proxy can also be deployed on both the IPv6 and IPv4
   networks, essentially in parallel with the 6/4 translator, as in:

     [IPv6-only client]---[HTTP proxy]---[IPv4 peer]

   For SIP, this is described in [I-D.ietf-sipping-v6-transition] using
   a TURN-IPv6 [I-D.ietf-behave-turn-ipv6] server as the relay between
   IPv6 and IPv4.  In such a deployment the TURN-IPv6 server is run in
   parallel with the 6/4 translator.  In contrast, a TURN server
   [I-D.ietf-behave-turn] could be run on the IPv4 Internet.

3.4.2.  Using 6/4 Translation Mechanism

   The application (or its underlying operating system) determines the
   IPv6 prefix (using [I-D.wing-behave-learn-prefix]).  With that
   information, the application can construct a destination IPv6
   address.  When sent, that packet will be routed to the 6/4
   translator, translated to the IPv4 destination address embedded in
   the IPv6 packet, and routed to the IPv4 peer.

   For SIP, this is described in Section 6.2 of
   [I-D.ietf-sipping-nat-scenarios] using a 6/4 translator between IPv6
   and IPv4.  (However, that document does not explain how a SIP client
   formulates packets that will be sent to the translator and translated
   by it, as this document explains.)

      Issue:  how does the application determine if its IPv6 network has
      a translator using the WKP prefix, if not via
      [I-D.wing-behave-learn-prefix]?




Wing                     Expires April 29, 2010                 [Page 6]

Internet-Draft       IPv6 Application to IPv4 Server        October 2009


4.  Security Considerations

   TBD.


5.  IANA Considerations

   This document requires no IANA actions.


6.  Informative References

   [Alexa]    Alexa, "Top 1,000,000 Global Sites", September 2009,
              <http://www.alexa.com/topsites>.

   [I-D.ietf-behave-address-format]
              Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X.
              Li, "IPv6 Addressing of IPv4/IPv6 Translators",
              draft-ietf-behave-address-format-01 (work in progress),
              October 2009.

   [I-D.ietf-behave-dns64]
              Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum,
              "DNS64: DNS extensions for Network Address Translation
              from IPv6 Clients to  IPv4 Servers",
              draft-ietf-behave-dns64-02 (work in progress),
              October 2009.

   [I-D.ietf-behave-turn]
              Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)",
              draft-ietf-behave-turn-16 (work in progress), July 2009.

   [I-D.ietf-behave-turn-ipv6]
              Perreault, S., Camarillo, G., and O. Novo, "Traversal
              Using Relays around NAT (TURN) Extension for IPv6",
              draft-ietf-behave-turn-ipv6-07 (work in progress),
              October 2009.

   [I-D.ietf-behave-v6v4-framework]
              Baker, F., Li, X., Bao, C., and K. Yin, "Framework for
              IPv4/IPv6 Translation",
              draft-ietf-behave-v6v4-framework-03 (work in progress),
              October 2009.

   [I-D.ietf-sipping-nat-scenarios]
              Boulton, C., Rosenberg, J., Camarillo, G., and F. Audet,



Wing                     Expires April 29, 2010                 [Page 7]

Internet-Draft       IPv6 Application to IPv4 Server        October 2009


              "Best Current Practices for NAT Traversal for Client-
              Server SIP", draft-ietf-sipping-nat-scenarios-09 (work in
              progress), September 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.

   [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-behave-http-ip-address-literals]
              Wing, D., "Coping with IP Address Literals in HTTP URIs
              with IPv6/IPv4 Translators",
              draft-wing-behave-http-ip-address-literals-00 (work in
              progress), October 2009.

   [I-D.wing-behave-learn-prefix]
              Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/
              IPv4 Translator", draft-wing-behave-learn-prefix-04 (work
              in progress), October 2009.


Appendix A.  HTTP IPv4 Address Literals on the Internet

   There has been some doubt that HTTP URIs on the Internet contain
   hostnames with IPv4 address literals.  This section provides some
   scripts which demonstrate the relatively low -- but prevalent --
   existence of IPv4 address literals.

   An examination of Alexa's top 1 million domains [Alexa] at the end of
   August, 2009, showed 2.38% of the HTML in their home pages contained
   IPv4 address literals.  This can be verified with:

     wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip
     unzip top-1m.csv.zip
     cat top-1m.csv |
       cut -d "," -f 2 |
       xargs -I % -n 1 -t wget -nv % -O - --user-agent="Mozilla/5.0" |
       grep -E "https?://[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"








Wing                     Expires April 29, 2010                 [Page 8]

Internet-Draft       IPv6 Application to IPv4 Server        October 2009


   Of the top 1 million websites at the end of August, 2009, 3455
   (0.35%) of them are IPv4 address literals (e.g., http://192.0.2.1).
   This can be verified with:

     wget http://s3.amazonaws.com/alexa-static/top-1m.csv.zip
     unzip top-1m.csv.zip
     grep -E "[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}"
       top-1m.csv | wc


Author's Address

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

   Email:  dwing@cisco.com
































Wing                     Expires April 29, 2010                 [Page 9]