Network Working Group J. Navali
Internet-Draft K. Chowdhury
Intended status: Standards Track Starent Networks
Expires: November 16, 2007 D. Premec
D. Damic
Nokia Siemens Networks
May 15, 2007
IPv6 over Network based Mobile IPv4
draft-navali-ip6-over-netmip4-02.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
This Internet-Draft will expire on November 16, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
There is a growing demand for routable IP addresses to support large
wireless user base today. Wireless operators are looking for ways to
leverage the IPv6 address space to meet the ever increasing number of
wireless data users. The operators who have network-based IPv4
mobility solutions can leverage the same scheme to provide mobility
Navali, et al. Expires November 16, 2007 [Page 1]
Internet-Draft May 2007
access service with larger address pool using IPv6 addressing. The
proposed approach solves both, by allowing provision of the network-
based mobility service, and the IPv6 address acquisition for the MNs.
The mobility contolling function may be located either at the
dedicated Access Node (achieving a virtual link-layer to the HA) or
at the first hop Access Router.
Navali, et al. Expires November 16, 2007 [Page 2]
Internet-Draft May 2007
Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5
3.1. NetMIP4 functionality at the Access Router . . . . . . . . 5
3.1.1. IPv6 addressing via IPv6CP . . . . . . . . . . . . . . 5
3.1.2. IPv6 addressing via DHCPv6 . . . . . . . . . . . . . . 11
3.2. NetMIP4 functionality at the Access Node . . . . . . . . . 13
3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2. Inital network entry . . . . . . . . . . . . . . . . . 14
3.2.3. Movement to a new AN . . . . . . . . . . . . . . . . . 18
3.2.4. DAD process failure . . . . . . . . . . . . . . . . . 19
3.2.5. Address lifetime . . . . . . . . . . . . . . . . . . . 19
4. MIPv4 Message Enhancements . . . . . . . . . . . . . . . . . . 20
4.1. IPv6 Home Address Request Extension . . . . . . . . . . . 20
4.2. IPv6 Home Address Extension . . . . . . . . . . . . . . . 21
4.3. MIPv4 Registration Request and Reply . . . . . . . . . . . 22
4.4. MIPv4 Registration Revocation Procedures . . . . . . . . . 22
5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 23
5.1. Mobile Node Requirements . . . . . . . . . . . . . . . . . 23
5.2. Access Node/NetMIP4 Client Requirement . . . . . . . . . . 23
5.2.1. NetMIP4 and MIP4 registration functions . . . . . . . 23
5.2.2. IPv6 Data processing . . . . . . . . . . . . . . . . . 23
5.3. Foreign Agent Requirements . . . . . . . . . . . . . . . . 24
5.4. Access Router/NAS/NetMIP4 Client/DHCP-proxy
Requirements . . . . . . . . . . . . . . . . . . . . . . . 24
5.4.1. IPv6 Addressing . . . . . . . . . . . . . . . . . . . 24
5.4.2. Authentication at the AR . . . . . . . . . . . . . . . 25
5.4.3. IPv6 Data processing . . . . . . . . . . . . . . . . . 25
5.5. Home Agent Requirements . . . . . . . . . . . . . . . . . 25
5.5.1. IPv6 Addressing . . . . . . . . . . . . . . . . . . . 25
5.5.2. Authentication at the HA . . . . . . . . . . . . . . . 26
5.5.3. IPv6 Data processing with 6to4 tunneling . . . . . . . 26
5.5.4. HA as the default IPv6 router . . . . . . . . . . . . 26
6. Security Considerations . . . . . . . . . . . . . . . . . . . 27
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28
9.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 30
Navali, et al. Expires November 16, 2007 [Page 3]
Internet-Draft May 2007
1. Introduction and Scope
The document deals with network-based mobility of IPv6 hosts in the
IPv4 network. Motivation is twofold:
A) Mobile operators are running out of routable subscriber IPv4
address space and are exploring ways to deploy IPv6 to leverage the
expanded 128-bit address space. In the absence of native IPv6
support on the IPv4 packet core network, a transition mechanism is
needed to use the IPv6 address space over existing IPv4 core
networks.
B) With the minimal extensions to the Mobile IPv4 enabled access
network, the mobility service for the unmodified IPv6 nodes can be
easily achieved.
This document proposes two methods providing the network-based
mobility:
The first approach enhances the network-based IPv4 mobility to
support IPv6 tunneling from the Access Router (AR) to the IPv6
correspondents via a dual stack home agent. The scheme employs MIPv4
messages to obtain an IPv6 Home address (HoA) or Home Link (HL)
prefix from the home agent, which the AR will assign to the IPv6 MN.
The access router and the home agent establish an IPv6-over-IPv4
tunnel to carry the IPv6 user traffic, which may further be extended
to a default 6to4 gateway. This facilitates seamless IPv6 handset
mobility across access routers while keeping the same IPv6 address.
On handoff, the new access router will register the same IPv6 HoA
with the home agent, but this time with a different IPv4 care-of-
address.
The second approach assumes the function preforming the registration
and providing the mobility service for the IPv6 hosts, is located in
the Access Node (a network node not intended to act as the first hop
IP router). By introducing the minimal IPv6 support in the form of
new MIP4 extensions used to establish IPv6-over-IPv4 tunneling, such
a node virtually extends the link-layer all the way to the HA and the
actual home link. This way the access network does not need
implementing extensive IPv6 support, while the MN doesn't need IPv4
nor MIPv6 implementations. MN will appear to be attached to its home
link, and still be able to move within the network. Mobility
management is based on Mobile IPv4 signalling, and is completely
provided by the network side. In this case the IPv6 service for the
host is provided exclusively by the home network.
2. Terminology
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Navali, et al. Expires November 16, 2007 [Page 4]
Internet-Draft May 2007
document are to be interpreted as described in [RFC2119].
NetMIPv4 Client:
The term NetMIPv4 Client used in this document refers to a Mobile
IPv4 client that is implemented in a access network node. This
entity is responsible and able to perform Mobile IPv4 registration on
behalf of the Mobile Node.
Access Node (AN):
The Access Node is an access network element, such as the Base
Station, the Access Point, or a router, which terminates the link
layer connectivity for the Mobile Node. AN does not operate as the
first hop Access Router, therefore it does not implement any
distinctive IPv6 support.
3. Solution Overview
The document describes in details the two related approaches aiming
to providing IPv6 service for mobility unaware hosts while operating
in the network-based MIPv4 environment. The common idea is utilized
for both approaches; the network-based entity NetMIP4 Client performs
Mobile registration on behalf of the MN, triggers the IPv6 address
assignment process, and establishes the v6overv4 tunnel to relay the
IPv6 user traffic to the home domain.
The NetMIP4 Client may be located either:
1) at the Access Router, where the AR actively takes part in the IPv6
addressing procedures,
2) or at the Access Node, in which case the HA is expected to act as
the first hop default router.
Depending on the deployment preference or the implemenation choice,
any of the two approaches may be chosen, adding this new
functionality to the prefered part of the network.
3.1. NetMIP4 functionality at the Access Router
3.1.1. IPv6 addressing via IPv6CP
For networks that use PPP as the link layer between the mobile Node
(MN) and the Access Router (AR), the interface ID (IID) negotiation
is performed via IPv6CP [RFC2023].
Following successful IPv6CP negotiation and establishment of the
unique link-local address, the AR initiates Router Advertisement (RA)
messages using its link-local address as the source address, as per
[RFC2461]. The RA messages contain a prefix used by the MS to
configure global IPv6 addresses. The AR supports Interface
Navali, et al. Expires November 16, 2007 [Page 5]
Internet-Draft May 2007
Identifier option negotiation. The AR generates local Interface
Identifier (for the local side of the PPP link) and Remote Interface
Identifier (for the Mobile side of the PPP link). The remote
Interface Identifier is assigned to the Mobile Node during IPv6CP
negotiation. The AR makes sure that the Interface Identifier is
unique over the PPP link. The Interface Identifier is used along
with the IPv6 HL prefix to construct the 128-bit IPv6 address for the
Mobile Node.
The ARs conformant to this specification shall behave as follows:
Upon receiving an IPv6CP configure request with IID set to 0, the AR
shall initiate a MIPv4 registration request to the home agent using a
IPv4 FA-COA and request an IPv6 HoA or HL prefix from the home agent.
The HA shall assign unique IPv6 HoA or HL prefix to a mobile node
after successfully processing the registering request. The HoA or HL
prefix range may be configured as IPv6 pool with in HA.
After receiving the MIPv4 RRP from the home agent with a valid IPv6
HoA or HL prefix, the AR sends a Router Advertisement message which
contains the HL prefix received from the home agent. This is done
assuming that at this time the IPv6CP negotiation with the MN is over
and the PPP link has reached the NCP open state.
The AR and the home agent establish an IPv6-in-IPv4 tunnel using the
FA-COA IPv4 address, the home agent's IPv4 address and the IPv6 HoA
tuple. The IPv6 traffic from the mobile node is carried in this
IPv6-in-IPv4 tunnel to the home agent. The 6to4 tunneling or other
form of tunneling may be used to forward IPv6 data packets from the
mobile node to another IPv6 Router/Host over the intermediate IPv4
networks.
3.1.1.1. IPv6 Addressing with unique HL prefix
In this section we show a scenario where an IPv6 address is assigned
to the MN using an unique HL prefix:
Navali, et al. Expires November 16, 2007 [Page 6]
Internet-Draft May 2007
+----+ +-------+ +-------+ +-----+
| | |NAS/ | | | | |
| MN/| |NetMIP4| | Home | |6to4 |
|User| |Client/| | Agent | |Relay|
| | | FA | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| LCP | | |
1) |<----------------------->| | |
| | | |
| IPv6CP Cfg-Req[IID=any] | | |
2) +-------------------------> | |
| | RRQ [HoAReqExt(IID)] | |
3) | +----------------------> |
| IPv6CP Cfg-Req[IID] | | |
4) <-------------------------+ | |
| | RRP [HoAExt(HoA)] *** proxy |
5) | <----------------------+ DAD |
| IPv6CP Cfg-NAK[IID] | | |
6) <-------------------------+ | |
| | | |
| IPv6CP Cfg-ACK | | |
7) +-------------------------> | |
| | | |
| IPv6CP Cfg-Req[IID] | | |
8) +-------------------------> | |
| | | |
| IPv6CP Cfg-ACK | | |
9) <-------------------------+ | |
| | | |
| RS | | |
10) +-------------------------> | |
| | | |
| RA [home prefix] | | |
11) <-------------------------+ | |
| | | |
12)*** Auto Config | | |
| IPv6 address | | |
| | 6over4 tunnel | |
13) |<----------------------->|<====================>|<========>|
Figure 1. IPv6 Addressing with unique HL prefix
Description of the steps:
1. MN and the NAS performs LCP phase. During this phase, the MN may
run CHAP or PAP. The NAS may authenticate the MN via an AAA
infrastructure (not shown here). At this step the AR (NAS) may
Navali, et al. Expires November 16, 2007 [Page 7]
Internet-Draft May 2007
receive a home agent address that should be used as the home agent to
acquire an HoA/HL prefix for the MN.
2. The MN sends an IPv6CP config request with IID set to any number.
3. The AR (NetMIP4 Client) assigns an IID for the MN. It sends a
MIP4 RRQ to the home agent (either configured in the AR or received
from the AAA server at step 1). The RRQ includes the assigned IID
for the MN in a HoA request extension. The RRQ has the CoA field set
to the FA-CoA of the AR.
4. The AR/NAS sends an IPv6CP config request to configure the IID
that it wants to use for the IPv6 Link Local address.
5. The home agent registers the MN's session and assigns an HoA.
The home agent constructs the HoA based on the received IID (lower 64
bits) with an unique prefix (upper 64-bits). The home agent may
perform proxy DAD on the newly formed HoA. Assuming proxy DAD
produces no response, the home agent returns the HoA in the RRP.
6. The AR/NAS responds back to the MN with an IPv6CP config-NAK to
suggest the IID that it wants the MN to use for link local address.
This happens in response to step 2.
7. The MN sends back an IPv6CP config-ACK to acknowledge the IID
that the AR/NAS proposed in step 4 that it would use.
8. The MN sends an IPv6CP config request to the AR/NAS with the IID
that was assigned by the AR/NAS in step 6.
9. The AR/NAS sends back an IPv6CP config-ACK to the MN in response
to step 8.
10. At this stage the MN and the AR/NAS PPP state machine should be
in NCP open state. The MN sends an Router Solicitation to the AR.
11. The AR responds with an Router Advertisement that contains a
prefix set to the home link prefix of the HoA that was received at
step 5.
12. The MN autoconfigures the IPv6 address with the IID and the
prefix from step 9 and step 11.
13. The MN's IPv6 traffic is tunneled by the AR to the HA via an
v6overv4 tunnel and the HA tunnels the packets via another tunnel
(6to4 in this illustration) to the v6 node/domain.
Navali, et al. Expires November 16, 2007 [Page 8]
Internet-Draft May 2007
3.1.1.2. IPv6 Addressing with shared HL prefix
In this section we show a scenario where an IPv6 address is assigned
to the MN using a shared HL prefix:
+----+ +-------+ +-------+ +-----+
| | |NAS/ | | | | |
| MN/| |NetMIP4| | Home | |6to4 |
|User| |Client/| | Agent | |Relay|
| | | FA | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| LCP | | |
1) |<----------------------->| | |
| | | |
| IPv6CP Cfg-Req[IID=any] | | |
2) +-------------------------> | |
| | RRQ [HoAReqExt(IID=0)] | |
3) | +------------------------> |
| IPv6CP Cfg-Req[IID] | | |
4) <-------------------------+ | |
| | RRP [HoAExt(HoA)] | |
5) | <------------------------+ |
| IPv6CP Cfg-NAK[IID] | | |
6) <-------------------------+ | |
| | | |
| IPv6CP Cfg-ACK | | |
7) +-------------------------> | |
| | | |
| IPv6CP Cfg-Req[IID] | | |
8) +-------------------------> | |
| | | |
| IPv6CP Cfg-ACK | | |
9) <-------------------------+ | |
| | | |
| RS | | |
10) +-------------------------> | |
| | | |
| RA [home prefix] | | |
11) <-------------------------+ | |
| | | |
12)*** Auto Config | | |
| IPv6 address | | |
| | 6over4 tunnel | |
13) |<----------------------->|<======================>|<========>|
Figure 2. IPv6 Addressing with shared HL prefix
Navali, et al. Expires November 16, 2007 [Page 9]
Internet-Draft May 2007
Description of the steps:
1. MN and the NAS performs LCP phase. During this phase, the MN may
run CHAP or PAP. The NAS may authenticate the MN via an AAA
infrastructure (not shown here). At this step the AR (NAS) may
receive a home agent address that should be used as the home agent to
acquire an HoA/HL prefix for the MN.
2. The MN sends an IPv6CP config request with IID set to any number.
3. in this case, the AR (NetMIP4 Client) does not assigns an IID for
the MN. It sends a MIP4 RRQ to the home agent (either configured in
the AR or received from the AAA server at step 1). The RRQ includes
IID=0 in a HoA request extension. The RRQ has the CoA field set to
the FA-CoA of the AR.
4. The AR/NAS sends an IPv6CP config request to configure the IID
that it wants to use for the IPv6 Link Local address.
5. The home agent registers the MN's session and assigns an HoA.
The home agent assigns an HoA for the MN from its pool. Since the
home agent is the custodian of the HoA (128-bits) it can use a HL
prefix that is shared among number of registered MNs, there may not
be a need to run proxy DAD for the assigned HoA in this case. The
home agent returns the HoA in the RRP.
6. The AR/NAS extracts the IID and the HL prefix from the received
IPv6 HoA extension in the RRP (step 5). The AR/NAS responds back to
the MN with an IPv6CP config-NAK to suggest this IID. This happens
in response to step 2.
7. The MN sends back an IPv6CP config-ACK to acknowledge the IID
that the AR/NAS proposed in step 4 that it would use.
8. The MN sends an IPv6CP config request to the AR/NAS with the IID
that was assigned by the AR/NAS in step 6.
9. The AR/NAS sends back an IPv6CP config-ACK to the MN in response
to step 8.
10. At this stage the MN and the AR/NAS PPP state machine should be
in NCP open state. The MN sends an Router Solicitation to the AR.
11. The AR responds with an Router Advertisement that contains a
prefix set to the home link prefix of the HoA (extracted at step 6)
that was received at step 5.
12. The MN autoconfigures the IPv6 address with the IID and the
Navali, et al. Expires November 16, 2007 [Page 10]
Internet-Draft May 2007
prefix from step 9 and step 11.
13. The MN's IPv6 traffic is tunneled by the AR to the HA via an
v6overv4 tunnel and the HA tunnels the packets via another tunnel
(6to4 in this illustration) to the v6 node/domain.
3.1.2. IPv6 addressing via DHCPv6
For networks that use DHCPv6 for IPv6 address configuration, the MN
and the AR exchanges DHCPv6 messages for this purpose. In this
section we describe the method via which the AR/NetMIPv4 Client
acquires an HoA for the MN.
It is assumed in this solution that the AR/NAS/FA, NetMIPv4 Client
and the DHCP server (sort of a DHCP proxy) are collocated.
The ARs conformant to this specification shall behave as follows:
Upon receiving an DHCP REQUEST from the MN (DHCP Client), the AR
shall initiate a MIPv4 registration request to the home agent using a
IPv4 FA-COA and request an IPv6 HoA or HL prefix from the home agent.
The HA shall assign unique IPv6 HoA or HL prefix to a mobile node
after successfully processing the registering request. The HoA or HL
prefix range may be configured as IPv6 pool with in HA.
After receiving the MIPv4 RRP from the home agent with a valid IPv6
HoA or HL prefix, the AR sends a DHCP REPLY message which contains
the HoA received from the home agent.
The AR and the home agent establish an IPv6-in-IPv4 tunnel using the
FA-COA IPv4 address, the home agent's IPv4 address and the IPv6 HoA
tuple. The IPv6 traffic from the mobile node is carried in this
IPv6-in-IPv4 tunnel to the home agent. The 6to4 tunneling or other
form of tunneling may be used to forward IPv6 data packets from the
mobile node to another IPv6 Router/Host over the intermediate IPv4
networks.
The following call flow illustrates the IPv6 addressing with DHCPv6:
Navali, et al. Expires November 16, 2007 [Page 11]
Internet-Draft May 2007
+----+ +-------+ +-------+ +-----+
| | |NAS/ | | | | |
| MN/| |NetMIP4| | Home | |6to4 |
|User| |Client/| | Agent | |Relay|
| | | FA | | | | |
| | |DHCP- | | | | |
| | | proxy | | | | |
+----+ +-------+ +-------+ +-----+
| | | |
| Network Access (EAP) | | |
1) |<-------------------->| | |
| | | |
| DHCPv6 REQ | | |
2) +----------------------> | |
| | RRQ [HoAReqExt(IID=0)] | |
3) | +------------------------> |
| | | |
| | RRP [HoAExt(HoA)] | |
4) | <------------------------+ |
| DHCPv6 REP [HoA] | | |
5) <----------------------+ | |
| | 6over4 tunnel | |
6) |<-------------------->|<======================>|<========>|
| | | |
Figure 3. Message flow for DHCPv6 based IPv6 addressing w/ NetMIP4
Description of the steps:
1. MN and the NAS performs access authentication and authorization
e.g. EAP. The NAS acting as the EAP authenticator authenticates the
MN via an AAA infrastructure (not shown here). At this step the AR
(NAS) may receive a home agent address that should be used as the
home agent to acquire an HoA prefix for the MN.
2. The MN sends an DHCP REQUEST message to the AR/DHCP-proxy. It is
assumed that the MN has discovered the DHCP-proxy address either via
a SOLICIT message or an ADVERTISE message from the DHCP-proxy. These
messages are not shown in this call flow.
3. The AR (NetMIP4 Client) sends a MIP4 RRQ to the home agent
(either configured in the AR or received from the AAA server at step
1). The RRQ includes IID=0 in a HoA request extension.
4. The home agent registers the MN's session and assigns an HoA.
The home agent assigns an HoA for the MN from its pool. Since the
home agent is the custodian of the HoA (128-bits) it can use a HL
Navali, et al. Expires November 16, 2007 [Page 12]
Internet-Draft May 2007
prefix that is shared among number of registered MNs, there may not
be a need to run proxy DAD for the assigned HoA in this case. The
home agent returns the HoA in the RRP.
5. The AR/NAS responds back to the MN with an DHCP REPLY message
containing the assigned HoA to the MN.
6. The MN's IPv6 traffic is tunneled by the AR to the HA via an
v6overv4 tunnel and the HA tunnels the packets via another tunnel
(6to4 in this illustration) to the v6 node/domain.
3.2. NetMIP4 functionality at the Access Node
This section analyzes an alternative to the previous case, by
locating the NetMIP4 Client at the Access Node. By dislocating the
NetMIP4 Client from the AR, and supressing the IPv6 service from the
access network, the link-layer can be virtually extended all the way
to the designated HA. The motive behind is to reduce the IPv6-bound
requirements for the access network, and therefore simplify possible
deployment and implementation scenarios.
3.2.1. Overview
We assume a MIPv4-based access network, connected to the router on
the MN's home network which acts as the HA. The NetMIP4 Client
resides at the AN, on MN's traffic path, and executes all mobility
procedures on behalf of the MN. The HA is a dual stack node, and it
is acting as a default router on its IPv6 link. We assume a point-
to-point MN-AN link in this example.
When the access network detects an attachment of a new IPv6 device,
the NetMIP4 Client initiates registration of the device with the HA
using the IPv4 care-of address. The IPv6 traffic is directly
tunneled between the NetMIP4 and the HA, the endpoints of the v6over4
tunnel.
+----+ +----+ IPv6 +----+ +--------+
| MN |---IPv6---| AN |----over----| HA |----|IPv6 net|
+----+ +----+ IPv4 +----+ +--------+
Figure4. NetMIP4 deployment at the Access Node
The AN is not processing IPv6 packets in any way besides tunneling
them between the HA and the MN. Thus, from the perspective of the
MN, the complete access network looks like a bridge, i.e. it appears
to be a single link layer connecting the MN with its HA. The MN
Navali, et al. Expires November 16, 2007 [Page 13]
Internet-Draft May 2007
believes to be attached directly to the HA and the home link.
Use of the FA may support several ANs and achieve mobility for
multiple MNs, by using a single globally routable FA-CoA address.
With respect to the limited IPv4 address space, such an addressing
mechanism achieves significant optimization, and also allows
distribution of overlapping IPv4 CoA and HoA addresses.
+----+ +----+ IPv6 +----+ MIP4 +----+ +--------+
| MN |---IPv6----| AN |---over---| FA |===tunnel===| HA |---|IPv6 net|
+----+ +----+ IPv4 +----+ +----+ +--------+
Figure 5. NetMIP4 deployment at AN with the FA
The NetMIP4 Client acts on behalf of the MN, by sending the
registration request to the FA. For this purpose the AN SHOULD use
its own address as the MN's CoA address, and request a dynamic HoA
assignment by the HA. In this case the HA MAY assign an overlapping
address from a private IPv4 address pool. The FA completes the
registration at the HA using its own FA-CoA to establish the FA-HA
tunnel. In this case on account of address space optimization, a
second IPv4 encapsulation layer must be introduced.
Entities performing the MIP4 registration MAY establish a mutual GRE
tunnel [RFC2784] to engage another mechanism leveraging the use of
the CoA address space. If wishing to set up the GRE, NetMIP4 Client
MAY initiate the procedure by setting the 'G' bit in the Registration
Request sent on behalf of the MN. If the FA is involved, then the
AN, the FA and the HA SHOULD all support the GRE functionality.
Using the GRE registration extensions described in
[I-D.yegani-gre-key-extension] it is possible to use GRE keys
negotiated between AN and the HA to distinguish between different
data streams exchanged in between. This way, all IPv6 session can be
served by a single IPv4 CoA address assigned to the AN.
3.2.2. Inital network entry
The AN is assumed to have direct link layer connectivity (from the
perspective of the IP layer) with the MN. When the MN attaches to
the network, in the course of link establishment it will be
authenticated. During the authentication process, the access network
will learn the NAI of the MN, and the NAI must be made available to
the AN. All these actions happen at the link layer, before any IP
layer connectivity.
After the authentication and after the link layer connectivity is
Navali, et al. Expires November 16, 2007 [Page 14]
Internet-Draft May 2007
successfully established, the MN, being an IPv6 host, will send a
Neighbor solicitation message on a newly established link to
configure its link local address. The following figure illustrates
the procedure in more details.
+----+ +-------+ +-------+ +-----+
| | | | | | | |
| MN/| | AN/ | | Home | |Home |
|User| |NetMIP4| | Agent | |Link |
| | |Client/| | | | |
+----+ +-------+ +-------+ +-----+
| link up | | |
1) <----------------> | |
| | | |
| NS(LLA) | | |
2) DAD --------------> | |
timer | | |
3) | *** acq. CoA | |
| | | |
| | RRQ[NAI, HoAReqExt] | |
4) | +-----------------------> |
| | | |
| | RegResp[HoAExt] | |
5) | <-----------------------+ |
| | | |
| | IP4[RA(home prefix)] | |
6) | <=======================+ |
| RA(home prefix)| | |
7) <----------------+ | |
| RS(LLA) | | |
8) |----------------> | |
| | IP4[NS(LLA), RS(LLA)] | |
9) | +=======================> |
| | | proxy |
10) | | *** DAD |
| | IP4[RA(home prefix)] | |
11) | <=======================+ |
| RA(home prefix)| | |
12) <----------------+ | |
Figure 6. NetMIP4 at AN: initial network entry
1. In this step the link is established and the MN is authenticated.
(e.g. using EAP). The AN SHALL learn the NAI of the MN in this step.
2. The MN sends the Neighbor solicitation to configure its link
local address and to trigger the DAD for the link-local address. The
MN expects to receive the notification of link-local address status
Navali, et al. Expires November 16, 2007 [Page 15]
Internet-Draft May 2007
before the DAD RetransTimer will expire. Prior to Neighbor
Solicitation, the MN may choose to send the Router Solicitation
message in order to decrease the period until the next Router
Advertisement.
3. When the AN receives the first IPv6 packet from a newly attached
MN, it MAY detect this host as an IPv6-only and initiate the mobility
procedure on its behalf. The Router Solicitation, or the Neighbor
solicitation whichever received first, AN SHALL interpret as a
trigger to register with the HA. First, the AN MUST acquire the IPv4
address which it will use as a care-of address for the MN. How
exactly the AN acquires the IPv4 care-of address is not defined in
this specification, but typically the AN may request the address from
the DHCPv4 server, or it can maintain its own address pool.
4. Triggered by the IPv6 packet received in step 3, the AN SHALL
generate the MIPv4 RRQ using the CoA obtained in step 3 and NAI
learned during the authentication. Further, the RRQ SHALL contain an
empty HoA Request Extension (length set to 1), requesting from the HA
the establishment of v6overv4 tunneling mode. In this case the AN
does not append the IID data, it simply uses the HoA request
extension as a capability exchange mechanism, to learn if the HA
supports such a function.
5. When the HA receives the RRQ with an empty HoA request extension
is SHALL create a binding entry between the MN (identified by its
NAI) and the CoA received in the RRQ. The HA will not assign the HoA
in this case. If the HA supports v6overv4 tunneling it SHALL send
the MIP4 RRP with an empty HoA extension (length set to 1) in
response. If the HA doesn't support tunneling it SHOULD send RRP
without the HoA extension. The AN receiving the RRP with an emtpy
HoA extension interprets this as a confirmation of the v6overv4
tunnel establishment, and creates a binding between the L2 link
associated to the MN, and the tunnel.
6. Successful processing of the RRQ which included the emtpy HoA
request extension, is the trigger that prompts the HA to distribute
the home address prefix. Immediately after sending the RRP, the HA
SHOULD send the Router advertisement over the newly established MIP4
v6overv4 tunnel. The RA, containing the home link prefix in the
prefix information option, is encapsulated and sent to the AN. The
inner header destination address is set to all-nodes-on-the-link
address. The RA also specifies which kind of address configuration
the MN may use: stateless or stateful.
7. The AN SHALL decapsulate and deliver any packets it receives via
the MIPv4 tunnel directly to the MN. In this step we see the
delivery of the Router Advertisement sent by the HA. The MN SHOULD
Navali, et al. Expires November 16, 2007 [Page 16]
Internet-Draft May 2007
use the home prefix received in the RA to configure its HoA. The MN
is not required to initiate DAD for the newly configured global
address, as per [RFC2462].
8. The MN has successfully processed the Router Advertisement and
autoconfigured its home addresss in step 7. To make sure the
unsolicited RA received is complete, the MN MUST send the Router
Solicitation if one was not sent until now [RFC2462].
9. After the MIPv4 v6overv4 tunnel is established, the AN SHALL
start delivering the uplink traffic to the HA. Here the Neighbor
solicitation from step 2, which was delayed until the v6overv4 tunnel
was set up, is tunneled to the HA. If sent by the MN, the Router
Solicitation message will also be tunneled to the HA at this point.
10. The arrival of a Neighbor Solicitation message verifying the
tentative address SHALL trigger the HA to perform proxy DAD on behalf
of the MN [RFC3775]. If the DAD is successful, the HA SHALL add
newly configured IPv6 HoA to the binding cache entry for the MN, and
SHALL start delivering all traffic on the home link destined to this
address via the MIPv4 tunnel to the current location of the MN.
Every time the MN configures an additional IPv6 address, the HA SHALL
perform proxy DAD for this additional address and bind it to the
MIPv4 tunnel associated with the MN.
11. Receipt of the Router Solicitation prompts the HA to update the
mobility bindings for the MN, if this is needed. The HA SHOULD
respond by sending the solicited RA, either immediately, or delaying
it for a previously scheduled occurrence.
12. Initial entry sequence is completed when the MN receives the
solicited Router Advertisement containing all the required options
within.
If the AN is aware that the MN is an IPv6-only host, then the AN MAY
initiate the setup of the MIPv4 tunnel immediately after the link
layer connection is successfully established. In other words, the
step 1 in the figure above may be followed by the step 3. This has
the advantage that the MIPv4 tunnel is setup in advance, before any
IPv6 traffic arrives at the AN. The benefit is that the delay caused
by the tunnel setup is minimized. This is especially important
because the tunnel setup delay may influence the DAD process.
It is apparent from the discussion above that the in this deployment
case the IPv6 traffic is entirely tunneled between the AN and the HA.
Thus the whole access network appears to the MN as a single link
connected directly to its HA. The MN is effectively deceived into
believing that it is attached to its home link.
Navali, et al. Expires November 16, 2007 [Page 17]
Internet-Draft May 2007
The MN MAY use either stateful or stateless methods to configure its
home address. This scenario doesn't mandate or prefer one method
over another and is compatible with both methods. Important point is
that whenever the MN configures an additional address, the HA SHALL
perform the proxy DAD for it and add the HoA to its binding cache.
3.2.3. Movement to a new AN
The following figure describes the sequence of events when the MN
moves to a new link which is associated with the new AN.
+----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | |
| MN/| | nAN | | oAN | | HA | |Home |
|User| | | | | | | |Link |
+----+ +-----+ +-----+ +-----+ +-----+
| | | | |
| link up | context tx. | | |
1) <-------->|<-------------->| | |
| | | | |
| | | | |
2) | *** acq. CoA | | |
| | | | |
| | RRQ[HoAReqExt] | | |
3) | +----------------------------> |
| | | | |
| | RRP[HoAExt] | | |
4) | <----------------------------| |
| | | | |
| | | RRev | |
5) | | <-----------+ |
| | | | |
| | | RRevAck | |
6) | | +-----------> |
| | | | |
Figure 7. MN moves to another AN
1. In this step the MN changed its point of attachment to the
network. The new link layer connection with the new AN (nAN) is
established. It is assumed that during the link layer handover the
old AN (oAN) transfers the MN related context to the new AN. The
context SHALL include at least the NAI and the current sequence
number used in MIPv4 Registration request messages. It MAY also
include any packets still buffered/arriving at the oAN. The protocol
for exchanging context between ANs is out of scope of this document.
2. - 4. These steps are the same as steps 3-5 in the Section 3.2.2.
Navali, et al. Expires November 16, 2007 [Page 18]
Internet-Draft May 2007
5. When the HA receives a RRQ for a MN for which it already has a
binding cache entry, the HA SHOULD send the MIP4 Registration
Revocation message [RFC3543] to the previous mobility agent, i.e. to
the oAN. This will expedite the release of resources at the oAN.
The oAN can safely remove all its resource associated with the MN
since it now knows that it will not receive any further traffic from
the HA for this MN. The HA will perform steps 4. and 5.
simultaneously.
6. The oAN acknowledges to the HA the release of the MN related
resources.
From the message flow above, it is obvious that the MN itself is not
involved in the handover at all. In fact, from the perspective of
the MN nothing changed, the illusion that it is connected to its home
link is still maintained by the network despite the fact that the MN
actually changed its point of attachment.
3.2.4. DAD process failure
The entry procedure may end in failure as a consequence of an
unsuccessful DAD process at the late stage (all steps in this section
refer to initial MN entry procedure over the AN, as described in
Section 3.2.2).
After sending the first Neighbor solicitation by which it tries to
verify the uniqueness of the tentative link-local address, the MN
must wait to insure the link-local address is not already in use
(Step 2). If no Neighbor Advertisements notifying a duplicate
address are received in the RetransTimer period, the MN will assign
and start using this address. Subsequently, the MN MAY configure its
home address at Step 7.
The initially sent Neighbor solicitation is delivered to the HA (Step
8) only after the AN-HA IPv6 tunnel has been established (Step 5).
In case that HA performs an unsuccessful proxy DAD and detects a
duplicate address (at Step 10), it MUST send the Neighbor
Advertisement to the MN signaling the address is already in use. The
HA is not aware of the configuration process duration at the MN, so
to make sure the entry process is completely stopped it MUST send a
Registration Revocation message to the AN signaling to detach the MN
from the link.
3.2.5. Address lifetime
Lifetime of the IPv6 address assigned to the MN and the binding
lifetime held in the HA's MIPv4 context are not directly related to
each other. The AN SHALL refresh the mobility binding before it
Navali, et al. Expires November 16, 2007 [Page 19]
Internet-Draft May 2007
expires. If the mobility binding ever expires, for whatever reason,
both AN and the HA SHALL release all resources related to that
mobility binding.
The MN is expected to take care of the lifetime of its IPv6 address.
The HA SHALL be aware of the lifetimes of the IPv6 addresses assigned
to the MN. If the MN is allowed to autoconfigure [RFC2462] its IPv6
address, then the MIPv4 binding lifetime SHALL be limited by the HA
to be no more than the (remaining) lifetime of the prefix used for
IPv6 address autoconfiguration. The HA MAY act as the DHCPv6 relay
agent in order to learn the lifetimes of IPv6 addresses assigned by
means of DHCPv6. If the IPv6 address of the MN ever expires, the HA
SHALL stop defending it on the home link and SHALL remove it from its
binding cache entry.
4. MIPv4 Message Enhancements
The following extensions are defined to exchange the Interface-ID and
IPv6 HoA information between the HA, and the NetMIP4 entity, either
AR or the AN. In case the AN is acting as the NetMIP4 Client, the
extensions only serve the purpose to establish the v6overv4 tunneling
with the HA. Note that any known and previously authenticated
username (e.g the username that was authenticated during EAP or LCP)
can be used as the NAI for the MIPv4 session and sent in the MN-NAI
extension. If PPP/EAP username is not available, then another
identifier will be needed to identify the session. In some wireless
networks It is possible to use the MSID of a subscriber or the
hardware ID (e.g. MAC address) of the MN to identify the session,
carried in the MN-NAI extension.
4.1. IPv6 Home Address Request Extension
The IPv6 Home Address Request Extension conforms to the Short
Extension format specified for Mobile IPv4 [RFC3344]. The IPv6 Home
Address Request Extension is not a skippable extension. The format
of the extension is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Sub-Type | IID ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8. IPv6 Home Address Request Extension
Navali, et al. Expires November 16, 2007 [Page 20]
Internet-Draft May 2007
Type
A 8-bit field indicating the type of the extension. To be
assigned by IANA.
Length
A 8-bit field indicating the length of the option. Field value is
set to 9 if message contains the Interface-ID, or to 1 if an empty
extension is sent.
Sub-Type
A 8-bit field not used in this extension. It is set to 0.
IID
A 64-bit field set to the Interface ID allocated by the AR for the
MN.
Note that the IPv6 Home Address Request Extension is included by the
AR / AN only in the initial RRQ messages sent to HA.
When the AR has locally assigned an Interface-ID to the MN, it
includes the non-zero Interface-ID (64-bits) in this extension to
request HA to assign a unique Home Link Prefix. If the AR expects
the HA to assign a Home Address (including Interface-ID), then the AR
sets the Interface-ID in this extension to zero. The AN always sends
the extension without the Interface-ID data.
4.2. IPv6 Home Address Extension
The IPv6 Home Address Extension may be included in the RRQ from the
AR or in the RRP from the HA to identify a MIP registration. Note
that this may also be included in MIPv4 Revocation and Acknowledgment
messages [RFC3543] for the same purpose. The format of the extension
is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |U| Reserved | IPv6 HoA ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9. IPv6 Home Address Extenstion
Navali, et al. Expires November 16, 2007 [Page 21]
Internet-Draft May 2007
Type
A 8-bit field indicating the type of the extension. To be
assigned by IANA.
Length
A 8-bit field indicating the length of the option. Field value is
set to 17 if the message contains the Home Address, or to 1 if an
empty extension is sent.
U
When set this indicates the uniqueness of the HL prefix used to
construct the HoA.
Reserved
Set to 0s.
IPv6 HoA
A 128-bit field set to the IPv6 address (HoA) allocated by the HA
for the MN.
4.3. MIPv4 Registration Request and Reply
For any MN that was assigned an IPv6 Home Address via NetMIPv4, the
MIPv4 Registration Request from the AR may include one of the
following extensions depending upon the type of request.
The IPv6 Home Address Request Extension is included in initial
registration request from the AR / AN to the HA for session setup.
The IPv6 Home Address Extension is included in renewal and de-
registration requests from the AR to the HA. It is also included in
all Registration Reply messages from the HA. An empty Home Address
Extension is included in inital registration response from HA to AN.
The IPv6 Home Address Request Extension and the IPv6 Home Address
Extension must be included before the FA-HA Authentication Extension.
4.4. MIPv4 Registration Revocation Procedures
For any MN that was assigned an IPv6 Home Address via NetMIPv4, the
MIPv4 Registration Revocation and Revocation Acknowledgment messages
[RFC3543] from the AR or the HA should include the IPv6 Home Address
Extension to identify the MIP registration correctly.
Navali, et al. Expires November 16, 2007 [Page 22]
Internet-Draft May 2007
The IPv6 Home Address Extension must be included before the FA-HA
Authentication Extension. Note that the AR sends a deregistration
Request (lifetime = 0) to terminate a binding at the HA and not a
Revocation message and the HA responds with a Deregistration Reply.
The HA sends a Revocation message to terminate a binding at the AR
and the AR responds with an Acknowledgment message.
5. Node Requirements
This section describes the requirements for each of the nodes
involved in this method.
5.1. Mobile Node Requirements
Mobile node behavior shall conform to the IPv6 specification defined
in [RFC2472], [RFC2460], [RFC2461], [RFC2462], [RFC3315]. The
Interface-Identifier is assigned by the AR to the Mobile during
IPv6CP negotiation in case the MN uses IPv6 over PPP. The HL prefix
is assigned to the mobile in the Router Advertisement message.
5.2. Access Node/NetMIP4 Client Requirement
In case the NetMIP4 Client resides at the Access Node following
requirements have to be met in order to provide mobility service to
the IPv6 MN.
5.2.1. NetMIP4 and MIP4 registration functions
When the AN detects an IPv6-only MN on the link (i.e. by the NS or
the RS), the AN SHALL register the MN with the HA by sending the
MIPv4 RRQ message. The RRQ SHALL contain the NAI, and the IPv6 HoA
Request Extension. If there is no IPv6 HoA Extension in the MIP4 RRP
message or the AN SHALL not provide the MN with mobility service.
The AN SHALL protect all MIPv4 signaling messages with the MN-HA
authentication extension.
5.2.2. IPv6 Data processing
For the MN traffic, the AN is acting as a link layer bridge. The AN
SHOULD not provide the IPv6 services for the MN, only the v6overv4
tunneling to the HA. In particular, the AN SHALL never decrease the
hop limit field in the IPv6 header nor will it change any other field
in the IPv6 header. AN SHALL not process the IPv6 HoA Extension
received from HA, except as a signal to establish the v6overv4
tunnel.
Navali, et al. Expires November 16, 2007 [Page 23]
Internet-Draft May 2007
The AN SHALL intercept Router Advertisements sent by the HA and
inspect them before relaying them to the MN. If the Router
advertisement contains the source link layer address option, the AN
SHALL use the advertised link layer address as the source address
when constructing the link layer header, provided that the underlying
link layer technology makes use of such an address. The intercepted
source LLA MAY be transferred during the handover to the new AN as
part of the MN context, and the new AN SHOULD use the transferred
link layer address when constructing the link layer header.
The AN SHALL encapsulate the IPv6 PDUs received from the MN, and send
them to the HA via the v6overv4 tunnel. The AN will decapsulate the
packets received from the HA and deliver the inner IPv6 PDU to the
MN. The AN SHALL generate the appropriate link layer header and
prepend it to the IPv6 packets delivered to the MN.
5.3. Foreign Agent Requirements
Scenario with the AN as the NetMIP4 Client supports the use of
unmodified foreign agents [RFC3344]. The AN will appear as regular
mobile node to the FA. Advantage of using the non-collocated CoA
mode is that the number of publicly routable IPv4 addresses is
minimized, only one is needed for FA. However, FA will add another
layer of encapsulation when tunneling back to the HA. This adds
additional processing overhead and diminishes the MTU size.
If the AN chooses to register with the FA, the AN will provide its
IPv4 address as a care-of address and SHALL request the dynamic
assignment of its HoA by setting the HoA field in RRQ to all zeros.
The HoA will be assigned by the HA in the RRP message. The HoA may
be allocated from private address space, and the FA may also
implement the support for overlapping address space.
5.4. Access Router/NAS/NetMIP4 Client/DHCP-proxy Requirements
5.4.1. IPv6 Addressing
If the MN needs to be assigned a unique HL Prefix, the AR assigns an
Interface-ID locally, and initiates NetMIP4 procedures to the HA.
The AR sends a RRQ to HA including the IPv6 Home Address Request
Extension with the Interface-ID set to the assigned Interface-ID.
If the MN does not need a unique HL prefix, the AR initiates NetMIP4
procedures to the HA when IPv6CP Conf-Req is received from the MN.
The AR sends a RRQ to HA including the IPv6 Home Address Request
Extension with the Interface-ID set to zero.
When a RRP (Accepted) with IPv6 Home Address Extension is received
Navali, et al. Expires November 16, 2007 [Page 24]
Internet-Draft May 2007
with a valid home address, the AR extracts the HL prefix from the
HoA. The AR indicates the HL Prefix to the MN via a Router
Advertisement message and puts the MN in connected state.
5.4.2. Authentication at the AR
The PPP CHAP or PAP or EAP authentication shall be performed for IPv6
network access. For NetMIP4 procedures, the MN-HA, MN-FA, FA-HA
authentication keys can be made available at the NetMIP4 Client via a
key distribution scheme that is implemented at the AR. All RRQ/RRP
messages must be protected by the FA-HA Authentication Extension.
The key distribution method is outside the scope of this document.
5.4.3. IPv6 Data processing
When the AR receives an IPv6 PDU from the MN, the AR encapsulates the
packet in a IPv4 packet and forwards it to the HA. If the AR
receives an IPv4 encapsulated IPv6 PDU from the HA, it removes the
outer IPv4 header and forwards the IPv6 PDU to the MN.
5.5. Home Agent Requirements
5.5.1. IPv6 Addressing
The HA needs to be configured with either IPv6 prefix pools or IPv6
address pools. If Interface-ID is assigned at the AR, the HA cannot
assign shared HL prefix; it has to be a unique HL prefix per MN.
When a RRQ is received with IPv6 Home Address Request Extension that
has a non-zero Interface-ID in it, the HA assigns a HL prefix to the
MN, forms the global IPv6 address for the MN using the received
Interface-ID and sends a Reply with IPv6 Home Address Extension.
When a RRQ is received with IPv6 Home Address Request Extension with
Interface-ID set to zero, the HA assigns a IPv6 Home address to the
MN, and sends a Reply with IPv6 Home Address Extension.
When a RRQ is received with an empty IPv6 Home Address Request
Extension (length set to one), the HA does not assign a IPv6 Home
address to the MN, but sends a Reply with empty IPv6 Home Address
Extension to confirm the v6overv4 tunneling mode.
If the Interface-ID is assigned at the HA, the HA can choose to
assign a shared or unique HL prefix per MN. Optionally the HA can
assign a unique HL prefix to the MN also. The HA sets the Unique HL
prefix bit "U" in the Home Address Extension to indicate this.
Navali, et al. Expires November 16, 2007 [Page 25]
Internet-Draft May 2007
5.5.2. Authentication at the HA
For NetMIP4 procedures, the MN-HA, FA-HA authentication keys can be
made available at the Home Agent via a key distribution scheme that
is implemented at the HA. All RRQ/RRP messages exchange with the AR
must be protected by the FA-HA, and those exchanged with the AN with
the MN-HA Authentication Extension. The key distribution method is
outside the scope of this document.
5.5.3. IPv6 Data processing with 6to4 tunneling
When the HA receives a IPv6 PDU over a 6to4 tunnel from the default
6to4router, it removes the IPv4 header and looks at the inner IPv6
address. If an tunnel has been established for this MN and there is
a binding cache entry for the same, the HA encapsulates the packet in
an IPv4 packet and forwards it to the AR. If the HA receives an IPv4
encapsulated IPv6 PDU from the AR, it removes the outer IPv4 header
and forwards the IPv6 PDU over the 6to4 tunnel to the default 6to4
router.
5.5.4. HA as the default IPv6 router
If the HA is acting as a first hop router for the MN then it requires
a dual stack support, for both IPv4 and IPv6. The HA MUST provide
the Mobile IPv4 service [RFC3344] on at least one interface which is
connected to the IPv4 network. HA MUST support the HoA-, and the HoA
Request extensions, as a mechanism to establish v6overv4 tunneling
with the AN representing the MN.
The HA MUST be configured with at least one 64-bit prefix which will
serve as the home link prefix. On the interface(s) advertising the
home link prefix, the HA provides the services of a default IPv6
router on the link. It also acts as IPv6 home agent, it MUST defend
home address of the MN while it is away, it intercepts its traffic
and forwards to the current MN location over the v6overv4 tunnel. If
the MN is allowed to autoconfigure its home address, the HA SHALL
perform the proxy DAD for the MN's HoA.
The receipt of RRQ with empty IPv6 HoA request extension, the HA
SHOULD interpret as a trigger to distribute the IPv6 address prefix.
The HA responds with RRP containing the empty HoA extension if it
supports tunneling mode, or omits the extension if it doesn't. At
this stage the HA SHOULD create the initial BCE for the specific MN,
containg the NAI and the CoA received in the RRQ.
When the MN configures an additional IPv6 address, in order to verify
its uniqueness HA starts DAD process by sending NS message to the
solicited node multicast group. When the HA receives such a packet
Navali, et al. Expires November 16, 2007 [Page 26]
Internet-Draft May 2007
via the MIPv4 tunnel, it MUST not deliver it to the home link.
Instead, the HA MUST perform proxy DAD on the home link for the
address being verified. If the DAD is successful, the HA SHALL add
the verified address to the binding cache entry for the MN and SHALL
treat the newly configured IPv6 address as an additional HoA of the
MN. If the DAD process fails, the HA SHALL relay the received NA to
the MN via the MIPv4 tunnel.
The HA SHALL be aware of the address lifetime of the IPv6 HoA
assigned to the MN. If the address lifetime expires, the HA SHALL
remove the expired address from its binding cache entry. The HA
SHALL in parallel take care of the related IPv4 CoA binding lifetime,
in case the lifetime does expire, the HA will remove this binding and
may send the Registration Revocation to the AN in order to speedup
the binding removal process.
6. Security Considerations
The proposed method of acquiring IPv6 address via network based
Mobile IPv4 (NetMIP4) requires secure key generation and key
distribution for securing the RRQs and RRPs. Although this key
generation and distribution details are not part of this document, it
is necessary to put in place a solution for this to prevent rouge
network nodes to launch attacks on user's sessions.
There are several work going on in IETF which are based on EAP keying
framework. Also several SDOs are developing key distribution schemes
that can be leveraged for a solution.
7. IANA Considerations
The following Extension Types MUST be assigned by IANA:
IPv6 Home Address Request Extension Type: TBD-1.
IPv6 Home Address Extension Type: TBD-2.
8. Acknowledgements
TBD.
9. References
Navali, et al. Expires November 16, 2007 [Page 27]
Internet-Draft May 2007
9.1. Normative References
[RFC2023] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2023, October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2472] Haskin, D. and E. Allen, "IP Version 6 over PPP",
RFC 2472, December 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
[RFC3543] Glass, S. and M. Chandra, "Registration Revocation in
Mobile IPv4", RFC 3543, August 2003.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
9.2. Informative References
[I-D.yegani-gre-key-extension]
Yegani, P., "GRE Key Extension for Mobile IPv4",
draft-yegani-gre-key-extension-02 (work in progress),
March 2007.
Navali, et al. Expires November 16, 2007 [Page 28]
Internet-Draft May 2007
Authors' Addresses
Jay Navali
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 978-851-1141
Email: jnavali@starentnetworks.com
Kuntal Chowdhury
Starent Networks
30 International Place
Tewksbury, MA 01876
US
Phone: +1 214-550-1416
Email: kchowdhury@starentnetworks.com
Domagoj Premec
Nokia Siemens Networks
Zagrebacka 145a
Zagreb 10000
Croatia
Phone: +385 1-6105-923
Email: domagoj.premec@siemens.com
Damjan Damic
Nokia Siemens Networks
Zagrebacka 145a
Zagreb 10000
Croatia
Phone: +385 1-6331-337
Email: damjan.damic@siemens.com
Navali, et al. Expires November 16, 2007 [Page 29]
Internet-Draft May 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Navali, et al. Expires November 16, 2007 [Page 30]