Mobile IP Working Group S.Mizuno INTERNET DRAFT H.Ohnishi Expires: April 2002 Y.Takagi NTT Corporation October 2002 Mobile IP Border Gateway (MBG) Status of This Memo This document is a submission by the mobile-ip Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the MOBILE-IP@STANDARDS.NORTELNETWORKS.COM mailing list. Distribution of this memo is unlimited. 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. Abstract This draft introduces the use of Mobile IP border gateways (MBGs) to optimize the Mobile IP packet routing from a correspondent node (CN) to a mobile node (MN) without adding more functions to the CNs. 1. Introduction The current Mobile IP specification [MIPv4][MIPv6] forces all packets forwarded to a mobile node (MN) to be routed via that MN's Home Agent (HA), which often leads to triangular routing, which in turn causes data transmission delay and wastes network resources. Internet-draft "Route optimization in Mobile IP"[OPTM] and "Mobility Support in IPv6"[MIPv6] shows a solution that can optimize the route length, but mizuno, et al. [Page 1] Internet Draft MBG (Mobile IP Border Gateway) October 2002 this solution requires the implementation of additional functions to CNs, e.g. managing the binding cache (and IP encapsulation only in [MIPv4]), on all CNs, such as thousands of WWW servers in the Internet, so it is not easy to achieve route optimization by these methods. If route optimization is to be achieved between CNs and MNs, the above methods are necessary. But ISPs that are going to provide Mobile IP service may want to optimize routes only inside the networks in order to provide the service without the need to alter and maintain CN software. This approach will significantly reduce the administrative costs of deploying route optimization. In that case, it can be achieved by network elements possessed by ISPs. This draft introduces the use of Mobile IP border gateways (MBGs) that are under ISP's control and can provide route optimization without adding more functions to CNs. MBGs are border gateways that have functions of Mobile IP. MBGs can maintain the MN's care-of address on behalf of CNs and create the binding cache. As the MBG maintains the binding cache, successive packets destined to a MN are forwarded directly to the MN's care-of address. This MBG method has the following features. - does not necessitate all nodes to implement these functions Usually IP networks have few border gateway routers, so the number of MBGs that need to have these specific functions can be limited. In addition, most MNs communicate with WWW servers in other networks more frequently, so it is very effective to optimize the downstream packets arriving from the other networks. - uses same messages specified in "Route optimization in Mobile IP"[OPTM] or "Mobility Support in IPv6" [MIPv6] This method does not need to define other messages. - can optimize the route in the network surrounded by MBGs regardless of CN's functionality MBG method has two modes. One is Encapsulation Mode, the other is Translation Mode. Encapsulation Mode operation is described in Chapter 3, and Translation Mode operation is described in Chapter 4. 2. Overview MBG is located between an IP network and a Mobile IP network (see Figure 1). It can be considered that the following four patterns are mizuno, et al. [Page 2] Internet Draft MBG (Mobile IP Border Gateway) October 2002 the forms of connection between Mobile IP network and IP network. 1) Mobile IPv4 network - IPv4 network 2) Mobile IPv4 network - IPv6 network 3) Mobile IPv6 network - IPv4 network 4) Mobile IPv6 network - IPv6 network Encapsulation Mode, described in Chapter 3, is proposed to apply in the pattern 1), and a few modifications enable Encapsulation Mode to be applied in the pattern 4), as described in Section 3.8. When MBG is located at the border of different IP version network, it is more efficient to use Translation Mode described in Chapter 4, because route optimization can be achieved without adding more functions to HAs. When MBG receives the packets from the other IP network, it searches for the destination IP address associated with registered IP addresses of MNs. If the destination IP address does not match any registered MN's IP address, MBG forwards the packet as ordinary IP routing. If the destination address matches the registered MN's IP address, MBG searches for this MN's binding cache. If a binding cache is not found, MBG gets the MN's care-of address as follows; - In Encapsulation Mode, MBG sends a Binding Request message to HA. If HA decides to teach care-of address of MN, it sends the Binding Update message to MBG. - In Translation Mode, MBG sends packets to the MN's home address. If the MN decides to teach its care-of address, it sends the Binding Update message to MBG after Return Routability Procedure is succeeded. After getting MN's care-of address, MBG transfers successive packets directly to the MN's care-of address. mizuno, et al. [Page 3] Internet Draft MBG (Mobile IP Border Gateway) October 2002 +----+ | CN | +----+ / | ... ... ... | +----------------+ | IP network | +----------------+ / | ... ... ... | +========+ || MBG || +========+ / | +-----+ +-----+ | HA2 | | HA1 | +-----+ +-----+ | | | +-----+ | FA | +-----+ | | | +-----+ ... | MN | +-----+ Figure 1: Domain with a MBG 3. Encapsulation Mode 3.1 Scope of solution This method can be applied to an ISP network that can achieve route optimization in itself. MBGs can achieve route optimization for MNs that are previously registered to MBGs. MBGs are located at border between an ISP and other IP networks and possessed by the ISP. The ISP must recognize MBGs and HAs that will provide functions of route optimization for MNs. In this mode, MBG interacts with HA to get MN's care-of address, so MBGs and HAs must know of each other. How to establish security association between MBGs and HAs depends on the location of HAs, - HAs located inside the ISPs ISPs are acting as home networks for users. MBGs and HAs are possessed by these same ISPs. ISPs establish security associations mizuno, et al. [Page 4] Internet Draft MBG (Mobile IP Border Gateway) October 2002 between MBGs and HAs. MBGs have information about HA addresses associated with specific prefix range of MN's address. - HAs located in intranets which directly connected to the ISPs Intranets are acting as home networks for users. HAs may be possessed by users or ISPs. If HAs are provided by users, HAs must be registered to ISPs for route optimization. ISPs establish security associations between MBGs and HAs. MBGs have information about HA addresses associated with specific prefix range of MN's address. - HAs located in other networks If there are any agreements between different IP networks, MBGs can have security associations with HAs in other IP networks. To achieve route optimization for MNs that are not pre-configured to MBGs, e.g. HAs in SOHO, a way described in "Intercepting Location Updates"[INTERCEPT] can be applied. In this case, HAs must support sending binding message with Router Alert Option and MBGs must support intercepting binding message with Router Alert Option. This is an engineering choice whether to support this method or not. 3.2 Terminology Binding Request message receiving list A list of MBG addresses, maintained by HA to keep MBGs that sent Binding Request messages to HA. The list contains MBG addresses, MN's addresses and associated lifetimes. Binding Request message sending list A list maintained by MBG to keep HA addresses to which the MBG sent Binding Request messages. The list contains HA addresses, MN addresses and associated lifetimes. Binding Update message sending list A list maintained by HA to keep MBG addresses to which HA sends Binding Update messages. The list contains MBG addresses, MN's addresses, associated lifetimes and flags to confirm the acknowledgements from MBGs. 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 [RFC 2119]. mizuno, et al. [Page 5] Internet Draft MBG (Mobile IP Border Gateway) October 2002 3.3. Message format "Route optimization in Mobile IP"[OPTM] defines four message types used for management of binding cache entries. This draft uses same messages for management of binding cache entries for MBG. 16 Binding Warning message 17 Binding Request message 18 Binding Update message 19 Binding Acknowledge message 3.3.1 Binding Warning message Binding Warning message is used for the same purpose specified in "Route optimization in Mobile IP"[OPTM]. After receiving Binding Warning message, HA send Binding Update message to Target Node. 3.3.2 Binding Request message Binding Request message is used for MBG to request a MN's current mobility binding associated with the MN's HA. 3.3.3 Binding Update message This message is used for HA to notify MBG of MN' current mobility binding. After HA makes a judgment to notify MBG of a mobility binding, this message is sent to the corresponding MBG in reference to Binding Request message receiving list. HA keeps the MBG addresses in Binding Update message sending list. Upon receiving the registration request whose care-of address is different from the one in the binding list that has already exist, if the Binding Update message sending list for the MN exists and flag is set, HA sends the Binding Update message to the MBG to support the movement of MN. 3.3.4 Binding Acknowledge message When an MBG receives a Binding Update message from HA, this message is sent to the HA by the MBG for confirmation. 3.4 MBG Route Optimization Authentication Extension The MBG Route Optimization Authentication extension is used to authenticate Route Optimization management messages sent with an SPI mizuno, et al. [Page 6] Internet Draft MBG (Mobile IP Border Gateway) October 2002 corresponding to the source IP address of the message. This extension is subtype TBD of the Generalized Authentication Extension [CHA/RES]. The authenticator value is computed, as before, from the stream of bytes including the shared secret, the UDP payload (that is, the Route Optimization management message), all prior extensions in their entirety, and the type, subtype, length, and SPI of this extension, but not including the authenticator field itself nor the UDP header. This extension is required to be used in any Binding Update message sent by the HA. 3.5 Miscellaneous Home Agent Operations 3.5.1 HA configuration HA shares keys with MBGs that have information about the HA address associated with specific prefix range of MN's address. 3.5.2 Receiving Binding Request messages If MNs are in the home network, HA does not send the Binding Update message to MBG. If MNs are not in the home network, HA send the Binding Update message to MBG according to the condition and create Binding Update message sending list. In order to know which MBGs correctly received the Binding Updates, HA SHOULD set the 'A' bit in the Binding Update, requesting an acknowledgement. Upon receiving the Binding Acknowledge from the MBG, HA sets the flag in the Binding Update message sending list. The examples of conditions are as follows. - The number of received packets in a fixed period - Sort of application - User profile 1) Route optimization judged by number of packets in a fixed period HA sends the Binding Update message to MBG when the number of packets exceeded threshold in fixed period. 2) Route optimization judged by application types The HA sends Binding Update message to the MBG only for the application which is supposed to use large traffic, such as FTP. 3) Route optimization judged by user profile types Users which route optimization are applied to, in addition to "P" mizuno, et al. [Page 7] Internet Draft MBG (Mobile IP Border Gateway) October 2002 bit which is established at the time of registration, can be previously set up at network side. It is possible to apply route optimization only for those users above. These judgments can be combined. It is also possible to perform route optimization only for the connection that exceeds a threshold out of the permitted users. 3.5.3 Receiving the registration in route optimization Upon receiving the registration request whose care-of address is different from the one in the binding list that has already exist, if the Binding Update message sending list for the MN exists and flag is set, the HA sends the Binding Update message to the MBG to support the movement of MN. 3.5.4 Receiving Binding Warning messages Receiving a Binding Warning message, HA send Binding Update messages to Target Node. 3.5.5 Receiving Binding Acknowledge messages Receiving a Binding Acknowledge message, HA set the flag in the Binding Update message sending list. 3.5.6 Sending update messages with the Router Alert Option To achieve route optimization for MNs that are not pre-configured to MBGs, a way described in "Intercepting Location Updates"[INTERCEPT] can be applied. In this case, HAs must send update message with the Router Alert Option. This is an engineering choice whether to support this method or not. 3.6 Miscellaneous MBG Operations 3.6.1 MBG configuration MBG is configured with IP addresses of HAs to recognize HAs that MBGs send the Binding Request messages. And MBG is also configured with IP addresses of MNs that belong to the HAs to find packets that are destined to MNs. HAs that MBG have information about are as follows, - HAs located inside the ISPs ISPs are acting as home networks for users. MBGs and HAs are possessed by these same ISPs. ISPs establish security associations between MBGs and HAs. MBGs have information about HA addresses mizuno, et al. [Page 8] Internet Draft MBG (Mobile IP Border Gateway) October 2002 associated with specific prefix range of MN's address. - HAs located in intranets which directly connected to the ISPs Intranets are acting as home networks for users. HAs may be possessed by users or ISPs. If HAs are provided by users, the HAs must be registered to ISPs for route optimization. ISPs establish security associations between MBGs and HAs. MBGs have information about HA addresses associated with specific prefix range of MN's address. - HAs located in other networks If there are any agreements between different IP networks, MBGs can have security associations with HAs in other IP networks. To achieve route optimization for MNs that are not pre-configured to MBGs, e.g. HAs in SOHO, a way described in "Intercepting Location Updates"[INTERCEPT] can be applied. In this case, HAs must support sending binding message with Router Alert Option and MBGs must support intercepting binding message with Router Alert Option. This is an engineering choice whether to support this method or not. 3.6.2 Receiving packets MBG searches for destination IP address associated with the registered IP addresses of MNs. If the destination address does not match any registered MN's IP address, MBG forward the packet as ordinary IP routing. If the destination address matches the registered MN's IP addresses, MBG searches for appropriate binding cache. If binding cache is found, MBG forward to the care-of address for the MN. If binding cache is not found, the procedure of 9.3 will be applied. 3.6.3 Sending Binding Request messages to HA MBG sends a Binding Request message to the HA and keeps the HA address, MN's address in Binding Request message sending list. Each Binding Request message sending list has an associated lifetime. Before the expiration of this time period, the MBG does not send the Binding Request message for the MN. After the expiration of this time period, MBG sends Binding Request message when MBG receives packets to the MN. 3.6.4 Binding Update message received from HA Upon receiving Binding Update from HA, the following procedures shall apply. mizuno, et al. [Page 9] Internet Draft MBG (Mobile IP Border Gateway) October 2002 1) The lifetime is not 0: In the absence of any binding cache entry, the MBG creates a binding cache entry. In the presence of binding cache entry, the MBG updates a binding cache without updating the lifetime in the binding cache. After receiving the Binding Update, the MBG sends the Binding Acknowledgement to the HA. 2) The lifetime is 0: The MBG deletes the binding cache. 3.6.5 Managing the binding list MBG maintains the binding list for lifetime. After the lifetime expired, the binding cache is deleted and packets destined to the MN is forwarded through the HA. Upon receiving the next Binding Update, MBG creates the binding cache and forward the packets for the MN directly to the MN's care-of address. MBGs, a way described in "Intercepting Location Updates"[INTERCEPT] is 3.6.6 Intercepting update message with the Router Alert Option To achieve route optimization for MNs that are not pre-configured to applied. In this case, MBG must intercept update message with the Router Alert Option like Correspondent Agent described in "Intercepting Location Updates"[INTERCEPT]. This is an engineering choice whether to support this function or not. 3.7 Using MBG together with "Route optimization in Mobile IP"[OPTM] This section shows route optimization using this draft together with "Route optimization in Mobile IP" [OPTM]. MBG method can be used with the "Route optimization in Mobile IP" [OPTM]. MNs do not need to have more functions for this method. 3.7.1 Communication between terminals in the Mobile IP network If both terminals have Mobile IP functions, "Route optimization in Mobile IP"[OPTM] method is applied. 3.7.2 Communication between terminals in the different IP networks If HA sends a Binding Update message immediately after receiving the packet to an MN without receiving Binding Request message from MBG, the HA sends the Binding Update message to a CN. In this case, mizuno, et al. [Page 10] Internet Draft MBG (Mobile IP Border Gateway) October 2002 "Route optimization in Mobile IP"[OPTM] is applied if the CN has Mobile IP functions. If the CN does not have Mobile IP functions, route optimization is achieved by MBG. 3.8 IPv6 Consideration MBGv6 also achieves route optimization without adding more functions to CNs. The procedure of MBGv6 is as same as that of MBGv4. This draft can be applied to the MBGv6 with some modifications as follows: -Binding Error massage is used in Mobile IPv6 [MIPv6] as Binding Warning message in MIPv4. -Binding Refresh Request massage is used in Mobile IPv6 as Binding Request message in MIPv4. -Binding Update massage is used in Mobile IPv6 as Binding Update message in MIPv4. -Binding Acknowledge massage is used in Mobile IPv6 as Binding Acknowledge message in MIPv4. Although MN may send Binding Update option to MBGv6 because Binding Update option is always sent by MN, we propose that HA should send Binding Update option to MBGv6. Because it is not desirable that MN should identify MBG. The MBGv6 cannot use a Routing header to forward these intercepted packets to the MN, since it cannot modify the packet in flight without invalidating any existing IPv6 AH [AH] or ESP [ESP] header present in the packet. 4. Translation Mode 4.1 Scope of solution In the early stage of Mobile IPv6, it is also necessary to take communication between MNs in Mobile IPv6 network with CNs in IPv4 network into consideration. In that case, it is effective that using this mode of MBG which uses address translation mechanisms, such as NAT-PT[NAT-PT] and DNS-ALG [DNS-ALG]. This method can optimize the route in Mobile IPv6 network without adding more functions to the existing specification of HAs, MNs (described in [MIPv6]), and existing IPv4 nodes. 4.2 Terminology Address Biding Cache mizuno, et al. [Page 11] Internet Draft MBG (Mobile IP Border Gateway) October 2002 A list of MN's home addresses and CN's addresses with appropriate lifetime. In this list, MN's home address is associated with IPv4 address which is assigned by MBG, and CN's address is associated with IPv6 address which is consisted IPv4 address and MBG's translation prefix. MBG maintains this list to translate address in DNS Reply messages, destination address and source address in IP packets. 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 [RFC 2119]. 4.3 Message format There is no change of the message format by this mode in Mobile IPv6 and IPv4 specification. 4.4 Miscellaneous MBG Operations 4.4.1 MBG configuration MBG, operated in Translation Mode, is located at a border between a Mobile IPv6 network and an IPv4 network (see Figure 2), and has information about MN's Home Address for which MBG provides route optimization. MBG has functions as follows; -NAT-PT function -DNS-ALG function -Mobile IPv6 CN function In order to enable IPv4 nodes and MNs to communicate with each other, MBG has translation prefixes internally to assign them to IPv4 nodes, and also has IPv4 addresses internally to assign them to MNs. The relations between IPv4 addresses and IPv6 addresses are maintained in Address Binding Cache. mizuno, et al. [Page 12] Internet Draft MBG (Mobile IP Border Gateway) October 2002 +----------------------+ |+-----+ IPv4 network | || DNS | | |+-----+ | | +---------------+| | | IPv4 nodes #A || | +---------------+| +----------------------+ | +=========+ || MBG || +=========+ | +------------------------------+ | +-----+ +-----+ | | | DNS | | HA1 | | | +-----+ +-----+ | Mobile IPv6 network / | | | +-----+ +-----+ | +-----------| AR1 |--| AR2 |---+ +-----+ +-----+ | +-------+ | MN #B | +-------+ Figure 2: MBG located in border between IPv4 and Mobile IPv6 network 4.4.2 Receiving DNS request packets Upon receiving DNS request message, MBG checks its Query type. If its Query type is "A", MBG modifies it to "AAAA". If its Query type is "AAAA", MBG modifies it to "A". After modifying DNS request message, MBG relays it to the other DNS, as described in [DNS-ALG]. 4.4.3 Receiving DNS response packets If received DNS response's type is "AAAA", MBG translates its type into "A" record, and replaces the IPv6 address (i.e. MN's Home Address) resolved by the DNS in Mobile IPv6 network with the IPv4 address internally assigned by MBG. At the same time of replacement, MBG creates or updates its Translation Cache which associates MN's Home Address and internally assigned IPv4 address. mizuno, et al. [Page 13] Internet Draft MBG (Mobile IP Border Gateway) October 2002 If its type is "A", MBG translates its type into "AAAA" record, and creates IPv6 address (i.e. temporary address for IPv4 node in Mobile IPv6 network) by adding appropriate translation prefix to IPv4 address which is resolved by the DNS in IPv4 network. Then MBG replaces IPv4 address with this created IPv6 address. After modifying DNS response message, MBG relays it to the other DNS. 4.4.4 Receiving data packets from MNs Upon receiving IPv6 data packet whose destination address has translation prefix, MBG can find destination IPv4 address (i.e. IPv4 node's "real" address in IPv4 network) by removing appropriate translation prefix (e.g. upper 96 bits) from destination IPv6 address in destination address field of IPv6 header, and configures this IPv4 address for destination address field in IPv4 header. MBG also configures source address field of IPv4 header by using of binding cache and (or) Translation Cache as follows; - If IPv6 data packet includes Home Address Destination Option, giving the MN's Home Address, MBG searches for source IPv4 address associated with MN's Home Address of received packet in Translation Cache. If MBG finds it, configures this IPv4 address into source address field of IPv4 header. Otherwise, this IPv6 data packet is silently discarded. - If IPv6 data packet does not includes Home Address Destination Option, MBG searches for MN's Home Address associated with source address of received packet in binding cache entry. If MBG finds it, then, procedure described above is applied. Otherwise, this IPv6 data packet is silently discarded. Then MBG transfers this IPv4 data packet to other network. 4.4.5 Receiving data packets from IPv4 nodes When MBG receives IPv4 data packet, it translates this packet to IPv6 data packet as follows; - MBG searches for destination IPv6 address (i.e. MN's Home Address) associated with IPv4 address of received packet in Translation Cache. If MBG finds destination IPv6 address in Translation Cache, it searches for MN's Home Address in binding cache. If MBG finds it, MBG configures MN's Care-of Address for destination address field of IPv6 packet. Otherwise, MBG configures MN's Home Address for mizuno, et al. [Page 14] Internet Draft MBG (Mobile IP Border Gateway) October 2002 destination address field of IPv6 packet. In both case, source address of this packet is translated to IPv6 address by adding appropriate translation prefix to IPv4 address (i.e. IPv4 node's address). Then MBG transfers this IPv6 data packet to the other network. MN which receives data packets via HA starts Return Routability Procedure based on the specification of [MIPv6], which is destined to the address consisted of MBG's internal translation prefix and IPv4 node's address. So MBG can get the MN's care-of address on behalf of IPv4 node and create or update its binding cache. Whether MBG should provide route optimization to MNs or not is depends on the information about MNs maintained by MBG. Example of procedures described above is shown in Figure 3. These procedures can be applied communication between Mobile IPv4 network and IPv6 network. mizuno, et al. [Page 15] Internet Draft MBG (Mobile IP Border Gateway) October 2002 Mobile IPv6 network <--|--> IPv4 network | MN HA DNS MBG DNS IPv4 node | | | | | | | | | | | DNS req. | | | | |<----------|<----------| | | | DNS req. * | | | | |<----------| | | | | | | | | | | | DNS rep. | | | | | |---------->| | | | | *, | | | | ** DNS rep.| | | | |---------->|---------->| | | | | | | | IPv4 data packets | | | |<----------------------| | | IPv6 data packets ** | |<==========|<----------------------| | | | | | | | RR Procedure | | |<~~~~~~~~~~|~~~~~~~~~~~~~~~~~~~~~~>| | | | BU | | |-----------|---------------------->| | | | BA | | |<----------|-----------------------| | | IPv6 data packets | | |---------------------------------->| | | ** IPv4 data packets | | |---------------------->| | | | * : DNS records translation ** : Address translation Figure 3 : MBG procedure (Communication started by MNs) 5. Security Consideration The calculation of the authentication data supplied with the Route Optimization messages is specified to be the same as in the base Mobile IP document for ease of implementation. There is a better method available (HMAC), specified in RFC 2104 [HMAC]. If the base Mobile IP specification is updated to use HMAC, then this specification SHOULD also be updated similarly. mizuno, et al. [Page 16] Internet Draft MBG (Mobile IP Border Gateway) October 2002 References [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [MIPv4] C. Perkins, Editor. IP Mobility Support for IPv4. RFC 3220, January 2002. [OPTM] Charles Perkins and David B. Johnson. Route Optimization in Mobile IP. draft-ietf-mobileip-optim-10.txt, November 2000. [INTERCEPT] C-Y Lee, G. Morrow and F. Kadri, Intercepting Location Updates. draft-lmk-mobileip-intercepting-update-01.txt, November 2000 [CHA/RES] P. Calhoun and C. E. Perkins. Mobile IPv4 Challenge/Response Extensions. November, May 2002. [MIPv6] D. Johnson, C. Perkins and Jari Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, June 2002. [AH] Stephen Kent and Randall Atkinson. IP Authentication Header. RFC 2402, November 1998. [ESP] Stephen Kent and Randall Atkinson. IP Encapsulating Security Payload (ESP). RFC 2406, November 1998. [HMAC] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. [NAT-PT] G. Tsirtsis, P. Srisuresh. Network Address Translation - Protocol Translation (NAT-PT). RFC 2766, February 2000 [DNS-ALG] P.Srisuresh, G.Tsirtsis, P.Akkiraju and A.Heffernan, "DNS extensions to Network Address Translators (DNS_ALG)", RFC 2694, September 1999. mizuno, et al. [Page 17] Internet Draft MBG (Mobile IP Border Gateway) October 2002 Author's Address Shiro Mizuno NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6965 EMail: mizuno.shiro@lab.ntt.co.jp Hiroyuki Ohnishi NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 4132 EMail: ohnishi.hiroyuki@lab.ntt.co.jp Yasushi Takagi NTT Network Systems Laboratories, NTT Corporation 9-11, Midori-Cho 3-Chome Musashino-Shi, Tokyo 180-8585 Japan Phone: +81 422 59 6059 EMail: takagi.yasushi@lab.ntt.co.jp mizuno, et al. [Page 18]