MANET WG Internet-Draft J. Jeong J. Park ETRI Y. Kim S. Ahn University of Seoul Expires: January 2005 12 July 2004 Multicast Ad hoc On-Demand Distance Vector Routing for IP version 6 (MAODV6) draft-jeong-manet-maodv6-00.txt Status of this Memo By submitting this Internet-Draft, we certify that any applicable patent or other IPR claims of which we are aware have been disclosed, and any of which we become aware will be disclosed, in accordance with RFC3668. 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 January 11, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Jeong, et al. Expires - January 2005 [Page 1] Internet-Draft MAODV6 July 2004 This document describes multicasting based on shared multicast tree for IPv6 mobile ad hoc networks, which specifies an extension of MAODV including message formats. In addition, forwarding mechanism of multicast data packets is described to prevent duplicate data packets from being received by multicast group members. Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. Message Formats...............................................3 3.1 Route Request (RREQ) Message Format......................3 3.2 Route Reply (RREP) Message Format........................4 3.3 Multicast Activation (MACT) Message Format...............5 3.4 Group Hello (GRPH) Message Format........................5 4. Forwarding of Multicast Data Packets..........................6 5. IANA Considerations...........................................8 6. Security Considerations.......................................8 7. Acknowledgements..............................................8 8. Normative References..........................................8 9. Informative References........................................9 10. Authors' Addresses...........................................9 Intellectual Property Statement.................................10 Full Copyright Statement........................................10 Acknowledgement.................................................11 1. Introduction The Multicast Ad hoc On-Demand Distance Vector (MAODV) protocol can be used for multicasting in IPv4 mobile ad hoc networks that use Ad hoc On-Demand Distance Vector (AODV) as unicast routing protocol [3][4]. Because IPv6 has abundant address space and auto-configuration facility, ad hoc networking can play an important role in ubiquitous networking through using IPv6 as network layer protocol [6]. This document describes multicasting based on shared multicast tree for IPv6 mobile ad hoc networks, which is an extension of MAODV for IPv6 (MAODV6). The operation of MAODV6 is intended to mirror the operation of MAODV for IPv4 [3], with changes necessary to allow for transmission of 128-bit addresses in use with IPv6 instead of the more traditional 32-bit addresses. The reader is referred to [3] for most of the terminology, and the specification of MAODV. In this document, message formats are described for MAODV6 Jeong, et al. Expires - January 2005 [Page 2] Internet-Draft MAODV6 July 2004 operations. In addition, forwarding mechanism of multicast data packets is described to prevent duplicate data packets from being received by multicast group members. 2. Terminology This document uses the terminology described in [3]-[5]. In addition, a new term is defined below: Multicast AODV for IPv6 (MAODV6) Multicast Ad hoc On-Demand Distance Vector (MAODV) routing protocol for IPv6 mobile ad hoc networks. 3. Message Formats 3.1 Route Request (RREQ) Message Format 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 |J|R|G|D|U| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit RREQ ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IPv6 Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IPv6 Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the IPv6 Route Request message (RREQ) is illustrated above, and contains the same fields with the same functions as the RREQ message defined for IP version 4 (in [3][4]), except as follows: Type TBD Destination IPv6 Address The 128-bit IPv6 address of destination for which a route is desired. Source IPv6 Address Jeong, et al. Expires - January 2005 [Page 3] Internet-Draft MAODV6 July 2004 The 128-bit IPv6 address of the node which originated the Route Request. Note also that the order of the fields has been changed to enable alignment along 128-bit boundaries. 3.2 Route Reply (RREP) Message Format 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 |R|A| Reserved | Prefix Size | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Destination Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Destination IPv6 Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IPv6 Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the IPv6 Route Reply message (RREP) is illustrated above, and contains the same fields with the same functions as the RREP message defined for IP version 4 (in [3][4]), except as follows: Type TBD Prefix Size The Prefix Size is 7 bits instead of 5, to account for the 128-bit IPv6 address space. Destination Sequence Number The destination sequence number associated to the route. Destination IPv6 Address The 128-bit IP address of the destination for which a route is supplied. Source IPv6 Address The 128-bit IP address of the source node which issued the RREQ for which the route is supplied. Note also that the order of the fields has been changed to enable Jeong, et al. Expires - January 2005 [Page 4] Internet-Draft MAODV6 July 2004 alignment along 128-bit boundaries. 3.3 Multicast Activation (MACT) Message Format 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 |J|P|G|U|R| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Source Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Multicast Group IPv6 Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Source IPv6 Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the IPv6 Multicast Activation (MACT) is illustrated above, and contains the same fields with the same functions as the MACT message defined for IP version 4 (in [3]), except as follows: Type TBD Multicast Group IPv6 Address The 128-bit IP address of the Multicast Group for which a route is supplied. Source IPv6 Address The 128-bit IP address of the sending node. Note also that the order of the fields has been changed to enable alignment along 128-bit boundaries. 3.4 Group Hello (GRPH) Message Format 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 |U|M| Reserved | Hop Count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 32-bit Multicast Group Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Group Leader IPv6 Address : | | Jeong, et al. Expires - January 2005 [Page 5] Internet-Draft MAODV6 July 2004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | : 128-bit Multicast Group IPv6 Address : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the IPv6 Group Hello (GRPH) is illustrated above, and contains the same fields with the same functions as the GRPH message defined for IP version 4 (in [3]), except as follows: Type TBD Group Leader IPv6 Address The 128-bit IP address of the group leader. Multicast Group IPv6 Address The 128-bit IP address of the Multicast Group for which the sequence number is supplied. Note also that the order of the fields has been changed to enable alignment along 128-bit boundaries. 4. Forwarding of Multicast Data Packets Forwarding of multicast data packets in MANET is different from that in wired networks. In wired networks, a network interface of a node has a one-to-one connection to one of the network interfaces of other nodes. If the packet coming into an incoming interface needs to be forwarded, it is delivered to the corresponding outgoing interface. Hence transmitting node plays a main role of forwarding in wired networks. However, in wireless ad hoc networks, in most cases each node has only one network interface, so the incoming interface is the same as the outgoing one. Because the wireless network interface of a node has a one-to-many connection to those of neighboring nodes, a node receiving a packet SHOULD filter unnecessary packets. In the unicast forwarding case, a node drops a received packet if the destination MAC address of the packet is different from its MAC address. In the multicast forwarding case, because the destination MAC address is a multicast group address, a node receiving a multicast packet can not know whether it has already received the packet or not. Here, since this document is focusing only on the multicast data forwarding, from now on, 'packet' or 'data' implies 'multicast packet' or 'multicast data'. According to the above-mentioned reason, tree-based ad hoc multicast routing protocols including MAODV6 may cause data duplication and the causes of data duplication can be classified as follows: Jeong, et al. Expires - January 2005 [Page 6] Internet-Draft MAODV6 July 2004 (a) Data duplication by reverse transmission When a node forwards a received packet to its next hop or hops, the packet is also sent to the node which has previously forwarded the packet to this node. This type of duplication is named as the "data duplication by reverse transmission". (b) Data duplication by transmission from non-neighbor When a packet is forwarded to the next hops which are members of the corresponding multicast tree, nodes which are not neighbors in the tree may receive the packet. This type of duplication is named as the "data duplication by transmission from non-neighbor". In IPv4, the data duplication by reverse transmission can be resolved by making each node maintain a message cache with (Source IPv4 Address, IPv4 Sequence Number) entries, in which IPv4 Sequence Number can be contained in 'Identification' field in IPv4 header. Upon receiving a packet, if the message cache of the node does not have the (Source IPv4 Address of the packet, IPv4 Sequence Number of the packet) entry, the entry is newly added to the message cache and the packet is accepted. Otherwise (i.e., the entry is already in the message cache), the packet is a duplicate and discarded. In IPv6, the above-mentioned scheme can not be applied since the 'Identification' field for sequence number does not exist in the IPv6 basic header. Furthermore, the message cache requires a lot of memory in maintaining entries for all non-duplicate packets. In order to prevent the data duplication by reverse transmission in the MAODV6 environment, each node is required to maintain a message cache with (Source IPv6 Address, Multicast Group IPv6 Address, Source MAC Address) entries. A packet can be accepted if it comes from the node with the same address as the source MAC address for the (Source IPv6 Address, Multicast Group IPv6 Address) pair. When a node receives a packet and if the message cache of the node does not have the (Source IPv6 Address of the packet, Multicast Group IPv6 Address of the packet, Source MAC Address of the packet) entry, the entry is newly added to the message cache and the packet is accepted. The number of entries is smaller than that of the method using the sequence number because in this case a message cache only has to maintain one entry per source of a multicast session. This approach is against the layering concept since the MAC address (which is relevant to the layer 2) is used in forwarding (which is relevant to the layer 3). However, this approach allows a node to know the previous node of a packet efficiently. To prevent the data duplication by transmission from non-neighbor, each node maintains a multicast neighbor table with (Multicast Group IPv6 Address, Neighbor MAC Address List) entries. This entry has the Jeong, et al. Expires - January 2005 [Page 7] Internet-Draft MAODV6 July 2004 meaning that a multicast packet is accepted if it comes from the node with the same address as one of the addresses (i.e., neighbors) in the neighbor MAC address list for the multicast group IPv6 address. When MAODV6 adds, deletes and updates entries of the multicast routing table, the multicast neighbor table SHOULD be updated so that the routing changes can be reflected. A node determines whether it has to forward a packet or not according to the number of neighboring nodes in the corresponding multicast tree. If the number of neighboring nodes is more than zero in the case of multicast source, or is more than one in the case of an intermediate node for forwarding, the packet is forwarded or transmitted. Like this, the multicast data forwarding in MAODV6 provides a simple forwarding mechanism for transmitting nodes and an efficient packet filtering mechanism for receiving nodes. 5. IANA Considerations The message types for MAODV6 should be defined by IANA, such as RREQ, RREP, MACT and GRPH. 6. Security Considerations Currently, MAODV6 does not specify any special security measures. Route protocols, however, are prime targets for impersonation attacks and must be protected by use of authentication techniques involving generation of unforgeable and cryptographically strong message digests or digital signatures. It is expected that, in environments where security is an issue, that IPSec authentication headers will be deployed along with the necessary key management to distribute keys to the members of the ad hoc network using MAODV6. 7. Acknowledgements The authors would like to appreciate the previous contribution of Charles E. Perkins and Elizabeth M. Belding-Royer. 8. Normative References [1] S. Bradner, "Intellectual Property Rights in IETF Technology", RFC 3668, February 2004. [2] S. Bradner, "IETF Rights in Contributions", RFC 3667, February 2004. Jeong, et al. Expires - January 2005 [Page 8] Internet-Draft MAODV6 July 2004 [3] E. Belding-Royer and C. Perkins, "Multicast Ad hoc On-Demand Distance Vector (MAODV) Routing", draft-ietf-manet-maodv- 00.txt. July 2000. [4] C. Perkins, E. Belding-Royer and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing", RFC3561, July 2003. [5] C. Perkins, E. Belding-Royer and S. Das, "Ad hoc On-Demand Distance Vector (AODV) Routing for IP version 6", draft- perkins-manet-aodv6-01.txt, November 2000. 9. Informative References [6] J. Jeong, J. Park and H. Kim, "Auto-Networking Technologies for IPv6 Mobile Ad Hoc Networks", ICOIN 2004, February 2004. 10.Authors' Addresses Jaehoon Paul Jeong ETRI / PEC 161 Gajeong-dong, Yuseong-gu Daejeon 305-350 Korea Phone: +82 42 860 1664 Fax: +82 42 861 5404 EMail: paul@etri.re.kr Jungsoo Park ETRI / PEC 161 Gajeong-dong, Yuseong-gu Daejeon 305-350 Korea Phone: +82 42 860 6514 Fax: +82 42 861 5404 EMail: pjs@etri.re.kr Youngmin Kim Dept. of Computer Science University of Seoul 90 Jeonnong-dong, Dongdaemoon-gu Seoul 130-743 Korea Phone: +82 2 2210 2957 Fax: +82 2 2210 5275 EMail: blhole@venus.uos.ac.kr Jeong, et al. Expires - January 2005 [Page 9] Internet-Draft MAODV6 July 2004 Sanghyun Ahn Dept. of Computer Science University of Seoul 90 Jeonnong-dong, Dongdaemoon-gu Seoul 130-743 Korea Phone: +82 2 2210 2631 Fax: +82 2 2210 5275 EMail: ahn@venus.uos.ac.kr Intellectual Property Statement The following intellectual property notice is copied from RFC3668, Section 5. 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. Full Copyright Statement The following copyright notice is copied from RFC3667, Section 5.4. It describes the applicable copyright for this document. 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. Jeong, et al. Expires - January 2005 [Page 10] Internet-Draft MAODV6 July 2004 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Jeong, et al. Expires - January 2005 [Page 11]