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
<draft-ohnishi-mobileip-v6vpngateway-00.txt>
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]