Mobile IP                                              Changwen Liu  
INTERNET DRAFT                                                Intel  
draft-liu-mobileip-mipv6tomipv4-00.txt                      May 2002  
                                                                   
     
       Connecting Mobile IPv6 Nodes Across IPv4 Clouds Back  
                  To IPv6 Domains With Mobile IPv4 
     
     
Status of this Memo  
     
     This document is an Internet-Draft and is in full conformance 
     with all provisions of Section 10 of RFC2026 [1].  
     
     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.  
     
     
1. Abstract  
     
   This document specifies a mechanism for Mobile IPv6 nodes of IPv6 
   Site to continue utilizing Mobile IPv6 services when they roam 
   into IPv4 domains. The mechanism is based on Mobile IPv6 and 
   Mobile IPv4 glued together by IPv4 encapsulation for delivering 
   IPv6 packets between the Mobile IPv6 nodes and their Mobile IPv6 
   home agents. To support the mechanism specified in this draft, the 
   Mobile IPv6 nodes MUST be Mobile IPv4 capable and MUST NOT utilize 
   Mobile IPv6 route optimization when in IPv4 domain, and some of 
   the border routers of the site MUST be capable to act as Mobile 
   IPv4 home agent(s). The IPv6 site does not need to run 6to4 
   protocol, however.  
     
    
    
    
    

 
Liu                     Expires 11/2002                   [Page i]                                                                       

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
    
                         Contents  
                           
Status of This Memo                                                 i  
  
Abstract                                                            i  
  
1. Introduction                                                     2  
  
   1.1 Terminology                                                  2  
  
2. Protocol Overview                                                2  
  
   2.1 Mobile Node Roams From IPv6 Domain Into IPv4 Domain          2  
       
   2.2 Packet Routing For MN Roaming into An IPv4 Domain            5  
  
   2.3 Mobile Node Roams From IPv4 Domain Into IPv6 Domain          6  
  
   2.4 Benefits                                                     6  
  
3. Mobile IPv4 Home Agent Considerations                            7  
   
4. Mobile Node Considerations                                       8  
  
   4.1 Configurations                                               8  
  
   4.2 Mobile IPv4 Registration and Mobile IPv6 Binding Update      9  
  
   4.3 Route Optimization                                           9  
  
   4.4 Detection of Movement to IPv4 Domain                         9 
            
   4.5 Establishing Forwarding from Previous CoA at Home Site       9  
 
   4.6 IPv4 Encapsulation and Decapsulation Requirement           10 
  
   4.7 IPv4 NAT and Firewall Traversal                             10 
   
5. Mobile IPv6 Home Agent Considerations                           10  
  
6. Mobile IPv4 Foreign Agent Considerations                        10  
       
7. Security Considerations                                         10  
  
8. Intellectual property rights                                    11  
  
9. Acknowledgements                                                11  
 

 
Liu                   Expires 11/2002                   - 1 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
1. Introduction  
     
   Mobile IPv6 [5], based on Mobile IPv4 [7] and developed as an  
   integrated part of IPv6 protocol suite, enables IPv6 nodes to 
   connect to networks and access and be accessible to their home 
   networks (the link on which their home IPv6 subnet prefixes are in 
   use) while the nodes are away from home. Like Mobile IPv4, Mobile 
   IPv6 is transparent to all IPv6 applications running on these 
   devices. Mobile IPv6 enabled devices, however, require a full IPv6 
   infrastructure deployment and work only within IPv6 networks. To 
   really spur the growth of IPv6 networks, it is necessary for the 
   Mobile IPv6 nodes to continue functioning even when they roam into 
   non-IPv6 domains, in particular IPv4 domains. This document 
   specifies a mechanism for Mobile IPv6 nodes of IPv6 site to 
   continue utilizing Mobile IPv6 services when they roam into IPv4 
   domains.  
     
1.1. Terminology  
     
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 
   in this document are to be interpreted as described in RFC 2119 
   [2].  
     
   In addition, this document frequently uses the following terms:  
     
   CoA  
        Care-of Address in both Mobile IPv4 and Mobile IPv6.  
     
   MN  
        Mobile Node in both Mobile IPv4 and Mobile IPv6.  
     
   IPv6 site 
        A site that runs IPv6. Usually it consists of multiple IPv6 
        links or subnets, e.g. an IPv6 site that runs global unicast 
        address family [11] has fixed TLA ID and NLA ID and each 
        subnet of the site is identified by the SLA ID.   
    
2. Protocol Overview  
     
   This section specifies the proposed mechanism and its benefits.  
      
2.1  Mobile Node Roams From IPv6 Domain Into IPv4 Domain  
     
   When a Mobile IPv6 node MN roams into IPv4 domains, as illustrated 
   in Figure 2.1 below, the MN first performs Mobile IPv4 agent 
   discovery and obtains either an IPv4 co-located or foreign agent 
   CoA. Note that the Mobile IPv6 MN MUST also support Mobile IPv4 MN 
   functionality for this to occur. The MN then performs a Mobile 
   IPv4 registration with a pre-configured border router that acts as  
 
Liu                   Expires 11/2002                   - 2 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
    
    
                  Mobile IPv6  
                        MN   
                         \  
                          \                            IPv6 Site  
                         IPv4 link                       /  \    
                            \                           /    \  
                             \_______                  /      \  
                                     \                /        \  
                                      \              /          \  
    Mobile IPv6 --- IPv4  - FA ----- IPv4 ---- Border ----Mobile IPv6   
         MN         link          Internet     Router          HA  
     
        Figure 2.1    Mobile IPv6 Nodes Roam into IPv4 domains  
     
   the MN's Mobile IPv4 Home agent as showed in Figure 2.2. If the MN 
   does not already have an IPv4 home address, it needs to get the 
   address from the border router with mechanisms such as NAI  
    
        MN                       Border Router        Mobile IPv6 HA   
          |   Mobile IPv4 Reg. Request   |                         |  
          |----------------------------->|                         |  
          |   Mobile IPv4 Reg. Reply     |                         |  
          |<-----------------------------|                         |  
          |                              |                         |   
          |          Mobile IPv6 Binding Update                    |  
          |------------------------------|------------------------>|  
          |          Mobile IPv6 Binding Acknowledgement           |  
          |<-----------------------------|-------------------------|  
     
          Figure 2.2 Registration and Binding Update of MN   
     
   Extension specified in [3, 7] during the Mobile IPv4 registration 
   process. The MN then constructs a 6to4 address based on its Mobile 
   IPv4 home address, creates and binds a 6to4 pseudo-interface to 
   the address locally. For example, if the MN has an IPv4 home 
   address 10.14.10.12, it can use the 6to4 address 
   2002:0A0E:0A0C::1/48 or 2002:0A0E:0A0C::1/64 as its Mobile IPv6 
   CoA. Essentially, a degenerated 6to4 site that consists of the MN 
   itself acting as both a host and a router is created. As showed in 
   Figure 2.2, upon successful completion of Mobile IPv4 
   registration, the MN performs the normal Mobile IPv6 binding 
   update with its Mobile IPv6 home agent. The binding update 
   specifies the MN's 6to4 address derived from its Mobile IPv4 home 
   address as its Mobile IPv6 primary CoA and is sent to its Mobile 
   IPv6 home agent HA via the 6to4 pseudo-interface. The binding 
   update messages are transferred as IPv4 encapsulated [8] and 
   Mobile IPv4 tunneled data packets as elaborated in the following 
   two cases  
 
Liu                   Expires 11/2002                   - 3 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
   1. Mobile IPv6 Binding Update packet: IPv4 encapsulation with  
   source address as MN IPv4 home address and destination address as 
   the border router address, which results in an IPv4 packet, is 
   applied first, followed by the Mobile IPv4 encapsulation by the MN 
   or a foreign agent. The packet is sent to the border router which 
   decapsulates the two outermost IPv4 encapsulations and forwards 
   the resulting packet to Mobile IPv6 home agent.  
   2. Mobile IPv6 Binding Acknowledgement packet: The Mobile IPv6 
   home agent replies to the binding update with the binding 
   acknowledgement destined to the MN's 6to4 address in the binding 
   update and sourced at the Mobile IPv6 home agent address. The 
   preconfigured border router that acts as the Mobile IPv4 home 
   agent of the MN will get the Binding Acknowledgement packet via 
   the sites internal routing mechanisms (see Section 3) and 
   encapsulate it with an IPv4 header with source address as the 
   border router exterior IPv4 address and destination address as MN 
   IPv4 home address. The IPv4 encapsulated packet will then be 
   forwarded to the MN using the border router's Mobile IPv4 mobility 
   binding over the IPv4 tunnel between the MN's Mobile IPv4 CoA and 
   the border router's exterior IPv4 address. The MN will decapsulate 
   the encapsulated packet and retrieve the original Mobile IPv6 
   binding acknowledgement.  
    
   Notice that in case 1, MN has to encapsulate all packets out of 
   its 6to4 pseudo-interface with an IPv4 header no matter whether 
   the destination is a 6to4 address or not, and the border router 
   has to decapsulate IPv4 packets with type 41 and route the IPv6 
   packets inside; in case 2, the border router has to encapsulate 
   all packets destined to 6to4 addresses with an IPv4 header no 
   matter whether the source address is a 6to4 address or not, and MN 
   has to decapsulate IPv4 packets with type 41 to retrieve IPv6 
   packets inside. If the IPv6 site runs 6to4 protocol and the MN’s 
   home agent address in case 1 and 2 is 6to4 address, then the 
   aforementioned encapsulations and decapsulations at MN and the 
   border router are naturally provided by the 6to4 protocol. 
   Otherwise, behavior changes at MN and the border router are 
   required. 
    
   In the above process, except for the initial Mobile IPv4 
   registration that is used to set up a Mobile IPv4 tunnel, the 
   Mobile IPv4 registration and Mobile IPv6 binding update are 
   independent of each other. For example, if a Mobile IPv6 binding 
   update is still valid when the MN moves to another IPv4 domain, 
   the MN only needs to perform a Mobile IPv4 registration. If the MN 
   roams into an IPv4 domain from its home site where its home IPv6 
   address is located, then in parallel to the MN's binding update 
   with its Mobile IPv6 home agent, MN MAY also send a binding update 
   to any home agent on the link on which the previous CoA is located 
   with the destination address as an IPv6 address of the home agent 
   and the newly derived 6to4 address as the CoA of MN. Similarly, 
 
Liu                   Expires 11/2002                   - 4 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
   the binding update messages are transferred as IPv4 and Mobile 
   IPv4 tunneled data packets.   
     
   With the IPv4 encapsulation [8] as the glue, Mobile IPv6 is 
   layered on top of Mobile IPv4 to deliver IPv6 packets between the 
   MN and its Mobile IPv6 home agent HA as described next. The 
   mechanism requires that the Mobile IPv6 route optimization feature 
   with MN be disabled entirely. 
          
2.2 Packet Routing For MN Roaming into An IPv4 Domain  
     
   When the MN's Mobile IPv6 home agent HA receives an IPv6 packet  
   addressed to the MN, the HA forwards the packet to the MN using 
   MN's Mobile IPv6 binding cache entry over the IPv6 tunnel between 
   MN's Mobile IPv6 CoA and the HA address. The pre-configured border  
   router that acts as the Mobile IPv4 home agent of the MN will get 
   the tunneled IPv6 packet via the site's internal routing 
   mechanisms (see Section 3) and encapsulate it with an IPv4 header 
   with destination address as MN IPv4 home address and source 
   address as the border router IPv4 address according to [8]. The 
   IPv4 encapsulated packet will then be forwarded to the MN using 
   the border router's Mobile IPv4 mobility binding over the IPv4 
   tunnel between MN's Mobile IPv4 CoA and the border routers’ 
   exterior IPv4 address. For FA-located CoA, the FA performs one 
   decapsulation and delivers the decapsulated packet to the MN. The 
   MN performs two consecutive decapsulations to retrieve the 
   original IPv6 packet and forwards the packet to upper layers of 
   its protocol stack. If the MN's IPv4 home address is private (i.e. 
   not globally routable), the FA SHOULD support the delivery of 
   packets to the MN as specified in [6]. For co-located CoA, the MN 
   performs the three decapsulations by itself. Figure 2.3 shows the 
   packet traffic flow in this forward direction for the co-located 
   CoA case.  
    
         MN                   Border Router                    Mobile   
                                                              IPv6 HA   
         |                             |                           |           
         |                             |     IPv6/IPv6 Traffic     |  
         |                             |< -------------------------|   
         |  IP/IP/IPv6/IPv6 Traffic    |                           |  
         |< -----------------------    |                           |  
           
         Figure 2.3   Packet Flow in Forward Direction  
     
   Mobile IPv6 [5] allows a mobile node to send a Binding Update to a   
   router on the link on which its previous care-of address is 
   located, for purposes of establishing forwarding from this 
   previous care-of address to its new care-of address. This feature 
   is still supported by the mechanism of the draft for the situation 
   when MN roams from its home IPv6 site into IPv4 domains. The 
 
Liu                   Expires 11/2002                   - 5 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
   mechanism works similarly for such forwarding as that from MN's 
   Mobile IPv6 home agent HA to MN.  
     
   When the MN sends an IPv6 packet using this mechanism, it must  
   reverse tunnel the packet to the MN's Mobile IPv6 HA using the 
   Mobile IPv6 binding between its Mobile IPv6 CoA (a 6to4 address) 
   and its Mobile IPv6 HA address. The reverse tunneled packet is 
   again encapsulated in an IPv4 header sourced from MN IPv4 home 
   address and destined to the border router IPv4 address according 
   to the IPv4 encapsulation [8]. When using FA-located CoA and 
   Mobile IPv4 reverse tunneling, the twice-encapsulated packet is 
   delivered to the FA, which encapsulates it again and routes it 
   towards the pre-configured home site border router. When using co-
   located CoA and Mobile IPv4 reverse tunneling, the MN performs the 
   third layer of encapsulation and routes the resulting packet 
   towards the site border router directly. Finally, when Mobile IPv4 
   reverse tunneling is not in use, the MN may send the twice-
   encapsulated packet directly to the site border router. The site 
   border router decapsulates either the two IPv4 outer layers if 
   Mobile IPv4 reverse tunneling is utilized or just the one IPv4 
   outer layer otherwise. The site border router relays the inner 
   reverse tunneled IPv6 packet to the MN's Mobile IPv6 HA which 
   decapsulates the packet to retrieve the original IPv6 packet and 
   send away the original packet. Figure 2.4 shows the packet traffic 
   in the reverse direction for the Co-located CoA case.  
     
          MN                   Border Router           Mobile IPv6 HA   
           |  IP/IP/IPv6/IPv6 Traffic    |                          |  
           | --------------------------->|                          |  
           |                             |       IPv6/IPv6 Traffic  |   
           |                             | ------------------------>|   
           
         Figure 2.4   Packet Flow in Reverse Direction  
     
2.3 Mobile Node Roams From an IPv4 Domain Back Into IPv6 Domain  
     
   When the Mobile IPv6 node MN roams from IPv4 domain into IPv6 
   domain, which may or may not be its home site, MN follows Mobile 
   IPv6 to perform normal binding update and packet routing except it 
   MUST NOT send any binding updates to establish forwarding from the 
   6to4 CoA derived from its IPv4 home address.   
     
2.4 Benefits  
     
   The mechanism described in this draft enables Mobile IPv6 nodes of 
   an IPv6 site to retain Mobile IPv6 services seamlessly when they 
   move into IPv4 domains. The mechanism enables the Mobile IPv6 
   nodes whose Mobile IPv6 home agents can be anywhere in the site 
   and do not have any IPv4 addresses to initiate IPv6 communication 
   sessions with its home IPv6 addresses at anywhere (IPv6 domains 
 
Liu                   Expires 11/2002                   - 6 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
   and IPv4 domains) and roam seamlessly in both IPv4 and IPv6 
   domains. The authentication in Mobile IPv4 registration also 
   enables the border router to securely redirect the packet traffic 
   to MN IPv4 CoA and hence eliminates significant vulnerability in 
   the traffic redirection to MN. In particular, the mechanism does 
   not affect an IPv4 FA nor require any link-layer support for IPv6 
   on the (foreign) visited link. It can leverage existing Mobile 
   IPv4 deployments and alleviate the demand for public IPv4 
   addresses while supporting globally routable IPv6 addresses. The 
   proposed mechanism therefore enables immediate deployment of 
   Mobile IPv6 in IPv6 sites without the needs for an IPv6 
   infrastructure deployment everywhere and any changes to deployed 
   Mobile IPv4 infrastructure. The only restriction to this mechanism 
   is that Mobile IPv6 reverse tunneling is required when MN roams 
   into IPv4 domains and no Mobile IPv6 route optimization is 
   allowed.   
     
3. Mobile IPv4 Home Agent Considerations  
        
   The pre-configured site border router acts as the Mobile IPv4 home  
   agent for Mobile IPv6 MNs of the site. The border router manages a 
   pool of IPv4 addresses, which usually are globally non-routable 
   due to global routable IPv4 address space depletion. The address 
   pool forms a virtual network. The border router can allocate 
   addresses from the pool to MNs either statically at MN 
   configuration time or dynamically with registration requests and 
   mechanisms such as the NAI extension. The IPv4 addresses in the 
   pool are for delivering IPv6 packets in IPv4 domains and SHOULD 
   NOT be used for initiating IPv4 communication sessions by MNs. As 
   discussed in Secion 2.1, the border router MUST encapsulate all 
   packets destined to 6to4 addresses with IPv4 headers and 
   decapsulate IPv4 packets with type 41. This encapsulation and 
   decapsulation requirement changes border router normal behavior 
   slightly. However if the IPv6 site runs 6to4 protocol with this 
   border router as its 6to4 router, then the encapsulation and 
   decapsulation at the border router is naturally provided by the 
   6to4 protocol. For the incoming IPv4 packets from IPv4 domains, 
   the site border router can demultiplex IPv4-encapsulated packets 
   from Mobile IPv4 encapsulated packets by looking at the protocol 
   type field value of outer IP header and hence can apply proper 
   decapsulation process to received packets. For example, the 
   protocol type field value of the outer IP header is 4 for IPIP 
   tunneled Mobile IPv4 packets and 41 for IPv4 tunneled IPv6 
   packets.  
       
   If the IPv6 site is single homed on IPv4, then its only border 
   router is the Mobile IPv4 home agent. The Mobile IPv4 home agent 
   MUST advertise the 6to4 prefix 2002::/16 within the site. As a 
   result, all tunneled packets from the MN's Mobile IPv6 agent to MN 
   will be routed to the border router automatically. Notice that the 
 
Liu                   Expires 11/2002                   - 7 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
   IPv6 site does not need to run the 6to4 protocol even with 
   advertisement of 6to4 prefix 2002::/16 across the site by the 
   border router. 
     
   If the IPv6 site is multi-homed on IPv4, it may have multiple IPv4  
   border routers, one for each IPv4 address. Either one border 
   router can be chosen as the Mobile IPv4 home agent for all MNs of 
   the site or different border routers can be chosen as Mobile IPv4 
   home agents with the following two rules:  
   1. All MNs in an IPv6 subnet use the same border router. Again the 
   Mobile IPv4 home agent MUST advertise the 6to4 prefix 2002::/16 
   within the site. 
   2. Each border router manages a distinct pool of IPv4 addresses.   
   Either way, a site border router that is also a Mobile IPv4 home  
   agent MUST advertise more specific 6to4 prefixes than 2002::/16  
   within the site so that packets destined to the 6to4 addresses  
   derived from the IPv4 address pool it manages are explicitly 
   routed to this border router. For example, if a site border router 
   manages the IPv4 address pool 10.14.x.x/16, the border router MUST  
   advertise 2002:0A0E::/32 prefix within the IPv6 site so that all 
   IPv6 packets destined to an address whose first 32 bits are 
   2002:0A0E are routed to this router. An exception is that in the 
   first case, if other border routers do not advertise the 6to4 
   prefix 2002::/16 within the site, then the chosen Mobile IPv4 home 
   agent only needs to advertise the 6to4 prefix 2002::/16 within the 
   site. Also as in the 6to4 protocol case [4], the more specific 
   6to4 prefix than 2002::/16 MUST not be advertised onto exterior 
   native IPv6 routing domain. Therefore, if the IPv6 site also has a 
   native IPv6 connection to another IPv6 site, it MUST NOT advertise 
   more specific 6to4 prefixes than 2002::/16, e.g. the 
   aforementioned 2002:0A0E:/32 routing prefix, on that connection. 
     
4. Mobile Node Considerations  
     
4.1 Configurations   
     
   A Mobile IPv6 node MN that wants to utilize the mechanism 
   mentioned in this document MUST be Mobile IPv4 capable and MUST 
   use a pre-configured site border router as its Mobile IPv4 home 
   agent. All Mobile IPv4 configuration requirements apply. In other 
   words, MN MUST be pre-configured with an IPv4 netmask, and a 
   mobility security association with the site border router. Since 
   the MN's home network usually is a virtual network, the MN has to 
   be configured with the IPv4 address of the site border router. The 
   MN MAY be configured with its IPv4 home address statically, which 
   usually is private. If the mobile node is not configured with an 
   IPv4 home address, it MUST be configured with other parameters 
   such as NAI and be able to obtain an IPv4 address from the site 
   border router via other mechanisms such as using the Mobile IP NAI 
   extension [3]. The MN SHOULD NOT use its IPv4 home address to 
 
Liu                   Expires 11/2002                   - 8 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
   initiate any communication sessions other than to encapsulate 
   Mobile IPv6 packets, in particular if the IPv4 home address is 
   globally non-routable.  
     
4.2 Mobile IPv4 Registration and Mobile IPv6 Binding Update  
     
   When the MN first roams into IPv4 domains, the MN performs both  
   Mobile IPv4 registration and Mobile IPv6 binding update. If the MN  
   does not have an IPv4 address from its site border router as its  
   Mobile IPv4 home address, the MN has to get such an address from 
   the site border router first, e.g. using NAI extension, with the 
   Mobile IPv4 registration. No matter whether MN has a Mobile IPv4 
   home address or not, it MUST perform Mobile IPv6 binding update 
   only after the initial Mobile IPv4 registration is successful 
   since the Mobile IPv6 binding update is carried as data traffic of 
   Mobile IPv4. A successful registration reply and a successful 
   binding acknowledgement are needed to start tunneling IPv6 data 
   packets between the MN and MN's Mobile IPv6 HA. If any of the 
   steps fail, the MN has to notify the proper home agent to revoke 
   its registration or binding update that is successful in a prior 
   step. When MN Mobile IPv6 home agent advertises a list of IPv6 
   addresses, including a 6to4 address derived from MN Mobile IPv4 
   home agent, to MN, MN SHOULD pick the 6to4 address for all its 
   communications to its Mobile IPv6 home agent. 
     
4.3 Detection of Movement to An IPv4 Domain   
     
   The MN MUST be able to detect the fact that it has roamed into an  
   IPv4 only domain. Such detection mechanisms, however, are beyond 
   the scope of this document.  
     
4.4 Route Optimization  
    
   Mobile IPv6 route optimization MUST NOT be used with this 
   mechanism. The primary reason is due to the fact that IPv4 home 
   addresses of MNs utilizing the mechanism are usually private and 
   hence packets from corresponding nodes that reside at other sites 
   cannot be routed across the global IPv4 infrastructure toward the 
   MNs.  
     
4.5 Establishing Forwarding from a Previous CoA at Home Site  
     
   If the MN wants to send a binding update to any home agent on the  
   link on which the previous CoA is located when it roams into IPv4  
   domain from its home IPv6 site, the MN MUST be able to determine 
   that its previous point of attachment is within its home IPv6 
   site. There are a few ways to do that. For example, if the home 
   IPv6 site runs global unicast address family and MN sees in router 
   advertisement on the previous link the router address is a global 
   unicast address and the first 48 bits of the router address (TLA 
 
Liu                   Expires 11/2002                   - 9 -                                                                     

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
   ID + NLA ID) is the same as that of its Mobile IPv6 home agent, 
   then it knows that its previous link is on its home IPv6 site.  
     
   When the MN roams into IPv4 domain from a place other than its 
   home IPv6 site, it MUST not send the binding update to any home 
   agent on the link on which the previous CoA is located. Otherwise, 
   the binding acknowledgement may get lost and the packets forwarded 
   by the home agent on the link will not reach MN since the packet 
   may not reach MN's Mobile IPv4 home agent, in particular if MN's 
   IPv4 home address is private.  
     
4.6 IPv4 Encapsulation and Decapsulation Requirement 
    
   As discussed in Secion 2.1, MN MUST encapsulate all packets out of 
   its 6to4 pseudo-interface with an IPv4 header and decapsulate IPv4 
   packets with type 41 when in IPv4 domain. The encapsulation and 
   decapsulation requirement changes normal MN behavior slightly. 
   However if MN’s home IPv6 site runs 6to4 protocol and the MN’s 
   home agent utilizes its 6to4 address, then the encapsulation and 
   decapsulation at MN is naturally provided by the 6to4 protocol.  
    
4.7 IPv4 NAT Traversal  
     
   If the MN roams into an IPv4 NAT domain, the MN needs the NAT  
   traversal support. The mechanisms specified in [9, 10] may be 
   applied.  
     
5. Mobile IPv6 Home Agent Considerations  
     
   The MIPv6 home agent does not need to have any 6to4 addresses. 
   However if a potential Mobile IPv6 home agent in an IPv6 site has 
   6to4 address, it SHOULD advertise in its router advertisements 
   either all of its 6to4 addresses and prefixes or just the 6to4 
   address and prefix derived from the IPv4 address of the 6to4 
   border router which serves as the Mobile IPv4 home agent for MNs 
   served by that 6To4 router. And when replying to Home Agent 
   Address Discovery requests, the home agent SHOULD include either 
   all 6to4 addresses and prefixes or the aforementioned 6to4 address 
   for each home agent on the link in addition to other (native) IPv6 
   addresses.   
     
6. Mobile IPv4 Foreign Agent Considerations  
    
   If the MN's IPv4 home address is globally non-routable, foreign 
   agent SHOULD support delivering packets to MNs with private 
   addresses as in [6].  
     
7. Security Considerations  
     

 
Liu                   Expires 11/2002                   - 10 -                                                                      

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
   The author is not aware of any new security vulnerabilities 
   outside of those introduced by the use of IPv4 encapsulation, 
   Mobile IPv4, and Mobile IPv6. Mobile IPv4 registration SA 
   management on the site border router is outside of the scope of 
   the current draft.  
     
8. Intellectual property rights  
     
   Intel Corporation (hereafter Intel) has one or more patents or 
   patent applications that may be relevant to this internet-draft. 
   If any claims of these are necessary for implementing this 
   standard, any party will be able to obtain a license from Intel to 
   use any such patent claims under openly specified, reasonable, 
   non-discriminatory terms, free of charge, for the purpose of 
   implementing it.  
     
9. Acknowledgements  
     
   The author would like to thank Prakash Iyer, and Farid Adrangi of 
   Intel Corporation for their review and feedback on an earlier 
   version of this draft.  
     
References  
     
   [1] Bradner, S., "The Internet Standards Process, Revision 3," RFC   
       2026, October 1996.  
   [2] S. Bradner. Key words for use in RFCs to Indicate Requirement   
       Levels. Request for Comments (Best Current Practice) 2119,    
       Internet Engineering Task Force, March 1997.  
   [3] Pat R. Calhoun, and Charles E. Perkins, "Mobile IP Network  
       Access Identifier Extension for IPv4", RFC 2794, March 2000  
   [4] B. Carpenter, "Connection of IPv6 Domains via IPv4 Clouds",  
       RFC 3056, Feb. 2001   
   [5] David B. Johnson, Charles E. Perkins, and Jari Arkko "Mobility  
       Support in IPv6", draft-ietf-mobileip-ipv6-17.txt, May 2002,  
       work in progress.   
   [6] G. Montenegro, "Reverse Tunneling for Mobile IP", RFC 3024,  
       Jan. 2001.  
   [7] Charles E. Perkins editor "IP Mobility Support for IPv4", RFC 
       3220, Jan. 2002.  
   [8] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6  
       Hosts and Routers", RFC 2893, August 2000. 
   [9] Farid Adrangi, and Prakash Iyer, Mobile IPv4 Traversal Across   
       Firewalls, draft-adrangi-mobileip-natvpn-traversal-00,  
       November 13 2001, work in progress.  
   [10]O. H. Levkowetz, J. Forslow, and H. Sjostrand, “NAT Traversal  
       for Mobile IP using UDP Tunnelling”, draft-ietf-mobileip-nat- 
       traversal-02.txt, April 5, 2002, work in progress. 
   [11]R. Hinden, M. O'Dell, and S. Deering, “An IPv6 Aggregatable  
       Global Unicast Address Format”, RFC 2374, July 1998. 
 
Liu                   Expires 11/2002                   - 11 -                                                                      

Internet Draft     draft-liu-mobileip-mipv6tomipv4-00.txt     May 2002 
 
    
     
11. Author's Addresses  
     
      Changwen Liu  
      Intel Labs  
      2111 NE 25th Ave, JF3-206   
      Hillsboro, OR  97124  
      USA  
     
      Phone: +1 503 264 9262  
      FAX:   +1 503 264 3483  
      E-mail: changwen.liu@intel.com  
     
     
Full Copyright Statement  
     
      Copyright (C) The Internet Society (2001). All Rights Reserved.     
      This document and translations of it may be copied and  
      furnished to others, and derivative works that comment on or  
      otherwise explain it or assist in its implementation may be  
      prepared, copied, published and distributed, in whole or in  
      part, without restriction of any kind, provided that the above  
      copyright notice and this paragraph are included on all such  
      copies and derivative works. However, this document itself may  
      not be modified in any way, such as by removing the copyright  
      notice or references to the Internet Society or other Internet  
      organizations, except as needed for the purpose of developing  
      Internet standards in which case the procedures for copyrights  
      defined in the Internet Standards process must be followed, or  
      as required to translate it into languages other than English.  
     
      The limited permissions granted above are perpetual and will  
      not be revoked by the Internet Society or its successors or  
      assigns. This document and the information contained herein is  
      provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE  
      INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.  
                                                                                  
    
    






 
Liu                   Expires 11/2002                   - 12 -