IETF Behave Working Group C. Perkins
Internet-Draft WiChorus Inc.
Expires: April 22, 2010 October 19, 2009
Payload-assisted Delivery for SIPNAT
draft-perkins-behave-dpinat-00.txt
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.
Perkins Expires April 22, 2010 [Page 1]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
Abstract
SIPNAT has been proposed as an effective method for enabling global
Internet access to IPv6-only domains. New methods have been devised
for accurate delivery of packets from the global Internet into the
internal domain of destinations that do not share a common address
space with the majority of the global Internet. These improvements
can be used to augment Source-IP NAT so that perfect accuracy can be
achieved in many common cases of interest.
Perkins Expires April 22, 2010 [Page 2]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
1. Introduction
Enabling the transition from IPv4 to IPv6 will depend to a large
extent upon how well businesses and online organizations can depend
on IPv6 to carry on their daily operations. One way to justify such
dependence on IPv6 is to assure businesses that their online services
will be accessible from the entire existing IPv54 Internet.
With traditional port-mapped NAT (NAPT), this has not been possible
because, for each source-destination flow, the translation parameters
for the flow have had to be established by the internal network node
(i.e., the node with the IP address that is incompatible with the
addressing domain of the global Internet). In particular, for each
such flow there needs to be an external IP address and an external
port assigned. Packets arriving at the external IP address and port
are then translated and retransmitted with new IP headers containing
the translated IP address and port number. This works for
IPv6-->IPv4 translation, IPv4-->IPv4 translation (e.g., today's
Internet), and other variations as well. It is a workable solution
(with various second-order difficulties) for enabling outgoing
traffic to be delivered into the global Internet.
But any business requires global presence and continuous, on-demand
availability. The customers have to be able to initiate contact with
the business services, not the other way around. Similary for all
other online service organizations (including governmental, non-
profit, and family websites).
One idea for enabling such incoming translations has been proposed,
called "source-IP NAT" (SIPNAT). This proposal relies on DNS to
establish the required parameters for the flow translation. It has
the advantage of dynamic allocation and deallocation of global IPv4
addresses for the potentially huge population of internal (say, IPv6)
network nodes. This is essential for scalability. The more global
IPv4 addresses, the better SIPNAT works. With as few as 128 IPv4
addresses, SIPNAT can offer reliability in excess of 99.99%,
depending on the arrival rate for new flows, the cohesiveness of each
flow, and other details about the statistics of the incoming traffic.
There are other protocol-specific mechanisms that can be used to
assist with the translation of incoming traffic. For almost all HTTP
traffic, the translation can be perfect. For SIP and peer-to-peer
traffic, other mechanisms can often be employed. For some traffic,
there may not be any additional mechanisms that are conveniently
realizable, or even available at all. For example, "ping" and
"telnet" do not make available the information needed for the
protocol mechanisms in this document.
Perkins Expires April 22, 2010 [Page 3]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
2. Failure cases for SIPNAT
SIPNAT relies on DNS Request messages to initialize a pending flow
translation. The pending flow translation will become established
when the first packet of the flow arrives at the external IP address
on the NAT box which has been allocated for that flow. The process
of establishment mainly involves inserting the source IP address of
that first packet as part of the parameters for the flow translation.
This also enables correct synthesis of the translated IPv6 address
that will be reported to the destination, and defines the IPv4 source
address for responses that are transmitted by the IPv6 destination to
be translated by the source-IP NAT.
The newly allocated IP address may already be supporting several (or
many) existing established flows; at any particular time, SIPNAT
requires that only one pending flow translation may await
establishment at the allocated IPv4 address. Because of this, SIPNAT
(while effective and generally robust) does have failure modes.
o The DNS Request does not identify the actual source computer.
This means the initial allocation for global Internet address on
the NAT cannot be established until a packet arrives from the
actual source. It is then possible for a flow translation to be
assigned on a global Internet address that already is hosting a
previous flow translation for the same requesting source-IP
address. In other words, it is possible for a source node, which
is already getting service from the NAT at a particular IPv4
address, to be accidentally allocated that same IPv4 address for a
different internal destination. But, according to the rules of
SIPNAT, two different IPv6 destinations for the same global
Internet source cannot be translated through the same NAT IPv4
address.
o Each IPv4 NAT interface to the global Internet can sustain only
one pending assignment. If too many new DNS resolutions arrive
nearly simultaneously, new flow allocations may temporarily become
unavailable.
o It is possible for a flow to persist even after the IPv4 address
allocated for the flow has timed out. For such flows, incoming
packets may be lost. To counter this, flow timeouts should be set
as long as possible consistent with the target error rate. This
amounts to a trade-off against the likelihood that the same
source-IP address will request a new flow before all of its
previous flows at the allocated NAT IP address have completed (and
their flow translation parameters deactivated)
The SIPNAT document describes how to reduce or eliminate these
Perkins Expires April 22, 2010 [Page 4]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
vulnerabilities by appropriate configuration and adjustments for the
timeout parameters. The first case is the most difficult case for
SIPNAT. Fortunately, according to traffic flows that have been
analyzed to date, this almost never happens for small-to-medium scale
websites that constitute the main use case for SIPNAT. This case
does happen for very large servers, but even then it is rare, and
such servers would be more efficiently handled by IVI [3].
Perkins Expires April 22, 2010 [Page 5]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
3. Using the Payload
The basic proposal in this document is to use information contained
in the payload to assist in translating the IP header from the global
Internet for better-assured delivery to the proper internal host.
This goes beyond previous suggestions for careful configuration and
management of the NAT interface.
For instance, almost all HTTP GET traffic has the host destination
host name as part of the HTTP payload:
http.host: news.google.com
http.host: my-IPv6-server.example-operator.com
For all such incoming traffic, translation can be performed with 100%
accuracy. Current experience with border routers offering DPI
features indicates that the translation can be done at wire speed.
It is expected that this one simple observation will, for all
practical purposes, eliminate any remaining ambiguities about the
delivery of HTTP traffic.
Even in the unlikely event that the "http.host" field is not present
in the HTTP GET traffic, web traffic offers other possibilities for
guiding correct traffic. For example, the pathname of the object
webpage is typically unique to the destination. In other words, it
is rarely the case that two different destinations in the same domain
would use the same pathname to identify any webpages hosted by those
destinations. If a database of associations between pathnames and
actual destinations is maintained, any such traffic containing the
pathname for a destination can be delivered correctly. Information
about rare cases where duplicate pathnames occur can also be
maintained. Even if the pathname can narrow down the selection to a
choice between a few competing websites, the other context for the
flow translation will typically be sufficient for accurate delivery.
Other protocols, such as SIP, also typically utilize URIs and URLS
that provide domain names identifying the desired destination. For
each such protocol, the DPI methods required for extracting the
destination information will be different, but the principle is the
same.
Perkins Expires April 22, 2010 [Page 6]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
4. Peer-to-Peer
After HTTP traffic, the next major source of traffic on the Internet
is Peer-to-Peer traffic. This is typically filesharing traffic,
often using the BitTorrent protocol. In order to understand the
interactions of such traffic with SIPNAT, we will use BitTorrent as
an example.
BitTorrent relies on four different kinds of protocol entities.
o Directory of trackers
o Trackers
o Servers
o Clients
A client uses some method for finding a tracker that maintains
information about servers offering a particular file of interest.
Once contact with a tracker is established, the client obtains a list
of file segments, and for each file segment, a list of servers that
offer availability for that file segment. A client can select one or
more servers for each segment of the desired file. If a transfer for
a specific file segment from one of the selected servers does not
complete, the client can pick another server for that file segment.
Eventually, all segments will be collected together for assembly into
the complete file of interest.
With this as context, it should be considered which configurations
are of most interest. For example, consider an IPv6-only server
offering segments to clients on the global Internet. In many cases,
this sort of service will work just fine, especially if the clients
attempt to resolve the server's domain name before issuing the
request for the file segment. However, the tracker often supplies
the IP address of the server instead of the server's domain name.
For such communications, the client would expect to make contact with
the server without any intermediate DNS resolution to obtain the IP
address of the server. In this case, the SIPNAT would not have the
opportunity to allocate the necessary IPv4 address for the flow
translation.
Nevertheless, it is still possible to handle such incoming traffic,
based on detailed methods for inspecting peer-to-peer traffic
payloads. This is to be specified in a companion ALG document
describing mechanisms for handling IPv4-->IPv6 translation for the
lists of servers provided by trackers. One simple solution is just
to set up IVI-style network interfaces for the servers. For dynamic
Perkins Expires April 22, 2010 [Page 7]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
allocations of IPv4 network interfaces on the NAT router, additional
payload inspection and alterations are needed.
Perkins Expires April 22, 2010 [Page 8]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
5. Other traffic
Aside from HTTP, peer-to-peer, and SIP traffic, other protocol
services should be considered on a case-by-case basis.
For instance, DNS traffic is extremely common on the Internet.
However, it is most likely not a suitable candidate for such protocol
translations as typically handled by NATs. Therefore, for the
purposes of this document, we may consider DNS traffic to be out of
scope for the translation problem.
Mobile IP signaling is not a good candidate for such protocol
translations, because a client is either a Mobile IPv4 mobile node or
a Mobile IPv6 mobile node, and there are already methods specified by
which a Mobile IPv6 mobile node can access its home agent by way of
IPv4 addresses.
It needs to be determined whether or not mail servers that have IPv6
addresses only should be accessible by way of SIPNAT. It seems more
likely, even if they should be accessible at all to the existing IPv4
global Internet, they would be either dual-stack already, or else
good candidates for assignment of a permanent (IVI-style) IPv4
address on the NAT.
FTP does not seem to offer a good way to identify the destination by
way of the payload-oriented mechanisms described earlier in this
document. Such FTP services are better handled by way of IVI-style
static address assignment. For most of the cases of interest, file
access is more likely mediated by HTTP access instead of FTP, and the
remaining cases are typically those more appropriate for static
assignment anyway.
Telnet is not used very often any more, and anyway is likely to be
handled very well by SIPNAT except for cases when the client attempts
to contact a destination by using the raw IP address. SIPNAT does
not offer a solution for that case.
IKEv2 [2] has been designed to work across NAT boundaries.
Consequently, it does not require the use of IP addresses as part of
the IKEv2 message payload. In the case of SIPNAT, the Notify
payloads NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP
will correctly indicate the presence of address translation. If use
of a well-known IPv6 prefix is used to translate the IPv4 address,
there may be an opportunity to precisely identify the type of NAT as
"SIPNAT".
... think about SSH ...
Perkins Expires April 22, 2010 [Page 9]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
6. Segregation by access type
HTTP is a particularly common case that is easy for SIPNAT to handle
with the extensions described in this document. For destinations
that only offer services by way of HTTP, all traffic can be delivered
accurately based on the payload. This means that many different
allocations could be made at the same time without danger of
ambiguity. Effectively, the restriction for only one pending
allocation at a time could be removed.
Suppose, then, that there is a special class of destinations that
only offer HTTP service. Also suppose that the NAT is equipped to
detect the "http.host" field of incoming HTTP GET requests. For
every destination in this special class, each DNS Request could
return the same IPv4 address in the DNS Reply. The same sort of flow
translation would be set up for each HTTP destination assigned to the
IPv4 address, but the destination IP address parameter would be
determined by the payload, and matched against the initial allocation
as determined by the DNS entity. However, packet delivery should
still be granted only for destinations that had been allocated to the
IPv4 address by way of a preceding DNS request. This eligibility
requirement should be a matter of operator policy. For such traffic,
the flow timeout parameter could be configured to a much larger
value.
This scheme could potentially be extended to allow HTTP access to
some destinations identified by IP address (not hostname) in URLs.
In other words, the pathname is located at a raw IP address instead
of the usual domain name for the destination node. For these cases,
the payload can be delivered accurately, but no DNS Request would be
received to trigger the allocation of a pending flow translation.
Such unusual URLs can be supported under the typical configuration
choice for HTTP servers as has been described. Again, it is a matter
for operator choice whether it should be appropriate to provide that
support. Moreover, it is not clear how a source would ever get such
a URL with an IPv4 address to represent the IPv6-only destination.
Perkins Expires April 22, 2010 [Page 10]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
7. References
7.1. Normative References
[1] Perkins, C., "Translating IPv4 to IPv6 based on source IPv4
address", draft-perkins-sourceipnat-00 (work in progress),
October 2009.
7.2. Informative References
[2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
December 2005.
[3] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The CERNET IVI
Translation Design and Deployment for the IPv4/IPv6 Coexistence
and Transition", draft-xli-behave-ivi-02 (work in progress),
June 2009.
[4] 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-00 (work in
progress), July 2009.
Perkins Expires April 22, 2010 [Page 11]
Internet-Draft Payload-assisted Delivery for SIPNAT October 2009
Author's Address
Charles E. Perkins
WiChorus Inc.
3590 N. 1st Street, Suite 300
San Jose CA 95134
USA
Email: charliep@computer.org
Perkins Expires April 22, 2010 [Page 12]