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]