idnits 2.17.1 draft-liu-isis-auto-conf-03.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 154: '...ring, this field MUST be 0 in 13 octet...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3469 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) == Missing Reference: 'OSPFv3AC' is mentioned on line 335, but not defined ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-10) exists of draft-ietf-homenet-hncp-01 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-ospfv3-autoconfig-09 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: April 30, 2015 Orange 6 I. Farrer 7 Deutsche Telekom AG 8 M. Abrahamsson 9 T-Systems 10 October 27, 2014 12 ISIS Auto-Configuration 13 draft-liu-isis-auto-conf-03 15 Abstract 17 This document describes 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 April 30, 2015. 41 Copyright Notice 43 Copyright (c) 2014 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-Hardware-Fingerprint TLV . . . . . . . . . . . 4 65 3.3.2. NET Duplication Detection and Resolution Procedures . 5 66 3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 6 67 3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 6 68 3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 6 69 3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 6 70 3.4.4. Purge Originator Identification TLV . . . . . . . . . 6 71 3.5. Routing Behavior Considerations . . . . . . . . . . . . . 6 72 3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 7 73 3.5.2. Co-existing with Other IGP Auto-configuration . . . . 7 74 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 79 7.2. Informative References . . . . . . . . . . . . . . . . . 8 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 82 1. Introduction 84 This memo describes mechanisms for IS-IS [RFC1195] [RFC5308] to be 85 auto-configuring. Such mechanisms could reduce the management burden 86 to configure a network. Home networks and small or medium size 87 enterprise networks where plug-n-play is expected can benefit from 88 these mechanisms. 90 In addition, this memo defines how such un-configured routers should 91 behave, in order to limit the risk on existing network using IS-IS 92 (Section 3.4.1 & 3.5). 94 IS-IS auto-configuration mainly contains the following aspects: 96 1. IS-IS Default Configurations 97 2. IS-IS NET Self-Generation 99 3. NET Duplication Detection and Resolution 101 4. ISIS TLVs utilization such as Authentication TLV, Wide Metric TLV 102 etc. 104 2. Scope 106 The auto-configuring mechanisms does not specifically destinguish 107 IPv4 or IPv6. 109 The auto-configuring mechanisms enabled interfaces are assumed to 110 have a 48-bit MAC address. 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 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 IS) is identified by an Network 142 Entity Title (NET) which is the address of a Network Service Access 143 Point (NSAP) and represented with an IS-IS specific address format. 145 The NSAP is a logical entity which represents an instance of the IS- 146 IS protocol 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 configuring, 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. As specified in IS-IS protocol, this field must be 160 unique among all level-1 routers in the same area when the IS 161 operates at Level 1. In IS-IS auto-configuring, this field 162 SHOULD be the MAC address of one IS-IS enabled interface. 164 o NSEL 166 This field is the N-selector, and is 1 octet in length. In IS- 167 IS auto-configuring, it SHOULD be set to "00". 169 3.3. IS-IS NET Duplication Detection and Resolution 171 NET addresses need to be distinct within one IS-IS area. This 172 document auto-configure the NET address based on the MAC address 173 which are supposed to be globally unique, but in order to detect and 174 correct the possible MAC duplication, this section defines how IS-IS 175 may detect and correct NET duplication. 177 3.3.1. Router-Hardware-Fingerprint TLV 179 The Router-Hardware-Fingerprint TLV is defined in 180 [I-D.ietf-ospf-ospfv3-autoconfig]. This document re-uses it to 181 achieve NET duplication detection. 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Router Hardware Fingerprint (Variable) | 189 . . 190 . . 191 . . 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 Figure 1 Router-Hardware-Fingerprint TLV Format 196 As defined in [I-D.ietf-ospf-ospfv3-autoconfig], the contents of the 197 hardware fingerprint should be some combination of CPU ID, or serial 198 number(s) that provides an extremely high probability of uniqueness. 199 It MUST be based on hardware attributes that will not change across 200 hard and soft restarts. The length of the Router-Hardware- 201 Fingerprint is variable but must be 32 octets or greater. 203 Note that, since the TLV is to detect MAC address based NET 204 duplication, the TLV content SHOULD NOT use MAC address. 206 3.3.2. NET Duplication Detection and Resolution Procedures 208 1) Flood the Router-Hardware-Fingerprint TLVs 210 When an IS-IS auto-configuration router gets online, it MUST 211 include the Router-Hardware-Fingerprint TLV in the first 212 originated level-1 LSP. Then all the routers in the area could 213 receive the information in the TLV. 215 2) Compare the received Router-Hardware-Fingerprint TLVs 217 An IS-IS auto-configuring router MUST compare a received self- 218 originated LSP's Router-Hardware-Fingerprint TLV against its own 219 one. If they are equal, it means the LSP was indeed originated by 220 the router itself; if they are not equal, it means some other 221 router has the same NET originated the LSP, thus there is a NET 222 duplication. 224 3) Duplication resolution 226 When NET duplication occurs, the router with the numerically 227 smaller router hardware fingerprint MUST generate a new NET. The 228 newly generated NET SHOULD take a NET duplication detection as 229 well. 231 4) Purge the LSPs containing duplicated NET 233 Before flooding the new NET, the LSP with the prior duplicate NET 234 MUST be purged. And any IS-IS neighbor adjacencies MUST be 235 reestablished. 237 5) Re-join the network with the new NET 239 After purging the LSPs with the duplicated NET, the router re-join 240 the IS-IS auto-configuration network with the newly generated NET. 242 3.4. IS-IS TLVs Usage 244 3.4.1. Authentication TLV 246 Every IS-IS auto-configuration message MUST include an authentication 247 TLV (TLV 10, [RFC5304]) with the Type 1 authentication mode 248 ("Cleartext Password") in order to avoid the auto-conf router to 249 accidentally join an existing IS-IS network which is not intended to 250 be auto-configured. 252 This feature is necessary since it might seriously break an existing 253 IS-IS network or cause unnecessary management confusion if a low end 254 CPE (which might be the normal form of ISIS-autoconf routers) 255 occasionally joins the network. 257 The cleartext password is specified as "isis-autoconf". Routers that 258 implement IS-IS auto-configuration MUST use this password as default, 259 so that different routers could authenticate each other with no human 260 intervene as default. And routers MUST be able to set manual 261 password by the users. 263 3.4.2. Wide Metric TLV 265 IS-IS auto-configuration routers SHOULD support wide metric (TLV 22, 266 [RFC5305]). It is recommended that IS-IS auto-configuration routers 267 use a high metric value (e.g. 1000000) as default in order to 268 typically prefer the manually configured adjacencies rather than the 269 auto-conf ones. 271 3.4.3. Dynamic Host Name TLV 273 IS-IS auto-configuration routers SHOULD advertise their Dynamic Host 274 Names TVL (TLV 137, [RFC5301]). The host names could be provisioned 275 by an IT system, or just use the name of vendor, device type or 276 serial number etc. 278 3.4.4. Purge Originator Identification TLV 280 For troubleshooting purpose, the Purge Originator Identification TLV 281 (TLV 13, [RFC6232]) MAY be used to determin the origin of the purge. 282 Please refer to [RFC6232] for details. 284 3.5. Routing Behavior Considerations 285 3.5.1. Adjacency Formation 287 Since ISIS does not require strict hold timers matching to form 288 adjacency, this document does not specify specific hold timers. 289 However, the timers should be within a reasonable range based on 290 current practisce in the industry. (For example, 30 seconds for 291 holdtime and 20 minutes for LSP lifetime.) 293 3.5.2. Co-existing with Other IGP Auto-configuration 295 If a router supports multiple IGP auto-configuration mechanisms (e.g. 296 both IS-IS auto-configuration and OSPF auto-configuration), then in 297 practice it is a problem that there should be a mechanism to decide 298 which IGP to be used, or even both. 300 However, the behavior of multiple IGP protocols interaction should be 301 done in the router level rather than in any IGP protocols. 302 Currently, there is some relevant work going on, for example, the 303 [I-D.ietf-homenet-hncp] is to have the proposed HNCP (Home Network 304 Control Protocol) choose what IGP should be used. 306 4. Security Considerations 308 In general, auto-configuration is mutually incompatible with 309 authentication. So we can't have both. This is not really specific 310 to IS-IS. 312 Unwanted routers could easily join in an existing IS-IS auto- 313 configuration network by setting the authentication password as 314 "isis-autoconf" default value or sniff the cleartext password online. 315 However, this is a common security risk shared by other IS-IS 316 networks that don't set proper authentication mechanisms. For wired 317 deployment, the wired line itself could be considered as an implicit 318 authentication that normally unwanted routers are not able to connect 319 to the wire line; for wireless deployment, the authentication could 320 be achieve at the lower wireless link layer. 322 Malicious router could modify the SystemID field to cause NET 323 duplication detection and resolution vibrate thus cause the routing 324 system vibrate. 326 5. IANA Considerations 328 The Router Hardware Fingerprint TLV type code needs an assignment by 329 IANA. 331 6. Acknowledgements 333 Many useful comments and contributions were made by Sheng Jiang. 335 This document was inspired by [OSPFv3AC]. 337 This document was produced using the xml2rfc tool [RFC2629]. 338 (initiallly prepared using 2-Word-v2.0.template.dot. ) 340 7. References 342 7.1. Normative References 344 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 345 dual environments", RFC 1195, December 1990. 347 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 348 June 1999. 350 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 351 Mechanism for IS-IS", RFC 5301, October 2008. 353 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 354 Authentication", RFC 5304, October 2008. 356 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 357 Engineering", RFC 5305, October 2008. 359 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 360 2008. 362 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 363 Originator Identification TLV for IS-IS", RFC 6232, May 364 2011. 366 7.2. Informative References 368 [I-D.ietf-homenet-hncp] 369 Stenberg, M. and S. Barth, "Home Networking Control 370 Protocol", draft-ietf-homenet-hncp-01 (work in progress), 371 June 2014. 373 [I-D.ietf-ospf-ospfv3-autoconfig] 374 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 375 draft-ietf-ospf-ospfv3-autoconfig-09 (work in progress), 376 September 2014. 378 Authors' Addresses 380 Bing Liu 381 Huawei Technologies 382 Q14, Huawei Campus, No.156 Beiqing Road 383 Hai-Dian District, Beijing, 100095 384 P.R. China 386 Email: leo.liubing@huawei.com 388 Bruno Decraene 389 Orange 390 Issy-les-Moulineaux FR 391 FR 393 Email: bruno.decraene@orange.com 395 Ian Farrer 396 Deutsche Telekom AG 397 Bonn 398 Germany 400 Email: ian.farrer@telekom.de 402 Mikael Abrahamsson 403 T-Systems 404 Stockholm 405 Sweden 407 Email: mikael.abrahamsson@t-systems.se