Network Working Group S. Vaarala Internet-Draft NetSeal Technologies Expires: January 10, 2002 July 12, 2001 Mobile IP NAT/NAPT/Firewall Traversal draft-vaarala-mobileip-nat-traversal-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 January 10, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract Mobile IP and Network Address Translation (NAT) are incompatible. This draft presents a mechanism of establishing a Mobile IP NAT traversal binding in a backwards compatible manner. The NAT traversal is based on using the Mobile IP Home Agent UDP port for encapsulation of data traffic, thus requiring only a single NAT address mapping. The presented method optimizes round trips required to set up the NAT address mapping, which is a critical measure for handover performance. Vaarala Expires January 10, 2002 [Page 1] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Previous work . . . . . . . . . . . . . . . . . . . . . . 4 1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Specification language . . . . . . . . . . . . . . . . . . 4 2. Protocol description . . . . . . . . . . . . . . . . . . . 5 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2 Message exchanges . . . . . . . . . . . . . . . . . . . . 6 2.2.1 Message exchange with NAT devices present . . . . . . . . 6 2.2.2 Message exchange without NAT devices present . . . . . . . 7 2.2.3 Message exchange with a non-compliant home agent . . . . . 8 2.3 Packet formats . . . . . . . . . . . . . . . . . . . . . . 8 2.3.1 Data packet encapsulation . . . . . . . . . . . . . . . . 8 2.3.2 Keepalive message . . . . . . . . . . . . . . . . . . . . 10 2.3.3 Registration Request . . . . . . . . . . . . . . . . . . . 10 2.3.4 Registration Reply . . . . . . . . . . . . . . . . . . . . 11 2.3.5 New extensions . . . . . . . . . . . . . . . . . . . . . . 11 2.3.5.1 Mobile node traversal extension . . . . . . . . . . . . . 12 2.3.5.2 Home agent traversal extension . . . . . . . . . . . . . . 13 2.4 Version considerations . . . . . . . . . . . . . . . . . . 14 3. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.1 Overhead . . . . . . . . . . . . . . . . . . . . . . . . . 15 3.2 Network requirements . . . . . . . . . . . . . . . . . . . 15 4. Security considerations . . . . . . . . . . . . . . . . . 16 5. Intellectual property rights . . . . . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 18 References . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . 20 Full Copyright Statement . . . . . . . . . . . . . . . . . 21 Vaarala Expires January 10, 2002 [Page 2] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 1. Introduction 1.1 Overview Network Address Translation (NAT) [7] is an algorithm for modifying IP packet address and optionally transport protocol fields in order to map private addresses to public addresses. While NAT is inherently incompatible with the Internet Protocol (IP) [1], it is widely deployed in practice, and cannot be ignored in protocol design. In addition to NAT devices there are routers that filter certain kinds of packets in the route between the mobile node and its home agent. Mobile IP [4] is a protocol that provides IP layer mobility for nodes. While Mobile IP itself is an established protocol, its design does not take NAT devices into account. Thus, Mobile IP will not work when the mobile node resides behind a NAT device (or several NAT devices). Packet filtering routers also pose a problem for Mobile IP connectivity because success in establishing a mobility binding does not ensure that packets can actually be routed between the mobile node and the home agent. This document presents a simple protocol for UDP-based Mobile IP NAT traversal. The protocol assumes that the network allows communication between an UDP port chosen by the mobile node, and the home agent UDP port 434. The user data is encapsulated in UDP packets that use the same port numbers as the Mobile IP signalling traffic, which has the following advantages. Firstly, only a single NAT mapping is required for both Mobile IP signalling and user data traffic. Secondly, server-to-client data can start flowing as quickly as possible, optimizing handover performance. Thirdly, a successful Mobile IP binding usually indicates that encapsulated packets will flow unfiltered. The protocol provides a method of NAT detection, and automatic use of NAT traversal if the home agent determines that it is necessary. In addition, the mobile node may request traversal to be used regardless of NAT detection outcome, which is useful if intervening firewalls block some types of traffic but let the Mobile IP traffic pass thru. To keep the NAT mapping constant, empty UDP packets are sent as keepalives in absence of traffic. The keepalive interval is controlled by the home agent, which may be useful since the home agent may have better knowledge of misbehaving NAT devices, and the proper keepalive interval to be used with each such device. Compatibility with existing Mobile IP implementations is ensured by using the standard Mobile IP vendor extension mechanism to implement the features described. Vaarala Expires January 10, 2002 [Page 3] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 1.2 Previous work Similar schemes have been presented previously for both Mobile IP and IPsec. The scheme presented for Mobile IP in [10] assumes a separate UDP port for data encapsulation, which requires extra message exchanges to establish a NAT mapping before server-to-client traffic may begin. Also, firewall traversal may be difficult since the UDP port chosen by the home agent for data encapsulation may be blocked even though the Mobile IP port 434 is not; there is no efficient method of discovering acceptable ports. The IPsec working group has presented a draft for IPsec NAT traversal [11], which incorporates NAT traversal negotiation into the IKE protocol [12] and reuses the IKE port (UDP port 500) for data encapsulation. A generalization of this approach (reusing a signalling channel for data encapsulation) is used in this document for Mobile IP NAT traversal. 1.3 Terminology The Mobile IP related terminology described in [4] is used in this document. In addition, the following terms are used: Traversal Mobility Binding: An extended kind of Mobile IP Mobility Binding, that includes NAT traversal state. Optimized Traversal: A method of UDP-based NAT traversal where the Mobile IP data port is used for tunnelling of IPv4 packets without extra overhead for any marker octets to distinguish Mobile IP and user data packets. Non-Optimized Traversal: A method of UDP-based NAT traversal where the Mobile IP data port is used for tunnelling of IPv4 packets. A reserved Mobile IP message type (marker) is used to distinguish data packets from Mobile IP packets. Data Encapsulation Marker: Mobile IP message type value(s) that are used to distinguish user data packets from Mobile IP packets. 1.4 Specification language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [6]. Vaarala Expires January 10, 2002 [Page 4] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 2. Protocol description 2.1 Overview The protocol described in this document has functionality (1) to negotiate NAT traversal support in a backwards compatible manner, (2) to detect the presence of NAT device(s), (3) to determine whether NAT traversal should be used or not, and if so, to assign a NAT keepalive interval, and (4) to tunnel data packets. The protocol assumes that the mobile node is registering using a co-located care-of address. All functionality except data packet tunnelling are performed within the standard Registration Request (RREQ) and Registration Reply (RREP) message exchange. The RREQ message contains a Mobile Node Traversal Extension, which is a Normal Vendor-Specific Extension (NVSE) [9], which indicates that the mobile node supports this protocol. The extension also contains a flag, which indicates that the mobile node requests unconditional tunnelling of data packets, regardless of the outcome of NAT detection performed by the home agent. The extension also contains the data encapsulation marker used by the mobile node. The home agent detects the presence of NAT device(s) by comparing the source IP address of the RREQ message, and the co-located care-of address contained within the message. A discrepancy indicates that an address translation has been performed. Traversal MUST be enabled if NAT is detected, or if the mobile node has requested unconditional tunnelling. However, the home agent MAY also enable traversal unilaterally. Should traversal be used, a Home Agent Traversal Extension, which is a Critical Vendor-Specific Extension (CVSE) [9], is inserted into the RREP message. The presence of the extension indicates that this protocol is supported by the home agent, and that NAT traversal has been enabled in the mobility binding shared by the mobile node and the home agent. The extension also includes the server data encapsulation marker, and the NAT keepalive interval that the mobile node should use. If NAT traversal is not used, or if the home agent does not support this protocol, the RREP message will not include the Home Agent Traversal Extension. Once NAT traversal has been enabled for a given Mobile IP binding, both the home agent and the mobile node encapsulate IPv4 packets inside UDP payloads, using the same ports as in the RREQ/RREP messages. Ordinary Mobile IP packets are differentiated from tunnelled IPv4 packets by means of the Mobile IP message type field. The data encapsulation markers exchanged in the RREQ/RREP message vendor extensions determine which message type octets serve as data Vaarala Expires January 10, 2002 [Page 5] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 encapsulation markers for each direction of traffic. Two types of encapsulation behavior are supported: optimized, with eight octet overhead, and non-optimized, with nine octet overhead. Empty UDP packets are used as NAT keepalive messages, should there be no user data or Mobile IP traffic within the NAT keepalive interval. Once the registration lifetime expires, the NAT traversal MUST be stopped. The traversal state is a part of the mobility binding, so a new RREQ/RREP message exchange is required to re-establish NAT traversal. Since the same UDP port is used for both Mobile IP traffic and encapsulated data traffic, the only requirements for firewalls and NAT devices is to pass traffic between the home agent UDP port 434 and the UDP port chosen by the mobile node. Also, if the RREQ/RREP message exchange succeeds, the data traffic encapsulation will almost certainly pass the routers between the mobile node and the home agent. 2.2 Message exchanges The notation "src-addr:src-udp-port -> dst-addr:dst-udp-port" is used in the following diagrams to indicate addressing fields of packets. COA is the possibly private co-located care-of address of the mobile node. HA is the home agent address, which is assumed to be a public address. X is the UDP source port used by the mobile node for Mobile IP (or data encapsulation) messages destined to the home agent. This port is assumed static for the duration of a given RREQ/RREP exchange, and the (possible) data encapsulation and keepalive traffic that follows. NAT-COA is the translated COA address, while NAT-X is the possibly translated UDP port X (NAT and NAPT are handled identically in the protocol, so the worst case, ie NAPT, is assumed). 2.2.1 Message exchange with NAT devices present This exchange of messages takes place when both mobile node and home agent are compliant, and one or more NAT/NAPT devices exist in the route between mobile node and home agent. Vaarala Expires January 10, 2002 [Page 6] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 mobile node NAT/NAPT device(s) home agent =========== ================== ========== ----------------> COA:X -> HA:434 Registration Request + co-located address COA + Mobile Node Traversal Extension (U-flag, mobile node encapsulation marker) --------------> NAT-COA:NAT-X -> HA:434 Registration Request Discrepancy: IP header source address is NAT-COA, while RREQ care-of address field is COA. HA->MN traffic can start flowing. <------------- HA:434 -> NAT-COA:NAT-X Registration Reply + Home Agent Traversal Extension (home agent encapsulation marker, NAT keepalive interval) <---------------- HA:434 -> COA:X Registration completed, MN->HA traffic can also start flowing. [data traffic] [NAT keepalive interval passed without traffic, send keepalive] ----------------> COA:X -> HA:434 keepalive (empty UDP) --------------> NAT-COA:NAT-X -> HA:434 2.2.2 Message exchange without NAT devices present This exchange of messages takes place when both mobile node and home agent are compliant, but no NAT/NAPT devices seem to be present. Vaarala Expires January 10, 2002 [Page 7] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 mobile node home agent =========== ========== -----------------------------------> COA:X -> HA:434 Registration Request + co-located address COA + Mobile Node Traversal Extension (U-flag, mobile node encapsulation marker) No discrepancy between the IP header source address field and the RREQ care-of address field. If the U-flag (unconditional tunnelling requested) is set, or if the home agent determines that UDP data encapsulation should be performed, the scenario reverts to the one described above. HA->MN traffic can start flowing. <---------------------------------- HA:434 -> COA:X Registration Reply [no keepalive traffic, behave as required by RFC 2002.] 2.2.3 Message exchange with a non-compliant home agent If the home agent does not support this protocol, it will ignore the NVSE sent by the mobile node. If NAT/NAPT devices are present, the d¨screpancy in the Mobile IP headers should cause the HA to discard or reject the registration. 2.3 Packet formats 2.3.1 Data packet encapsulation Since the same UDP ports are used to send both Mobile IP packets and encapsulated data packets, there must be a method of identifying which kind of packet was received by a mobile node or by a home agent. This protocol uses the first octet of the UDP payload data to make this determination. The IPv4 header has the following format [1]: Vaarala Expires January 10, 2002 [Page 8] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Mobile IP messages have a one octet message type identifier, with rest of the message being message type specific. For instance, Registration Request has the following format [4]: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |S|B|D|M|G|V|rsv| Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Home Agent | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Care-of Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Identification + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions ... +-+-+-+-+-+-+-+- The first octet of an IPv4 header contains both an IP version field (always 4 for IPv4) and the Internet Header Length field, which is always in the range 5...15. Thus the first octet of IPv4 header is always in the range 0x45...0x4f. This fact is used by the optimized traversal mode to differentiate packet types. If the first octet of the UDP payload is in the range 0x45...0x4f, the UDP payload (including the first octet) is assumed to be an encapsulated IPv4 packet. Otherwise the payload is assumed to be a Mobile IP message. The optimized traversal mode does not add extra overhead (in addition to the UDP header), but requires that Vaarala Expires January 10, 2002 [Page 9] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 the receiver has reserved the Mobile IP message types 0x45...0x4f for data encapsulation markers. In non-optimized traversal a single message type is used as a data encapsulation marker. The marker message type can be chosen dynamically, and is sent as part of both Mobile Node Traversal Extension and Home Agent Traversal Extension. If the first octet of the UDP payload equals the marker chosen by the receiving host, the UDP payload excluding the first octet is assumed to be an encapsulated IPv4 packet. Otherwise the payload is assumed to be a Mobile IP message. Non-optimized traversal mode adds one octet overhead (in addition to the UDP header), but only requires that a single Mobile IP message type be reserved to serve as a marker. Since the marker is not pre-defined by this protocol, any Mobile IP message type can serve as one; thus there is no possibility of conflict with future Mobile IP message types, as long as there is at least one unused message type to serve as a marker. Both modes of traversal MUST be supported. The receiving host chooses which type of traversal it expects in packets sent to it, and if non-optimized traversal is used, which marker octet is used. To emphasize, the marker may be different in each direction. 2.3.2 Keepalive message A keepalive message is an empty UDP packet sent using the same port information as Mobile IP and encapsulated data packets. This packet is differentiated from Mobile IP and encapsulated data packets using the UDP length field (which MUST be eight) [2]. 2.3.3 Registration Request When using this protocol, the Registration Request message consists of an IPv4 header, followed by an UDP header, followed by the fixed Mobile IP Registration Request header [4], followed by extensions, including the Mobile Node Traversal Extension, followed by the Mobile-Home Authentication Extension ([4], Section 3.5.2), which MUST NOT be followed by any extensions. The UDP source port of the Registration Request may be chosen freely by the mobile node. However, the source port MUST stay constant for the duration of the binding being requested, and for the data/keepalive traffic that follows. This ensures that the NAT mapping stays valid. The mobile node SHOULD use the same source port for all interactions with the home agent. The Registration Request message fields operate normally, with the following exceptions. The 'D' (decapsulation by mobile node) bit MUST be set, because only co-located care-of address mode is Vaarala Expires January 10, 2002 [Page 10] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 supported. The 'M' (minimal encapsulation) bit MUST NOT be set, since it conflicts with NAT. The 'G' (generic routing encapsulation, or GRE [8]) bit operates normally, as do the other flag bits. The Care-of Address field is set to the possibly private co-located care-of address. When simultaneous bindings are used, the usage of traversal applies to each binding individually, ie each binding has a different keepalive interval and potentially different encapsulation markers. 2.3.4 Registration Reply The Registration Reply message consists of an IPv4 header, followed by an UDP header, followed by the fixed Mobile IP Registration Reply header [4], followed by extensions, possibly including the Home Agent Traversal Extension, followed by the Mobile-Home Authentication Extension, which MUST NOT be followed by any extensions. The Registration Reply message fields are set normally. Because there is nothing to guarantee that the NAT mapping is not lost -- data and keepalive packets may be lost, or the NAT device may be rebooted -- the home agent implementation MUST take the special case of a lost NAT mapping into consideration. To avoid a long traffic blackout in such situations the home agent SHOULD set the lifetime of the binding to a conservative value, such as one minute. This ensures that if the NAT mapping is lost, a new one is formed by a new RREQ/RREP exchange in a reasonable time. The NAT traversal state is conceptually added into the Mobile IP binding state, and thus, it MUST be re-negotiated for every RREQ/RREP message pair exchange. 2.3.5 New extensions The Normal Vendor-Specific Extensions (NVSE) and Critical Vendor-Specific Extensions (CVSE) used in this document conform to [9]. Unauthenticated extensions MUST NOT be processed. Vaarala Expires January 10, 2002 [Page 11] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 2.3.5.1 Mobile node traversal extension 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor/Org-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-NVSE-Type |U| Reserved | Marker | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Mobile Node Traversal Extension is a NVSE (Normal Vendor-Specific Extension), which indicates support for this protocol. It is ignored by the receiver if the extension is not supported. The fields are set as follows: Type: NVSE-TYPE-NUMBER 134 [9]. Length: 10. Vendor/Org-Id: 9213, hex 0x23fd, registered to NetSeal Technologies. Vendor-NVSE-Type: 16385 (0x4001) U-flag: Indicates that the mobile node wants to use traversal regardless of the outcome of NAT detection performed by the home agent. This is useful if the route between the mobile node and the home agent works for Mobile IP signalling packets, but not for generic data packets (eg because of firewall filtering rules). If the home agent supports this protocol, it MUST either accept the traversal and reply with a Home Agent Traversal Extension or reject the traversal. The suggested value for the Registration Reply Code field in case of failed registration is 129 ("administratively prohibited"). Marker: If zero, indicates that the mobile node uses optimized traversal. If non-zero, indicates that the mobile node uses non-optimized traversal, and the value of the field is the marker octet to be placed in the UDP payload prior to the actual encapsulated IPv4 packet. The home agent MUST use the encapsulation method and marker octet indicated by the mobile node in encapsulated packets sent to the mobile node. All reserved fields MUST be set to zero. If a reserved field is non-zero when the extension is received, the whole extension MUST be ignored. Vaarala Expires January 10, 2002 [Page 12] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 2.3.5.2 Home agent traversal extension 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Reserved | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor/Org-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor-CVSE-Type | Reserved | Marker | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Keepalive-Interval-Secs | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Home Agent Traversal Extension is a CVSE, which indicates that (1) the home agent supports this protocol, and (2) that the traversal has been enabled for the mobility binding established using the RREQ/RREP exchange. The fields are set as follows: Type: CVSE-TYPE-NUMBER 38 [9]. Length: 12. Vendor/Org-Id: 9213, hex 0x23fd, registered to NetSeal Technologies. Vendor-CVSE-Type: 16386 (0x4002) Marker: If zero, indicates that the home agent uses optimized traversal. If non-zero, indicates that the home agent uses non-optimized traversal, and the value of the field is the marker octet to be placed in the UDP payload prior to the actual encapsulated IPv4 packet. The mobile node MUST use the encapsulation method and marker octet indicated by the home agent in encapsulated packets sent to the home agent. Keepalive-Interval-Secs: Specifies the NAT keepalive interval that the mobile node SHOULD use. A keepalive packet SHOULD be sent if Keepalive-Interval-Secs seconds have elapsed without any signalling or data traffic being sent. The keepalive interval may depend on specific NAT devices. It may be the case that the home agent is aware of parts of the network, and can "recommend" proper keepalive traffic intervals for mobile nodes. For example, the server wants keepalive traffic to be sent with an interval of 60 seconds by default, but certain problem devices require shorter keepalive packet intervals. These "problem devices" can be configured to the home agent one by one, while other devices Vaarala Expires January 10, 2002 [Page 13] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 are handled using the default value. Note that the mobile node is incapable of making an informed decision since it does not see the external address that the NAT device assigns to it. All reserved fields MUST be set to zero. If a reserved field is non-zero when the extension is received, the mobile node MUST assume that the registration failed. 2.4 Version considerations There are no version negotiation fields in this protocol. If functionality is changed radically new vendor extension IDs are allocated to the new traversal protocol. The mobile node may indicate support for several versions of this protocol by appending several NVSE extensions in the Registration Request message. If the home agent detects a flag in the currently reserved area of the Mobile Node Traversal Extension that it does not support, it MUST reject the registration. Suggested Code is 134 (poorly formed Request). If the mobile node detects a flag in the currently reserved area, it MUST act as if the registration had failed, and that the binding was not completed. Vaarala Expires January 10, 2002 [Page 14] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 3. Analysis 3.1 Overhead This draft does not add significant latency to the ordinary Mobile IP Registration Request / Registration Reply message exchange. In particular, the NAT address mapping is formed when the mobile node sends its first Registration Request message, and is already valid when the home agent receives the packet. Thus, the home agent may start forwarding traffic to the client immediately after receiving the Registration Request (assuming, of course, that the binding is accepted). In other words, the latency for server-to-client traffic flow is 0.5 roundtrips, and for client-to-server traffic, one roundtrip. The extra data in the form of vendor extensions does add some transmission latency, and may be noticeable especially using slow media. If optimized data encapsulation is used, there is an eight octet overhead (compared to IP-IP tunnelling) per data packet caused by the UDP header required for traversal. For non-optimized data encapsulation, the corresponding overhead is nine octets per data packet. 3.2 Network requirements The protocol described in this document works in networks where there are ordinary routers, NAT/NAPT routers, and firewalls that are configured to pass Mobile IP packets (variable mobile node port and fixed home agent port 434). There are no other requirements with regards to UDP ports, and since there are no extra UDP ports for data encapsulation, there is no need to use heuristics to determine which UDP port might actually work for data encapsulation: if the Registration Request is received, both the Registration Reply and encapsulated data is typically received properly. Since the Mobile IP home agent port is used for data encapsulation, there MUST NOT be foreign agents in the route (which might be confused by such packets). In particular, only the co-located care-of address mode of Mobile IP is supported. (In fact, a DHCP server that also performs NAT is a viable replacement for a FA.) Vaarala Expires January 10, 2002 [Page 15] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 4. Security considerations The Traversal Extensions used by this protocol are authenticated by the Mobile IP Mobile-Home Authentication Extension. The presence of the extensions do not seem to cause vulnerabilities, since the information contained in them is not confidential. Support of this protocol may be considered as useful information for an attacker, though. A strong attacker is free to modify the IP packets sent, and thus eg cause the home agent to mistakenly believe there are NAT device(s) in the route between mobile node and the home agent. However, such modifications require read-write access to the packet flow, which already enable other more powerful attacks to be performed. Vaarala Expires January 10, 2002 [Page 16] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 5. Intellectual property rights NetSeal Technologies has no patent applications related to the protocol described in this document. Vaarala Expires January 10, 2002 [Page 17] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 6. Acknowledgements Levkowetz et al. have proposed a similar scheme in [10], the difference being a dedicated UDP tunnelling port. Kivinen, Stenberg, Huttunen et al. have proposed a NAT traversal protocol for IPsec [11], which uses the same approach taken here, in particular reusing the NAT address mapping of the signalling channel (in their draft, IKE) for data encapsulation. The author would like to thank the staff at NetSeal Technologies for useful feedback. Vaarala Expires January 10, 2002 [Page 18] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 References [1] Defense Advanced Research Projects Agency (DARPA), Information Processing Techniques Office and , "Internet Protocol", STD 5, RFC 791, September 1981. [2] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [3] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [4] Perkins, C., "IP Mobility Support", RFC 2002, October 1996. [5] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [7] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [8] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [9] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization-Specific Extensions", RFC 3115, April 2001. [10] Levkowetz, O. H., Forslow, J. and H. Sjostrand, "NAT Traversal for Mobile IP using UDP Tunnelling (Work in Progress)", July 2001. [11] Huttunen, A., Dixon, W., Swander, B., Kivinen, T., Stenberg, M., Volpe, V. and L. DiBurro, "UDP Encapsulation of IPsec Packets (Work in Progress)", June 2001. [12] Kivinen, T., Stenberg, M., Huttunen, A., Dixon, W., Swander, B., Volpe, V. and L. DiBurro, "Negotiation of NAT-Traversal in the IKE (Work in Progress)", June 2001. Vaarala Expires January 10, 2002 [Page 19] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 Author's Address Sami Vaarala NetSeal Technologies P.O Box 38 Niittykatu 6 02201 Espoo Phone: +358-9-435 310 Fax: +358-9-435 311 00 EMail: sami.vaarala@netseal.com URI: http://www.netseal.com/ Vaarala Expires January 10, 2002 [Page 20] Internet-Draft Mobile IP NAT/NAPT/Firewall Traversal July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Vaarala Expires January 10, 2002 [Page 21]