idnits 2.17.1 draft-montenegro-lowpan-aodv-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 300. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 277. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 290. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2005) is 6864 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ipv6-2461bis' is defined on line 181, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-rfc2462bis' is defined on line 185, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 199, but no explicit reference was found in the text == Unused Reference: 'RFC2460' is defined on line 203, but no explicit reference was found in the text == Unused Reference: 'RFC3513' is defined on line 206, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipngwg-icmp-v3' is defined on line 223, but no explicit reference was found in the text == Unused Reference: 'KW03' is defined on line 238, but no explicit reference was found in the text == Unused Reference: 'RFC3439' is defined on line 244, but no explicit reference was found in the text == Unused Reference: 'RFC3756' is defined on line 247, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-03 ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3513 (Obsoleted by RFC 4291) ** Downref: Normative reference to an Experimental RFC: RFC 3561 -- Possible downref: Non-RFC (?) normative reference: ref. 'ieee802.15.4' == Outdated reference: A later version (-07) exists of draft-ietf-ipngwg-icmp-v3-06 == Outdated reference: A later version (-26) exists of draft-ietf-manet-dymo-02 Summary: 7 errors (**), 0 flaws (~~), 15 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Montenegro 3 Internet-Draft Microsoft Corporation 4 Expires: January 12, 2006 N. Kushalnagar 5 Intel Corp 6 July 11, 2005 8 AODV for IEEE 802.15.4 Networks 9 draft-montenegro-lowpan-aodv-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 12, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 This document describes how to use the Ad Hoc On-Demand Vector 43 Protocol (AODV) in IEEE 802.15.4 networks. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1 Requirements notation . . . . . . . . . . . . . . . . . . 3 49 2. AODV Operation over IEEE 802.15.4 . . . . . . . . . . . . . . 3 50 3. Suggested AODV Simplifications . . . . . . . . . . . . . . . . 4 51 4. Packet Delivery in a Mesh . . . . . . . . . . . . . . . . . . 4 52 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 54 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 55 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 8.1 Normative References . . . . . . . . . . . . . . . . . . . 5 57 8.2 Informative References . . . . . . . . . . . . . . . . . . 6 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 59 Intellectual Property and Copyright Statements . . . . . . . . 8 61 1. Introduction 63 The IEEE 802.15.4 standard [ieee802.15.4] targets low power personal 64 area networks. The "IPv6 over IEEE 802.15.4" document 65 [I-D.montenegro-lowpan-ipv6-over-802.15.4] defines basic 66 functionality required to carry IPv6 packets over IEEE 802.15.4 67 networks (including an adaptation layer, header compression, etc). 68 Likewise, the functionality required for packet delivery in IEEE 69 802.15.4 meshes is defined, as mesh topologies are expected to be 70 common in LoWPAN networks. However, neither the IEEE 802.15.4 71 standard nor the "IPv6 over IEEE 802.15.4" specification provide any 72 information as to how such a mesh topology could be obtained and 73 maintained. 75 This document specifies how to use the Ad Hoc On-Demand Vector 76 Protocol (AODV) [RFC3561] to provide mesh routing in IEEE 802.15.4 77 networks. To distinguish this instantiation of the protocol from 78 AODV over IPv4 and AODV over IPv6, the label "LoWPAN-AODV" is used in 79 this document. Given the very stringent limitations of the target 80 devices, this document offers guidance regarding simplifications that 81 are recommended to the base AODV specification. Given the 82 specificity of certain deployment scenarios, it is not expected that 83 AODV will always be the best choice for a mesh routing protocol. 84 Nevertheless, specifying how other mesh routing protocols may apply 85 is out of scope of this document. 87 1.1 Requirements notation 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 2. AODV Operation over IEEE 802.15.4 95 Except for the exceptions mentioned in this section, AODV operation 96 over IEEE 802.15.4 networks is as defined in [I-D.perkins-manet- 97 aodvbis]. 99 The addresses used in AODV control messages are IEEE 802.15.4 IEEE 100 64-bit extended addresses [EUI64] (however, 16-bit short address 101 support may be added later). Additionally, it should be noted that 102 as used in this specification, AODV is not layered on top of IP, but 103 underneath it. It is an underlay. As such, it creates a mesh 104 network topology underneath and unbeknownst to IP. IP sees a PAN as 105 a single link. This is similar to how other technologies regularly 106 create complex structures underneath IP (e.g., ethernet spanning tree 107 bridges, token ring source routing, ATM, etc). Of course, this does 108 not preclude simultaneously using AODV above IP. One can envision a 109 sub-IP mesh creating the illusion that all the devices on that PAN 110 are on the same IPv6 link (sharing the same IPv6 prefix). At the 111 same time, normal usage of AODV (above IP) could tie together several 112 such "links" (potentially using different technologies for each) into 113 a larger mesh. 115 AODV over IPv4 makes use of broadcast in its route discovery. It 116 does so in order to propagate the Route Request control packets 117 (RREQs). In this specification, such broadcast packets are obtained 118 by setting the PAN id to the broadcast PAN (0xffff) and by setting 119 the destination address to the broadcast short address (0xffff) 121 AODV control packets use the encapsulation defined in 122 [I-D.montenegro-lowpan-ipv6-over-802.15.4]. All AODV control packets 123 shall use the prot_type value TBD (suggested value of 4). This 124 prot_type is used to send AODV messages in a manner similar to how 125 normal AODV uses the properly assigned UDP port (654). In both 126 cases, the different types of AODV control packets (i.e., RREQ, RREP, 127 RERR and RREP-ACK) are handled via Types. This specification uses 128 the same Types and message formats as defined for normal AODV 129 [I-D.perkins-manet-aodvbis]. 131 3. Suggested AODV Simplifications 133 Besides the main AODV specification [RFC3561], several efforts aim at 134 further correctness [I-D.perkins-manet-aodvbis] or simplifications of 135 the protocol, as in the AODVjr proposal [AODVjr] or the TinyAODV 136 implementation [TinyAODV]. Similarly, DyMO allows for minimalist 137 implementation leaving non-essential functionality as optional 138 [I-D.ietf-manet-dymo]. In keeping with the spirit of the above, 139 LoWPAN-AODV simplifies AODV as follows: 140 o The only AODV control messages required to be implemented are RREQ 141 (Route Request) and RREP (Route Reply). 143 o Only the final destination responds to a RREQ by sending an RREP. 145 o Only hop count is used to determine best routes. 147 o Hello messages are not used. Instead, the IEEE 802.15.4 148 acknowledgement mechanism is used to determine if a neighbor is no 149 longer responsive. This information is obtained when transmitting 150 a packet with acknowledgements turned on. 152 4. Packet Delivery in a Mesh 154 Packet delivery is done by using the "Final Destination" field 155 defined and procedures defined in [I-D.montenegro-lowpan-ipv6-over- 156 802.15.4]. 158 5. IANA Considerations 160 This document requests that IANA assign a value out of the prot_type 161 (Protocol Type) registry defined in [I-D.montenegro-lowpan-ipv6-over- 162 802.15.4]. The value requested is for LoWPAN-AODV (suggested value: 163 4). 165 6. Security Considerations 167 TBD. 169 7. Acknowledgements 171 TBD. 173 8. References 175 8.1 Normative References 177 [EUI64] "GUIDELINES FOR 64-BIT GLOBAL IDENTIFIER (EUI-64) 178 REGISTRATION AUTHORITY", IEEE http://standards.ieee.org/ 179 regauth/oui/tutorials/EUI64.html. 181 [I-D.ietf-ipv6-2461bis] 182 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 183 draft-ietf-ipv6-2461bis-03 (work in progress), May 2005. 185 [I-D.ietf-ipv6-rfc2462bis] 186 Thomson, S., "IPv6 Stateless Address Autoconfiguration", 187 draft-ietf-ipv6-rfc2462bis-08 (work in progress), 188 May 2005. 190 [I-D.montenegro-lowpan-ipv6-over-802.15.4] 191 Montenegro, G., "Transmission of IPv6 Packets over IEEE 192 802.15.4 Networks", 193 draft-montenegro-lowpan-ipv6-over-802.15.4-02 (work in 194 progress), February 2005. 196 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 197 Requirement Levels", BCP 14, RFC 2119, March 1997. 199 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 200 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 201 October 1998. 203 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 204 (IPv6) Specification", RFC 2460, December 1998. 206 [RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 207 (IPv6) Addressing Architecture", RFC 3513, April 2003. 209 [RFC3561] Perkins, C., Belding-Royer, E., and S. Das, "Ad hoc On- 210 Demand Distance Vector (AODV) Routing", RFC 3561, 211 July 2003. 213 [ieee802.15.4] 214 IEEE Computer Society, "IEEE Std. 802.15.4-2003", 215 October 2003. 217 8.2 Informative References 219 [AODVjr] Chakeres, Ian and Klein-Berndt, Luke, "AODVjr, AODV 220 Simplified", ACM SIGMOBILE Mobile Computing and 221 Communications Review pp. 100-101, July 2002. 223 [I-D.ietf-ipngwg-icmp-v3] 224 Conta, A., "Internet Control Message Protocol (ICMPv6)for 225 the Internet Protocol Version 6 (IPv6) Specification", 226 draft-ietf-ipngwg-icmp-v3-06 (work in progress), 227 November 2004. 229 [I-D.ietf-manet-dymo] 230 Chakeres, I., "Dynamic MANET On-demand (DYMO) Routing", 231 draft-ietf-manet-dymo-02 (work in progress), June 2005. 233 [I-D.perkins-manet-aodvbis] 234 Perkins, C., "Ad hoc On-Demand Distance Vector (AODV) 235 Routing", draft-perkins-manet-aodvbis-01 (work in 236 progress), February 2004. 238 [KW03] Karlof, Chris and Wagner, David, "Secure Routing in Sensor 239 Networks: Attacks and Countermeasures", Elsevier's AdHoc 240 Networks Journal, Special Issue on Sensor Network 241 Applications and Protocols vol 1, issues 2-3, 242 September 2003. 244 [RFC3439] Bush, R. and D. Meyer, "Some Internet Architectural 245 Guidelines and Philosophy", RFC 3439, December 2002. 247 [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 248 Discovery (ND) Trust Models and Threats", RFC 3756, 249 May 2004. 251 [TinyAODV] 252 "TinyAODV Implementation", TinyOS Source Code Repository h 253 ttp://cvs.sourceforge.net/viewcvs.py/tinyos/tinyos-1.x/ 254 contrib/hsn/. 256 Authors' Addresses 258 Gabriel Montenegro 259 Microsoft Corporation 261 Email: gabriel_montenegro_2000@yahoo.com 263 Nandakishore Kushalnagar 264 Intel Corp 266 Email: nandakishore.kushalnagar@intel.com 268 Intellectual Property Statement 270 The IETF takes no position regarding the validity or scope of any 271 Intellectual Property Rights or other rights that might be claimed to 272 pertain to the implementation or use of the technology described in 273 this document or the extent to which any license under such rights 274 might or might not be available; nor does it represent that it has 275 made any independent effort to identify any such rights. Information 276 on the procedures with respect to rights in RFC documents can be 277 found in BCP 78 and BCP 79. 279 Copies of IPR disclosures made to the IETF Secretariat and any 280 assurances of licenses to be made available, or the result of an 281 attempt made to obtain a general license or permission for the use of 282 such proprietary rights by implementers or users of this 283 specification can be obtained from the IETF on-line IPR repository at 284 http://www.ietf.org/ipr. 286 The IETF invites any interested party to bring to its attention any 287 copyrights, patents or patent applications, or other proprietary 288 rights that may cover technology that may be required to implement 289 this standard. Please address the information to the IETF at 290 ietf-ipr@ietf.org. 292 Disclaimer of Validity 294 This document and the information contained herein are provided on an 295 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 296 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 297 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 298 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 299 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 300 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 302 Copyright Statement 304 Copyright (C) The Internet Society (2005). This document is subject 305 to the rights, licenses and restrictions contained in BCP 78, and 306 except as set forth therein, the authors retain all their rights. 308 Acknowledgment 310 Funding for the RFC Editor function is currently provided by the 311 Internet Society.