idnits 2.17.1 draft-liu-isis-auto-conf-05.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 125: '... o IS-IS SHOULD be enabled as defau...' RFC 2119 keyword, line 127: '...tions, interface MAY be excluded if it...' RFC 2119 keyword, line 130: '...IS-IS interfaces MUST be auto-configur...' RFC 2119 keyword, line 136: '...ation interfaces MUST be configured wi...' RFC 2119 keyword, line 153: '...tion, this field MUST be 0 in 13 octet...' (26 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 (June 19, 2015) is 3231 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-06 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 21, 2015 Orange 6 I. Farrer 7 Deutsche Telekom AG 8 M. Abrahamsson 9 T-Systems 10 June 19, 2015 12 ISIS Auto-Configuration 13 draft-liu-isis-auto-conf-05 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. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 21, 2015. 40 Copyright Notice 42 Copyright (c) 2015 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 60 3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3 61 3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 3 62 3.3. IS-IS NET Duplication Detection and Resolution . . . . . 4 63 3.3.1. Router-Fingerprint TLV . . . . . . . . . . . . . . . 4 64 3.3.2. NET Duplication Detection and Resolution Procedures . 5 65 3.3.3. SysID and Router-Fingerprint Generation 66 Considerations . . . . . . . . . . . . . . . . . . . 6 67 3.3.4. Double-Duplication of both NET and Router-Fingerprint 7 68 3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 7 69 3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 7 70 3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 8 71 3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 8 72 3.4.4. Purge Originator Identification TLV . . . . . . . . . 8 73 3.5. Routing Behavior Considerations . . . . . . . . . . . . . 8 74 3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 8 75 3.5.2. Co-existing with Other IGP Auto-configuration . . . . 9 76 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 81 7.2. Informative References . . . . . . . . . . . . . . . . . 10 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction 86 This document describes mechanisms for IS-IS [RFC1195] [RFC5308] to 87 be auto-configuring. Such mechanisms could reduce the management 88 burden to configure a network. Home networks and small or medium 89 size enterprise networks where plug-and-play is expected can benefit 90 from these mechanisms. 92 In addition, this document defines how such un-configured routers 93 should behave, in order to limit the risk on existing network using 94 IS-IS (please refer to Section 3.4.1 andSection 3.5). 96 IS-IS auto-configuration contains the following aspects: 98 1. IS-IS default configurations 100 2. IS-IS NET (Network Entity Title) self-generation 102 3. NET duplication detection and resolution 104 4. ISIS TLVs utilization such as Authentication TLV, Wide Metric TLV 105 etc. 107 2. Scope 109 The auto-configuring mechanisms does not specifically distinguish 110 IPv4 or IPv6. 112 This auto-configuration mechanism aims at simple case. The following 113 advanced features are out of scope: 115 o Multiple IS-IS instances 117 o Multi-area and level-2 routers 119 o Interworking with other routing protocols 121 3. Protocol Specification 123 3.1. IS-IS Default Configuration 125 o IS-IS SHOULD be enabled as default on all interfaces in a router 126 that requires the IS-IS auto-configuration. For some specific 127 situations, interface MAY be excluded if it is a clear that 128 running IS-IS auto-configuration on the interface is not required. 130 o IS-IS interfaces MUST be auto-configured to an interface type 131 corresponding to their layer-2 capability. For example, Ethernet 132 interfaces will be auto-configured as broadcast networks and 133 Point-to-Point Protocol (PPP) interfaces will be auto-configured 134 as Point-to-Point interfaces. 136 o IS-IS auto-configuration interfaces MUST be configured with level- 137 1. 139 3.2. IS-IS NET Generation 141 In IS-IS, a router (known as an Intermediate System) is identified by 142 an NET which is the address of a Network Service Access Point (NSAP) 143 and represented with an IS-IS specific address format. The NSAP is a 144 logical entity which represents an instance of the IS- IS protocol 145 running on an IS. 147 The NET consists of three parts. The auto-generation mechanisms of 148 each part are described as the following: 150 o Area address 152 This field is 1 to 13 octets in length. In IS-IS auto- 153 configuration, this field MUST be 0 in 13 octets length. 155 o System ID 157 This field follows the area address field, and is 6 octets in 158 length. There are two basic requirements for the System ID 159 generation: 161 - As specified in IS-IS protocol, this field must be unique 162 among all routers in the same area. 164 - In order to make the routing system stable, the System ID 165 SHOULD remain the same after it is firstly generated. It 166 SHOULD not be changed due to device status change (such as 167 interface enable/disable, interface plug in/off, device 168 reboot, firmware update etc.) or configuration change (such 169 as changing system configurations or IS-IS configurations 170 etc.); but it MUST allow be changed by collision resolution 171 and SHOULD allow be cleared by user enforced system reset. 173 More specific considerations for SysID generation are described 174 in Section 3.3.3 . 176 o NSEL 178 This field is the N-selector, and is 1 octet in length. In IS- 179 IS auto-configuration, it SHOULD be set to "00". 181 3.3. IS-IS NET Duplication Detection and Resolution 183 NET addresses need to be distinct within one IS-IS area. As 184 described in Section 3.3.3, the NET address is generated based on 185 entropies such as MAC address which are supposed to be unique, but in 186 theory there is still possibility of duplication. This section 187 defines how IS-IS detects and corrects NET duplication. 189 3.3.1. Router-Fingerprint TLV 191 The Router-Fingerprint TLV re-uses the design of Router-Hardware- 192 Fingerprint TLV defined in [RFC7503]. 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type | Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Router Fingerprint (Variable) | 200 . . 201 . . 202 . . 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 The length of the Router-Fingerprint is variable but must be 32 206 octets or greater; and the content is also supposed to be unique 207 among all the routers. 209 More specific considerations for Router-Fingerprint is described in 210 Section 3.3.3 . 212 3.3.2. NET Duplication Detection and Resolution Procedures 214 1) Flood the Router-Fingerprint TLVs 216 When an IS-IS auto-configuration router gets online, it MUST 217 include the Router-Fingerprint TLV in the first originated level-1 218 LSP. Then all the routers in the area could receive the 219 information in the TLV. 221 2) Compare the received Router-Fingerprint TLVs 223 When receiving a LSP having its own NET address, an IS-IS router 224 MUST check the Router-Fingerprint TLV. If the Router-Fingerprint 225 TLV is different from its own, there is a NET duplication and the 226 following procedure SHOULD be performed. 228 3) Duplication resolution 230 When NET duplication occurs, the router with the numerically 231 smaller Router-Fingerprint MUST generate a new NET. Note that, 232 the router MUST compare the two Router-Fingerprint in terms of two 233 numeric numbers (e.g. unsigned integer). 235 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 Note that, there might be an exceptional case that one auto- 250 configuring router detects the NET duplication by LSP war (as 251 described in Section 3.3.4 ), but there is no Router-Fingerprint TLV 252 from the duplicated router for comparing. This might be caused by a 253 non-autoconfiguration router by accident connected to the auto- 254 configuration domain (with the Authentication TLV correctly set by 255 accident) or other unexpected bad behaviors. In this case, the auto- 256 configuration router MUST generate a new NET and re-joint the 257 network. 259 3.3.3. SysID and Router-Fingerprint Generation Considerations 261 As specified in this document, there are two distinguisher need to be 262 self-generated, which is SysID and Router-Fingerprint. In a network 263 device, normally there are resources which provide an extremely high 264 probability of uniqueness thus could be used as seeds to derive 265 distinguisher (e.g. hashing or generating pseudo-random numbers), 266 such as: 268 o MAC address(es) 270 o Configured IP address(es) 272 o Hardware IDs (e.g. CPU ID) 274 o Device serial number(s) 276 o System clock at a certain specific time 278 o Arbitrary received packet 280 This document does not specify a certain method to generate the SysID 281 and Router-Fingerprint. However, the generation of SysID and Router- 282 Fingerprint MUST be based on different seeds so that the two 283 distinguisher would not collide. 285 There is an important concern that the seeds listed above (except MAC 286 address) might not be available in some small devices such as home 287 routers. This is because of the hardware/software limitation and the 288 lack of sufficient communication packets at the initial stage in the 289 home routers when doing ISIS-autoconfiguration. In this case, this 290 document suggests to use MAC address as SysID and generate a pseudo- 291 random number based on another seed (such as the memory address of a 292 certain variable in the program) as Router-Fingerprint. The pseudo- 293 random number might not have a very high quality in this solution, 294 but should be sufficient in home networks scenarios. 296 Note that, the Router-Fingerprint SHOULD also remain the same after 297 it is firstly generated. It SHOULD not be changed due to device 298 status change (such as interface enable/disable, interface plug in/ 299 off, device reboot, firmware update etc.) or configuration change 300 (such as changing system configurations or IS-IS configurations 301 etc.); but it MUST allow be changed by double-duplication resolution 302 Section 3.3.4 and SHOULD allow be cleared by user enforced system 303 reset. 305 3.3.4. Double-Duplication of both NET and Router-Fingerprint 307 As described above, the resources for generating the distinguisher 308 might be very constrained at the initial stage. Hence, the double- 309 duplication of both NET and Router-Fingerprint needs to be 310 considered. 312 ISIS-autoconfiguring routers SHOULD support detecting NET duplication 313 by LSP war. LSP war is a phenomenon that if a router receives a LSP 314 originated with it's NET, but it doesn't find it in the database, or 315 it does not match the one the router has (e.g. It advertises IP 316 prefixes that the router doesn't own, or IS neighbors that the router 317 doesn't see), then per ISIS specification, the router must re- 318 originate its LSP with an increased sequence number. If double- 319 duplication happens, the duplicated two routers will both 320 continuously have the above behavior. After multiples iterations, 321 the program should be able to deduce that double-duplication happens. 323 At the point when double-duplication happens, routers should have 324 much more entropies available. Thus, the router is to extend or re- 325 generate its Router-Fingerprint (one simple way is just adding the 326 LSP sequence number of the next LSP it will send to the Router- 327 Fingerprint). 329 3.4. IS-IS TLVs Usage 331 3.4.1. Authentication TLV 333 Every IS-IS auto-configuration message MUST include an authentication 334 TLV (TLV 10, [RFC5304]) with the Type 1 authentication mode 335 ("Cleartext Password") in order to avoid the auto-conf router to 336 accidentally join an existing IS-IS network which is not intended to 337 be auto-configured. 339 This feature is necessary since it might seriously break an existing 340 IS-IS network or cause unnecessary management confusion if a low end 341 CPE (which might be the normal form of ISIS-autoconfiguration 342 routers) occasionally joins the network. 344 The cleartext password is specified as "isis-autoconf". Routers that 345 implement IS-IS auto-configuration MUST use this password as default, 346 so that different routers could authenticate each other with no human 347 intervene as default. And routers MUST be able to set manual 348 password by the users. 350 3.4.2. Wide Metric TLV 352 IS-IS auto-configuration routers SHOULD support wide metric (TLV 22, 353 [RFC5305]). It is recommended that IS-IS auto-configuration routers 354 use a high metric value (e.g. 1000000) as default in order to 355 typically prefer the manually configured adjacencies rather than the 356 auto-conf ones. 358 3.4.3. Dynamic Host Name TLV 360 IS-IS auto-configuration routers SHOULD advertise their Dynamic Host 361 Names TLV (TLV 137, [RFC5301]). The host names could be provisioned 362 by an IT system, or just use the name of vendor, device type or 363 serial number etc. 365 3.4.4. Purge Originator Identification TLV 367 For troubleshooting purpose, the Purge Originator Identification TLV 368 (TLV 13, [RFC6232]) MAY be used to determine the origin of the purge. 369 Please refer to [RFC6232] for details. 371 3.5. Routing Behavior Considerations 373 3.5.1. Adjacency Formation 375 Since ISIS does not require strict hold timers matching to form 376 adjacency, this document does not specify specific hold timers. 377 However, the timers should be within a reasonable range based on 378 current practise in the industry. (For example, 30 seconds for 379 holdtime and 20 minutes for LSP lifetime.) 381 3.5.2. Co-existing with Other IGP Auto-configuration 383 If a router supports multiple IGP auto-configuration mechanisms (e.g. 384 Both IS-IS auto-configuration and OSPF auto-configuration), then in 385 practice it is a problem that there should be a mechanism to decide 386 which IGP to be used, or even both. 388 However, the behavior of multiple IGP protocols interaction should be 389 done in the router level rather than in any IGP protocols. For 390 example, with the Home Network Control Protocol 391 ([I-D.ietf-homenet-hncp]), the routers could achieve a consensus on 392 what IGP to use. 394 4. Security Considerations 396 In general, auto-configuration is mutually incompatible with 397 authentication. This is a common problem that IS-IS auto- 398 configuration can not avoid. 400 Unwanted routers could easily join in an existing IS-IS auto- 401 configuration network by setting the authentication password as 402 "isis-autoconf" default value or sniff the cleartext password online. 403 However, this is a common security risk shared by other IS-IS 404 networks that don't set proper authentication mechanisms. For wired 405 deployment, the wired line itself could be considered as an implicit 406 authentication that normally unwanted routers are not able to connect 407 to the wire line; for wireless deployment, the authentication could 408 be achieve at the lower wireless link layer. 410 Malicious router could modify the SysID field to keep causing NET 411 duplication detection and resolution thus cause the routing system 412 vibrate. 414 5. IANA Considerations 416 The Router-Fingerprint TLV type code needs an assignment by IANA. 418 6. Acknowledgements 420 This document was heavily inspired by [RFC7503]. 422 Martin Winter, Christian Franke and David Lamparter gave essential 423 feedback to improve the technical design based on their 424 implementation experience. Many useful comments and contributions 425 were made by Sheng Jiang, Qin Wu, Hannes Gredler, Peter Lothberg, Uma 426 Chundury, Nan Wu, Acee Lindem, Karsten Thomann, Les Ginsberg and some 427 other people in ISIS working group. 429 This document was produced using the xml2rfc tool [RFC2629]. 430 (initially prepared using 2-Word-v2.0.template.dot. ) 432 7. References 434 7.1. Normative References 436 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 437 dual environments", RFC 1195, December 1990. 439 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 440 June 1999. 442 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 443 Mechanism for IS-IS", RFC 5301, October 2008. 445 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 446 Authentication", RFC 5304, October 2008. 448 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 449 Engineering", RFC 5305, October 2008. 451 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 452 2008. 454 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 455 Originator Identification TLV for IS-IS", RFC 6232, May 456 2011. 458 7.2. Informative References 460 [I-D.ietf-homenet-hncp] 461 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 462 Control Protocol", draft-ietf-homenet-hncp-06 (work in 463 progress), June 2015. 465 [RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration", RFC 466 7503, April 2015. 468 Authors' Addresses 470 Bing Liu 471 Huawei Technologies 472 Q14, Huawei Campus, No.156 Beiqing Road 473 Hai-Dian District, Beijing, 100095 474 P.R. China 476 Email: leo.liubing@huawei.com 477 Bruno Decraene 478 Orange 479 Issy-les-Moulineaux FR 480 FR 482 Email: bruno.decraene@orange.com 484 Ian Farrer 485 Deutsche Telekom AG 486 Bonn 487 Germany 489 Email: ian.farrer@telekom.de 491 Mikael Abrahamsson 492 T-Systems 493 Stockholm 494 Sweden 496 Email: mikael.abrahamsson@t-systems.se