NEMO Working Group Ryuji Wakikawa INTERNET DRAFT Keio Univ./WIDE 21 Feb 2005 Vijay Devarapalli Nokia Research Center Carl E. Williams KDDI Labs USA IPv4 Care-of Address Registration draft-wakikawa-nemo-v4tunnel-01.txt Status of This Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with RFC 3668. 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. Abstract The NEMO Basic support protocol [1] specifies the operation of a Mobile Router. The Mobile Router has a bi-directional tunnel to its Home Agent through which it reverse tunnels all traffic. When the Mobile Router roams and connects to an access network that only implements IPv4, it needs to use IPv6 transition tunneling mechanisms to reach its Home Agent. This will result in a NEMO tunnel inside a transition tunnel. This document describes protocol extensions to the NEMO Basic support protocol to maintain IPv6 connectivity for the Mobile Router via its Home Agent with IPv6-over-IPv4 encapsulation with no special boxes to be deployed anywhere in the network. R. Wakikawa et.al. [Page 1] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 Contents Status of This Memo 1 Abstract 1 1. Introduction 3 2. Terminology 4 3. Protocol Overview 4 4. Mobile IPv6 Extensions 5 4.1. IPv4 Care-of Address option . . . . . . . . . . . . . . . 5 4.2. Binding Update . . . . . . . . . . . . . . . . . . . . . 6 4.3. Binding Acknowledgment . . . . . . . . . . . . . . . . . 7 5. Securing the tunnel between the Mobile Router and the Home Agent 7 5.1. Packet Formats . . . . . . . . . . . . . . . . . . . . . 7 5.1.1. Binding Update and Binding Acknowledgement . . . 8 5.1.2. Mobile Prefix Discovery . . . . . . . . . . . . . 8 5.1.3. Mobile Network Traffic . . . . . . . . . . . . . 9 5.2. IPsec Configuration . . . . . . . . . . . . . . . . . . . 9 5.2.1. Binding Update and Acknowledgement . . . . . . . 9 5.2.2. Mobile Prefix Discovery . . . . . . . . . . . . . 10 5.2.3. Mobile Network Traffic . . . . . . . . . . . . . 11 6. Home Agent IPv4 Address Discovery 12 7. IPv4 Care-of Address Registration 12 7.1. Sending Binding Update . . . . . . . . . . . . . . . . . 12 7.2. Receiving Binding Update . . . . . . . . . . . . . . . . 13 7.3. Sending Binding Acknowledgment . . . . . . . . . . . . . 13 7.4. Receiving Binding Acknowledgment . . . . . . . . . . . . 14 7.5. IPv4 forwarding Setup . . . . . . . . . . . . . . . . . . 14 8. Applicability to Mobile IPv6 15 9. NAT Traversal 15 10. IANA Considerations 15 11. Security Considerations 16 12. Acknowledgements 16 R. Wakikawa et.al. [Page 2] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 1. Introduction The Network Mobility basic support protocol (NEMO) [1] describes the operation of Mobile Routers to enable session continuity for all nodes in the Mobile Network. This protocol is specified only for IPv6. There is some interest in deploying the NEMO protocol. However, the current Internet is based on both IPv4 and IPv6 protocols and we cannot assume that IPv6 will be deployed everywhere in the near future. To provide roaming for the Mobile Network, IPv6 support is required in wireless access networks. This is because the Mobile IPv6 [2] and the NEMO Basic Support protocols are not IP protocol independent. IPv6 was designed with integrated support for Mobile IP as a native IPv6 feature. Also, the Mobile IPv6 and the NEMO protocols are designed to use the rich feature set of IPv6; hence, there exists a tight coupling of mobility signaling and IPv6 used in the media plane. When a Mobile Router roams and connects to an IPv4 only access network, it needs to be able to reach its Home Agent through the IPv4 network. The Mobile Router could use IPv6 transition mechanisms [17] to reach the Home Agent. But this will result in a NEMO bi-directional tunnel inside a transition tunnel. In the current NEMO protocol all traffic from the Mobile Network is sent through the bi-directional tunnel between the Mobile Router and the Home Agent. This results in a high per-packet overhead. If the Home Agent can support transition tunneling mechanisms in addition to the Mobile IPv6 and NEMO functionality, then the tunnel overhead can be reduced. The bi-directional tunnel between the Mobile Router will serve as a transition tunnel in addition to providing mobility for the Mobile Network. This document describes extensions to the NEMO protocol to allow the Mobile Router and the Home Agent to use an IPv6-over-IPv6 tunneling for the bi-directional tunnel. There is some earlier work related to IPv6 Mobile Nodes and Mobile Routers roaming onto IPv4 access networks, "Dual Stack Mobile IPv6" [10] and "Doors" [11]. The protocol extensions described in this document have the following features. - The ability to use a variety of tunnels between Mobile Router and Home Agent. Possible tunnel types are IPv6-over-IPv4, and IPv6-over-UDP-in-IPv4 for NAT traversal, ESP protected IPv6-over-IPv4 tunnels, GRE tunneling, and UDP encapsulated ESP protected IPv6-over-IPv4 tunnels. R. Wakikawa et.al. [Page 3] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 - Reduced packet overhead because of the transition tunnel and the NEMO bi-directional tunnel being the same. - IPsec protection for the tunnels - NAT Traversal 2. Terminology Home Agent IPv4 Address The global IPv4 address of the Home Agent. This address should be reachable from the Mobile Router's IPv4 access network. IPv4 Care-of Address The Care-of address acquired by the Mobile Router, through an address configuration mechanism such as DHCP, when it attaches to an IPv4 access network. IPv4 Forwarding IPv4 forwarding for all Mobile Network Prefixes of the basic NEMO protocol. The IPv4 forwarding is enabled to reduce the tunnel overhead due to IPv6-in-IPv6 [4] encapsulation of packets meant for the Mobile Network. 3. Protocol Overview A Mobile Router, that implements the NEMO Basic Support protocol [1] could roam and attach to different access networks. When the Mobile Router attaches to an access link that implements only IPv4, it acquires an IPv4 address for use on the link. It uses the IPv4 address as a Care-of address and sends a Binding Update to its Home Agent. This binds the IPv4 Care-of address to the Mobile Router's IPv6 Home Address. This operation is called IPv4 Care-of Address Registration. The Mobile Router needs to configured with the IPv4 address of the Home Agent in addition to the IPv6 address of the Home Agent. In this document we describe some extensions to the Dynamic Home Agent Address Discovery messages, described in section 6, to carry the IPv4 address of the Home Agent in addition to the IPv6 address. Whenever the Mobile Router moves into an IPv4 only access network, it configures an IPv4 Care-of Address and sends an Binding Update R. Wakikawa et.al. [Page 4] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 to the Home Agent to bind the IPv4 Care-of address to the IPv6 home address. The IPv4 Care-of address is carried in the Binding Update using a new mobility option, the IPv4 Care-of Address option (section 4.1). The Mobile Routers uses with IPv6-over-IPv4 encapsulation to send the Binding Update to the Home Agent. The outer IP header is an IPv4 header with the source address set to the Mobile Router's IPv4 Care-of address and the destination address set to the Home Agent IPv4 address. The inner IP header is an IPv6 header with source address set to the Mobile Router's IPv6 home address and the destination address set to the Home Agent's address. If the Home Agent has an existing binding cache entry for the Mobile Router, it updates the binding cache entry with the new IPv4 Care-of Address instead of the IPv6 address. The Home Agent updates the forwarding entries for the Mobile Network prefix to reflect the use of an with IPv6-over-IPv4 tunnel instead of the IPv6-in-IPv6 tunnel. This draft supports various kinds of tunneling methods such as Generic IP-in-IP tunneling [12], GRE tunneling [13], IPsec tunneling [14] [15], and IPv6 in UDP over IPv4 tunneling for private IPv4 addresses. The Mobile Router indicates to the Home Agent which tunneling method it wants to use through a flag in IPv4 Care-of Address option. The Home Agent MUST include the IPv4 Care-of Address option in the Binding Acknowledgement. If the Home Agent does not support the tunneling method the Mobile Router requested, it sets the Binding Acknowledgement status value to 144 (Tunneling method not supported) and indicate through a flag which tunneling method it supports. Once the Mobile Router gets a success Binding Acknowledgement, it starts using the with IPv6-over-IPv4 tunnel with its Home Agent to tunnel all traffic from the Mobile Network to the Internet. With using the protocol extensions described above, we avoid using a NEMO tunnel inside a transition tunnel. The Home Agent itself serves as a transition router. 4. Mobile IPv6 Extensions 4.1. IPv4 Care-of Address option The IPv4 Care-of Address option is included in Binding Update and Binding Acknowledgment. R. Wakikawa et.al. [Page 5] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 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 | +-+-+-+-+-----------------------+-------------------------------+ |I|R|S|U| Reserved | Port Number | +-+-+-+-+-----------------------+-------------------------------+ | IPv4 Care-of Address | +---------------------------------------------------------------+ Type TBA Length Eight-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. Set to 8. Flags Generic IP in IP Encapsulation tunnel (I) Flag GRE tunnel (R) Flag IPsec tunnel (S) Flag UDP tunnel (U) Flag Reserved Set to 0 and ignored by the receiver. Port Number Sixteen-bit field to carry the port number used for UDP-IP tunnel to traverse NAPT. IPv4 Care-of Address The IPv4 Care-of Address field contains the IPv4 Care-of address of the mobile router. 4.2. Binding Update If a mobile node wants to bind an IPv4 Care-of addresses to its Home Address it includes the IPv4 Care-of Address Option in the Binding Update. The source and destination address of the inner IPv6 header are set to the Home Address of the Mobile Router and the IPv6 R. Wakikawa et.al. [Page 6] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 address of the Home Agent respectively. The Binding Update is always encapsulated in an IPv4 header with destination set to the Home Agent IPv4 address. The lifetime in the Binding Update should be set to a valid lifetime. 4.3. Binding Acknowledgment If a Binding Update had contained the IPv4 Care-of address option, the Home Agent MUST include the IPv4 Care-of address option in the Binding Acknowledgement. If the requesting tunnel method is not supported by a Home Agent, the Home Agent should reply with the status code "Tunnel Method not supported". In such a case, the Home Agent should set the flags that correspond to the tunneling methods it supports in the IPv4 Care-of address option. If the Home Agent that receives the Binding Update is a legacy Mobile IPv6 Home Agent and does not understand the new IPv4 Care-of Address option, it ignores the Binding Update. Some implementations treat the Binding Update as a de-registration Binding Update since the Binding Update appears as if it was sent from the home link. But the Home Agent will not be able to send the Binding Acknowledgement because the Mobile Router is not at home. In both cases, the Mobile Router does not receive a Binding Acknowledgement from the Home Agent. If the Mobile Router does not receive any Binding Acknowledgements even after sending multiple Binding Updates, it MUST consider the Home Agent as one that does not support transition mechanisms and should stop sending Binding Updates with IPv4 Care-of Address Option. Note that, if the Mobile Router uses the extended DHAAD mechanism, described in section 6, it would be configured with Home Agents that support the IPv4 Care-of Address option. 5. Securing the tunnel between the Mobile Router and the Home Agent 5.1. Packet Formats This section assumes that the Mobile Router and the Home Agent are using IPv6-over-IPv4 tunneling for the bi-directional tunnel between them. The IPv6-over-IPv4 tunnel can be protected by ESP in tunnel mode if required. The following packet formats must be supported by the Mobile Router and the Home Agent. For brevity, packet formats for other encapsulation methods are not described here. R. Wakikawa et.al. [Page 7] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 5.1.1. Binding Update and Binding Acknowledgement When the Mobile Router sends a Binding Update from an visited link that supports only IPv4, it should use the following packet format. IPv4 header (source = IPv4 care-of address, destination = IPv4 home agent address) ESP header in tunnel mode IPv6 header (source = IPv6 home address, destination = IPv6 home agent address) Mobility header Binding Update IPv4 Care-of Address option (IPv4 care-of address) When the Home Agent sends a Binding Acknowledgement to the Mobile Router, it should the following packet format. IPv4 header (source = IPv4 home agent address, destination = IPv4 care-of address) ESP header in tunnel mode IPv6 header (source = IPv6 home agent address, destination = IPv6 home address) Mobility header Binding Acknowledgement IPv4 Care-of Address option (IPv4 care-of address) 5.1.2. Mobile Prefix Discovery When the Mobile Router sends a Mobile Prefix Solicitation message from the IPv4 visited network, it should use the following packet format. IPv4 header (source = IPv4 care-of address, destination = IPv4 home agent address) ESP header in tunnel mode IPv6 header (source = IPv6 home address, destination = IPv6 home agent address) ICMPv6 header Mobile Prefix Solicitation When the Home Agent sends a Mobile Prefix Advertisement to the Mobile Router, it should use the following packet format. IPv4 header (source = IPv4 home agent address, destination = IPv4 care-of address) ESP header in tunnel mode IPv6 header (source = IPv6 home agent address, destination = IPv6 home address) R. Wakikawa et.al. [Page 8] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 ICMPv6 header Mobile Prefix Advertisement 5.1.3. Mobile Network Traffic The Mobile Router should use the following packet format to tunnel all traffic from the Mobile Network to the Correspondent Nodes through the Home Agent. IPv4 header (source = IPv4 care-of address, destination = IPv4 home agent address) ESP header in tunnel mode IPv6 header (source = IPv6 MNN, destination = IPv6 CN) Any payload The Home Agent should use the following packet format to tunnel all traffic meant for the Mobile Network to the Mobile Router's IPv4 Care-of Address. IPv4 header (source = IPv4 home agent address, destination = IPv4 care-of address) ESP header in tunnel mode IPv6 header (source = IPv6 CN, destination = IPv6 MNN) Any Payload If ESP protection is not required, the Mobile Router and the Home Agent should omit the ESP header. 5.2. IPsec Configuration This section describes the security policy entries on the Mobile Router and the Home Agent, assuming a dynamic key exchange protocol like IKEv2 is used. This section assumes ESP in tunnel mode protection is used for Binding Updates and Acknowledgements, Mobile Prefix Discovery messages and the payload traffic between the nodes in the Mobile Network and their CNs. 5.2.1. Binding Update and Acknowledgement Mobile Router SPD OUT - IF source = mr_hoa & destination = ha_ipv6 & proto = mh & mhtype = BU Then use SA ESP Tunnel mode R. Wakikawa et.al. [Page 9] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 outer src addr = mr_ipv4_coA outer dst addr = ha_ipv4 Mobile Router SPD IN - IF source = ha_ipv6 & destination = mr_hoa & proto = mh & mhtype = BACK Then use SA ESP Tunnel mode outer src addr = ha_ipv4 outer dst addr = mr_ipv4_coa Home Agent SPD OUT - IF source = ha_ipv6 & destination = mr_hoa & proto = mh & mhtype = BACK Then use SA ESP Tunnel mode outer src addr = ha_ipv4 outer dst addr = mr_ipv4_coa Home Agent SPD IN - IF source = mr_hoa & destination = ha_ipv6 & proto = mh & mhtype = BU Then use SA ESP Tunnel mode outer src addr = mr_ipv4_coa outer dst addr = ha_ipv4 5.2.2. Mobile Prefix Discovery Mobile Router SPD OUT - IF source = mr_hoa & destination = ha_ipv6 & proto = icmpv6 & icmp_type = mps Then use SA ESP Tunnel mode outer src addr = mr_ipv4_coA outer dst addr = ha_ipv4 Mobile Router SPD IN - IF source = ha_ipv6 & destination = mr_hoa & proto = icmpv6 & icmp_type = mpa Then use SA ESP Tunnel mode outer src addr = ha_ipv4 outer dst addr = mr_ipv4_coa Home Agent SPD OUT - IF source = ha_ipv6 & destination = mr_hoa R. Wakikawa et.al. [Page 10] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 & proto = icmpv6 & icmp_type = mps Then use SA ESP Tunnel mode outer src addr = ha_ipv4 outer dst addr = mr_ipv4_coa Home Agent SPD IN - IF source = mr_hoa & destination = ha_ipv6 & proto = icmpv6 & icmp_type = mpa Then use SA ESP Tunnel mode outer src addr = mr_ipv4_coa outer dst addr = ha_ipv4 5.2.3. Mobile Network Traffic Mobile Router SPD OUT - IF source = mnn & destination = cn_ipv6 & proto = any Then use SA ESP Tunnel mode outer src addr = mr_ipv4_coA outer dst addr = ha_ipv4 Mobile Router SPD IN - IF source = cn_ipv6 & destination = mnn & proto = any Then use SA ESP Tunnel mode outer src addr = ha_ipv4 outer dst addr = mr_ipv4_coa Home Agent SPD OUT - IF source = mnn & destination = cn_ipv6 & proto = any Then use SA ESP Tunnel mode outer src addr = ha_ipv4 outer dst addr = mr_ipv4_coa Home Agent SPD IN - IF source = cn_ipv6 & destination = mnn & proto = any Then use SA ESP Tunnel mode outer src addr = mr_ipv4_coa outer dst addr = ha_ipv4 R. Wakikawa et.al. [Page 11] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 6. Home Agent IPv4 Address Discovery A Mobile Router must acquire the Home Agent's IPv4 address in addition to the IPv6 address. We extend the Dynamic Home Agent Address Discovery (DHAAD) messages for the Mobile Router to acquire the Home Agent's IPv4 address. A new flag 'I' in introduced in the DHAAD request and reply messages. The Mobile Router sets the 'I' flag in the DHAAD request if it wants to acquire the IPv4 address of the Home Agent. The Home Agent that processes the request must send a DHAAD reply. The 'I' flag MUST be set and the IPv4 addresses of the Home Agents must be present in the reply. Home Agents that do not have an IPv4 address configured do not reply to the DHAAD requests that have the 'I' flag set. It is important for the Mobile Router to acquire Home Agents IPv4 addresses from IPv6 network, since the DHAAD mechanism relies on IPv6 anycast routing. The Mobile Router maintains a list of Home Agents IPv4 addresses, similar to the Home Agents IPv6 address list. 7. IPv4 Care-of Address Registration 7.1. Sending Binding Update When a Mobile Router roams and attaches to an IPv4 only access network, it does not have a valid IPv6 Care-of Address to bind to its Home Address. It configures an IPv4 address from the visited network and registers the address as the IPv4 Care-of address with the Home Agent. From the view of the Basic NEMO Protocol, this Binding Update is treated as de-registration Binding Update. A Mobile Router include an IPv4 Care-of Address option in the Binding Update and tunnels the Binding Update to a Home Agent IPv4 address. Although the Mobile Router sets its Home Address as the Source Address field of the inner IPv6 header, it MUST set appropriate lifetime value to the Lifetime filed of Binding Update. The Mobile Router MUST NOT set zero lifetime for the IPv4 Care-of Address Binding Update. The following options are required for IPv4 Care-of Address registration - IPv4 Care-of Address option - Mobile Network Prefix option R. Wakikawa et.al. [Page 12] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 7.2. Receiving Binding Update If a Home Agent receives a Binding Update that does not contain an IPv4 Care-of Address option, the processing of the Binding Update is same as in [7] and [1]. If the Home Agent currently has setup forwarding for the Mobile Network through an IPv4 tunnel, it must delete that state and create a regular binding cache entry for the Mobile Router. It must also setup forwarding for the Mobile Network as described in [1]. If the Binding Update contains an IPv4 Care-of Address option, the Home Agent should perform the following additional checks. - If the Binding Update contains an IPv4 Care-of address option, it should not contain an IPv6 Alt-CoA address option. If the IPv6 Alt CoA option is present, the Home Agent must reject the Binding Update and send a Binding Acknowledgement with status '145' (Invalid Care-of Address). - If the lifetime field of the Binding Update is set to zero, the receiver MUST ignore the Binding Update. When the IPv4 Care-of Address option is present, the lifetime field indicates the lifetime value for IPv4 Care-of Address. - If the requested tunnel type is not supported by the receiver node, the Binding Update is discarded and a Binding Acknowledgment with status 144 (Tunneling method not supported) is sent to the Mobile Router. Once the Binding Update is processed successfully, the Home Agent sets up IPv4 forwarding for the Mobile Router's Home Address and the Mobile Network Prefixes. The Home Agent also sends a Binding Acknowledgment with the correspondent IPv4 Care-of Address option to the Mobile Router. 7.3. Sending Binding Acknowledgment Whenever a Home Agent sends a Binding Acknowledgment for IPv4 Care-of Address registration, it MUST include the received IPv4 Care-of Address option. If the Home Agent does not support the tunneling method proposed by the Mobile Router, it must set the status in the Binding Aknowledgement to 144 (Tunneling method not supported) and set the flags in the IPv4 Care-of Address option according to the tunneling methods it supports. After receiving the Binding Acknowledgment, the Mobile Router MAY again try to setup IPv4 forwarding according to supported tunnel method. R. Wakikawa et.al. [Page 13] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 7.4. Receiving Binding Acknowledgment When the Mobile Router receives the Binding Acknowledgment, it verifies whether it contains the IPv4 Care-of Address option. If the option is not present, it can retry sending a Binding Update with an IPv4 Care-of Address option. However, the Mobile Router SHOULD stop sending the Binding Update at some point, because the Home Agent might be a legacy Home Agent that does not support IPv4 Care-of Address Registration. Once a Mobile Router receives Binding Acknowledgment with a successful status code, it creates an IPv6-over-IPv4 tunnel with its Home Agent IPv4 address. The tunnel source address is a IPv4 Care-of Address of Mobile Router and the tunnel destination address is a Home Agent IPv4 address. All traffic originating in the Mobile Network is routed to the tunnel with the Home Agent. If a Mobile Router receives the status code 144 (Tunneling method not supported), it should select a different tunneling mechanism based on the flags in the received IPv4 Care-of address option and attempt registering its IPv4 Care-of Address to the Home Agent again. If the Mobile Router does not implement any of the tunneling mechanisms the Home Agent supports, then the Mobile Router must stop trying to register with the Home Agent. 7.5. IPv4 forwarding Setup When a Home Agent processes a Binding Update successfully, it sets up IPv4 forwarding according to the Flag field in the IPv4 Care-of Address option. There are several types of tunnel such as GRE tunnel, Generic Encapsulation (IPv4-IPv4) tunnel, IPsec tunnel, UDP-IPv4 tunnel for NAPT. When IPsec tunnel is selected, the Home Agent MUST establish Security Association with the Mobile Router. When UDP tunnel flag is set, the Home Agent creates UDP-IPv4 tunnel with the specified port number in the IPv4 Care-of Address option. The Mobile Router also sets up IPv4 forwarding after accepting a Binding Acknowledgment with success status code. The procedure to setup IPv4 forwarding is same as Home Agent. R. Wakikawa et.al. [Page 14] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 8. Applicability to Mobile IPv6 This mechanism can be applied to Mobile IPv6 as well. However, Mobile IPv6 uses Proxy Neighbor Discovery for the Home Agents to intercept packets meant for the mobile node. Therefore, after de-registering the regular binding cache entry, the Home Agent still defends the Home Address and intercepts packets meant for the Home Address using Proxy Neighbor Discovery. The Home Agent then forwards packets to Mobile Node's IPv4 Care-of Address by IPv4 forwarding. For the Correspondent Node, the Mobile Node MUST de-register its binding cache by sending a Binding Update via Home Agent. The Mobile Node tunnels the CN Binding Update to Home Agent IPv4 address by IPv4 forwarding and the Home Agent forwards the Binding Update to the Correspondent Node. This means route optimization can not be used while the Mobile Node is located on an IPv4 access network. Future extensions to the Correspondent Node behavior and the Return Routability mechanism can enable the Mobile Node to register an IPv4 Care-of address with the Correspondent Node directly. 9. NAT Traversal If ESP tunnel mode is used to protect all traffic sent between the Mobile Router and the Home Agent, through the bi-directional IPv6-over-IPv4 tunnel, then UDP encapsulation of IPsec protected [16] packets can be used to traverse a NAT box. No additional mechanism needs to be defined in this document. The Mobile IPv6 signaling messages, including Binding Updates, Binding Acknowledgements, Mobile Prefix Discovery and Return Routability signaling require IPsec protection. Using ESP tunnel mode to protect this traffic when the traffic is sent through the IPv6-in-IPv4 tunnel along with UDP encapsulation of the IPsec protected traffic automatically provides NAT traversal. If ESP tunnel mode protection is not used to protect the payload traffic between the Mobile Network and the Correspondent Nodes, then traffic must be sent by encapsulating the IPv6 packets in UDP over IPv4. 10. IANA Considerations This document defines a new Mobility Header option, the IPv4 Care-of Address Option as described in section 4.1. The type value for this option needs to be assigned from the same space used for the mobility options defined in [2]. R. Wakikawa et.al. [Page 15] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 Two new Binding Acknowledgement status values need to assigned. - 144 Tunneling method not supported - 145 Invalid Care-of Address 11. Security Considerations This document does not introduce any additional security considerations from what is mentioned in NEMO Basic support [1] and the Mobile IPv6 [2] specifications. 12. Acknowledgements The authors would like to thank Keisuke Uehara and the members of the WIDE project. The authors would also like to thank Jari.T.Malinen, T.J.Kniveton, Teemu Savolainen, Mika Joutsenvirta, and Rajeev Koodli for interesting discussions on this topic. Normative References [1] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. Thubert, "NEMO Basic Support Protocol", RFC 3963, January 2005. [2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [3] Devarapalli, V., "Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture", draft-ietf-mip6-ikev2-ipsec-01.txt (work in progress), February 2004. [4] Conta, A., and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [6] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", draft-ietf-ipsec-ikev2-17.txt (work in progress), September 2004. R. Wakikawa et.al. [Page 16] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 Informative References [7] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents", RFC 3776, June 2004. [8] Manner, J., and M. Kojo, "Mobility Related Terminology", RFC 3753, June 2004. [9] Ernst, T., and H.-Y. Lach. "Network Mobility Support Terminology" draft-ietf-nemo-terminology-02.txt (work in progress), October 2004. [10] Soliman, H., and G. Tsirtsis, "Dual Stack Mobile IPv64", draft-soliman-v4-v6-mipv4-01.txt (work in progress), October 2004. [11] Thubert, P., et. al., "IPv4 traversal for MIPv6 based Mobile Routers"", draft-thubert-nemo-ipv4-traversal-01.txt (work in progress), May 2003. [12] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. [13] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 1701, October 1994. [14] Kent, S., and K Seo, "Security Architecture for the Internet Protocol", draft-ietf-ipsec-rfc2401bis-05.txt (work in progress), December 2004. [15] Kent, S., "IP Encapsulating Security Payload (ESP)", draft-ietf-ipsec-esp-v3-09.txt (work in progress), September 2004. [16] Huttunen, A., et. al., "UDP Encapsulation of IPsec Packets", RFC 3948, January 2005. [17] Nordmark, E., and R. E. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", draft-ietf-v6ops-mech-v2-06.txt (work in progress), September 2004. R. Wakikawa et.al. [Page 17] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 Authors' Addresses Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252 JAPAN EMail: ryuji@sfc.wide.ad.jp Vijay Devarapalli Nokia Research Center 313 Fairchild Drive Mountain View, CA 94043 USA Email: vijay.devarapalli@nokia.com Carl E. Williams KDDI Labs USA Palo Alto, CA 94301 USA EMail: carlw@kddilabs.com 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. R. Wakikawa et.al. [Page 18] Internet Draft IPv4 traversal for IPv6 Mobility Protocols 21 Feb 2005 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 (2004). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. R. Wakikawa et.al. [Page 19]