Internet DRAFT - draft-wu-behave-udp-tunnel
draft-wu-behave-udp-tunnel
Network Working Group Xiangyang. Wu
Internet-Draft Huawei Technologies
Expires: March 5, 2006 September 2005
UDP enhanced tunnel for traversing NAT
draft-wu-behave-udp-tunnel-01
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 March 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This protocol specification describes a more generic method to
encapsulate and decapsulate packets inside a UDP enhanced tunnel for
traversing Network Address Translators (NATs). UDP enhanced tunnel
header (UTH) encapsulation, as defined in this document, can be used
in both IPv4 and IPv6 scenarios.
Wu Expires March 5, 2006 [Page 1]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 4
3. Basic technique . . . . . . . . . . . . . . . . . . . . . . . 5
4. UDP enhanced tunnel Header (UTH) Format . . . . . . . . . . . 7
5. Encapsulation and Decapsulation Procedures . . . . . . . . . . 8
5.1. xTC behaviors . . . . . . . . . . . . . . . . . . . . . . 8
5.1.1. xTC encapsulate packets . . . . . . . . . . . . . . . 8
5.1.2. xTC decapsulate packets . . . . . . . . . . . . . . . 9
5.2. xTS behaviors . . . . . . . . . . . . . . . . . . . . . . 9
5.2.1. xTS decapsulate packets . . . . . . . . . . . . . . . 9
5.2.2. xTS encapsulate packets . . . . . . . . . . . . . . . 9
6. The whole procedures description . . . . . . . . . . . . . . . 11
7. NAT Keepalive Procedure . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
11.1. Normative References . . . . . . . . . . . . . . . . . . . 16
11.2. Informative References . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Wu Expires March 5, 2006 [Page 2]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
1. Introduction
RFC3948 [1] has given a method to solve the NAT (Network Address
Translators) traversal problem of IPSec ESP packets, it uses a UDP
encapsulation. This protocol specification describes a more generic
method to encapsulate and decapsulate packets inside a UDP enhanced
tunnel for traversing Network Address Translators (NATs).
Some signaling protocol, such as h.323, use multi protocols
(RAS(Registration,Admission and Status), h.225.0, etc) in it's
signaling procedures. The previous procedure (RAS) negotiates/
allocates transport address that will be used in subsequence
procedures. And often, the negotiated/allocated transport address is
different than the initial protocol uses.
If a network element in internal of NAT allocates a transport address
and notifies it to the external network element, the external element
can connect to it for subsequence procedure continues. But cause the
hindrance of NAT, this inbound connection to internal element will be
forbidden by NAT in generally. To cope with this situation, we
introduce a UDP enhanced tunnel between internal element and external
element.
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in RFC2119 [2] and
indicate requirement levels for compliant implementations.
Wu Expires March 5, 2006 [Page 3]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
2. Terminology and Notation
The following terms are used throughout the document.
UDP enhanced tunnel
a logical tunnel created between xTC and xTS, which use UTH
encapsulation
UTH
UDP enhanced Tunnel Header, the encapsulation format for UDP enhanced
tunnel
xTC
traversal Tunnel Client; it is the client side of a logical tunnel
which use UTH encapsultion, the tunnel is initiated from xTC to xTS
xTS
traversal Tunnel Server; it is the server side of a logical tunnel
which use UTH encapsultion, the tunnel is terminated on xTS
ALG
Application Level Gateway
Wu Expires March 5, 2006 [Page 4]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
3. Basic technique
To aid the packet traversing NAT, two logical element are introduced
in network(see Figure 1), they located at two sides of NAT. The
element located in internal of NAT is referred as Traversal Tunnel
Client (xTC), and the element located in external of NAT is referred
as Traversal Tunnel Server (xTS). A tunnel that used between xTC and
xTS is referred as UDP enhanced tunnel, which use encapsulation and
decapsulation techniques described in Section 4, Section 5.
network layout before introduction of xTC and xTS
------ -------- ------
| | | | | |
| I |<--->| NAT |<--->| E |
| | | | | |
------ -------- ------
network layout after introduction of xTC and xTS
------ ------- -------- ------- ------
| | | | | | | | | |
| I |<--->| xTC |<--->| NAT |<--->| xTS |<--->| E |
| | | | | | | | | |
------ ------- -------- ------- ------
I-internal network element
E-external network element
xTC-traversal tunnel client
xTS-traversal tunnel Server
Figure 1: Introduce xTC and xTS to aid traversing NAT
A UDP enhanced tunnel (see Section 4, Section 5 for details)
establishes from xTC to xTS. When external element sends packet to
internal element, to avoid hindrance of NAT, it first send the packet
to xTS, xTS sends the packet to xTC via the tunnel. xTC will do the
decapsulation and forward the packet to the real destination.
If internal element sends packet to a external element, it can select
to send the packet directly to NAT, or according pre-configuration,
sends the packet to xTC. If xTC receives the packet, it SHOULD
encapsulate the packet and sends it to xTS via the enhanced UDP
tunnel. When packet arrives xTS, xTS decapsulates the packet and
forwards the packet to real destination.
Although the packets can traverse through the NAT via UDP enhanced
Wu Expires March 5, 2006 [Page 5]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
tunnel, we still have a problem that the transport addresses hold in
payload of packets is private addresses. If xTS don't handle this
situation, and forward it to the real destination, then the
destination element can't give a correct response. So besides the
tunnel function, xTS general needs ALGs function comprised with it,
the ALGs do the translation work of payload. ALG functionality for
xTC/xTS is the same functionality required for NAT-ALG in general, so
no additional requirements are being added in this document.
Wu Expires March 5, 2006 [Page 6]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
4. UDP enhanced tunnel Header (UTH) Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port | Destination Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Orig-protocol | other-fields |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| other-field(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| body after original IP header |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The UDP enhanced tunnel header is comprised of three parts: a UDP
header, a protocol field and a other-fields.
The UDP header is a standard RFC0768 [3] header, where
o Source port and Destination port are two end ports of the tunnel,
o the IPv4 UDP Checksum can be transmitted as a zero value, or non-
zero value, if use non-zero value, it should be calculate
according to RFC0768 [3],
o receivers should verify the Checksum according to RFC0768 [3].
The Orig-protocol field holds the protocol field of original IP
header.
The other-fields is not defined in this document, it is reserved for
extension.
Wu Expires March 5, 2006 [Page 7]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
5. Encapsulation and Decapsulation Procedures
xTc and xTS all do the encapsulation and decapsulation in the tunnel
procedures. They encapsulate a general packet and send it to it's
peer, and decapsulate the packet encapsulated by its peer.
5.1. xTC behaviors
5.1.1. xTC encapsulate packets
xTC will encapsulate the packets it receives if:
o the packet is sent to xTC, and the packets belong to a specified
protocol it should encapsulate according to it's configuration
BEFORE APPLYING UTH
--------------------------------
IPv4 |orig IP hdr | | |
|(any options)| UDP/TCP | Data |
--------------------------------
AFTER APPLYING UTH
--------------------------------------
IPv4 |orig IP hdr | UTH | | |
|(any options)| Hdr | UDP/TCP | Data |
--------------------------------------
If it needs to encapsulate the packet, xTC follows this procedure:
o A properly formatted UDP enhanced tunnel header(UTH header) is
inserted where shown.
o The Source, destination address, Total Length, Protocol, and
Header Checksum (for IPv4) fields in the new IP header are edited
to match the resulting IP packet.
o The destination should be one ip address of xTS.
o And cause IP header is modified, a map entry should be recorded by
xTC for correct processing the packets sent from xTS.
o The resulting packet is forwarded to xTS.
Wu Expires March 5, 2006 [Page 8]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
5.1.2. xTC decapsulate packets
When xTC receives encapsulated packet, it follow this procedure:
o The UTH header is removed from the packet.
o The Source, destination address, Total Length, Protocol, and
Header Checksum (for IPv4) fields in the new IP header are edited
to match the resulting IP packet, in this procedure, the map entry
recorded earlier is used to aid the process.
o The resulting packet is forwarded to the real destination.
5.2. xTS behaviors
5.2.1. xTS decapsulate packets
xTS will decapsulate the packets it receives if:
o the packet is sent to xTS and the port receives the packet is used
for UDP enhanced tunnel.
To decapsulate the packet, xTS follows this procedure:
o The UTH header is removed from the packet.
o Do the ALG process if needed.
o The source, destination address, Total Length, Protocol, and
Header Checksum (for IPv4) fields in the new IP header are edited
to match the resulting IP packet.
o The resulting packet is forwarded to the real destination.
The resulting destination address is one ip address of external
element. Cause the real destination address is not carried in the
packets xTS received, for correctly process, this address should be
known to the xTS previously; this requirement may be acheived via
pre-configure mechanism. The IP header is modified in this
procedure, so a map entry should be recorded in xTS for correctly
process the subsequence packets related to this interaction.
5.2.2. xTS encapsulate packets
xTS will encapsulate the packets it receives if:
o the packet is related to a previous packet it decapsulated,
includes
Wu Expires March 5, 2006 [Page 9]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
* the direct response packet or
* other packets send to the transport addresses hold in payload
of previous packet, etc.
To encapsulate the packet, xTS follow this procedure:
o A properly formatted UDP enhanced tunnel header(UTH header) is
inserted just as section 4.1.1.
o Do the ALG process if needed.
o The source, destination address, Total Length, Protocol, and
Header Checksum (for IPv4) fields in the new IP header are edited
to match the resulting IP packet. To accomplish this, the map
entry recorded in previously procedure should be used.
o The resulting packet is forwarded to xTC.
Wu Expires March 5, 2006 [Page 10]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
6. The whole procedures description
Here, we briefly describe the procedures involved in the whole
process between xTC and xTS:
o internal element sends packet, which should be sent to external
element if don't use UTH, to xTC,
o xTC encapsulates a packet it receives in UDP enhanced tunnel and
sends it to xTS,
o xTS decapsulates the packet it receives, cause the transport
addresses in the payload are private ones,
o xTS does the ALG function if needed, and forwards the packet to
real destination, here, the transport addresses have been
translated to public addresses,
o the real destination responses/connects to the transport address
hold in payload, sure this packet is sent to xTS, cause xTS has do
a ALG translation work on payload,
o xTS does the ALG function if needed, and hands over the packet to
tunnel process,
o xTS encapsulates the packet in UDP enhanced tunnel and sends it to
xTC via the tunnel,
o xTC decapsulates the packet and forwards it to real destination.
In the procedures, the response/connection from external to internal
will be encapsulated in the same tunnel between xTC and xTS, that is
created from xTC to xTS in initial procedure, so there aren't any
hindrance to forbid the connection from external to internal of NATs.
Wu Expires March 5, 2006 [Page 11]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
7. NAT Keepalive Procedure
Because the map entry created in NAT has a time to live limit, we may
need a mechanism to keep the entry alive during the interaction of
internal and external element. To keep the map entry alive in NAT, a
NAT keep-alive packet may be sent between xTC and xTS, the other-
fields of UTH header MAY be used to fulfill this function. We may
use a mechanism like RFC3948 [1] in section 4; Or use a keepalive
request/response mechanism like RFC3489 [4] in section 10.2.
Wu Expires March 5, 2006 [Page 12]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
8. Security Considerations
This document just gives a UDP enhanced tunnel mechanism for
traversing NAT. No any authentication procedure is addressed here.
But we should note that, in realization, an authentication procedure
is RECOMMENDED to be used. The other-fields MAY help to fulfill this
function.
Wu Expires March 5, 2006 [Page 13]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
9. IANA Considerations
None.
Wu Expires March 5, 2006 [Page 14]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
10. Acknowledgments
Thanks Xin. Yao for original thoughts on this mechanism.
Thanks advices from Spencer Dawkins, Zhong. Luo, Peili. Xu,
Jincheng. Li, on this document.
Wu Expires March 5, 2006 [Page 15]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
11. References
11.1. Normative References
[1] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M.
Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948,
January 2005.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997.
[3] Postel, J., "User Datagram Protocol", RFC 0768, August 1980.
[4] 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.2. Informative References
Wu Expires March 5, 2006 [Page 16]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
Author's Address
Xiangyang Wu
Huawei Technologies
Bantian
Shenzhen, Longgang 518129
China
Phone: +86 755 28780808
Email: wuxy@huawei.com
Wu Expires March 5, 2006 [Page 17]
Internet-Draft UDP enhanced tunnel for traversing NAT September 2005
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 (2005). 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.
Wu Expires March 5, 2006 [Page 18]
