Mobile IP Working Group H. Ohnishi INTERNET DRAFT K. Suzuki Expires: April 2002 Y. Takagi NTT Corporation October 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 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. 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 October 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 change tunneled gateway address when the MN changes its Care-of address (CoA) for IPsec's endpoint [MN-HA IPsec]. This requires the VPN GW to have Mobile IP functions, because it has to manage the Binding Cache enty. A VPN GW with Mobile IP CN functions can set up IP sec with an MN's CoA, 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 CoA 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 October 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 is 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 than 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 an 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 from the MN's CoA 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. The GHA maintains same key that is shared between MN and HA. Then it can send Binding Update to HAv6. The GHA acts like MN proxy when the MN is in the outside its Intranet. Ohnishi, et al. [Page 3] Internet Draft Mobile IPv6 VPN October 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 October 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. The GHA provides v4/v6 translation function. It receives a Binding Update from a MN and sends a Registration Request to the MN's HAv4. When the MN moves to IPv6 network, it creates it's IPv6 home address (HoA) by combining IPv6 prefix and IPv4 address. The security association between the MN and the GHA is manually or dynamically configured. Ohnishi, et al. [Page 5] Internet Draft Mobile IPv6 VPN October 2002 MN GHA HAv4 | | | | | | | Binding Update | | |------------------------>| Reg. Request | | |-------------------------->| | | | | | | | | Reg. Reply | | Binding Acknowledge |<--------------------------| |<------------------------| | Figure 5: Registration procedures MN GHA HAv4 | | | | IPv6 over IPv6(IPsec) | | |------------------------>| IPv4 over IPv4 | | |-------------------------->| | | | | | | | | IPv4 over IPv4 | | IPv6 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 are set up manually or dynamically. The basic mechanism is the same as for the Intranet GW scenarios. The security association between the MN and the GHA is manually or dynamically configured. Ohnishi, et al. [Page 6] Internet Draft Mobile IPv6 VPN October 2002 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 IPv6 messages. GHA identifies MN's home network by using MN's HoA prefix or NAI in the Binding Update message. In the case that GHA identifies MN's Intranet by using MN's HoA prefix, MN creates it's IPv6 HoA by combining IPv6 prefix and IPv4 HoA. The IPv6 prefix is assigned by a service provider for each Intranet. So the GHA can recognize which Intranet the MN is belonging to. In the case that GHA identifies MN's Intranet by using NAI, MN has to include its NAI in the Binding Update (how to include is FFS). The relationship between MN's HoA and HA is configured in GHA, and upon receiving the Binding Update the GHA translates it to Mobile IPv4 Registration Request message. After receiving the Ohnishi, et al. [Page 7] Internet Draft Mobile IPv6 VPN October 2002 Registration Reply from HAv4, the GHA translates it to Binding Acknowledgement to the MN. The GHA maintains same key that is shared between MN and HA. GHA acts like MN proxy when MN is in the outside its Intranet. The security association between the MN and the GHA is manually or dynamically configured. MN GHA VPN GW HAv4 | | | | | SA between MN and GHA | | | |<--------------------->| | | | | | | | | | | | Binding Update |/////IPsec tunnel///// | | |---------------------->| | | | | Reg. Request | | | |--------------------------------------->| | | | | | | Reg. Reply | | | |<---------------------------------------| | Binding Ack. | | | |<----------------------|/////IPsec tunnel///// | | | | | | Figure 9: Registration procedures MN GHA VPN GW HAv4 | | | | | |/////IPsec tunnel///// | | | IPv6 in IPv6 (IPsec) | | | |---------------------->| IPv4 in IPv4 | | | |--------------------------------------->| | | | | | | IPv4 in IPv4 | | | |<---------------------------------------| | IPv6 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]. If MN moves from an IPv6 Intranet to an IPv6 public network, HA authenticates a Binding Update by using security association between Ohnishi, et al. [Page 8] Internet Draft Mobile IPv6 VPN October 2002 the GHA and the HA instead of using security association between the MN and the HA. The key between MN and HA are also possessed by GHA. Then the message from the GHA is identified by the HA as if it comes from the MN. 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 address by using the MN's HoA. If the received Binding Update has a Network Access Identifier (NAI) (how to include an NAI in a Binding Update is FFS), 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 Intranet is IPv6 network. 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 same as that between the MN and HA. 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 lifetime from expiring. Ohnishi, et al. [Page 9] Internet Draft Mobile IPv6 VPN October 2002 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 Intranet is IPv4 network. 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 Registration Request to the HAv4. The HAv4 address is configured in the GHA. The GHA translates the Mobile IPv6 Binding Update to Mobile IPv4 Registration Request. The method of creating the Binding Cache entry is described in Mobile IPv6 [Mobile IPv6] . This Binding Cache entry is a little bit different from the other Binding Cache entries. The Binding Cache entry binds MN's HoAv4, CoAv4, HoAv6 and v6 CoAv6. The security association between the GHA and HA to authenticate this message is same as that between the MN and HA. The Binding Update sent to the HA is constructed as follows: -The CoA in the Binding Update is the IPv4 address of the GHA. The GHAv4 address can be assigned different IPv4 address for each Intranet. This assignment enables GHA to identify the Intranet from which packets come from. -If a Binding Cache entry exists, the GHA updates the entry and sends a Binding Acknowledgement back to the MN. 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 Ohnishi, et al. [Page 10] Internet Draft Mobile IPv6 VPN October 2002 the Binding Cache entry for the MN and sends a Binding Acknowledgement. If the GHA receives a successful Registration Reply, it creates or updates the Binding Cache entry and sends a Binding Acknowledgement. 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 and MN's Intranet is IPv6 network, it decapsulates the packets and forwards them to the HAv6 by using IPv6 in the IPv6 tunneling mechanism. If the GHA receives IPv6 over IPv6 packets and MN's Intranet is IPv4 network, it decapsulates the packets, translates to IPv4 packets and forwards them to the HAv4 by using IPv4 in the IPv4 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 mechanism. If the GHA receives the packets from an HAv4, it decapsulates the packets, translates to IPv6 packets and forwards them to the MN by using IPv6 in the IPv6 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 Ohnishi, et al. [Page 11] Internet Draft Mobile IPv6 VPN October 2002 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 has to change IPsec endpoints depending on the Binding Cache entry's updates. 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 | +---------------------------+ | | | ESP Header | +---------------------------+ | | | Inner IP Header | +---------------------------+ | IP Payload | | | | | +---------------------------+ Figure 11: Packet format 6. Miscellaneous MN Operations 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 Ohnishi, et al. [Page 12] Internet Draft Mobile IPv6 VPN October 2002 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. 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, a service provider should assign different IPv6 prefix to each Intranet. The MN uses its IPv6 prefix to create IPv6 HoA from IPv4 HoA. If the Binding Update can include NAI, the GHA MAY use it to identify the MN's Intranet. 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 in Mobile IPv6 [Mobile IPv6]. 6.4. Routing consideration An MN MUST uses IPsec between itself and the GHA. 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. 7. Support for Mobile IPv6 route optimization An MN can optimize routes by sending Binding Updates (the GHA address Ohnishi, et al. [Page 13] Internet Draft Mobile IPv6 VPN October 2002 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]. References [Mobile IPv4] C. Perkins, Editor. "IP Mobility Support for IPv4", RFC 3220, January 2002. [Mobile IPv6] D. Johnson, C. Perkins and Jari Arkko, "Mobility Support in IPv6", draft-ietf-mobileip-ipv6-18.txt, June 2002. [VPN problem] Farid Adrangi, Prakash Iyer, Kent Leung, Milind Kulkarni, Alpesh Patel, Qiang Zhang and Joe Lau, "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. [MN-HA IPsec] Jari Arkko, Vijay Devarapalli and Francis Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", draft-ietf-mobileip-mipv6-ha-ipsec-01.txt, October Ohnishi, et al. [Page 14] Internet Draft Mobile IPv6 VPN October 2002 2002. A. Registration from MN by using MIPv4 over IPv6 tunnel In this document, we assume the GHA has IPv4/IPv6 translation function. 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 IPv4 over IPv6 tunnel. .KS 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 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 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. Ohnishi, et al. [Page 15] Internet Draft Mobile IPv6 VPN October 2002 C. Using GHA as a VPN gateway from IPv4 public network to IPv6 intranet The GHA mechanism can support a 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 October 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 Ohnishi, et al. [Page 17] Internet Draft Mobile IPv6 VPN October 2002 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 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]