Internet Draft S. M. Shahrier Document: draft-shahrier-mobileip-nat-00.txt InterDigital Expires: 2001 May 2001 Incorporating NAT boxes in Mobile IPv4 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 obsolete 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. Conventions used in this document 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 [1]. Abstract In this draft, we propose an Internet architecture consisting of large number private networks, individually connected to the Internet backbone via NAT-routers. Hosts within the same private network can communicate with one another locally, and also with hosts in other networks via the Internet backbone. The routers in each private network maintain their own local routing state and routers in the backbone maintain their own external routing state. More specifically, the routers within a particular domain are not cognizant of routes outside that domain. We suggest some modifications to the Basic Static NAT-routers to implement mobility protocols for the cases where: (a) MHs are only allowed to move about their own private network, (b) MHs are allowed to move around from one private network to another. We provide a description of the protocols. Shahrier Informational - Expires September 2001 1 Integrating Basic NAT with Mobile IP May 2001 1. Introduction In this draft, we propose an Internet architecture consisting of a large number of private networks connected to the Internet backbone via NAT-routers. Hosts in different private networks can communicate with one another via the public Internet backbone. The routers in each private network maintain all routes locally; hidden from other private networks and the Internet. In other words, these routers have no knowledge of routes outside of their private domain. Likewise, the backbone (public) routers are not cognizant of the routes to any local addresses. ---------------------------------------------------- | | | INTERNET BACKBONE | | | ---------------------------------------------------- | | | ----- ----- ----- | NAT | | NAT | | NAT | NAT-enabled ----- ----- ----- routers | | | | | | ----- ----- ----- | | | | | | | PVT | | PVT | | PVT | Private | NET | | NET | | NET | Networks | | | | | | ----- ----- ----- Figure 1 Multiple Private Networks Connected by an Internet Backbone Traditionally, NAT-enabled routers [1,2] are used for connecting private networks to the Internet. This was done to try and enhance the use of the address space. The whole 24-bit address space has been split up into a set of registered addresses and a set of unregistered addresses, by IANA [3]. There is no overlap between the private and public addresses, which means that the private networks can use any any one of the unregistered addresses, without prior approval fro IANA. The public or global addresses are unregistered addresses, and without loss of generality, we assume that exactly one address from this pool is assigned each NAT-router. In this draft, we suggest modifications to the NAT functions described above to handle the cases where: (a) MHs are only allowed to move around within its own private network, (b) MHs are allowed to move from one private network to another. The rest of the document is organized as follows: section 2 describes how the NAT is implemented in a system consisting of a large number of private networks, connected to an external backbone; section 3 describes the Internet Draft - Expires November 2001 2 Integrating Basic NAT with Mobile IP May 2001 mobility management protocol where MHs are allowed to move around within its own private network; section 4 describes modifications to the NAT where MHs are allowed to move from one private network to another. The document is concluded in section 5. 2. Terminology The following list of terms are defined in this document: NAT Network Address Translation. MH Mobile Host. IANA Internet Assigned Numbers Authority. COA Care of Address. CN Corresponding Node. 2. System Architecture This section describes how private networks are connected to an external backbone via NAT-enabled routers. Using such a scheme, a large number of private networks can be connected to the external backbone. Hosts within different private networks can communicate with each other via the backbone, using one of the registered addresses assigned by IANA. Hosts within a private network can communicate with one another using their unregistered addresses. Thus, the registered addresses are globally unique, while unregistered addresses have local significance only. The local addresses and the global addresses are mutually exclusive. We discuss next, the operation of the NAT. Consider networks A and B, connected to the Internet, via NAT enabled routers NAT-A and NAT-B respectively. Suppose that a packet was to be sent from A to B. Before data transfer can take place, The NAT tables have to be set up, to reflect the correct binding between the global address of NAT-A and the local address of the sender in A; the global address of NAT-B and the local address of the receiver in B. The exact method by which the tables are configured is outside the scope of this document. The configuration sets up the binding between MH_ in A and NAT-A, and similarly the MH in B and NAT-B. This is illustrated as follows: Binding for NAT-A: ------------------------------------------------------ |Global address of NAT-A | Local address of sender in A| ------------------------------------------------------ Binding for NAT-B: -------------------------------------------------------- |Global address of NAT-B | Local address of receiver in B| -------------------------------------------------------- The procedure for sending out a packet is as follows. The packet is encoded with the global address of NAT-A and the global address of Internet Draft - Expires November 2001 3 Integrating Basic NAT with Mobile IP May 2001 NAT-B. The receiving NAT-B checks the binding in its table, and retrieves the local address of the host. It replaces the global destination field in the header with the local address of MH in B. The packet is then forwarded to that host. The reverse set of actions takes place whenever B sends to A. 3. Mobility Management within a Private Network Suppose that the MH wishes to move about within its private network. It sends a dbase-binding-update to the mobile-database. This message informs the mobile-database, about is impending COA. The new COA is registered, and a dbase-binding-acknowledgement is echoed back to the MH. The format of each entry in the mobile-database is as follows: ------------------------------------------------ |Local IP (home) | New Global IP | New Local IP | | Address | Address | Address | ------------------------------------------------ The local IP address is the pre-assigned local IP address of the MH in its private home network. Thus, if the mobile is currently within its home network, then the ôNew Global IP Addressö field contains the networkÆs global IP address after the mobile has moved to its new COA. Similar explanation is given for the ôCurrent Local IP Addressö field. At the same time as sending dbase-binding-update, the MH also sends a nat-binding-update to the NAT, where the NAT checks it binding table to determine if it has a binding with the MH. If it has a binding then the local address portion of the entry is updated, to reflect the new address of the MH. If no binding currently exists, then a new binding is created and placed in the database. The format of a binding is as follows: -------------------------------------- | Global IP Address | New Local IP | | Of NAT | Address | -------------------------------------- In the figure, the ôNew Local IP Addressö is the new local IP address of the MH. The updating of the NAT binding is necessary so that sessions coming into the private network from the outside can be routed to the correct MH. The MH then waits for nat-binding-acknowledgement to also come back, after which it moves to its new location. Thereafter, any CN that wishes to communicate with the MH has to send a mobile-location- solicitation to the mobile-database. The mobile-database may be in the current network, or in a different private network. The mobile- database searches the database to determine the current location of the MH, and sends back a mobile-location-advertisement, indicating the current location of the MN, in terms of both its global private network address and the local IP address within that network. The CN can start forwarding packets to the MN, thus bypassing the home agent altogether. Internet Draft - Expires November 2001 4 Integrating Basic NAT with Mobile IP May 2001 If the MH is receiving traffic from a source, it has to notify the source of its intended move, so that it can redirect its flow to the new COA. To accomplish this, the MH sends both its new global IP address and its local IP address to the sender using the move-new- location message. The source responds back with move-new- acknowledgement message and redirects its flow. Some buffering has to be provided so that no packets ôin flightö are lost while the MH is performing the handover. This is an important subject matter, but lies outside the scope of this draft. 4. Mobility Management Across Multiple Private Networks A MH may leave its ôprivate home networkö and enter a different private network, called a ôprivate foreign networkö. If this occurs, the MH sends a registration message, called mobile-registration. This message indicates the MHÆs ôhome networkö global address, its local (assigned) address in its home network, the MHÆs foreign network global address, its local address in its foreign network. Thus, these four elements make up the registration message. The MHÆs private network NAT-router intercepts this message, and updates its mobile-database to reflect the new global and local address of the MH in the foreign network. In addition to this task, the foreign NAT must also form a binding for the MH based on the current local address of the MH in the foreign network. This binding is entered into the table described previously. These steps are also suffice when the MH moves from a ôprivate foreign networkö back into its ôprivate home networkö. Next, letÆs consider how packets are sent from the CN to the MH. Before a packet can be sent, an enquiry is made to the MHÆs home network, to be ascertain of its current location. For this, a mobile-solicitation message is sent to the mobileÆs private home network containing the local IP address of the MH in its home network. The NAT-router performs a look-up into its table using the IP address as an index and responds back with a mobile-advertisement message, specifying the current location of the MH, in terms of its current network IP address and its current local IP address. Thereafter, when CN sends a packet to the MH, it inserts this current global network IP address into the destination field. It inserts its own networkÆs global address into the source field. Next, we consider a situation where the MH moves to a different private network while it was still receiving traffic from a CN. Thus, in order for the operation to be seamless, in addition to complying with all the protocol steps described above, it must notify the source of the flow, and receive acknowledgement back from the source, before it moves to its new location. It sends the message move-location message to the source, indicating the global IP address of its new private network and its local IP address within that network. This will subsequently allow the CN to redirect its flow to the new location. If the MH is in a foreign network, this message is also sent to the MHÆs home network in order to update its mobile-database. A nat-binding-update is also sent to the Internet Draft - Expires November 2001 5 Integrating Basic NAT with Mobile IP May 2001 NAT, in order to update the current binding. In both cases, the MH must wait to receive back a move-location-acknowledgement and nat- binding-acknowledgement, before it can move to its new location. 5. References [1] T. Hain,öArchitectural Implications of NATö, RFC 2993. [2] P. Srisuresh and M. Holdrege,öIP Network Address Translator (NAT) Terminology and Consideratonsö, RFC 2663. [3] Y. Rekhter et. al.,öAddress Allocation for Private Internetsö, RFC 1918. Sharif M. Shahrier InterDigital 781 Third Ave. Phone: 1-610-337-4343 King of Prussia, PA. USA Email: sharif.shahrier@interdigital.com Internet Draft - Expires November 2001 6