MIP6 Working Group Ryuji Wakikawa INTERNET DRAFT Keio Univ./WIDE Category: Personal Carl E. Williams 10 Jun 2004 KDDI Labs USA Keisuke Uehara Keio Univ./WIDE IPv4 Care-of Address Registration draft-wakikawa-nemo-v4tunnel-00.txt Status of This Memo This document is a submission to the MIP6 Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the mip6@ietf.org (mobile-ip@sunroof.eng.sun.com) mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 On the Internet, two different IP protocols are deployed such as IPv4 [8] and IPv6 [2]. The Mobile IPv6 Router uses the basic NEMO protocol [3] which is IPv6 protocol specific. During the early period of time that IPv6 transition is occurring it is very likely that a Mobile IPv6 router will move to an IPv4 only access network. When this occurs the Mobile IPv6 Router will no longer be able to operate using the basic NEMO protocol. There has already been some earlier work to provide IPv6 capability over an IPv4 access network for a Mobile IPv6 Router [see [10] [11]]. This draft provides a capability by to maintain IPv6 connectivity for the Mobile IPv6 R. Wakikawa et.al. Expires 10 Dec 2004 [Page 1] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 Router via its Home Agent with IPv4-in-IPv6 encapsulation with no special boxes to be deployed elsewhere in the network. Contents Status of This Memo 1 Abstract 1 1. Introduction 3 2. Terminology 3 3. Protocol Overview 4 4. Mobile IPv6 Extensions 5 4.1. IPv4 Care-of Address sub-option . . . . . . . . . . . . . 5 4.2. Binding Update . . . . . . . . . . . . . . . . . . . . . 6 4.3. Binding Acknowledgment . . . . . . . . . . . . . . . . . 7 5. Home Agent Address Discovery 7 6. IPv4 Care-of Address Registration 8 6.1. Sending Binding Update . . . . . . . . . . . . . . . . . 8 6.2. Receiving Binding Update . . . . . . . . . . . . . . . . 9 6.3. Sending Binding Acknowledgment . . . . . . . . . . . . . 10 6.4. Receiving Binding Acknowledgment . . . . . . . . . . . . 10 6.5. IPv4 forwarding Setup . . . . . . . . . . . . . . . . . . 10 7. Applicability to Mobile IPv6 11 References 11 Authors' Addresses 12 R. Wakikawa et.al. Expires 10 Dec 2004 [Page 2] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 1. Introduction The basic NEMO protocol [3] is currently being standardized at IETF and is ready for the deployment phase with high interest on the Internet. However, the current Internet is based on both IPv4 and IPv6 network and we cannot assume that IPv6 networks will be deployed everywhere. To provide the functionality of a Mobile IPv6 Router in a wireless system, IPv6 support is required in the architecture of the wireless access networks. This is because the Mobile IPv6 is not protocol independent. IPv6 was designed with an integrated support for Mobile IP as native IPv6 feature. As such Mobile IPv6 and the Basic NEMO protocol for Mobile Routers is designed to use the rich feature set of IPv6; hence, there exist a tight coupling of mobility signaling and IPv6 used in the media plane. Operation of Mobile IPv6 Router would not be guaranteed since that also depends on the IPv6 capabilities of the networks the Mobile IPv6 Router is visiting i.e.: a Mobile IPv6 Router attempting to connect via a IPv4 only network would not be able to maintain IPv6 connectivity. There are earlier works at the IETF MIP6 working group such as `` Dual Stack Mobile IPv6``[10] and ``Doors'' [11]. The features of this proposal are listed below: - using variety of tunnels between Mobile Router and Home Agent. Possible tunnel types are IPv4-IPv6, and UDP/IPv4-IPv6 for NAPT address. - Doing de-registration for regular binding when a Mobile Router visits an IPv4 network. This leads an advantage of reducing tunnel header between Mobile Router and Home Agent [1] [5] [3], which is not negligible. 2. Terminology Home Agent IPv4 Address A Home Agent MUST have an IPv4 global address for IPv4 care-of address registration. IPv4 Care-of Address is an IPv4 address. This address is acquired by a Mobile Router through any address configuration mechanism such as DHCP, when the Mobile Router visits an IPv4 only network. R. Wakikawa et.al. Expires 10 Dec 2004 [Page 3] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 IPv4 Care-of Address Registration A Mobile Router registers its IPv4 Care-of address bound to the IPv6 Home Address to a Home Agent. IPv4 Forwarding IPv4 forwarding for all Mobile Network Prefixes of the basic NEMO protocol. The IPv4 forwarding is enable to minimalizes tunnel overhead of IPv6-IPv6 [1] encapsulation for packets meant for Mobile Network Prefixes. 3. Protocol Overview When a Mobile Router visits an IPv4 only network, it uses IPv4 address as its Care-of address to tunnel packets between the Mobile Router and the Home Agent. This operation is called IPv4 Care-of Address Registration. While a Mobile Router lives in IPv6 network, it acquires Home Agent IPv4 addresses with extended Dynamic Home Agent Address Discovery operations. Whenever the Mobile Router moves into an IPv4 only network, it gets an IPv4 address and sends an extended Binding Update with new IPv4 Care-of Address sub-option to the Home Agent IPv4 address by using IPv4-in-IPv6 encapsulation. In the outer IPv4 header, the source address is a Mobile Router's IPv4 Care-of address and the destination address is the Home Agent IPv4 address. In the inner IPv6 header, the source address is a Mobile Router's Home Address and the destination address is Home Agent address. The Binding Update requests to delete the regular binding cache for the Mobile Router. But then, IPv4 address is stored in the IPv4 Care-of Address sub-option and can be used to setup IPv4 forwarding on behalf of regular forwarding on the basic NEMO protocol. The Mobile Router MUST NOT set zero lifetime in the Binding Update, but it MUST set the lifetime for the IPv4 Care-of Address. The Mobile Router creates Binding Update with 'I' flag set and processes IPsec for the Binding Update as described in [5]. When the Home Agent receives the Binding Update, it first disables or removes the regular binding cache and sets up IPv4 forwarding which is an IPv4-IPv6 tunnel for the Mobile Router's Home Address and Mobile Network Prefixes. This draft supports various kinds of tunnel methods such as Generic IP Encapsulation [9], GRE tunneling [4], IPsec tunneling [7] [6], and UDP tunneling for NAPT address. These tunnel method is specified in the IPv4 Care-of Address sub-option. The Home Agent MUST reply a Binding Acknowledgment with an IPv4 Care-of Address sub-option to the Mobile Router's IPv4 Care-of address by using IPv4 forwarding. R. Wakikawa et.al. Expires 10 Dec 2004 [Page 4] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 After getting successful Binding Acknowledgment, the Mobile Router forwards all packets meant to the Internet from its Mobile Networks to Home Agent IPv4 address by using IPv4-in-IPv6 encapsulation. Without our proposal, the double encapsulation such as IPv4-in-IPv6-in-IPv6 tunnel is occurred. By using IPv4 forwarding, the basic NEMO protocol can reduce one IPv6 header which is used for regular forwarding. 4. Mobile IPv6 Extensions 4.1. IPv4 Care-of Address sub-option The IPv4 Care-of Address sub-option is included in Binding Update and Binding Acknowledgment. 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 = TBD | Length = 4 | +-+-+-+-+-----------------------+-------------------------------+ |I|R|S|U| Reserved | Port Number | +-+-+-+-+-----------------------+-------------------------------+ | IPv4 Care-of Address | +---------------------------------------------------------------+ Type Type value for Binding Unique Identifier will be assigned later. Length The value MUST be always 4. Flag Generic IP in IP Encapsulation tunnel (I) Flag When this flag is set, the home agent MUST use Generic Encapsulation tunneling for IPv4-IPv6 encapsulation. GRE tunnel (R) Flag When this flag is set, the home agent MUST use GRE tunneling for IPv4-IPv6 encapsulation. R. Wakikawa et.al. Expires 10 Dec 2004 [Page 5] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 IPsec tunnel (S) Flag When this flag is set, the home agent MUST use IPsec tunneling for IPv4-IPv6 encapsulation. UDP tunnel (U) Flag When this flag is set, the home agent MUST use the Port value for UDP tunneling to go through NAPT. Reserved Reserved field must be set with all 0. Port Number A port number which is used for UDP-IP tunnel to traverse NAPT. IPv4 Care-of Address The IPv4 Care-of Address field contains an IPv4 address of a mobile router. 4.2. Binding Update If a mobile node wants to register IPv4 care-of addresses which would be bound to a IPv6 home address, mobile node MUST set 'I' flag and include a IPv4 Care-of Address sub-option. When a mobile router sends a Binding Update with I flag set, the source address of IPv6 header is the Home Address of the mobile router. The Binding Update is always encapsulated by IPv4 to Home Agent IPv4 Address. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |A|H|L|K|R|I| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 support flag (I) This flag is used for IPv4 care-of address registration. R. Wakikawa et.al. Expires 10 Dec 2004 [Page 6] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 Reserved Reserved field is reduced to 11 bits. Lifetime Lifetime for IPv4 Care-of Address stored in a IPv4 Care-of Address sub-option. 4.3. Binding Acknowledgment The message format of Binding Acknowledgment is not changed, but operations listed below are added for IPv4 care-of address registration. If a Binding Update has 'I' flag and an IPv4 Care-of Address sub-option is present, a receiver node MUST reply a Binding Acknowledgment containing an appropriate IPv4 Care-of Address sub-option. If the requesting tunnel method is not supported by a Home Agent, the Home Agent MUST reply with the status code ``Tunnel Method is not valid''. In such case, the Home Agent can set the flag of tunnel methods which Home Agent currently support. This is useful when a Mobile Router decides the tunnel method from available methods at a Home Agent. This document defines a new number for 'I' flag handling. TBD Tunnel Method is not valid When a receiver is somehow legacy Home Agent and can not process an IPv4 Care-of Address sub-option, it de-registers the binding and returns a Binding Acknowledgment to the Home Address. However, the legacy Home Agent can not resolve Neighbor Discovery Cache for the Home Address and can not send it to the link, because the sender (i.e. Mobile Router) is not at the home link. In such case, the sender (i.e. Mobile Router) can not receive the Binding Acknowledgment at the visiting network. If the Mobile Router can not receive any Binding Acknowledgment after sending multiple Binding Updates with an IPv4 Care-of Address sub-option, it MUST stop IPv4 Care-of Address Registration. Note that, Mobile Router basically does not send such Binding Updates to legacy Home Agent because of extended Home Agent Address Discovery mechanism described in Section 5. 5. Home Agent Address Discovery A Mobile Router MUST acquire Home Agent IPv4 address. Dual Stack Mobile IPv6[10] has already proposed mechanism for this. However, R. Wakikawa et.al. Expires 10 Dec 2004 [Page 7] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 this draft is not aimed to use an IPv4 Home Address on Mobile Router, we slightly extended the Dynamic Home Agent Address Discovery. When a Mobile Router requests lists of Home Agents, it sends Dynamic Home Agent Address Discovery Request to Home Agent anycast address. In that time, the Mobile Router can set ``I'' flag in the message. The Home Agent who received the request with I flag set MUST contain Home Agent IPv4 address if its available. It is important to acquire Home Agent's IPv4 addresses from IPv6 network. When a Mobile Router moves to IPv4 only network, it can't acquire Home Agent addresses from IPv4 network. A Mobile Router maintain the Home Agent's IPv4 address as same as Home Agent IPv6 address in the home agent list. 6. IPv4 Care-of Address Registration 6.1. Sending Binding Update When a Mobile Router lost its IPv6 Care-of Address at a visiting network, it can register available IPv4 addresses as its IPv4 Care-of Address to a Home Agent. The packet sent from a Mobile Router is shown in Figure 1. From the view of the Basic Nemo Protocol, this Binding Update is treated as de-registration Binding Update. A Mobile Router sets I flag in the Binding Update with an IPv4 Care-of Address sub-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. IPv4 header IPv6 Header HoA Dest Option Mobility Header +---------------+---------------+-----------+------------------------+ | SRC: IPv4-CoA | SRC: MR-HoA | MR HoA | Binding Update w/ | | DST: IPv4-HA | DST: HA | | I flag and sub-options | +---------------+---------------+-----------+------------------------+ Figure 1: Binding Update for IPv4 Care-of Address R. Wakikawa et.al. Expires 10 Dec 2004 [Page 8] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 The following sub-options are required for IPv4 Care-of Address registration - Alternate Care-of Address Sub-option set a Mobile Router's Home Address - IPv4 Care-of Address Sub-option set a Mobile Router's Care-of Address - Mobile Network Prefix Sub-option set a Mobile Router's Mobile Network Prefix 6.2. Receiving Binding Update If a Binding Update does not contain an IPv4 Care-of Address sub-option and it does not have 'I' flag set, the processing of the Binding Update is same as [5]. But if the receiver maintains IPv4 forwarding, it MUST discards the IPv4 forwarding and creates a binding cache entry for the new IPv6 Care-of Address as described in [5] and [3]. On the other hand, if a Binding Update contains an IPv4 Care-of Address sub-option, or 'I' flag set, a receiver node MUST operate additional validations as follows. - If the Binding Update has 'I' flag at the Flag field, an IPv4 Care-of Address sub-option MUST be present in Mobility options field of the Binding Update. Otherwise, the receiver node MUST silently drop the Binding Update. - If the lifetime field of the Binding Update is set to zero, the receiver MUST ignore the Binding Update. When the I flag is set, 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 [TBD] (Tunnel method is not valid) MUST be replied to the sender Mobile Router. After successfully processing the Binding Update, the Home Agent MUST create IPv4 forwarding for the Mobile Router's Home Address and the Mobile Network Prefixes. The Home Agent MUST returns a Binding Acknowledgment with the correspondent IPv4 Care-of Address sub-option to the Mobile Router. R. Wakikawa et.al. Expires 10 Dec 2004 [Page 9] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 6.3. Sending Binding Acknowledgment Whenever a Home Agent sends a Binding Acknowledgment for IPv4 Care-of Address registration, it MUST contain the received IPv4 Care-of Address sub-option. Only when the Home Agent sends a Binding Acknowledgment with status code [TBD] (Tunnel method is not valid) set, it SHOULD modified the Flag field of IPv4 Care-of Address sub-option according to supporting tunnel methods by the Home Agent. After receiving the Binding Acknowledgment, the Mobile Router MAY retry to create IPv4 forwarding according to supported tunnel method. 6.4. Receiving Binding Acknowledgment When a Mobile Router receives a Binding Acknowledgment, it MUST verify whether the Binding Acknowledgment has an IPv4 Care-of Address sub-option or not. If the sub-option is not available, it can retry sending a Binding Update with an IPv4 Care-of Address sub-option. However, the Mobile Router SHOULD stop sending the Binding Update at some point, because the Home Agent MAY NOT support IPv4 care-of Address Registration. Once a Mobile Router receives Binding Acknowledgment with a successful status code, it MUST creates IPv4-IPv6 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 packets originated from a Mobile Network is routed to the tunnel using the tunnel method which is recorded into the Flag field of the IPv4 Care-of Address sub-option. If a Mobile Router receives the status code [TBD] (Tunnel Method is not valid), it MUST re-select the tunnel method from the received IPv4 Care-of address sub-option and re-registers its IPv4 Care-of Address to the Home Agent. 6.5. IPv4 forwarding Setup When a Home Agent processes a Binding Update successfully, it setup IPv4 forwarding according to the Flag field of IPv4 Care-of Address sub-option. There are several types of tunnel such as GRE tunnel, Generic Encapsulation (IPv4-IPv4) tunnel, IPsec tunnel, UDP-IPv4 tunnel for NAPT. R. Wakikawa et.al. Expires 10 Dec 2004 [Page 10] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 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 sub-option. Mobile Router also setup IPv4 forwarding after accepting a Binding Acknowledgment with success status code. The procedure to setup IPv4 forwarding is same as Home Agent. 7. Applicability to Mobile IPv6 Our mechanism can be applied to Mobile IPv6 as well. However, Mobile IPv6 uses Proxy Neighbor Discovery to intercept packets at the Home Agent. Therefore, after de-registering the regular binding cache entry, the Home Agent still defends the Home Address to intercept packets meant for the Home Address by Proxy Neighbor Discovery. Once the Home Agent intercept packets by Proxy Neighbor Discovery, the Home Agent 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 Binding Update to Home Agent IPv4 address by IPv4 forwarding and the Home Agent deliver the Binding Update to each Correspondent Node. It means route optimization can not be used while the Mobile Node locates in IPv4 network. References [1] A. Conta and S. Deering. Generic Packet Tunneling in IPv6 Specification. Request for Comments (Proposed Standard) 2473, Internet Engineering Task Force, December 1998. [2] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [3] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Nemo Basic Support Protocol (work in progress). Internet Draft (draft-ietf-nemo-basic-support-02), Internet Engineering Task Force, December 2003. [4] S. Hanks, T. Li, D. Farinacci, and P. Traina. Generic Routing Encapsulation (GRE). Request for Comments (Informational) 1701, Internet Engineering Task Force, October 1994. R. Wakikawa et.al. Expires 10 Dec 2004 [Page 11] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 [5] D. Johnson, C. Perkins, and J. Arkko. Mobility support in IPv6 (work in progress). Internet Draft, (draft-ietf-mobileip-ipv6-24.txt), Internet Engineering Task Force, June 2003. [6] S. Kent and R. Atkinson. IP Encapsulating Security Payload (ESP). Request for Comments (Proposed Standard) 2406, Internet Engineering Task Force, November 1998. [7] S. Kent and R. Atkinson. Security Architecture for the Internet Protocol. Request for Comments (Proposed Standard) 2401, Internet Engineering Task Force, November 1998. [8] J. Postel. Internet Protocol. Request for Comments (Standard) 791, Internet Engineering Task Force, September 1981. [9] W. Simpson. IP in IP Tunneling. Request for Comments (Informational) 1853, Internet Engineering Task Force, October 1995. [10] T. Soliman and G. Tsirtsis. Dual Stack Mobile IPv6 (work in progress). Internet Draft (draft-soliman-v4v6-mipv4-00.txt), Internet Engineering Task Force, August 2003. [11] P. Thubert, P. Molteni, and P. Wetterwald. IPv4 traversal for MIPv6 based Mobile Routers (work in progress). Internet Draft (draft-thubert-nemo-ipv4-traversal-01.txt), Internet Engineering Task Force, May 2003. Authors' Addresses Ryuji Wakikawa Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252 JAPAN Phone: +81-466-49-1394 EMail: ryuji@sfc.wide.ad.jp Fax: +81-466-49-1395 Carl E. Williams KDDI Labs USA Palo Alto, CA 94301 USA Phone: +1.650.279.5903 EMail: carlw@kddilabs.com R. Wakikawa et.al. Expires 10 Dec 2004 [Page 12] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 Keisuke Uehara Keio University and WIDE 5322 Endo Fujisawa Kanagawa 252 JAPAN Phone: +81-466-49-1394 EMail: kei@wide.ad.jp Fax: +81-466-49-1395 R. Wakikawa et.al. Expires 10 Dec 2004 [Page 13] Internet Draft The Basic Nemo on IPv4 10 Jun 2004 Full Copyright Statement ``Copyright (C) The Internet Society (year). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.'' ``This document and the information contained herein are provided on an ``AS IS'' basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.'' (See RFC 3667 sections 5.4 and 5.5.) Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. R. Wakikawa et.al. Expires 10 Dec 2004 [Page 14]