MIP6 Working Group P. Yang Internet-Draft H. Deng Expires: December 21, 2006 Hitachi (China) June 19, 2006 IPv4/netlmm6/IPv4 draft-yang-softwire-netlmm-v4netlmm6v4-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 December 21, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract NETLMM6 may be widely deployed in the 3G network. But currently, most of the mobile hosts are IPv4 nodes without any Mobile IPv4/IPv6 stacks. This document proposes the solution to enable the IPv4 hosts to obtain the network connection and set up IPv4 sessions over NETLMM6 network. Extensions and option are added to proxy Mobile IPv6 allowing for single IPv4 stack hosts to access kind of IPv6 network. The IPv4 Address could be maintained constantly in the domain of NETLMM6. Yang & Deng Expires December 21, 2006 [Page 1] Internet-Draft IPv4/netlmm6/IPv4 June 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. conventions used in this document . . . . . . . . . . . . . . 6 3. overview of this solution . . . . . . . . . . . . . . . . . . 7 3.1. definition of the messages . . . . . . . . . . . . . . . . 7 3.1.1. Proxy BU for IPv4 Mobile Station . . . . . . . . . . . 7 3.1.2. Proxy BA for IPv4 Mobile Station . . . . . . . . . . . 8 3.1.3. IPv4 Home Address (HoA) option . . . . . . . . . . . . 8 3.2. registration procedure . . . . . . . . . . . . . . . . . . 9 3.3. error code . . . . . . . . . . . . . . . . . . . . . . . . 12 3.4. packet forwarding . . . . . . . . . . . . . . . . . . . . 12 4. mobile station consideration . . . . . . . . . . . . . . . . . 13 4.1. Address configuration . . . . . . . . . . . . . . . . . . 13 5. Dual-stack Mobility Proxy Agent consideration . . . . . . . . 14 5.1. maintenance of the visitor list . . . . . . . . . . . . . 14 5.2. DHCP consideration . . . . . . . . . . . . . . . . . . . . 15 5.3. ARP consideration . . . . . . . . . . . . . . . . . . . . 15 5.4. ICMP consideration . . . . . . . . . . . . . . . . . . . . 15 6. Dual-stack Local Mobility Anchor Point consideration . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 9. Reference . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Yang & Deng Expires December 21, 2006 [Page 2] Internet-Draft IPv4/netlmm6/IPv4 June 2006 1. Introduction Mobile IPv6 protocol [RFC3775] enables mobile stations to move within the IPv6 Internet while persisting the retaining the reachability and session continuity. However, there are many devices which do not have mobile IP functionality and could not support IPv4/IPv6 dual stack. For instance, currently most of the cellular phone or WLAN phone could only support IPv4 stack without mobile IP functions. With the growth of IPv6 network deployment, it is possible to assume that IPv4 mobile stations will need the internet access through NETLMM6 network. In Softwire [Dawkins06], there is the transition requirement on IPv4 accross IPv6 network. IPv4 hosts connectivity over IPv6 network is one of the important scenarios for traversal of networks with differing address familities. The solution in this document enables IPv4 hosts to access kind of IPv6 network. At the edge of the IPv6 network, the dual-stack mobility proxy agent (DMPA) is responsible for the network access registration and packet forwording of the IPv4 hosts. The IPv4 hosts will be kept intact. And, Enabling unmodified mobile nodes is one of the targets of Localized obility Management (NETLMM)[Kempf06b]. This could be able to help the service providers to support as many customers as possible. The other benefits includes decreasing the Update latency, saving the Signaling overhead over the air, Protecting the location privacy of mobile hosts.[Kempf06] The solution in this document could support the roaming of unmodified IPv4 mobile nodes within the localized Mobile IPv6 domain. Proxy Mobile IPv6 [PMIP6] provides the solution to support the unmodified IPv6 mobile nodes within NETLMM domain. This specifiction extends Proxy Mobile IPv6 to enable the unmodified IPv4 mobile stations to access the NETLMM domain by introducing a dual-stack mobility proxy agent (DMPA). Figure1 shows an example of providing the network access to IPv4 Mobile stations in IPv6 NETLMM domain. Similar to Proxy Mobile IPv6, DMPA will register to Dual-stack Local Mobility Anchor Point (DLMAP),which functions as a local Home Agent, on behalf of mobile stations. A IPv4 over IPv6 tuunel is set up between DMPA and LMAP for traffic from and to the mobile stations. DMPA should support IPv4/IPv6 dual stack and be responsible for the network access of IPv4 mobile station. LMAP should support IPv4/IPv6 dual stack to intercept data traffic for a Mobile Station. Yang & Deng Expires December 21, 2006 [Page 3] Internet-Draft IPv4/netlmm6/IPv4 June 2006 +----------+ | IPv4 Host| +----------+ Internet | -------------------------+----------------------------------------- NETLMM domain +----+ | +----+ |AAA |-----|DHCP| +----+ | +----+ | / \ / | \ / | \ / | \ / | \ / | \ +-----+ +-----+ +-----+ |DLMAP| |DLMAP| |DLMAP| +-----+ +-----+ +-----+ / \ / \ / \ / \ / \ / \ +-----+ +-----+ +-----+ +-----+ |DMPA | |DMPA | |DMPA | |DMPA | +-----+ +-----+ +-----+ +-----+ / \ / \ / \ / \ / \ / \ / \ / \ +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ |BS| |BS| |BS| |BS| |BS| |BS| |BS| |BS| +--+ +--+ +--+ +--+ +--+ +--+ +--+ +--+ | | /:\ /:\ : : : : +-------+ +-------+ |IPv4 MS| |IPv4 MS| +-------+ +-------+ Figure 1: IPv4 Mobile stations in NETLMM domain After mobile station has successfully registered on DLMAP, All the packets sent to the mobile node's IPv4 home address should be intercepted by DLMAP and be tunneled to DMPA. DMPA will decapsulate the IPv6 tunnel packet and send the inner IPv4 packet to the mobile station directly. The mobile station does not need to do any tunnel encapsulation or decapsulation to send/receive IPv4 packets. In this solution, mobile station's upper layer can not detect its movement. DMPA shall register the location on DLMAP, which makes the Yang & Deng Expires December 21, 2006 [Page 4] Internet-Draft IPv4/netlmm6/IPv4 June 2006 mobile station believe that it remains on the same network. Yang & Deng Expires December 21, 2006 [Page 5] Internet-Draft IPv4/netlmm6/IPv4 June 2006 2. conventions used in this document 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 BCP 14, [RFC2119]. The following new terminology and abbreviations are introduced in this document and all the other general mobility related terms as defined in [RFC3775] and [PMIP6]. Dual-stack Mobility Proxy Agent (DMPA) The dual stack Mobile IPv6 function that offers proxy mobility services for IPv4 mobile stations. Mobile Station Any IPv4 node that has the ability to access to different networks. It does not have mobile IP protocol stack. Dual-stack Local Mobility Anchor Point (DLMAP) The dual-tack mobile IP entity which functions as a local Home Agent to intercept data traffic for both IPv4 and IPv6 Mobile Station. IPv4 Home Address Option The Mobile IPv6 option that indicate the IPv4 home address of the MS to DMPA and DLMAP. Yang & Deng Expires December 21, 2006 [Page 6] Internet-Draft IPv4/netlmm6/IPv4 June 2006 3. overview of this solution In the case of mobile IPv6 network in picture 1, DMPA coule be deployed on BS or AR. In the meanwhile, the BS/AR could provide the IPv6 access as well with dual stack support. But, it is out of the scope of this document. The picture below depicts the both cases: VAAA <========================>HAAA // \\ DMPA@BS: MS <--(IPv4)--> BS/DMPA <======(MIPv6)=========> DLMAP VAAA<==============>HAAA // \\ DMPA@AR: MS <-(IPv4)-> BS <-(IPv4)-> AR/DMPA <===(MIPv6)===> DLMAP Figure 2: DMPA location cases 3.1. definition of the messages This section defines the extensions and options to the Proxy MIPv6 messages. 3.1.1. Proxy BU for IPv4 Mobile Station 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|M|R|P|V| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Just like [PMIP6], int this solutions the P bit should be set to 1 to indicate that Proxy MIPv6 is used. A new bit, the 'V' bit is added to the Proxy BU message. This 'V' bit indicates that the registration is for IPv4 MS only. When a DMPA sends a proxy BU to DLMAP, the V bit MUST be set to 1 make the DLMAP knows that this registration is a proxy registration on behalf of an IPv4 MS. When V bit is set to 1, DLMAP SHALL NOT set up MIPv6 binding entry upon receiving the proxy BU even if the home address options [RFC3775] is included. When the V bit is set to 0, the binding update message with IPv4 home address option could register the dual-stack MS to DLMAP [Soliman]. Yang & Deng Expires December 21, 2006 [Page 7] Internet-Draft IPv4/netlmm6/IPv4 June 2006 3.1.2. Proxy BA for IPv4 Mobile Station 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status |K|R|P|V| Resv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The 'V' bit is set to 1 only if the corresponding proxy binding update has the IPv4 MS flag set to 1. The P flag SHOULD be 1 for IPv4 MS registration. 3.1.3. IPv4 Home Address (HoA) option 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 | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Home Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD. Sequence number This sequence is corresponding to the IPv4 MS. DLMAP is repsonsible to maintain the order of the IPv4 MS's registration. It SHOULD be assigned by DLMAP and shared between DMPA and DLMAP for registered IPv4 MS. IPv4 Home Address This address could be public or private unicast IPv4 address for MS. When IPv4 HoA is assigned by DLMAP dynamically, this SHOULD be 0.0.0.0 in Proxy BU If each DMPA works independently the registration from previous DMPA may cause the problem of "out of order". In order to maintian the right sequence order, DLMAP assigns a sequence number to DMPA in the Proxy BA, when DMPA registers for the first time on behalf of one IPv4 MS. Then subsequent proxy BU for the IPv4 MS could contain the Yang & Deng Expires December 21, 2006 [Page 8] Internet-Draft IPv4/netlmm6/IPv4 June 2006 right sequence. The sequence number in the MIPv6 BU header is corresponding to the DMPA. 3.2. registration procedure In this solution, mobile station could do roaming in the mobile IPv6 network without any mobility related signaling. The picture below shows the sequence of steps when mobile station attachs to the mobile IPv6 network. MS DMPA VAAA DLMAP HAAA | IPv4 Access | | | | | to DMPA | | | | 1) x-------------x | | | | | AAA Request | | 2) | o---------->| | | | | o------------------------->| | | | | o MS Auth | | | AAA Reply | | | |<-------------------------o 3) | |<----------o | | | | | | | | o DMPA Get | | | | Auth Success| MS Profile| | | 4) x-------------x | | | | | | | | | | Proxy MIP6 BU with | | | | IPv4 HoA option | | 5) | o---------------------->| | | | | | | | | | o Binding Cache| | | | | update | | | Proxy MIP6 BA with | | | | IPv4 HoA option | | 6) | |<----------------------o | | | | | | | | If code is success | | | o in BA, set up tunnel | | | | between DMPA and DLMAP| | | | | | | 7) | |<----------o | | | | | | | Figure 6: network access call flows The control flows after MS attached to DMPA includes: Yang & Deng Expires December 21, 2006 [Page 9] Internet-Draft IPv4/netlmm6/IPv4 June 2006 - network access authentication 1) mobile station attachs to the network 2) DMPA sends the AAA request to the HAAA server via VAAA server 3) HAAA does the network accesss authentication and sends the MS profile to DMPA by AAA reply (In this case, network authentication is assumed to be success). 4) network access authentication success. MS could do the address acquisition. - Proxy mobile IPv6 5) When mobile station's address acquisition is detected, the Proxy binding update message with IPv4 HoA option is sent to DLMAP. The 'P' bit and 'V' bit MUST be set to 1. On DLMAP, the related Binding Cache Entry (BCE) is updated according as the NAI information in the Mobile Node Identifier Option[Patel05]. 6) DLMAP sends the Proxy BA with IPv4 HoA option to DMPA. 7) If the proxy BA received by DMPA contains successful code, the tunnel is set up between DLMAP and DMPA. The following figure shows the procedure when MS handover from old DMPA (oDMPA) to new DMPA (nDMPA). Yang & Deng Expires December 21, 2006 [Page 10] Internet-Draft IPv4/netlmm6/IPv4 June 2006 MS oDMPA nDMPA DLMAP | IPv4 move | | | | to nDMPA | | | 1)x-------------------------x | | | | Proxy MIP6 BU with | | | | IPv4 HoA option | 2)| | o------------------------->| | | | | | | | oBCE | | | |update | | Proxy Binding Revocation with | | | IPv4 HoA option | 3)| |<-------------------------------------o | | | | |Remove visit o | | |Entry for MS | | | | | Proxy Binding Revocation Ack. with | | | IPv4 HoA option | 4)| o------------------------------------->| | | | Proxy MIP6 BA with | | | | IPv4 HoA option | 5)| | |<-------------------------| | | | | | | o set up tunnel between | | | | nDMP and DLMAP | Figure 7: call procedures during handover The control flows include: 1) MS moves to nDMPA after successful network access authentication 2) nDMPA send the proxy BU with IPv4 HoA option on behalf of MS. 'P' bit and 'V' bit are both set to be 1. DLMAP SHOULD check the BCE. If the BCE with oDMPA exists, the proxy binding revocation message should be sent to oDMPA. The IPv4 HoA option should be included in this revocation message[Haley05]. 3) Upon receiving the proxy binding revocation message, oDMPA removes the visiting entry for the IPv4 MS. 4) The acknowledgement is sent by oDMPA for the revocation. Yang & Deng Expires December 21, 2006 [Page 11] Internet-Draft IPv4/netlmm6/IPv4 June 2006 5) Then, DLMAP sends the Proxy BA with the IPv4 HoA option to the nDMPA. 3.3. error code This sub-section defines the status code values in the proxy BA message for this solution 142: IPv4 Home Address unavailable 143: Invalid IPv4 address 3.4. packet forwarding All the IPv4 packets from the MS to the other IPv4 hosts will be sent as normal IPv4 packets setting the source address to the HoA and the destination address to the other host's IPv4 address. The default gateway for the MS will always be the DLMAP's IPv4 address. The ARP Entry for DLMAP address is a pseudo DLMAP MAC address. DMPA MUST be able to intercept all IPv4 packets sent from the MS and forward them to DLMAP by via the IPv6 tunnel. DLMAP MUST be able to decapsulate the IPv6 tunnel packets received on its IPv6 stack and transfer the inner IPv4 packets from MS to its IPv4 stack. Then the IPv4 packets could be sent to other IPv4 hosts. DLMAP MUST be able to intercept all the IPv4 packets to registered IPv4 MS on its IPv4 stack. The IPv4 packets then SHOULD be transfered to the IPv6 stack and sent out the DMPA/DLMAP tunnel created for supporting the MS. In DMPA, the tunneled packets are received by the IPv6 stack. The inner IPv4 packets are extracted and sent out to MS by the IPv4 stack of DMPA. Yang & Deng Expires December 21, 2006 [Page 12] Internet-Draft IPv4/netlmm6/IPv4 June 2006 4. mobile station consideration In this solution, the MS would work as a normal IPv4 host. It should have the behavior consistent with the base IPv4 specification [RFC2119]. When the MS access the network and attaches to the DMPA for the first time, it could present its identity in the form of NAI to the network during the network access authentication. When MS moves to new DMPA of the same DLMAP domain, the IP address MUST be retained unchanged, which makes the MS believe that it is on the same link as the home link. The MS may detect its movement in the Link layer. The network side (DMPA) SHOULD process the DHCP, ARP and ICMP behavior of MS to deceive the upper link that MS is still on the same link. If MS moves to the DMPA of the different domain with another DLMAP, it need the mobile IP stack to support the handover across domains. 4.1. Address configuration The IPv4 HoA could be manuely configured in MS. When MS access to the network for the first time, it could use DHCP to obtain an IPv4 HoA from the home network. If PPP [RFC1331] is used for MS, the network access authentication could be done during LCP. After the authentication, the NAS (here is DMPA) will send the proxy BU with IPv4 HoA option to DLMAP. After receiving the successful proxy BA with IPv4 HoA option, the NAS will notify MS the HoA using IPCP [RFC1332] Yang & Deng Expires December 21, 2006 [Page 13] Internet-Draft IPv4/netlmm6/IPv4 June 2006 5. Dual-stack Mobility Proxy Agent consideration In the MIPv6 network, DMPA works as the mobile nodes. It sends the proxy BU with IPv4 HoA option to DLMAP to set up the tunnel for MS. In order to providing the mobility service to IPv4 MS, DMPA MUST at least support IPv4 stack. Upon sending the proxy BU message to DLMAP, DMPA should at least know the following information of MS profile: - NAI of MS - the IPv6 address of DLMAP - the authentication credentials - the IPv4 default gateway address (optional) This profile could be gained by the ways described in [PMIP6]. DMPA MUST perform the tunnel capsulation/decapsulations for the IPv4 packets from/to MS as described in section 4.4. 5.1. maintenance of the visitor list All the DMPA MUST maintain a visitor list for all the served IPv4 MS. Every list entry is for one MS and should have following items: - The NAI of the MS. This is provided by MS and used for MS profile downloading - MAC address of MS - HoA of MS - Source address of the tunnel, which is a routable IPv6 address in DMPA - Destination address of the tunnel, which is a routable IPv6 address of DLMAP - psudo MAC address or common MAC address shared by all the DMPA in the same field. This is used to handle the ARP request message from MS Yang & Deng Expires December 21, 2006 [Page 14] Internet-Draft IPv4/netlmm6/IPv4 June 2006 - Address of MS's default gateway. This is used to handle the ICMP query message from MS - The sequence number of MS. This is assigned by DLMAP in proxy BA and used for the right order of the MS related proxy MIPv6 messages 5.2. DHCP consideration This solution allows for the normal IPv4 operation of MS using the standard DHCP to configure the IP address. When MS attachs to the network and trigger the DHCP, MPA tunnels the DHCP message to DLMAP in IPv4 in IPv6 tunnel. DLMAP will carry out the DHCP relay in this case. Upon receiving the DHCP ack message tunneled from DLMAP, DMPA will send the proxy BU message to set up the routing for MS. After the IP address configuration, MS could send the DHCP request message to DHCP server directly for IP address renewal. The IP-IP tunnel between DMPA and DLMAP will be used for the routing of the DHCP messages exchanged between MS and DHCP server. 5.3. ARP consideration In the IEEE 802 type access networks, the host sends ARP request for other hosts and default gateway on its attached links. The host will maintain the ARP entries for delivery of the packets to the links. In this solution, the default gateway of MS is the IPv4 address of DLMAP DMPA will intercept the packets from MS to DLMAP. In MS, the ARP entries for default gateway and other hosts could be set to be a common MAC address for all the DMPA in current domain. If DMPA is on BS, the ARP entries on MS could be set as a psudo MAC that is never be used. If DMPA is on AR, BS could modify the destination MAC address from MS properly to reach DMPA. All the ARP entries for the default gateway nad other hosts 5.4. ICMP consideration As described in [RFC0792], the MS may send ICMP query message to the default gateway. The TTL of this ICMP message is 1. This is to ensure that the default gateway is still reachable on the link. DMPA should give a echo of this ICMP query to the MS served by it. Yang & Deng Expires December 21, 2006 [Page 15] Internet-Draft IPv4/netlmm6/IPv4 June 2006 6. Dual-stack Local Mobility Anchor Point consideration In addition to the home agent specification in [RFC3775] and [PMIP6], DLMAP MUST be able to process the proxy BU with 'V' bit and IPv4 HoA option and generate the proxy BA with 'V' bit set to 1 and IPv4 HoA option. When the DLMAP receives a proxy BU with IPv4 HoA option, it should follow all the required steps in [RFC3775] and [PMIP6], in addition, the following checks MUST be done: - If the 'V' bit is set to 1 and the IPv4 HoA option has a valid unicast IPv4 address, DLMAP must check that this address is allocated to the MS. - If the 'V' bit is set to 1 and the IPv4 HoA option has the all 0 address, DLMAP should allocate a valid IPv4 HoA to MS. If the it is not available, DLMAP should send the error code to DMPA. - If the proxy BU is accepted, DLMAP must create the binding cache entry for the MS's IPv4 HoA. The destination address of the tunnel should be stored as the Care-of Address (CoA) of the MS. This could be obtained from the source address field in the IPv6 header of proxy BU or by the alternate Care-of Address option [RFC3775] if present. A sequence number MUST be assigned to this MS. - After building the entry for MS, DLMAP must create a proxy BA message to DMPA. The 'V' bit should be set to 1. The IPv4 HoA option MUST be included with the HoA and assigned sequence number inside. If the 'V' bit is set to 1, DLMAP must not create the IPv6 binding cache entry even if the proxy BU contains the IPv6 Home Address option [RFC3775]. Given the NAI of MS, DLMAP MUST be able to find the IPv4 home address of the MS and store it in the binding cache entry. This address could be static or dynamically assigned. Upon the receiving of the proxy BU from DMPA, the DLMAP look up the BCE by NAI. If BCE exists, DLMAP will compare the sequence number between the one in IPv4 HoA option and BCE. it the value in the option is zero or greater than or equal to the one in BCE, DLMAP will accepts this registration. In the IPv4 HoA option of the proxy BA reply, DLMAP will include a sequence number that is one greater than the larger value of either the BCE or proxy binding BU. If the registration is denied, DLMAP sends the error code "administratively prohibited" (129). Yang & Deng Expires December 21, 2006 [Page 16] Internet-Draft IPv4/netlmm6/IPv4 June 2006 Upon the receiving of the proxy BU from DMPA, the DLMAP look up the BCE by NAI. If BCE exists and the address of the DMPA is different from the one in BCE, DLMAP will send the proxy binding revocation message to the old DMPA and update the BCE with the IPv6 address of the new DMPA. When building the proxy BA message, DLMAP should follow the rules in [RFC3775] and [PMIP6]. The routing heaader MUST always contain the IPv6 address of DMPA as described in [RFC3775]. After the MS's IPv4 HoA has successfully registered in DLMAP, all the packets destinated to MS's IPv4 HoA MUST intercepted by DLMAP. They are encapsulated in the IPv6 tunnel between DLMAP and DMPA and sent out to DMPA. Because MS and other hosts use the IPv4 address for communication, the route optimization [RFC3775] method will not be used in this solution. Yang & Deng Expires December 21, 2006 [Page 17] Internet-Draft IPv4/netlmm6/IPv4 June 2006 7. Security Considerations This solution introduces new mobility funtion, DMPA. Network Access Authentication and authorization MUST be done prior to the proxy binding messages. DMPA does the proxy MIPv6 registration on behalf of MS, so the security association should be set up between DLMAP and DMPA for securing the signaling. MS's identity, NAI is used during network authentication and proxy MIPv6 registration. Therefore, in order to authenticate the IPv4 HoA of MS, DLMAP MUST store the IPv4 HoA corresponding to the NAI of MS. The message MUST be pretected by IPsec or using an Authentication Option [Patel05b]. Yang & Deng Expires December 21, 2006 [Page 18] Internet-Draft IPv4/netlmm6/IPv4 June 2006 8. IANA Considerations This document defines one new flag 'V' to the binding update and binding acknowledgement messages. This flag should be allocated from the same space used by the flags in binding update and binding acknowledgement messages in [RFC3775]. This document defines one option, IPv4 HoA option. It is a mobility option as defined in the base IPv6 specification [RFC2460]. The IANA should assign a value for the type value of this option. This document defines one new status code to binding acknowledgement message. This flag should be allocated from the same space used by the binding acknowledgement message status codes in [RFC3775]. 9. Reference [Dawkins06] Dawkins, Ed., S., "Softwire Problem Statement", May 2006, . [Haley05] Haley, B. and S. Gundavelli, "Mobility Header Signaling Message", Oct 2005, . [Kempf06] Kempf, J., "Problem Statement for Network-based IP Local Mobility", Jul 2006, . [Kempf06b] Kempf, J., Leung, K., and al. et, "Goals for Network-based Localized Mobility Management (NETLMM)", Apr 2006, . [PMIP6] Gundavelli, S. and K. Leung, "Localized Mobility Management using Proxy Mobile IPv6", Nov 2005, . [Patel05] Patel, A. and al. et, "Mobile Node Identifier Option for MIPv6", Sep 2005, . [Patel05b] Patel, A. and al. et, "Authentication Protocol for Mobile IPv6", Sep 2005, . Yang & Deng Expires December 21, 2006 [Page 19] Internet-Draft IPv4/netlmm6/IPv4 June 2006 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1331] Simpson, W., "The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to- Point Links", RFC 1331, May 1992. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [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. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [Soliman] Soliman, H. and G. Tsirtsis, "Dual Stack Mobile IPv6", Jul 2005, . Yang & Deng Expires December 21, 2006 [Page 20] Internet-Draft IPv4/netlmm6/IPv4 June 2006 Authors' Addresses Peng Yang Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: pyang@hitachi.cn Hui Deng Hitachi (China) Beijing Fortune Bldg. 1701 5 Dong San Huan Bei-Lu Chao Yang District Beijing 100004 China Email: hdeng@hitachi.cn Yang & Deng Expires December 21, 2006 [Page 21] Internet-Draft IPv4/netlmm6/IPv4 June 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. Yang & Deng Expires December 21, 2006 [Page 22]