Network Working Group J. Navali Internet-Draft K. Chowdhury Expires: August 29, 2006 Starent Networks February 25, 2006 IPv6 over Network based Mobile IPv4 draft-navali-ip6-over-netmip4-00.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 August 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). 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 has network based IPv4 mobility solutions can leverage the same scheme to provide mobility access service with larger address pool using IPv6 addressing. This document defines such a mechanism. Navali & Chowdhury Expires August 29, 2006 [Page 1] Internet-Draft February 2006 Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.1 IPv6 addressing via IPv6CP . . . . . . . . . . . . . . . . 3 3.1.1 IPv6 Addressing with unique HL prefix . . . . . . . . 4 3.1.2 IPv6 Addressing with shared HL prefix . . . . . . . . 7 3.2 IPv6 addressing via DHCPv6 . . . . . . . . . . . . . . . . 10 4. MIPv4 Message Enhancements . . . . . . . . . . . . . . . . . . 12 4.1 IPv6 Home Address Request Extension . . . . . . . . . . . 12 4.2 IPv6 Home Address Extension . . . . . . . . . . . . . . . 13 4.3 MIPv4 Registration Request and Reply . . . . . . . . . . . 14 4.4 MIPv4 Registration Revocation Procedures . . . . . . . . . 14 5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 14 5.1 Mobile Node Requirements . . . . . . . . . . . . . . . . . 15 5.2 Access Router/NAS/NetMIP4 Client/DHCP-proxy Requirements . . . . . . . . . . . . . . . . . . . . . . . 15 5.2.1 IPv6 Addressing . . . . . . . . . . . . . . . . . . . 15 5.2.2 Authentication at the AR . . . . . . . . . . . . . . . 15 5.2.3 IPv6 Data processing . . . . . . . . . . . . . . . . . 15 5.3 Home Agent Requirements . . . . . . . . . . . . . . . . . 15 5.3.1 IPv6 Addressing . . . . . . . . . . . . . . . . . . . 15 5.3.2 Authentication at the HA . . . . . . . . . . . . . . . 16 5.3.3 IPv6 Data processing . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 9. Normative References . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . 19 Navali & Chowdhury Expires August 29, 2006 [Page 2] Internet-Draft February 2006 1. Introduction and Scope 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 IP core networks. This document describes an approach to utilize network based IPv4 mobility solution to support tunneling of IPv6 traffic from an access router to an IPv6 correspondent node 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 so that the access router can assign an IPv6 address to an IPv6 mobile node. The access router and the home agent establish an IPv6-over-IPv4 tunnel to carry the IPv6 user traffic. The tunnel is extended to a default 6to4 gateway configured for the IPv6 address pool on the home agent. 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 each time with a different IPv4 care-of-address. 2. Terminology The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The term NetMIPv4 used in this document refers to a Mobile IPv4 client that is implemented in a network node. This entity can perform Mobile IPv4 registration on behalf of the Mobile Node. 3. Solution Overview 3.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 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 Navali & Chowdhury Expires August 29, 2006 [Page 3] Internet-Draft February 2006 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 behaves 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 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 & Chowdhury Expires August 29, 2006 [Page 4] Internet-Draft February 2006 +----+ +-------+ +-------+ +-----+ | | | | | | | | | MN/| |NAS/ | | Home | |6to4 | |User| |NetMIP4| | Agent | |Relay| | | |Client/| | | | | | | | FA | | | | | +----+ +-------+ +-------+ +-----+ | | | | | 1 | | | |<------------->| | | | | | | | 2 | | | |-------------->| | | | | 3 | | | 4 |------------>| | |<--------------| | | | | 5 | | | |<------------| | | 6 | | | |<--------------| | | | | | | | 7 | | | |-------------->| | | | | | | | 8 | | | |-------------->| | | | | | | | 9 | | | |<--------------| | | | | | | | 10 | | | |-------------->| | | | | | | | 11 | | | |<--------------| | | | | | | | | | | Auto Config 12 | | | IPv6 address | | | | | | | | 13 | | | |<------------->|<===========>|<========>| | | | | Figure 1. IPv6 Addressing with unique HL prefix Navali & Chowdhury Expires August 29, 2006 [Page 5] Internet-Draft February 2006 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. 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. Navali & Chowdhury Expires August 29, 2006 [Page 6] Internet-Draft February 2006 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 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: Navali & Chowdhury Expires August 29, 2006 [Page 7] Internet-Draft February 2006 +----+ +-------+ +-------+ +-----+ | | | | | | | | | MN/| |NAS/ | | Home | |6to4 | |User| |NetMIP4| | Agent | |Relay| | | |Client/| | | | | | | | FA | | | | | +----+ +-------+ +-------+ +-----+ | | | | | 1 | | | |<------------->| | | | | | | | 2 | | | |-------------->| | | | | 3 | | | 4 |------------>| | |<--------------| | | | | 5 | | | |<------------| | | 6 | | | |<--------------| | | | | | | | 7 | | | |-------------->| | | | | | | | 8 | | | |-------------->| | | | | | | | 9 | | | |<--------------| | | | | | | | 10 | | | |-------------->| | | | | | | | 11 | | | |<--------------| | | | | | | | | | | Auto Config 12 | | | IPv6 address | | | | | | | | 13 | | | |<------------->|<===========>|<========>| | | | | Figure 1. IPv6 Addressing with shared HL prefix Navali & Chowdhury Expires August 29, 2006 [Page 8] Internet-Draft February 2006 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 & Chowdhury Expires August 29, 2006 [Page 9] Internet-Draft February 2006 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.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 behaves 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 & Chowdhury Expires August 29, 2006 [Page 10] Internet-Draft February 2006 +----+ +-------+ +-------+ +-----+ | | | | | | | | | MN/| |NAS/ | | Home | |6to4 | |User| |NetMIP4| | Agent | |Relay| | | |Client/| | | | | | | | FA/ | | | | | | | |DHCP- | | | | | | | | proxy | | | | | +----+ +-------+ +-------+ +-----+ | | | | | 1 | | | |<------------->| | | | | | | | 2 | | | |-------------->| | | | | 3 | | | |------------>| | | | | | | | 4 | | | |<------------| | | 5 | | | |<--------------| | | | | | | | | | | | 6 | | | |<------------->|<===========>|<========>| | | | | Figure 1. 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 Navali & Chowdhury Expires August 29, 2006 [Page 11] Internet-Draft February 2006 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 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. 4. MIPv4 Message Enhancements The following extensions are defined to exchange the Interface-ID and IPv6 HoA information between the AR and 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 .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type A 8-bit field indicating the type of the extension. To be assigned by IANA. Navali & Chowdhury Expires August 29, 2006 [Page 12] Internet-Draft February 2006 Length A 8-bit field indicating the length of the option. Set to 11. 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 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. 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 .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. Set to 19. Navali & Chowdhury Expires August 29, 2006 [Page 13] Internet-Draft February 2006 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 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. 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. 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. Navali & Chowdhury Expires August 29, 2006 [Page 14] Internet-Draft February 2006 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 Router/NAS/NetMIP4 Client/DHCP-proxy Requirements 5.2.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 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.2.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.2.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.3 Home Agent Requirements 5.3.1 IPv6 Addressing The HA needs to be configured with either IPv6 prefix pools or IPv6 Navali & Chowdhury Expires August 29, 2006 [Page 15] Internet-Draft February 2006 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. 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. 5.3.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 must be protected by the FA-HA Authentication Extension. The key distribution method is outside the scope of this document. 5.3.3 IPv6 Data processing 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. 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. Navali & Chowdhury Expires August 29, 2006 [Page 16] Internet-Draft February 2006 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. 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. [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. Navali & Chowdhury Expires August 29, 2006 [Page 17] Internet-Draft February 2006 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 Navali & Chowdhury Expires August 29, 2006 [Page 18] Internet-Draft February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Navali & Chowdhury Expires August 29, 2006 [Page 19]