idnits 2.17.1 draft-ietf-autoconf-statement-03.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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 392. 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 IETF Trust 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 (January 31, 2008) is 5901 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: '2' is defined on line 268, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 271, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 274, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 278, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 281, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 284, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 287, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 289, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 292, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 296, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 299, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 302, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 305, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 308, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 311, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 314, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 317, but no explicit reference was found in the text ** Downref: Normative reference to an Informational draft: draft-ietf-autoconf-manetarch (ref. '1') -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '4') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 2740 (ref. '9') (Obsoleted by RFC 5340) -- Obsolete informational reference (is this intentional?): RFC 3041 (ref. '12') (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. '18') (Obsoleted by RFC 8415) Summary: 2 errors (**), 0 flaws (~~), 19 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MANET Autoconfiguration (Autoconf) E. Baccelli (Ed.) 3 Internet-Draft INRIA 4 Expires: August 3, 2008 K. Mase 5 Niigata University 6 S. Ruffino 7 Telecom Italia 8 S. Singh 9 Samsung 10 January 31, 2008 12 Address Autoconfiguration for MANET: Terminology and Problem Statement 13 draft-ietf-autoconf-statement-03 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 3, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 This document states the problems pertaining to automatic IPv6 47 address configuration and prefix allocation in MANETs. 49 This draft currently contains terminology, target scenarios and goals 50 for MANET autoconfiguration. Future versions of this document will 51 also review the applicability of existing IPv6 address 52 autoconfiguration and prefix allocation mechanisms, and security 53 considerations. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. MANET Categories . . . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. Subordinate MANET . . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. Scenarios of Subordinate MANETs . . . . . . . . . . . 6 62 3.2. Autonomous MANET . . . . . . . . . . . . . . . . . . . . . 6 63 3.2.1. Scenarios of Autonomous MANETs . . . . . . . . . . . . 7 64 4. MANET Autoconfiguration Goals . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 67 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 69 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 70 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 72 Intellectual Property and Copyright Statements . . . . . . . . . . 15 74 1. Introduction 76 As defined in [1], a MANET is a network composed of MANET routers, 77 each of which has at least one MANET interface. This document states 78 the goals of autoconfiguration mechanism(s) for MANETs, with respect 79 to the necessary parameters for basic IP identification. 80 Specifically, this document thus states the requirements for: 82 - autoconfiguring MANET interfaces with IPv6 addresses; 84 - automatic allocation of IPv6 prefixes to MANET routers. 86 This draft currently contains terminology, target scenarios and goals 87 for MANET autoconfiguration. Future versions of this document will 88 also review the applicability of existing IPv6 address 89 autoconfiguration and prefix allocation mechanisms, and security 90 considerations. 92 2. Terminology 94 This document uses the terminology defined in [1], as well as the 95 following terms : 97 External Network - a network connected to the MANET, through an 98 interface that is not part of this MANET. 100 Subordinate MANET - a MANET, which is connected to one or more 101 external network(s), and where such external network(s) are 102 imposing an addressing hierarchy scheme on the MANET. 104 Autonomous MANET - a MANET upon which no external network imposes an 105 addressing hierarchy. 107 Address autoconfiguration - the process of configuring an interface 108 with a given address, using an automatic mechanism (contrary to 109 manual configuration). 111 Prefix allocation - the process of providing a router with authority 112 over an aggregatable pool of addresses (i.e. a prefix), for the 113 purpose of configuring interfaces or other routers. 115 Disjoint prefixes - two prefixes are said to be disjoint if and only 116 if their respective address ranges do not overlap. 118 Network merging - the process by which two or more previously 119 disjoint MANETs get connected. 121 Network partitioning - the process by which a MANET splits into two 122 or more disconnected MANETs. 124 3. MANET Categories 126 IP address autoconfiguration on MANET interfaces and prefix 127 allocation for MANET routers may be used in a number of deployment 128 scenarios. This section outlines the different types of scenarios 129 that are to be addressed by solutions for MANET autoconfiguration. 131 Note that solutions should also aim at coping with special cases such 132 as a MANET transiting from one type of scenario to an other, or such 133 as routers pre-configured with IP addresses (or prefixes) joining the 134 MANET. 136 3.1. Subordinate MANET 138 A subordinate MANET, as shown in Fig. 1, is a MANET which is 139 connected to at least one external network N that imposes a specific 140 addressing hierarchy on the MANET. In a subordinate MANET, this 141 addressing hierarchy yields the use of specific prefixes for 142 communications between nodes in the MANET and nodes in or across 143 network N. For instance, in Fig. 1, these prefixes need to be 144 topologically correct, i.e. allocated from within a prefix p::, over 145 which the point of attachment to network N has authority. 147 '. / 148 `. Network N / 149 `. _,' 150 `-.__ _,,' 151 `'-.,._,,'' 152 : Topologically correct prefix 153 +-:-+ p:: with respect to network N 154 |MNR| 155 +-|-+ 156 +-+ +---+ / /|\ \ +---+ 157 | |...MNR--- .-. ---MNR| 158 +-+ +---+ \ ,-( _)-. / +---+ 159 .-(_ MANET )-. 160 Other ( Communication ) 161 Nodes `-(______)-' 162 and \|/ \|/ 163 Networks +-|-+ +-|-+ 164 |MNR| \|/ |MNR| 165 +-:-+ +-|-+ +-:-+ 166 |MNR| : 167 +-:-+ +-+ 168 +-+ 170 Figure 1: Subordinate MANET. Imposed address 171 hierarchy by external network N. 173 3.1.1. Scenarios of Subordinate MANETs 175 This section contains a non-exhaustive list of examples of MANETs 176 falling in the subordinate category. 178 A typical example of subordinate MANET is a MANET that is part of the 179 Internet, which yields the use of topologically correct IP addresses 180 in order to communicate over the Internet. For instance public 181 wireless mesh networks, i.e. scattered fixed WLAN access routers 182 participating in a MANET of mobile users, and acting as border 183 routers. 185 Another typical example is the coverage extension of a fixed wide- 186 area wireless network, where one or more MANET router(s) are 187 connected to the Internet through technologies such as UMTS or WiMAX. 189 Car-to-car communication networks connected to an external 190 infrastructure may also be understood as an instance of subordinate 191 MANET. 193 3.2. Autonomous MANET 195 Autonomous MANETs are MANETs upon which no external network imposes 196 an addressing hierarchy. This is shown in Fig. 2, as opposed to the 197 subordinate MANET category described in Section 3.1. 199 +---+ 200 |MNR| 201 +-|-+ 202 +-+ +---+ / /|\ \ +---+ 203 | |...MNR--- .-. ---MNR| 204 +-+ +---+ \ ,-( _)-. / +---+ 205 .-(_ MANET )-. 206 Other ( Communication ) 207 Nodes `-(______)-' 208 and \|/ \|/ 209 Networks +-|-+ +-|-+ 210 |MNR| \|/ |MNR| 211 +-:-+ +-|-+ +-:-+ 212 |MNR| : 213 +-:-+ +-+ 214 +-+ 216 Figure 2: Autonomous MANET. No subordination to an 217 addressing scheme imposed by an external network. 219 3.2.1. Scenarios of Autonomous MANETs 221 This section contains a non-exhaustive list of instances of MANETs 222 falling in the autonomous category. 224 Typical examples of autonomous MANETs are networks set-up in areas 225 where infrastructure is unavailable or inapproriate. For instance, 226 car-to-car communication for sharing traffic and safety-related 227 information, on-site emergency communication among rescue team 228 members for disaster recovery, file sharing in conference or class 229 rooms. 231 4. MANET Autoconfiguration Goals 233 The goals of AUTOCONF is to provide autoconfiguration mechanisms 234 which allow each MANET router to: 236 1. configure IPv6 addresses that are unique within the MANET, on 237 their MANET interface(s). 239 2. be allocated IPv6 prefixes that are disjoint from prefixes 240 allocated to other routers within the MANET. 242 3. maintain, within the MANET, the uniqueness of configured addresses 243 and the disjoint character of allocated prefixes (even in face of 244 network merging). 246 4. be allocated topologically correct prefixes, in the subordinate 247 MANET scenario. 249 5. Security Considerations 251 This document does not currently introduce security considerations 252 beyond those captured by [1]. 254 6. IANA Considerations 256 This document does not specify IANA considerations. 258 7. References 260 7.1. Normative References 262 [1] Macker, J., Chakeres, I., and T. Clausen, "Mobile Ad hoc 263 Network Architecture", ID draft-ietf-autoconf-manetarch, 264 February 2007. 266 7.2. Informative References 268 [2] Macker, J. and S. Corson, "MANET Routing Protocol Performance 269 Issues and Evaluation Considerations", RFC 2501, January 1999. 271 [3] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 272 "Neighbor Discovery for IPv6", RFC 4861, September 2007. 274 [4] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 275 Carney, "Dynamic Host Configuration Protocol for IPv6", 276 RFC 3315, July 2003. 278 [5] Narten, T., Thomson, S., and T. Jinmei, "IPv6 Stateless Address 279 Autoconfiguration", RFC 4862, September 2007. 281 [6] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 282 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 284 [7] Draves, R. and D. Thaler, "Default Router Preferences and More- 285 Specific Routes", RFC 4191, 2005. 287 [8] Moy, J., "OSPF version 2", RFC 2328, 1998. 289 [9] Moy, J., Coltun, R., and D. Ferguson, "OSPF for IPv6", 290 RFC 2740, 1999. 292 [10] Chakeres, I., "Internet Assigned Numbers Authority (IANA) 293 Allocations for the Mobile Ad hoc Networks (MANET) Working 294 Group", ID draft-ietf-manet-iana, May 2007. 296 [11] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, 297 2001. 299 [12] Narten, T. and R. Draves, "Privacy Extensions for Stateless 300 Address Autoconfiguration in IPv6", RFC 3041, 2001. 302 [13] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 303 Neighbor Discovery (SEND)", RFC 3971, 2005. 305 [14] Aura, T., "Cryptographically Generated Addresses (CGA)", 306 RFC 3972, 2005. 308 [15] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 309 IPv6", RFC 4429, 2006. 311 [16] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 312 Addresses", RFC 4193, 2005. 314 [17] Thubert, P. and TJ. Kniveton, "Mobile Network Prefix 315 Delegation", ID draft-ietf-nemo-prefix-delegation, August 2007. 317 [18] Troan, O. and R. Droms, "IPv6 Prefix Options for DHCPv6", 318 RFC 3633, 2003. 320 Contributors 322 This document is the result of joint efforts, including those of the 323 following contributers, listed in alphabetical order: C. Adjih, C. 324 Bernardos, T. Boot, T. Clausen, C. Dearlove, U. Herberg, G. 325 Montenegro, H. Moustafa, C. Perkins, A. Petrescu, P. Ruiz, P. Stupar, 326 F. Templin, D. Thaler, R. Wakikawa, K. Weniger. 328 Authors' Addresses 330 Emmanuel Baccelli 331 INRIA 333 Phone: +33 1 69 33 55 11 334 Email: Emmanuel.Baccelli@inria.fr 336 Kenichi Mase 337 Niigata University 339 Phone: +81 25 262 7446 340 Email: Mase@ie.niigata-u.ac.jp 342 Simone Ruffino 343 Telecom Italia 345 Phone: +39 011 228 7566 346 Email: Simone.Ruffino@telecomitalia.it 348 Shubhranshu Singh 349 Samsung 351 Phone: +82 31 280 9569 352 Email: Shubranshu@gmail.com 354 Full Copyright Statement 356 Copyright (C) The IETF Trust (2008). 358 This document is subject to the rights, licenses and restrictions 359 contained in BCP 78, and except as set forth therein, the authors 360 retain all their rights. 362 This document and the information contained herein are provided on an 363 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 364 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 365 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 366 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 367 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 368 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 370 Intellectual Property 372 The IETF takes no position regarding the validity or scope of any 373 Intellectual Property Rights or other rights that might be claimed to 374 pertain to the implementation or use of the technology described in 375 this document or the extent to which any license under such rights 376 might or might not be available; nor does it represent that it has 377 made any independent effort to identify any such rights. Information 378 on the procedures with respect to rights in RFC documents can be 379 found in BCP 78 and BCP 79. 381 Copies of IPR disclosures made to the IETF Secretariat and any 382 assurances of licenses to be made available, or the result of an 383 attempt made to obtain a general license or permission for the use of 384 such proprietary rights by implementers or users of this 385 specification can be obtained from the IETF on-line IPR repository at 386 http://www.ietf.org/ipr. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights that may cover technology that may be required to implement 391 this standard. Please address the information to the IETF at 392 ietf-ipr@ietf.org. 394 Acknowledgment 396 Funding for the RFC Editor function is provided by the IETF 397 Administrative Support Activity (IASA).