idnits 2.17.1 draft-jelger-autoconf-mla-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 210. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 187. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 194. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 200. ** 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 == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (April 12, 2006) is 6588 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) ** Obsolete normative reference: RFC 3513 (ref. '2') (Obsoleted by RFC 4291) ** Obsolete normative reference: RFC 3041 (ref. '3') (Obsoleted by RFC 4941) Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Autoconf Working Group C. Jelger 3 Internet-Draft Fraunhofer FOKUS 4 Expires: October 14, 2006 April 12, 2006 6 MANET Local IPv6 Addresses 7 draft-jelger-autoconf-mla-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 14, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 This document defines how Unique Local IPv6 Unicast Addresses (RFC- 41 4193) can be used in wireless mobile ad hoc networks (MANETs) as 42 MANET Local IPv6 Addresses (MLAs). MLAs are intended to be used 43 inside a MANET and are not expected to be routable on the global 44 Internet. Each MANET node is expected to generate its MLA locally 45 without any coordination with other MANET nodes. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. MANET Local IPv6 Addresses (MLAs) . . . . . . . . . . . . . . . 3 54 3.1. Format . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.2. Address generation . . . . . . . . . . . . . . . . . . . . 4 56 3.3. Address scope . . . . . . . . . . . . . . . . . . . . . . . 4 58 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 Intellectual Property and Copyright Statements . . . . . . . . . . 7 63 1. Introduction 65 This document defines a possible use of Unique Local IPv6 Unicast 66 Addresses (ULAs)[1] as MANET Local IPv6 Addresses (MLAs) in wireless 67 mobile ad hoc networks (MANETs). MLAs are intended to be used inside 68 a MANET and are not expected to be routable on the global Internet. 69 Each MANET node is expected to generate its MLA locally, i.e. without 70 any coordination with other MANET nodes. 72 This extends the usage of ULAs to an extreme case where each MANET 73 node is considered as being a site and subnet [1] by itself. Since 74 MANET routing is flat (i.e. it creates /128 host routes), MANET nodes 75 do not necessarily need to share a network prefix for intra-MANET 76 communications. This loose addressing model allows to use a large 77 fraction of the upper 64-bit part of IPv6 addresses in order to 78 create addresses that are sufficiently random to avoid the use of 79 duplicate address detection schemes for intra-MANET communications. 81 2. Acknowledgements 83 The idea of using Unique Local IPv6 Addresses as MANET Local 84 Addresses has been originally discussed with a number of people 85 including Ryuji Wakikawa, Francisco Ros, Robert Hinden, Brian 86 Haberman and Guillaume Chelius. Therefore the author of this 87 document does not claim exclusive credit. Also note that the 88 formatting of this document is mostly inspired by [1]. 90 3. MANET Local IPv6 Addresses (MLAs) 92 3.1. Format 94 Strictly speaking, MLAs have the same format as ULAs. The only 95 difference with ULAs is that both the Global ID and Subnet ID fields 96 are randomly generated. This results in a merged 56-bit field called 97 the Random ID. 99 | 7 bits |1| 56 bits | 64 bits | 100 +--------+-+------------------------+----------------------------+ 101 | Prefix |L| Random ID | Interface ID | 102 +--------+-+------------------------+----------------------------+ 103 Where: 105 Prefix FC00::/7 prefix to identify Local IPv6 unicast 106 addresses. 108 L Set to 1. See [1] for details. 110 Random ID 56-bit random identifier used to create a 111 globally unique address. 113 Interface ID 64-bit Interface ID as defined in [2]. 115 3.2. Address generation 117 To create an MLA for a given physical interface, a MANET node locally 118 generates its Random ID in a random manner. Since MANET routing is 119 flat and creates /128 host routes, MANET nodes do not need to share a 120 network prefix. Hence the Random ID is used in addition to the 121 Interface ID in order to create unique addresses (with a very high 122 probability of uniqueness). Using 56 bits gives around 7.2e+16 123 possible values for the Random ID, hence drastically reducing the 124 probability of an address collision if two nodes having the same 125 Interface ID generate the same Random ID. 127 The probability of an address collision is further reduced by the use 128 of EUI-64 identifiers as Interface IDs. EUI-64 that derive from 129 EUI-48 (e.g. IEEE 802 48-bit MAC addresses) are indeed expected to 130 be globally unique, while randomly generated identifiers [3] have an 131 extremely low collision probability (around 1.8e+19 possible values). 133 Given the network size currently being considered within the MANET 134 community (a few hundred nodes), and given the extremely large 135 randomness of MLAs, a node must not necessarily check whether a 136 generated MLA is unique. The overhead of performing duplicate 137 address detection (DAD) greatly superseeds its gain since the 138 probability of address collisions is extremely low. 140 Nevertheless, a passive DAD technique could be used in order to 141 detect address collisions, eventhough such events are very unlikely 142 to occur. This extra mechanism is however out of the scope of this 143 document. 145 3.3. Address scope 147 As Unique Local IPv6 Unicast Addresses, MANET Local Addresses have a 148 global scope. However MLAs are not globally routeable, and their use 149 is restricted inside a MANET. Since there does not exist any 150 standardized definition of the boundaries of a MANET, we assume that 151 the use of MLAs is restricted to the set of MANET nodes (or routing 152 instances) willing to route packets using MLAs. This assumes that a 153 MANET routing protocol should always be willing to route packets 154 whose source and/or destination addresses are MLAs. 156 4. References 158 [1] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 159 Addresses", RFC 4193, October 2005. 161 [2] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 162 Addressing Architecture", RFC 3513, April 2003. 164 [3] Narten, T. and R. Draves, "Privacy Extensions for Stateless 165 Address Autoconfiguration in IPv6", RFC 3041, January 2001. 167 Author's Address 169 Christophe Jelger 170 Fraunhofer Institute FOKUS 171 Kaiserin-Augusta-Allee 31 172 Berlin 10589 173 Germany 175 Phone: +49 30 3463 7137 176 Email: cje@fokus.fraunhofer.de 178 Intellectual Property Statement 180 The IETF takes no position regarding the validity or scope of any 181 Intellectual Property Rights or other rights that might be claimed to 182 pertain to the implementation or use of the technology described in 183 this document or the extent to which any license under such rights 184 might or might not be available; nor does it represent that it has 185 made any independent effort to identify any such rights. Information 186 on the procedures with respect to rights in RFC documents can be 187 found in BCP 78 and BCP 79. 189 Copies of IPR disclosures made to the IETF Secretariat and any 190 assurances of licenses to be made available, or the result of an 191 attempt made to obtain a general license or permission for the use of 192 such proprietary rights by implementers or users of this 193 specification can be obtained from the IETF on-line IPR repository at 194 http://www.ietf.org/ipr. 196 The IETF invites any interested party to bring to its attention any 197 copyrights, patents or patent applications, or other proprietary 198 rights that may cover technology that may be required to implement 199 this standard. Please address the information to the IETF at 200 ietf-ipr@ietf.org. 202 Disclaimer of Validity 204 This document and the information contained herein are provided on an 205 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 206 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 207 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 208 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 209 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 210 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 212 Copyright Statement 214 Copyright (C) The Internet Society (2006). This document is subject 215 to the rights, licenses and restrictions contained in BCP 78, and 216 except as set forth therein, the authors retain all their rights. 218 Acknowledgment 220 Funding for the RFC Editor function is currently provided by the 221 Internet Society.