Mobile IP Working Group H. Ohnishi INTERNET DRAFT K. Suzuki Expires: December 2002 Y. Takagi NTT Corporation June 2002 Mobile IPv6 VPN using Gateway Home Agent 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 Mobile IPv6 [Mobile IPv6] provides mobility functions for IPv6. It can also be used for public mobility services. One of the most important services is the VPN service enabling users to access their Intranets from outside. Mobile IP does notwork well with VPN, however, and this issue is being discussed in the Mobile IP WG [VPN problem]. This document proposes a simple mechanism that combines VPN and Mobile IP functions. This mechanism uses a hierarchical HA architecture and includes an HA with GW functions, called a Gateway Home Agent (GHA). 1. Introduction Ohnishi, et al. [Page 1] Internet Draft Mobile IPv6 VPN July 2002 Wireless broadband services, e.g., high-speed mobile communication service (3rd-generation mobile phone service) and Hotspot service using wireless LANs, are regarded as important access technologies for providing ubiquitous service, enabling users to communicate anytime, anywhere, and with anybody. Among these technologies, Mobile IP has been specified as a method that supports mobility between sub-networks using wireless LANs and between 3G mobile networks and wireless LANs. Many wireless services now use IPv4. But many devices are being assigned IP addresses and it follows that the associated services will have to use IPv6. Mobile IPv6[Mobile IPv6] provides mobility functions in IPv6, enabling the large IPv6 address space to be used for public mobility services. One of the most important mobility services is VPN service, in which users can access their Intranets from outside. Mobile IP does not work well with VPN, however, and this issue is being discussed in the Mobile IP WG [VPN problem]. This document proposes a simple mechanism that combines VPN and Mobile IP functions. To support this approach, a hierarchical HA architecture is used. The VPN problem document [VPN problem] refers to renegotiation of the IPsec problem. To avoid renegotiation, a VPN GW has to use a Mobile Node's (MN) Home Address (HoA) instead of its Care-of address (CoA) for IPsec's endpoint. This requires the VPN GW to have Mobile IP functions, because it has to understand the HoA option. A VPN GW with Mobile IP CN functions can set up IP sec with an MN's HoA, but the MN has to send two Binding Updates, one for the VPN GW and the other for the HA. The proposed mechanism, on the other hand, can create updates in a single registration. The mechanism uses hierarchical HA architecture, and includes an HA with GW functions, called a Gateway Home Agent(GHA). The relationship between a GHA and an HA is almost the same as that between an FA and an HA in Mobile IPv4 [Mobile IPv4]. A Binding Update from an MN is first authenticated by the GHA. Then, only if the authentication is successful, the Binding Update is forwarded to the HA. Upon receiving the Binding Update, the HA authenticates it and sends a Binding Acknowledgment. The GHA then creates a Binding Cache entry and forwards a Binding Acknowledgment to the MN. The GHA uses this Binding Cache entry to configure an IPsec tunnel with the HoA from the MN to itself. The GHA and MN thus do not need to renegotiate for IPsec even if the MN changes its CoA. 2. Terminology Ohnishi, et al. [Page 2] Internet Draft Mobile IPv6 VPN July 2002 Gateway Home Agent(GHA): A VPN GW that has Mobile IP HA functions and can authenticate Mobile IP messages and forward packets by using an inter-work mechanism. A GHA also has a translation function to support IPv4 Intranets. 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. 3. Protocol overview A GHA can be deployed in one of two scenarios. In one, the GHA is used as a VPN GW in the Intranet. In the other, the GHA is deployed in a public network and supports more that two different Intranets. The following sections describe the basic procedures in these scenarios. 3.1. GHA as Intranet GW The GHA supports both IPv6 and IPv4 Intranets. The following sections provide overviews of the Intranet deployment scenario for each IP version. 3.1.1. v6 Intranet support The MN moves from a Intranet to a public network and it sends a Binding Update that includes CoA assigned by public network to the GHA, which authenticates the Binding Update message. If the message is accepted, the GHA sends the Binding Update to the HAv6. The Binding Update includes the GHA v6 address as the MN's CoA. The HAv6 creates a Binding Cache entry and sends a Binding Acknowledgement to the GHA. Upon receiving the Binding Acknowledgement, the GHA creates a Binding Cache entry and sends a Binding Acknowledgement to the MN. This procedure thus creates Binding Cache entries not only in the HA but also in the GHA. This enables the GHA to identify the IPsec packet with the HoA option from the MN and also to forward the IPsec tunnel to the MN's CoA without renegotiating it. The security association between the MN and the GHA is manually or dynamically configured. Ohnishi, et al. [Page 3] Internet Draft Mobile IPv6 VPN July 2002 MN GHA HAv6 | SA between MN and GHA | | |<----------------------->| | | | | | Binding Update | | |------------------------>| Binding Update | | |-------------------------->| | | | | | | | | Binding Acknowledgement | | Binding Acknowledgement |<--------------------------| |<------------------------| | | | | Figure 1: Registration procedure If a Binding Cache entry for the MN already exists, the GHA just updates the entry and sends a Binding Acknowledgement to the MN. The GHA also maintains the lifetime of the Binding Cache entry maintained by the HAv6 and periodically sends Binding Update to update the lifetime, so that it does not expire while the GHA is serving the MN. MN GHA HAv6 | | | | Binding Update | | |------------------------>| | | | | | | | | | | | | | | Binding Acknowledgement | | |<------------------------| | | | | Figure 2: Procedure for successive registrations Ohnishi, et al. [Page 4] Internet Draft Mobile IPv6 VPN July 2002 MN GHA HAv6 | | | | | | | | Binding Update | | |-------------------------->| | | | | | | | | Binding Acknowledgement | | |<--------------------------| | | | | | | Figure 3: Refreshing the Binding Cache entry in the HAv6 Figure 4 illustrates the packet forwarding procedure. The MN uses a reverse tunnel with IPsec to forwards packets to the Intranet. Upon receiving the packets, the GHA validates them and forwards them to the HAv6. The IPsec tunnel is used between the MN and GHA. MN GHA HAv6 | | | | IPv6 over IPv6(IPsec) | | |------------------------>| IPv6 over IPv6 | | |-------------------------->| | | | | | | | | IPv6 over IPv6 | | IPv6 over IPv6(IPsec) |<--------------------------| |<------------------------| | Figure 4: Packet forwarding 3.1.2. v4 Intranet support This scenario assumes that the MN supports a Mobile IPv4/Mobile IPv6 dual stack. The MN sends a Mobile IPv6 message to the GHA to create an IPv6 tunnel. The MN uses this tunnel to forward IPv4 packets over the IPv6 network. The GHA then sends a Mobile IPv4 message to the MN through the IPv6 tunnel. The GHA provides FAv4 functions to the HA in the Intranet. The MN uses reverse tunnel direct delivery mode by employing the IPv4 over IPv6 tunnel to the GHA. The security association between the MN and the GHA is manually or dynamically configured. Ohnishi, et al. [Page 5] Internet Draft Mobile IPv6 VPN July 2002 MN GHA HAv4 | | | | SA between MN and GHA | | |<----------------------->| | | | | | Binding Update | | |------------------------>| | | | | | Binding Acknowledgement | | |<------------------------| | | | | | Agent Advertisement | | |<------------------------| | | | | |Reg.Req. over IPv6(IPsec)| | |------------------------>| Reg. Request | | |-------------------------->| | | | | | | | | Reg. Reply | |Reg.Rep over IPv6(IPsec) |<--------------------------| |<------------------------| | Figure 5: Registration procedures MN GHA HAv4 | | | | IPv4 over IPv6(IPsec) | | |------------------------>| IPv4 over IPv4 | | |-------------------------->| | | | | | | | | IPv4 over IPv4 | | IPv4 over IPv6(IPsec) |<--------------------------| |<------------------------| | Figure 6: Packet forwarding 3.2. GHA as public node In the Intranet deployment scenario, users have to deploy the GHA as their GW. In this scenario, users only deploy the VPN GW in their network. 3.2.1. v6 Intranet support The GHA supports more than two Intranets and sets up an IPsec tunnel between itself and the VPN GW for each Intranet. The IPsec tunnels Ohnishi, et al. [Page 6] Internet Draft Mobile IPv6 VPN July 2002 are set up manually or dynamically. The basic mechanism is the same as for the Intranet GW scenarios. If the GHA supports more than two networks using the same IP address space, it has to use another identifier, e.g. the network address identifier (NAI), to identify the MN's Intranet and HA. The security association between the MN and the GHA is manually or dynamically configured. MN GHA VPN GW HAv6 | | | | | SA between MN and GHA | | | |<--------------------->| | | | | | | | |/////IPsec tunnel///// | | | Binding Update | | | |---------------------->| Binding Update | | | |--------------------------------------->| | | | | | | Binding Ack. | | | |<---------------------------------------| | Binding Ack. | | | |<----------------------|/////IPsec tunnel///// | | | | | | Figure 7: Registration procedures MN GHA VPN GW HAv6 | | | | | |/////IPsec tunnel///// | | | IPv6 in IPv6 (IPsec) | | | |---------------------->| IPv6 in IPv6 | | | |--------------------------------------->| | | | | | | IPv6 in IPv6 | | | |<---------------------------------------| | IPv6 in IPv6 (IPsec) | | | |<----------------------|/////IPsec tunnel///// | | | | | | Figure 8: Packet forwarding 3.2.2. v4 Intranet support The GHA authenticates Mobile IPv4 and Mobile IPv6 messages. It can not identify the MN's HoA if more than two Intranets use private addresses, so it has to identify the MN by using its HoA and IPv6 CoA assigned by visited IPv6 network. The security association between the MN and the GHA is manually or dynamically configured. Ohnishi, et al. [Page 7] Internet Draft Mobile IPv6 VPN July 2002 MN GHA VPN GW HAv4 | | | | | SA between MN and GHA | | | |<--------------------->| | | | | | | | Bidning Update | | | |---------------------->| | | | | | | | Binding Ack. | | | |<----------------------| | | | | | | | Agent Advertisement | | | |<----------------------| | | | | | | |Reg.Req./IPv6(IPsec) |/////IPsec tunnel///// | | |---------------------->| | | | | Reg. Request | | | |--------------------------------------->| | | | | | | Reg. Reply | | | |<---------------------------------------| |Reg.Rep./IPv6(IPsec) | | | |<----------------------|/////IPsec tunnel///// | | | | | | Figure 9: Registration procedures MN GHA VPN GW HAv4 | | | | | |/////IPsec tunnel///// | | | IPv4 in IPv6 (IPsec) | | | |---------------------->| IPv4 in IPv4 | | | |--------------------------------------->| | | | | | | IPv4 in IPv4 | | | |<---------------------------------------| | IPv4 in IPv6 (IPsec) | | | |<----------------------|/////IPsec tunnel///// | | | | | | Figure 10: Packet forwarding 4. Miscellaneous HA operations The HA's operation is the same as that defined for Mobile IPv6 [Mobile IPv6] and Mobile IPv4 [Mobile IPv4]. Ohnishi, et al. [Page 8] Internet Draft Mobile IPv6 VPN July 2002 If MN moves from an IPv6 Intranet to an IPv6 public network, HA authenticates a Binding Update by using security association between the GHA and the HA instead of using security association between the MN and the HA. 5. Miscellaneous GHA operations 5.1. Receiving Binding Update/Registration Request from MN When a GHA receives a Binding Update, it MUST validate it and determine its type according to the steps described in Mobile IPv6 [Mobile IPv6]. The security association between the GHA and MN is configured manually or dynamically. The method of dynamic configuration is beyond the scope of this specification. The MN's HA address is also configured in the GHA. The GHA searches for the MN's HA by using the MN's HoA. If the received Binding Update has a Network Access Identifier (NAI) (the question of how to include an NAI in a Binding Update is beyond the scope of this document), the GHA identifies the MN's security association and HA address by using the HoA and NAI. GHA operation differs depending on the version of the MN's HA address. (a) MN's HA address is IPv6. If the Binding Update is an invalid message, the GHA sends back a Binding Acknowledgement message with an error code defined in Mobile IPv6 [Mobile IPv6]. If the GHA accepts the Binding Update, it MUST perform the following procedures: If no Binding Cache entry exists for the MN, the GHA creates a new pending entry and sends a Binding Update to the HA. The method of creating the Binding Cache entry is described in Mobile IPv6 [Mobile IPv6]. The security association between the GHA and HA to authenticate this message is configured manually or dynamically. The Binding Update sent to the HA is constructed as follows: -The CoA in the Binding Update is the IPv6 address of the GHA. If a Binding Cache entry exists, the GHA updates the entry and sends a Binding Acknowledgement back to the MN without sending a Binding Update message to the HA. The GHA MUST also maintain the lifetime of the MN's HA and send a Binding Update to the HA to prevent the Ohnishi, et al. [Page 9] Internet Draft Mobile IPv6 VPN July 2002 lifetime from expiring. The GHA binds this Binding Cache entry to the IPsec policy. This enables the GHA to validate successive packets sent by the MN from its new CoA, and also to forward packets protected by the IPsec to the new CoA. (b) MN's HA address is IPv4. If the Binding Update is an invalid message, the GHA sends back a Binding Acknowledgement message with an error code defined in Mobile IPv6 [Mobile IPv6]. If the GHA accepts the Binding Update, it MUST perform the following procedures: -If no Binding Cache entry exists for the MN, the GHA creates a new pending entry and sends a Binding Acknowledgement back to the MN. The method of creating the Binding Cache entry is described in Mobile IPv6 [Mobile IPv6]. -If a Binding Cache entry exists, the GHA updates the entry and sends a Binding Acknowledgement back to the MN. After sending the Binding Acknowledgement to the MN, the GHA waits for an ensuing Mobile IPv4 message from the MN. If it does not receive any Mobile IPv4 messages after a certain time, it deletes the information in the Mobile IPv6 Binding Cache entry. If the GHA receives an IPv6 packet that includes a Mobile IPv4 message (Registration Request) in its payload, the GHA validates the Registration Request message. The GHA works like an Foreign Agent(FA) in Mobile IPv4 and relays the Registration Request to the HAv4. If the GHA rejects the Registration Request, it deletes not only the Mobile IPv4 visitor list but also the Mobile IPv6 Binding Cache entry and sends Registration Reply with an appropriate error code defined in Mobile IPv4[Mobile IPv4]. The GHA binds this Binding Cache entry to the IPsec policy. This enables the GHA to validate successive packets sent by the MN from its new CoA, and also to forward packets protected by the IPsec to the new CoA. The GHA can authenticate Binding Updates/Registration Requests from the MN, so it can protect HAs located in Intranets from being attacked by malicious nodes. Ohnishi, et al. [Page 10] Internet Draft Mobile IPv6 VPN July 2002 5.2. Receiving Binding Acknowledgement or Registration Reply from HA If the GHA receives an unsuccessful Binding Acknowledgement, it deletes the Binding Cache entry for the MN and sends a Binding Acknowledgement with the appropriate error code to the MN. If the GHA receives a successful Binding Acknowledgement, it creates or updates the Binding Cache entry and sends a Binding Acknowledgement to the MN. If the GHA receives an unsuccessful Registration Reply, it deletes the visitor list and Binding Cache entry for the MN and sends a Registration Reply with the appropriate error code over IPv6. If the GHA receives a successful Registration Reply, it creates or updates the visitor list and Binding Cache entry and sends a Registration Reply to the MN by using IPv6 tunneling. 5.3. Routing consideration If the GHA receives packets other than Mobile IPv4/v6 messages, it must validate the packets' source and destination addresses. If these packets are directed to or from an MN that has not been registered with the GHA, the GHA MUST discard the packets. The GHA must also validate the IPsec tunnel by using the Binding Cache entry information. This guarantees that packets from unregistered (invalid) CoAs are discarded by the GHA. If the GHA receives valid packets from an MN, it searches for the HA address to which the MN belongs and sends the packets to the HA by using IP through an IP tunnel. The GHA identifies the HA by using the MN's HoA, which is the source address inside the packet, and the MN's CoA, which is the source address outside the packet. The GHA has to use these two IP addresses (HoA and CoA) to support more than two private networks, which can lead to HoA conflicts between MNs. If the GHA receives IPv6 over IPv6 packets, it decapsulates. the packets and forwards them to the HAv6 by using IPv6 in the IPv6 tunneling mechanism. If the GHA receives IPv4 over IPv6 packets, it decapsulates the packets and forwards them to the HAv4 by using IPv4 in the IPv6 tunneling mechanism. If the GHA receives valid packets from the HA, it sends the packets to the MN's CoA by using IP through an IP tunnel. If the GHA receives the packets from an HAv6, it decapsulates the packets and forwards them to the MN by using IPv6 in the IPv6 tunneling Ohnishi, et al. [Page 11] Internet Draft Mobile IPv6 VPN July 2002 mechanism. If the GHA receives the packets from an HAv4, it decapsulates the packets and forwards them to the MN by using IPv4 in the IPv4 tunneling mechanism. Packets sent from the GHA to an MN are protected by IPsec. IP packets in the IP tunnel between an MN and the GHA have to be protected by IPsec. The security policy between the GHA and HA depends on the user's operations. -If the users set up a VPN GW in their network, an IPsec tunnel can be set up between the GHA and the VPN tunnel manually or dynamically. -If the users have a dedicated line between their Intranet and the GHA, IPsec is not needed to apply. -If an Intranet has no VPN gateway, IPsec between the GHA and HA has to be supported. To use the route optimization mechanism in this case, the Correspondent Nodes (CNs) in the Intranet have to apply IPsec encryption to every packet, because IPsec can not be applied to the CNs' packets by other nodes. To support IPsec with mobility, the GHA and MN set up an IPsec tunnel between the MN's HoA and the GHA address. The MN has to put the HoA option outside the IP packets. This mechanism does not require IPsec renegotiation even if the MN moves and changes its CoA. The packet format between the MN's HoA and the HA is as follows. +---------------------------+ | | | Outer IP Header | +---------------------------+ | | | HoA option | +---------------------------+ | | | ESP Header | +---------------------------+ | | | Inner IP Header | +---------------------------+ | IP Payload | | | | | +---------------------------+ Figure 11: Packet format 6. Miscellaneous MN Operations Ohnishi, et al. [Page 12] Internet Draft Mobile IPv6 VPN July 2002 6.1. Discovering GHA address The GHA address is manually or dynamically configured for the MN. If the GHA is deployed as a GW in an Intranet, its address can be configured manually. If the GHA is deployed in the public network, the MN uses the DNS or Anycast address (if some Anycast address can be assigned for GHA) to find the GHA address. The MN starts using the GHA mechanism when it is notified manually by its user or automatically by a router advertisement in the public network. To support automatic detection of whether an MN belongs to an Intranet or the public network, the MN has to know which address prefixes are used in its Intranet. The MN uses the same GHA while it is attached to the public network. After being rebooted, the MN MAY use another GHA to access its Intranet. An algorithm for an assignment of GHA address to MN has some choices. The detail of the algorithm is out of scope this document, but a service provider can uses this mechanism for assigning the most nearest GHA from the MN or most low-loaded GHA in the network. To connect to an IPv4 Intranet, an MN has to know the GHA's IPv4 address. This can be obtained by receiving an Agent Advertisement from the GHA after setting up an IPv6 tunnel between the MN and the GHA. 6.2. Sending Binding Update/Registration Request to GHA An MN MUST register a new IPv6 CoA with its GHA by sending a Binding Update. The security association between the MN and the GHA is configured manually or dynamically. The Binding Update is the same as that specified in Mobile IPv6 [Mobile IPv6]. If the MN's home Intranet uses IPv4 addressing, the MN first sends a Binding Update to the GHA to set up an IPv6 tunnel. If the MN receives a successful Binding Acknowledgement from the GHA, it then waits for an Agent Advertisement. After receiving the Agent Advertisement, the MN sends a Registration Request to the GHA. In this case, the GHA is used as an FA by the MN. 6.3. Receiving Binding Acknowledgement from GHA When an MN receives a Binding Acknowledgement from the GHA, it MUST be validated. The receiving procedure is the same as that described Ohnishi, et al. [Page 13] Internet Draft Mobile IPv6 VPN July 2002 in Mobile IPv6 [Mobile IPv6]. If an IPv6 payload has a Registration Reply message, the MN also MUST validate this. This procedure is mentioned in Mobile IPv4 [Mobile IPv4]. 6.4. Routing consideration An MN MUST uses IPsec between itself and the GHA. To notify the GHA of its HoA, the MN has to put the HoA option outside the tunnel. It MUST NOT send packets by using a new CoA until it registers the CoA with the GHA. If the MN's home Intranet uses IPv6 addressing, it sends IPv6 over IPv6 packets. If an MN handles two traffic routes, one is to/from the GHA and the other is directly to/from the Internet (without passing through the GHA). The MN has to support some policies and changes the route depending on the communication environment. If an MN's home Intranet uses IPv4 addressing, it sends IPv4 over IPv6 packets. The MN uses the direct delivery mode of a reverse tunnel [Reverse tunnel]. 7. Support for Mobile IPv6 route optimization An MN can optimize routes by sending Binding Updates (the GHA address is included as a CoA). Packets can be securely delivered between the MN and CNs in the Intranet, because if the GHA is set up as a GW in the Intranet, the packets are protected by the IPsec tunnel between the MN and the GHA, while if the GHA is located in the public network, the packets are protected by IPsec between the MN and the GHA, and between the GHA and the VPN GW. If MN notifies IPv6 address assigned by a visited network as CoA, it is not guaranteed that packets from CN are forwarded through the GHA to the MN. It is difficult to protect the packets by IPsec tunnel that is set up between the MN and the GHA. It can be possible to set some policy that forces all the packets from the Intranet go through the GHA, but the policy causes high-load to the GHA. 8. Security considerations This document proposes a method for mobile nodes to register their gateway nodes in a public network. The authentication methods are those defined in Mobile IPv6 [Mobile IPv6]. Key distribution is to be performed, for instance, according to Mobile IPv6 AAA [Mobile IPv6 AAA]. Ohnishi, et al. [Page 14] Internet Draft Mobile IPv6 VPN July 2002 References [Mobile IPv4] C. Perkins, Editor. "IP Mobility Support for IPv4", RFC 3220, January 2002. [Mobile IPv6] D. Johnson and C. Perkins, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-17.txt, May 2002. [VPN problem] Stephen Kent and Randall Atkinson, "Problem Statement for Mobile IPv4 Traversal Across VPN Gateways" , draft-ietf- mobileip-vpn-problem-statement-00, March 2002. [Mobile IPv6 AAA] Stefano M. Faccin, Franck Le, Basavaraj Patil, Charles E. Perkins, Francis Dupont, Maryline Laurent-Maknavicius and Julien Bournelle, "Mobile IPv6 Authentication, Authorization, and Accounting Requirements", draft-le-aaa-mipv6-requirements-00.txt, February 2002. [Reverse tunnel] G. Montenegro, Editor, "Reverse Tunneling for Mobile IP", RFC2344, May 1998. A. Registration from MN by using MIPv4 over IPv6 tunnel In this document, we assume the GHA has both HAv6 functions and FAv4 functions to support IPv4 Intranets. From the viewpoint of implementation, this requires more investigation. The following procedures show another way to support IPv4 Intranets. In this figure, the GHA has a Mobile IP v4/v6 translation function. MN GHA HAv4 | | | | Binding Update | | |------------------------>| Registration Request | | |-------------------------->| | | | | | | | | Registration Reply | | Binding Acknowledgement |<--------------------------| |<------------------------| | | | | Figure 12: Registration procedures using Mobile IPv4 over IPv6 B. Using multiple HoAs Using the GHA architecture forces packets to pass through the GHA. To directly access CNs located in the public network, an MN MAY use more than two home addresses, including one for the IP address Ohnishi, et al. [Page 15] Internet Draft Mobile IPv6 VPN July 2002 assigned by the Intranet and another assigned by the public network. The MN uses this GHA mechanism only to access the Intranet. If it wants to access data on public web servers, it can use another IP address. C. Using GHA as a VPN gateway from IPv4 public network to IPv6 intranet The GHA mechanism can support an VPN access from an IPv4 public network to an IPv6 network. But in this case, service providers have to have enough IP addresses for the assignment of collocated-CoA for MNs. Following figures shows an overview of procedures. MN GHA VPN GW HAv6 | | | | | SA between MN and GHA | | | |<--------------------->| | | | | | | | Reg. Request | | | |---------------------->| | | | | | | | Reg. Reply | | | |<----------------------| | | | | | | | Router Advertisement | | | |<----------------------| | | | | | | | BU over IPv4(IPsec) |/////IPsec tunnel///// | | |---------------------->| | | | | Binding Update | | | |--------------------------------------->| | | | | | | Binding Ack. | | | |<---------------------------------------| | BA over IPv4(IPsec) | | | |<----------------------|/////IPsec tunnel///// | | | | | | Figure 13: Registration procedures Ohnishi, et al. [Page 16] Internet Draft Mobile IPv6 VPN July 2002 MN GHA VPN GW HAv4 | | | | | |/////IPsec tunnel///// | | | IPv6 in IPv4 (IPsec) | | | |---------------------->| IPv6 in IPv6 | | | |--------------------------------------->| | | | | | | IPv6 in IPv6 | | | |<---------------------------------------| | IPv6 in IPv4 (IPsec) | | | |<----------------------|/////IPsec tunnel///// | | | | | | Figure 14: Packet forwarding Chairs' Addresses The working group can be contacted via the current chairs: Basavaraj Patil Phil Roberts Nokia Megisto Corp. 6000 Connection Dr. Suite 120 20251 Century Blvd Irving, TX. 75039 Germantown MD 20874 USA USA Phone: +1 972-894-6709 Phone: +1 847-202-9314 Email: Basavaraj.Patil@nokia.com Email: PRoberts@MEGISTO.com Author's Address Hiroyuki Ohnishi NTT Network Systems Laboratories, NTT Corporation 9-11-3 Midori-Cho Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422-59-4132 EMail: ohnishi.hiroyuki@lab.ntt.co.jp Ohnishi, et al. [Page 17] Internet Draft Mobile IPv6 VPN July 2002 Kazuhiko Suzuki NTT Network Systems Laboratories, NTT Corporation 9-11-3 Midori-Cho Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422-59-3458 EMail: suzuki.kazuhiko@lab.ntt.co.jp Yasushi Takagi NTT Network Systems Laboratories, NTT Corporation 9-11-3 Midori-Cho Musashino-Shi, Tokyo 180-8585, Japan Phone: +81 422-59-6059 EMail: takagi.yasushi@lab.ntt.co.jp Ohnishi, et al. [Page 18]