autoconf Working Group Jaehwoon Lee Internet Draft Dongguk University Expires: April 29, 2009 Sanghynn Ahn University of Seoul Younghan Kim Soongsil University Yuseon Kim Sangeon Kim KT October 30, 2008 Address Autoconfiguration for the subordinate MANET with Multiple MBRs draft-jaehwoon-autoconf-mmbr-01.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on April 29, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Jaehwoon Lee, et al. Expires April 29, 2009 [Page 1] Internet-Draft Address Autoconfiguration for multiple MBRs Oct. 30, 2008 Abstract In order to allow the subordinate MANET to be connected to the external network, the MANET border router (MBR) has been defined. For providing scalability and reliability to the subordinate MANET, multiple MBRs may be deployed. One of the issues on the subordinate MANET with multiple MBRs is which network prefixes are to be advertised by MBRs. In the case when MBRs advertise different network prefixes, if a MANET node changes its default MBR to a new one, the node may have to transmit packets via non-optimal paths to keep using the existing connection to the previous MBR, or change its address by using the network prefix information from the new MBR. In the latter case, on-going sessions can be terminated because of the address change. In this draft, we define a PMIPv6 based address autoconfiguration mechanism that enables MANET nodes to operate properly when all MBRs advertise the same network prefix in the subordinate MANET. Table of Contents 1. Introduction..................................................3 2. Terminology...................................................4 3. Message format................................................4 3.1 Registration Request message..............................4 3.2 Registration Confirmation message.........................4 4. Protocol operation............................................4 5. Security Considerations.......................................7 6. IANA Considerations...........................................7 References.......................................................7 Author's Addresses...............................................8 Intellectual Property and Copyright Statements ..................9 Jaehwoon Lee, et al. Expires April 29, 2009 [Page 2] Internet-Draft Address Autoconfiguration for multiple MBRs Oct. 30, 2008 1. Introduction The mobile ad hoc network (MANET) enables mobile nodes to communicate via multiple wireless hops without the need of any wired infrastructure. In a MANET, two nodes not within their transmission range have to deliver data to each other through other intermediate nodes. For forwarding packets destined to other nodes, each node must have the routing capability, i.e., the mechanism for establishing data delivery routes between any pair of source and destination nodes. The IETF MANET working group has defined route setup mechanisms for delivering data between MANET nodes. Especially for an ad hoc network such as the MANET, the mechanism that can allow nodes to configure their addresses autonomically is more desirable than the static address configuration mechanism since the former has less configuration and management overhead by not incurring manual intervention. The MANET can be classified into the subordinate MANET or the autonomous MANET depending on whether it is connected to the external network or not[1]. The MANET border router (MBR) which is a gateway device connecting the MANET with the external network has been defined for the subordinate MANET. As the number of nodes in the MANET increases, the amount of traffic between the MANET and the Internet increases, so the MBR gets overloaded, resulting in the overall network performance degradation. To overcome this problem, multiple MBRs can be used for the Internet connectivity [2]. Mechanisms in which each MBR advertises a different network prefix have been proposed for the MANET with multiple MBRs[3-4]. However, in these mechanisms, if a node moves to another place, it sends packets via non-optimal paths to maintain its connection to the previous MBR, or it changes its address by using the network prefix from the new MBR. In the latter case, an on-going session may get terminated because of the address change. In this draft, we define an address autoconfiguration mechanism for the subordinate MANET with multiple MBRs which advertise the same network prefix. In the proposed mechanism, since all MBRs advertise the same network prefix, even a node moves it can still use its preconfigured address. That means that no address reconfiguration is needed in case of node movement, so the proposed mechanism has the advantage of keeping on maintaining its existing session(s). Furthermore, under node movement, a node can still find an optimized path without changing its address because it can choose the MBR that can be reached via the minimum number of hops. Jaehwoon Lee, et al. Expires April 29, 2009 [Page 3] Internet-Draft Address Autoconfiguration for multiple MBRs Oct. 30, 2008 2. Terminology TBD. 3. Message Format 3.1 Registration Request (RR) Message TBD 3.2 Registration Confirmation (RC) Message TBD 4. Protocol Operation MR MBR1(MAG1) MBR2(MAG2) LMA (internet) CN | | | | | |<----------| | | | ICMP SERA message | | | (Configure IPv6 address to MANET interface) | | |<--------->| | | | (DHCP with prefix delegation) | | | |---------->| | | | |RR message | | | | | |---------------------------------->| | | | PBU message (Create Binding Cache Entry) | | |<----------------------------------| | | | PBAck message | | |<----------| | | | |RC message | | | | |<--------->|<=================================>|<------------>| | Data packet transfer between MR and CN via MBR1 and LMA | (MR changes its default gateway from MBR1 to MBR2) | | |<---------------------------| | | | ICMP SERA message | | | |--------------------------->| | | | RR message | | | | | |----------------->| | | | | PBU message | | | | | (Update Binding Cache Entry | | | |<-----------------| | | | | PBAck message | | |<---------------------------| | | | RC message | | | |<-------------------------->|<================>|<------------>| | Data packet transfer between MR and CN via MBR2 and LMA | | | | | | Figure 1: Message exchange scenario Jaehwoon Lee, et al. Expires April 29, 2009 [Page 4] Internet-Draft Address Autoconfiguration for multiple MBRs Oct. 30, 2008 The message exchange scenario considered in this draft is depicted in figure 1. The network is composed of the external network such as the global Internet, a PMIPv6 domain and a MANET. The operation of the PMIPv6 protocol is defined in [5]. In the PMIPv6 domain, a local mobility anchor (LMA) is located and acts as a kind of home agent (HA). The MANET can be connected to the PMIPv6 domain through a multiple number of mobility access gateways (MBRs) and an MBR operates as a mobility access gateway (MAG) in the PMIPv6 domain. One network prefix is assigned to the MANET, and each MBR periodically advertises scope-extended Router Advertisement (SERA) messages to the entire MANET [6]. The SERA message is defined to resolve the duplicate packet reception problem which can occur in a multi-hop wireless network such as the MANET. The network prefix assigned to the MANET and the address of the MBR originating the SERA message are included in the message. Even though the MBR address information included in the SERA messages sent by different MBRs, the network prefixes MBR addresses that can be derived by using the prefix length are the same. In other words, the MBRs connecting the MANET and the global Internet advertise the same network prefix. A MANET node is composed of a MANET router (MR) and hosts [7]. A MR has a MANET interface to connect to the MANET and IP interfaces to connect to hosts. When a MR connects to the MANET for the first time, it waits for a SERA message from a MBR. Assume that the SERA message from MBR1 arrives first. Then the MR configures the IPv6 address of its MANET interface by utilizing the stateless address autoconfiguration mechanism based on its MAC address and the network prefix obtained from the MBR1 address and the network prefix length [8]. After that, the MR sets the MBR1 address in the SERA message as the address of its default gateway, and stores the distance to MBR1 which can be calculated with '255 - the Cur Hop Limit in the scope-extended RA message + 1' in its routing table. In addition to that, the MR sets the value in the source IP address field of the IP packet having the received SERA message as the next-hop address to its default gateway and records this information in its routing table. Then, the MR decreases the Cur Hop Limit value in the received SERA message by 1 and broadcasts the modified SERA message. Also, the MR sends a Registration Request (RR) message to MBR1. Upon receiving the RR message, MBR1 sends a Proxy Binding Update (PBU) message with the MR address to the LMA. The LMA stores the binding information for the MR and MBR1 and sends a Proxy Binding Acknowledgement (PBAck) Jaehwoon Lee, et al. Expires April 29, 2009 [Page 5] Internet-Draft Address Autoconfiguration for multiple MBRs Oct. 30, 2008 message to MBR1. After that, a tunnel between the LMA and MBR1 is established for the MR. After receiving the PBAck message from the LMA, MBR1 sends a Registration Confirmation (RC) message to the MR. Now, the MR can communicate with any host in the global Internet. That is, if MBR1 receives a packet from the MR, it transmits the packet to the LMA via the established tunnel which, in turn, forwards it to the destination host in the global Internet. Since SERA messages are periodically advertised by each MBR, a MR can receive SERA messages advertised by another MBR even after it has configured an IPv6 address of its MANET interface. The operation of a MR receiving a SERA message is as follows. Once a MR receives a SERA message broadcasted by the neighbor node which is set as the next-hop node to its default gateway, the MR updates its corresponding routing table entry using the information in the received SERA message. That is, the MR determines the distance to its default gateway based on the Cur Hop Limit value in the SERA message. Moreover, if the MBR address in the SERA message is different from its current default gateway, the MR changes its default gateway to the MBR (i.e., MBR2) specified in the SERA message and sends a RR message to MBR2. After that, the MR broadcasts the SERA message with the modified Cur Hop Limit value. If the MR receives a SERA message from another neighbor node which is not the next-hop node to the default gateway, the MR compares the distance to the MBR having sent the SERA message (which can be computed from the Cur Hop Limit value in the SERA message) and that to its default gateway. If the former one is larger than or equal to the latter, it discards the received SERA message. Otherwise, it updates its corresponding routing table entry based on the information in the received SERA message. That is, the MR changes the distance to the default gateway to the distance value obtained from the SERA message and sets the neighbor node as the next-hop node to the default gateway. And, if the MBR address in the SERA message is different from the address of its default gateway, the MR changes its default gateway to the MBR specified in the SERA message and sends an RR message to the new default gateway. After that, the MR broadcasts a SERA message with the modified distance value. In this case, even when the default gateway is changed, the network prefix for the MANET is kept the same, so the MR can keep on maintaining its on-going session(s) because it can still use its IPv6 address configured on its MANET interface. Furthermore, even if the MR changes its default gateway, the IPv6 address configured on its MANET interface is kept the same. Thus, if the packets from a host in the Internet arrive at the MBR chosen as its previous default Jaehwoon Lee, et al. Expires April 29, 2009 [Page 6] Internet-Draft Address Autoconfiguration for multiple MBRs Oct. 30, 2008 gateway before the registration process is completed, they can be delivered to the MR via the previous default gateway, so no packet loss due to address changes will happen. If the MR does not receive a SERA message from its next-hop node to the default gateway for some time duration or it determines that the next-hop node is no more its neighbor node, the MR deletes the default gateway related entry from its routing table. 5. Security Consideration TBD. 6. IANA Considerations TBD. References [1] E. Baccelli et al., "Address Autoconfiguration for MANET: Terminology and Problem Statement", draft-ietf-autoconf- statement-04, Work in progress, Feb. 2008. [2] S. Ruffino, P. Stupar and T. Clausen, "Autoconfiguration in a MANET: connectivity scenarios and technical issues", draft- ruffino-manet-autoconf-scenarios-00, work in progress, Oct. 2004. [3] S. Ruffino and P. Stupar, "Automatic configuration of IPv6 addresses for MANET with multiple gateways (AMG)", draft-ruffino-manet-autoconf-multigw-03, work in progress, June 2006. [4] C. Jelger, T. Noel and A. Frey, "Gateway and address autoconfiguration for IPv6 adhoc networks", draft-jelger-manet- gateway-autoconf-v6-02, work in progress, apr. 2004. [5] S. Gundavelli, K. Leung, V. Devarapalli, K. Chowdhury and B. Patil, "Proxy Mobile IPv6", RFC 5213, Aug. 2008. Jaehwoon Lee, et al. Expires April 29, 2009 [Page 7] Internet-Draft Address Autoconfiguration for multiple MBRs Oct. 30, 2008 [6] J. H. Lee, S. Ahn, Y. Kim, Y. Kim and S. Kim, "Scope-Extended Router Advertisement for Connected MANETs", draft-jaehwoon- autoconf-sera-00, Work in progress, July 2008. [7] I. Chakeres, J. Macker and T. Clausen, "Mobile Ad hoc Network Architecture", draft-ietf-autoconf-manetarch-07, Work in progress, Nov. 2007. [8] S. Thomson and T. Narten, "IPv6 Stateless Address A utoconfiguration", RFC 2462, Dec. 1998. Author's Addresses Jaehwoon Lee Dongguk University 26, 3-ga Pil-dong, Chung-gu Seoul 100-715, KOREA Email: jaehwoon@dongguk.edu Sanghyun Ahn University of Seoul 90, Cheonnong-dong, Tongdaemun-gu Seoul 130-743, KOREA Email: ahn@uos.ac.kr Younghan Kim Soongsil University 11F Hyungnam Engineering Bldg. 317, Sangdo-Dong, Dongjak-Gu, Seoul 156-743 Korea E-main: yhkim@dcn.ssu.ac.kr Yuseon Kim KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792, KOREA Email: yseonkim@kt.co.kr Sangeon Kim KT 17 Woomyeon-dong, Seocho-gu Seoul 137-792, KOREA Email: sekim@kt.co.kr Jaehwoon Lee, et al. Expires April 29, 2009 [Page 8] Internet-Draft Address Autoconfiguration for multiple MBRs Oct. 30, 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Jaehwoon Lee, et al. Expires April 29, 2009 [Page 9]