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]