Internet DRAFT - draft-chown-cost-of-nat
draft-chown-cost-of-nat
Network Working Group T. Chown
Internet-Draft University of Southampton
Expires: December 21, 2006 June 19, 2006
The Cost of Application Development with NATs
draft-chown-cost-of-nat-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 December 21, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The deployment of IP Network Address Translators (NATs) for IPv4 has
become very pervasive in the last 10-12 years. The original goal of
NAT was to conserve IP address space, but the technology has now
become very popular in home and SOHO type networks, as well as many
larger organisations, for a variety of reasons. At the same time,
the introduction of NAT adds a cost for application and service
developers. This document presents a brief overview of the history
of NAT, alongside a list of ongoing work related to NAT workarounds
for current IETF protocol designs. The document intends to present a
Chown Expires December 21, 2006 [Page 1]
Internet-Draft The Cost of NAT June 2006
neutral view of the cost of NAT for discussion in the IETF and wider
community.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specific NAT Traversal Methods . . . . . . . . . . . . . . . . 4
2.1. ICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. SIMCO . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3. STUN . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4. TURN . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Application and Service Considerations . . . . . . . . . . . . 4
3.1. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. NSIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. Peer to Peer Applications . . . . . . . . . . . . . . . . 5
3.5. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Other NAT-Related Issues . . . . . . . . . . . . . . . . . . . 6
4.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. General NAT Behavioural Requirements . . . . . . . . . . . 6
4.3. Topologies . . . . . . . . . . . . . . . . . . . . . . . . 6
4.4. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
8. Informative References . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
Chown Expires December 21, 2006 [Page 2]
Internet-Draft The Cost of NAT June 2006
1. Introduction
In this text, we present a very brief overview of the origins of IP
Network Address Translation (NAT), before looking at a wide range of
ongoing IETF protocol and related design that is currently having to
consider or work around NAT deployments. We include sections on:
o NAT traversal techniques
o Ongoing IETF work due to the presence of NATs
o Other NAT considerations
One goal of the text is to try to present an objective view of the
cost of NAT in terms of application and service deployment. A by-
product of the document may be to encourage application designers to
consider IPv6 versions of applications, for which such workarounds
are not required. It also highlights the long-term cost should NATs
be deployed for IPv6 networks. While NATs are here to stay for IPv4,
their introduction for IPv6 should be debated carefully.
This document may well overlap with some ongoing work in the BEHAVE
Working Group of the IETF. The aim at present is to capture NAT
issues in this text. The value of the text, and the purposes to
which it may be placed, are open for discussion, possibly within that
WG.
The basic specification of NAT [1] has been in existence for 12 years
at the time of writing, and has since been extended [7]. The
technology has undoubtedly allowed the Internet to grow with the
limitations of IPv4 address space, by allowing multiple client
devices to run local private [2] IP addresses on internal networks
while often sharing just a single global IP address externally.
The pros and cons of using NAT, in terms of the architectural
implications, have been documented before [6]. Protocol
complications have also been described in a separate text [8]. Those
keen to see the original Internet goal of transparency [5] retained
have documented arguments in favour of avoiding the use of NAT.
Whatever is written, the fact is that NAT is universally popular for
its ease of deployment, in particular for home networking. However,
there is a cost, and that is shifted to the application and protocol
designers, who have to work around the limitations that NAT devices
impose.
Some efforts have been made in terms of classifying NATs, for example
NAT Classification Test Results [26], which is an ongoing IETF draft.
Chown Expires December 21, 2006 [Page 3]
Internet-Draft The Cost of NAT June 2006
The IPv6 protocol [3] does not explicitly preclude the use of NAT.
However, it is argued that the very raison d'etre of IPv6 is
universal global addressability, and to use NAT would defeat the very
purpose of deploying the new protocol. A work in progress on IPv6
Network Architecture Protection [24] describes how IPv6 protocol
features can be used to achieve the same effect as NAT for site
networks.
2. Specific NAT Traversal Methods
There are some existing well-known (public) NAT traversal methods.
2.1. ICE
The Interactive Connectivity Establishment (ICE) [21] protocol is a
protocol for NAT traversal for multimedia session signaling protocols
based on the offer/answer model, such as the Session Initiation
Protocol (SIP). An additional draft has been published on reducing
the amount of messaging required [27].
2.2. SIMCO
A draft of the Simple Middlebox Configuration (SIMCO) Protocol v3.0
[32] describes a protocol for controlling middleboxes such as
firewalls and network address translators.
2.3. STUN
Simple Traversal of User Datagram Protocol (UDP) Through Network
Address Translators (NATs), or STUN before [10] offers one method of
NAT traversal for UDP traffic. STUN is a lightweight protocol that
allows applications to discover the presence and types of NATs and
firewalls between them and the public Internet, as well as the global
IP address used by the NAT. There is a STUN update [20] draft in
progress. Another draft discusses a STUN-based Signalling Framework
[31].
2.4. TURN
The TURN protocol [18] is now the subject of a draft describing it as
a usage of STUN.
3. Application and Service Considerations
An existing RFC discusses application design guidelines [9] when
considering NATs. The document provides recommendations to authors
Chown Expires December 21, 2006 [Page 4]
Internet-Draft The Cost of NAT June 2006
of new protocols about the effects to consider when designing new
protocols such that special handling is not required at NAT gateway
points. It discusses the limitations, including the lack of
availability of end-to-end IPsec. It makes recommendations such as
using domain names rather than IP addresses where possible. The
document lacks any firm conclusion, but presents a set of issues
well.
3.1. HIP
The IRTF HIP WG is working on Middlebox Traversal Issues of Host
Identity Protocol (HIP) Communication [25]. The text identifies and
discusses issues in the current HIP specifications that affect
communication across these types of middleboxes. Some HIP extensions
for NAT traversal are defined in another draft [30].
3.2. IPv6
The Teredo [11] protocol specifies an IPv6 tunnelling mechanism that
can work through NAT devices.
There is also an extension of TURN proposed in a draft on using a
TURN extension for IPv4/IPv6 transition [19].
3.3. NSIS
The NSIS WG is working on a NAT/Firewall NSIS Signaling Layer
Protocol (NSLP) [22]. NSLP allows hosts to signal along a data path
for Network Address Translators and firewalls to be configured
according to the data flow needs. A separate draft talks about NAT
issues for the General Internet Signalling Transport (GIST) protocol
[28].
3.4. Peer to Peer Applications
An overview of peer-to-peer application usage across NATs [33] is
underway as a draft, as is a general text on application design
guidelines for NAT traversal, with a focus on peer to peer [13].
3.5. SIP
An RFC has been published [12] that describes NAT considerations,
referring to STUN and UPnP support, and there is also a draft on BCP
for NAT traversal and SIP [23] and another draft on the problem
statement for SIP-signalled P2P applications with NATs and
middleboxes [29].
Chown Expires December 21, 2006 [Page 5]
Internet-Draft The Cost of NAT June 2006
4. Other NAT-Related Issues
4.1. IPsec
Issues surrounding tunnel mode IPsec and NATs are described in
guidelines [4].
4.2. General NAT Behavioural Requirements
The BEHAVE WG has produced a draft on NAT behavioural requirements
[15]. The document defines basic terminology for describing
different types of NAT behaviour when handling Unicast UDP and also
defines a set of requirements that would allow many applications,
such as multimedia communications or on-line gaming, to work
consistently. A companion document provides similar text for NATs
and ICMP [16] and for unicast TCP [17].
4.3. Topologies
There is a draft on problems caused by complex, for example multi-
layer, NAT topologies [14], and how these complicate NAT traversal.
4.4. Tunnels
There is a general problem for tunnel methods, for example GRE, where
demultiplexing multiple GRE tunnels to many nodes behind a NAT is
problematic. This can impact IPv6 (for example 6to4) and Multicast
(for example AMT) tunnel handling.
5. Conclusions
The IETF has created a WG (BEHAVE) to look at the issues of NAT
traversal; this WG has focused on general documents at a more focused
protocol level. This document looks to take a broader view, to
highlight the volume of effort ongoing in NAT traversal. There are
examples of ongoing drafts resulting from the presence of NATs in at
least the SIP, NSIS, HIP, IPv6 and Multicast WGs of the IETF, in
addition to WGs involving P2P application usage.
This text is still very much in draft format. We aim to focus on the
structure for the -01 release. Any comments to the author welcomed.
6. Security Considerations
There are no specific security considerations in this document.
Chown Expires December 21, 2006 [Page 6]
Internet-Draft The Cost of NAT June 2006
7. IANA Considerations
There are no IANA considerations for this document.
8. Informative References
[1] Egevang, K. and P. Francis, "The IP Network Address Translator
(NAT)", RFC 1631, May 1994.
[2] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E.
Lear, "Address Allocation for Private Internets", BCP 5,
RFC 1918, February 1996.
[3] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[4] Srisuresh, P., "Security Model with Tunnel-mode IPsec for NAT
Domains", RFC 2709, October 1999.
[5] Carpenter, B., "Internet Transparency", RFC 2775,
February 2000.
[6] Hain, T., "Architectural Implications of NAT", RFC 2993,
November 2000.
[7] Srisuresh, P. and K. Egevang, "Traditional IP Network Address
Translator (Traditional NAT)", RFC 3022, January 2001.
[8] Holdrege, M. and P. Srisuresh, "Protocol Complications with the
IP Network Address Translator", RFC 3027, January 2001.
[9] Senie, D., "Network Address Translator (NAT)-Friendly
Application Design Guidelines", RFC 3235, January 2002.
[10] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, "STUN
- Simple Traversal of User Datagram Protocol (UDP) Through
Network Address Translators (NATs)", RFC 3489, March 2003.
[11] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network
Address Translations (NATs)", RFC 4380, February 2006.
[12] Sinnreich, H., Lass, S., and C. Stredicke, "SIP Telephony
Device Requirements and Configuration", RFC 4504, May 2006.
[13] Ford, B., "Application Design Guidelines for Traversal through
Network Address Translators", draft-ford-behave-app-02 (work
in progress), March 2006.
Chown Expires December 21, 2006 [Page 7]
Internet-Draft The Cost of NAT June 2006
[14] Ford, B. and P. Srisuresh, "Complications from Network Address
Translator Deployment Topologies", draft-ford-behave-top-01
(work in progress), March 2006.
[15] Audet, F. and C. Jennings, "NAT Behavioral Requirements for
Unicast UDP", draft-ietf-behave-nat-udp-07 (work in progress),
June 2006.
[16] Srisuresh, P., "NAT Behavioral Requirements for ICMP protocol",
draft-ietf-behave-nat-icmp-00 (work in progress), May 2006.
[17] Guha, S., "NAT Behavioral Requirements for Unicast TCP",
draft-ietf-behave-tcp-00 (work in progress), February 2006.
[18] Rosenberg, J., "Obtaining Relay Addresses from Simple Traversal
of UDP Through NAT (STUN)", draft-ietf-behave-turn-00 (work in
progress), March 2006.
[19] Camarillo, G. and O. Novo, "Traversal Using Relay NAT (TURN)
Extension for IPv4/IPv6 transition",
draft-ietf-behave-turn-ipv6-00 (work in progress), March 2006.
[20] Rosenberg, J., "Simple Traversal of UDP Through Network Address
Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-03
(work in progress), March 2006.
[21] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
Methodology for Network Address Translator (NAT) Traversal for
Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in
progress), March 2006.
[22] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol
(NSLP)", draft-ietf-nsis-nslp-natfw-11 (work in progress),
April 2006.
[23] Boulton, C., "Best Current Practices for NAT Traversal for
SIP", draft-ietf-sipping-nat-scenarios-04 (work in progress),
March 2006.
[24] Velde, G., "IPv6 Network Architecture Protection",
draft-ietf-v6ops-nap-02 (work in progress), October 2005.
[25] Stiemerling, M., "NAT and Firewall Traversal Issues of Host
Identity Protocol (HIP) Communication",
draft-irtf-hiprg-nat-03 (work in progress), June 2006.
[26] Jennings, C., "NAT Classification Test Results",
draft-jennings-behave-test-results-01 (work in progress),
Chown Expires December 21, 2006 [Page 8]
Internet-Draft The Cost of NAT June 2006
July 2005.
[27] Cooper, E. and P. Matthews, "Eliminating Duplicate Connectivity
Checks in ICE",
draft-matthews-mmusic-ice-eliminating-duplicates-00 (work in
progress), June 2006.
[28] Pashalidis, A. and H. Tschofenig, "GIST NAT Traversal",
draft-pashalidis-nsis-gimps-nattraversal-02 (work in progress),
March 2006.
[29] Quittek, J., "Problem Statement for SIP-signalled Peer-to-Peer
Communication across Middleboxes",
draft-quittek-p2p-sip-middlebox-00 (work in progress),
March 2006.
[30] Schmitt, V., "HIP Extensions for the Traversal of Network
Address Translators", draft-schmitt-hip-nat-traversal-01 (work
in progress), June 2006.
[31] Shore, M., "A STUN-Based Signaling (SBS) Framework",
draft-shore-stun-signaling-00 (work in progress),
December 2005.
[32] Stiemerling, M., "Simple Middlebox Configuration (SIMCO)
Protocol Version 3.0", draft-stiemerling-midcom-simco-08 (work
in progress), December 2005.
[33] Srisuresh, P., "State of Peer-to-Peer(P2P) Communication Across
Network Address Translators(NATs)",
draft-srisuresh-behave-p2p-state-03 (work in progress),
June 2006.
Chown Expires December 21, 2006 [Page 9]
Internet-Draft The Cost of NAT June 2006
Author's Address
Tim Chown
University of Southampton
Southampton, Hampshire SO17 1BJ
United Kingdom
Email: tjc@ecs.soton.ac.uk
Chown Expires December 21, 2006 [Page 10]
Internet-Draft The Cost of NAT June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Chown Expires December 21, 2006 [Page 11]
