idnits 2.17.1 draft-liu-isis-auto-conf-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 126: '... o IS-IS SHOULD be enabled as defau...' RFC 2119 keyword, line 128: '...tions, interface MAY be excluded if it...' RFC 2119 keyword, line 131: '...IS-IS interfaces MUST be auto-configur...' RFC 2119 keyword, line 137: '...ation interfaces MUST be configured wi...' RFC 2119 keyword, line 154: '...tion, this field MUST be 0 in 13 octet...' (25 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: - In order to make the routing system stable, the System ID SHOULD remain the same after it is firstly generated. It SHOULD not be changed due to device status change (such as interface enable/disable, interface plug in/off, device reboot, firmware update .etc) or configuration change (such as changing system configurations or IS-IS configurations .etc); but it MUST allow be changed by collision resolution and SHOULD allow be cleared by user enforced system reset. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Note that, the Router-Fingerprint SHOULD also remain the same after it is firstly generated. It SHOULD not be changed due to device status change (such as interface enable/disable, interface plug in/ off, device reboot, firmware update .etc) or configuration change (such as changing system configurations or IS-IS configurations .etc); but it MUST allow be changed by double-duplication resolution Section 3.3.4 and SHOULD allow be cleared by user enforced system reset. -- The document date (May 30, 2015) is 3253 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 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-04 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 isis B. Liu 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track B. Decraene 5 Expires: December 1, 2015 Orange 6 I. Farrer 7 Deutsche Telekom AG 8 M. Abrahamsson 9 T-Systems 10 May 30, 2015 12 ISIS Auto-Configuration 13 draft-liu-isis-auto-conf-04 15 Abstract 17 This document specifies an IS-IS auto-configuration technology. The 18 key mechanisms of this technology are IS-IS NET (Network Entity 19 Title) self-generation, duplication detection and duplication 20 resolution. This technology fits the environment where plug-and-play 21 is expected, e.g., home networks and small or medium size enterprise 22 networks. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 1, 2015. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 61 3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3 62 3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 3 63 3.3. IS-IS NET Duplication Detection and Resolution . . . . . 4 64 3.3.1. Router-Fingerprint TLV . . . . . . . . . . . . . . . 5 65 3.3.2. NET Duplication Detection and Resolution Procedures . 5 66 3.3.3. SysID and Router-Fingerprint Generation 67 Considerations . . . . . . . . . . . . . . . . . . . 6 68 3.3.4. Double-Duplication of both NET and Router-Fingerprint 7 69 3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 7 70 3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 7 71 3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 8 72 3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 8 73 3.4.4. Purge Originator Identification TLV . . . . . . . . . 8 74 3.5. Routing Behavior Considerations . . . . . . . . . . . . . 8 75 3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 8 76 3.5.2. Co-existing with Other IGP Auto-configuration . . . . 8 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 82 7.2. Informative References . . . . . . . . . . . . . . . . . 10 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 85 1. Introduction 87 This document describes mechanisms for IS-IS [RFC1195] [RFC5308] to 88 be auto-configuring. Such mechanisms could reduce the management 89 burden to configure a network. Home networks and small or medium 90 size enterprise networks where plug-n-play is expected can benefit 91 from these mechanisms. 93 In addition, this document defines how such un-configured routers 94 should behave, in order to limit the risk on existing network using 95 IS-IS (please refer to Section 3.4.1 andSection 3.5). 97 IS-IS auto-configuration contains the following aspects: 99 1. IS-IS default configurations 101 2. IS-IS NET (Network Entity Title) self-generation 103 3. NET duplication detection and resolution 105 4. ISIS TLVs utilization such as Authentication TLV, Wide Metric TLV 106 etc. 108 2. Scope 110 The auto-configuring mechanisms does not specifically distinguish 111 IPv4 or IPv6. 113 This auto-configuration mechanism aims at simple case. The following 114 advanced features are out of scope: 116 o Multiple IS-IS instances 118 o Multi-area and level-2 routers 120 o Interworking with other routing protocols 122 3. Protocol Specification 124 3.1. IS-IS Default Configuration 126 o IS-IS SHOULD be enabled as default on all interfaces in a router 127 that requires the IS-IS auto-configuration. For some specific 128 situations, interface MAY be excluded if it is a clear that 129 running IS-IS auto-configuration on the interface is not required. 131 o IS-IS interfaces MUST be auto-configured to an interface type 132 corresponding to their layer-2 capability. For example, Ethernet 133 interfaces will be auto-configured as broadcast networks and 134 Point- to-Point Protocol (PPP) interfaces will be auto-configured 135 as Point- to-Point interfaces. 137 o IS-IS auto-configuration interfaces MUST be configured with level- 138 1. 140 3.2. IS-IS NET Generation 142 In IS-IS, a router (known as an Intermediate System) is identified by 143 an NET which is the address of a Network Service Access Point (NSAP) 144 and represented with an IS-IS specific address format. The NSAP is a 145 logical entity which represents an instance of the IS- IS protocol 146 running on an IS. 148 The NET consists of three parts. The auto-generation mechanisms of 149 each part are described as the following: 151 o Area address 153 This field is 1 to 13 octets in length. In IS-IS auto- 154 configuration, this field MUST be 0 in 13 octets length. 156 o System ID 158 This field follows the area address field, and is 6 octets in 159 length. There are two basic requirements for the System ID 160 generation: 162 - As specified in IS-IS protocol, this field must be unique 163 among all routers in the same area. 165 - In order to make the routing system stable, the System ID 166 SHOULD remain the same after it is firstly generated. It 167 SHOULD not be changed due to device status change (such as 168 interface enable/disable, interface plug in/off, device 169 reboot, firmware update .etc) or configuration change (such 170 as changing system configurations or IS-IS configurations 171 .etc); but it MUST allow be changed by collision resolution 172 and SHOULD allow be cleared by user enforced system reset. 174 More specific considerations for SysID generation are described 175 in Section 3.3.3 . 177 o NSEL 179 This field is the N-selector, and is 1 octet in length. In IS- 180 IS auto-configuration, it SHOULD be set to "00". 182 3.3. IS-IS NET Duplication Detection and Resolution 184 NET addresses need to be distinct within one IS-IS area. As 185 described in Section 3.3.3, the NET address is generated based on 186 entropies such as MAC address which are supposed to be unique, but in 187 theory there is still possibility of duplication. This section 188 defines how IS-IS detects and corrects NET duplication. 190 3.3.1. Router-Fingerprint TLV 192 The Router-Fingerprint TLV re-uses the design of Router-Hardware- 193 Fingerprint TLV defined in [RFC7503]. 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Type | Length | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Router Fingerprint (Variable) | 201 . . 202 . . 203 . . 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 The length of the Router-Fingerprint is variable but must be 32 207 octets or greater; and the content is also supposed to be unique 208 among all the routers. 210 More specific considerations for Router-Fingerprint is described in 211 Section 3.3.3 . 213 3.3.2. NET Duplication Detection and Resolution Procedures 215 1) Flood the Router-Distinguisher TLVs 217 When an IS-IS auto-configuration router gets online, it MUST 218 include the Router-Fingerprint TLV in the first originated level-1 219 LSP. Then all the routers in the area could receive the 220 information in the TLV. 222 2) Compare the received Router-Fingerprint TLVs 224 When receiving a LSP having its own NET address, an IS-IS router 225 MUST check the Router-Fingerprint TLV. If the Router-Fingerprint 226 TLV is different from its own, there is a NET duplication and the 227 following procedure SHOULD be performed. 229 3) Duplication resolution 231 When NET duplication occurs, the router with the numerically 232 smaller Router-Fingerprint MUST generate a new NET. Note that, 233 the router MUST compare the two Router-Fingerprint in terms of two 234 numeric numbers (e.g. Unsigned integer). 236 4) Re-join the network with the new NET 237 The router with the smaller Router-Fingerprint advertise new LSPs 238 based on the newly generated NET to re-join the IS-IS auto- 239 configuration network. 241 Note that, since the other router still uses the old NET, the 242 smaller Router-Distinguisher router MUST NOT purge it's LSPs; the 243 router with the highest Router-Distinguisher MUST re-advertise its 244 own LSP (after increasing the sequence number). 246 The newly generated NET SHOULD take a NET duplication detection as 247 well. 249 3.3.3. SysID and Router-Fingerprint Generation Considerations 251 As specified in this document, there are two distinguisher need to be 252 self-generated, which is SysID and Router-Fingerprint. In a network 253 device, normally there are resources which provide an extremely high 254 probability of uniqueness thus could be used as seeds to derive 255 distinguisher (e.g. hashing or generating pseudo-random numbers), 256 such as: 258 o MAC address(es) 260 o Configured IP address(es) 262 o Hardware IDs (e.g. CPU ID) 264 o Device serial number(s) 266 o System clock at a certain specific time 268 o Arbitrary received packet 270 This document does not specify a certain method to generate the SysID 271 and Router-Fingerprint. However, the generation of SysID and Router- 272 Fingerprint MUST be based on different seeds so that the two 273 distinguisher would not collide. 275 There is an important concern that the seeds listed above (except MAC 276 address) might not be available in some small devices such as home 277 routers. This is because of the hardware/software limitation and the 278 lack of sufficient communication packets at the initial stage in the 279 home routers when doing ISIS-autoconfiguration. In this case, this 280 document suggests to use MAC address as SysID and generate a pseudo- 281 random number based on another seed (such as the memory address of a 282 certain variable in the program) as Router-Fingerprint. The pseudo- 283 random number might not have a very high quality in this solution, 284 but should be sufficient in home networks scenarios. 286 Note that, the Router-Fingerprint SHOULD also remain the same after 287 it is firstly generated. It SHOULD not be changed due to device 288 status change (such as interface enable/disable, interface plug in/ 289 off, device reboot, firmware update .etc) or configuration change 290 (such as changing system configurations or IS-IS configurations 291 .etc); but it MUST allow be changed by double-duplication resolution 292 Section 3.3.4 and SHOULD allow be cleared by user enforced system 293 reset. 295 3.3.4. Double-Duplication of both NET and Router-Fingerprint 297 As described above, the resources for generating the distinguisher 298 might be very constrained at the initial stage. Hence, the double- 299 duplication of both NET and Router-Fingerprint needs to be 300 considered. 302 ISIS-autoconfiguring routers SHOULD support detecting NET duplication 303 by LSP war. LSP war is a phenomenon that if a router receives a LSP 304 originated with it's NET, but it doesn't find it in the database, or 305 it does not match the one the router has (e.g. It advertises IP 306 prefixes that the router doesn't own, or IS neighbors that the router 307 doesn't see), then Per ISIS specification, the router must re- 308 originate its LSP with an increased sequence number. If double- 309 duplication happens, the duplicated two routers will both 310 continuously have the above behavior. After multiples iterations, 311 the program should be able to deduce that double-duplication happens. 313 At the point when double-duplication happens, routers should have 314 much more entropies available. Thus, the router is to extend or re- 315 generate its Router-Fingerprint (one simple way is just adding the 316 LSP sequence number of the next LSP it will send to the Router- 317 Fingerprint). 319 3.4. IS-IS TLVs Usage 321 3.4.1. Authentication TLV 323 Every IS-IS auto-configuration message MUST include an authentication 324 TLV (TLV 10, [RFC5304]) with the Type 1 authentication mode 325 ("Cleartext Password") in order to avoid the auto-conf router to 326 accidentally join an existing IS-IS network which is not intended to 327 be auto-configured. 329 This feature is necessary since it might seriously break an existing 330 IS-IS network or cause unnecessary management confusion if a low end 331 CPE (which might be the normal form of ISIS-autoconf routers) 332 occasionally joins the network. 334 The cleartext password is specified as "isis-autoconf". Routers that 335 implement IS-IS auto-configuration MUST use this password as default, 336 so that different routers could authenticate each other with no human 337 intervene as default. And routers MUST be able to set manual 338 password by the users. 340 3.4.2. Wide Metric TLV 342 IS-IS auto-configuration routers SHOULD support wide metric (TLV 22, 343 [RFC5305]). It is recommended that IS-IS auto-configuration routers 344 use a high metric value (e.g. 1000000) as default in order to 345 typically prefer the manually configured adjacencies rather than the 346 auto-conf ones. 348 3.4.3. Dynamic Host Name TLV 350 IS-IS auto-configuration routers SHOULD advertise their Dynamic Host 351 Names TVL (TLV 137, [RFC5301]). The host names could be provisioned 352 by an IT system, or just use the name of vendor, device type or 353 serial number etc. 355 3.4.4. Purge Originator Identification TLV 357 For troubleshooting purpose, the Purge Originator Identification TLV 358 (TLV 13, [RFC6232]) MAY be used to determine the origin of the purge. 359 Please refer to [RFC6232] for details. 361 3.5. Routing Behavior Considerations 363 3.5.1. Adjacency Formation 365 Since ISIS does not require strict hold timers matching to form 366 adjacency, this document does not specify specific hold timers. 367 However, the timers should be within a reasonable range based on 368 current practise in the industry. (For example, 30 seconds for 369 holdtime and 20 minutes for LSP lifetime.) 371 3.5.2. Co-existing with Other IGP Auto-configuration 373 If a router supports multiple IGP auto-configuration mechanisms (e.g. 374 Both IS-IS auto-configuration and OSPF auto-configuration), then in 375 practice it is a problem that there should be a mechanism to decide 376 which IGP to be used, or even both. 378 However, the behavior of multiple IGP protocols interaction should be 379 done in the router level rather than in any IGP protocols. For 380 example, with the Home Network Control Protocol 381 ([I-D.ietf-homenet-hncp]), the routers could achieve a consensus on 382 what IGP to use. 384 4. Security Considerations 386 In general, auto-configuration is mutually incompatible with 387 authentication. So we can't have both. This is not really specific 388 to IS-IS. 390 Unwanted routers could easily join in an existing IS-IS auto- 391 configuration network by setting the authentication password as 392 "isis-autoconf" default value or sniff the cleartext password online. 393 However, this is a common security risk shared by other IS-IS 394 networks that don't set proper authentication mechanisms. For wired 395 deployment, the wired line itself could be considered as an implicit 396 authentication that normally unwanted routers are not able to connect 397 to the wire line; for wireless deployment, the authentication could 398 be achieve at the lower wireless link layer. 400 Malicious router could modify the SysID field to cause NET 401 duplication detection and resolution vibrate thus cause the routing 402 system vibrate. 404 5. IANA Considerations 406 The Router Hardware Fingerprint TLV type code needs an assignment by 407 IANA. 409 6. Acknowledgements 411 This document was heavily inspired by [RFC7503]. 413 Martin Winter, Christian Franke and David Lamparter gave essential 414 feedback to improve the technical design based on their 415 implementation experience. Many useful comments and contributions 416 were made by Sheng Jiang, Qin Wu, Hannes Gredler, Peter Lothberg, Uma 417 Chundury, Nan Wu, Acee Lindem, Les Ginsberg and some other people in 418 ISIS working group. 420 This document was produced using the xml2rfc tool [RFC2629]. 421 (initially prepared using 2-Word-v2.0.template.dot. ) 423 7. References 424 7.1. Normative References 426 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 427 dual environments", RFC 1195, December 1990. 429 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 430 June 1999. 432 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 433 Mechanism for IS-IS", RFC 5301, October 2008. 435 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 436 Authentication", RFC 5304, October 2008. 438 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 439 Engineering", RFC 5305, October 2008. 441 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 442 2008. 444 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 445 Originator Identification TLV for IS-IS", RFC 6232, May 446 2011. 448 7.2. Informative References 450 [I-D.ietf-homenet-hncp] 451 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 452 Control Protocol", draft-ietf-homenet-hncp-04 (work in 453 progress), March 2015. 455 [RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration", RFC 456 7503, April 2015. 458 Authors' Addresses 460 Bing Liu 461 Huawei Technologies 462 Q14, Huawei Campus, No.156 Beiqing Road 463 Hai-Dian District, Beijing, 100095 464 P.R. China 466 Email: leo.liubing@huawei.com 467 Bruno Decraene 468 Orange 469 Issy-les-Moulineaux FR 470 FR 472 Email: bruno.decraene@orange.com 474 Ian Farrer 475 Deutsche Telekom AG 476 Bonn 477 Germany 479 Email: ian.farrer@telekom.de 481 Mikael Abrahamsson 482 T-Systems 483 Stockholm 484 Sweden 486 Email: mikael.abrahamsson@t-systems.se