idnits 2.17.1 draft-liu-isis-auto-conf-02.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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 132: '... o IS-IS SHOULD be enabled on all in...' RFC 2119 keyword, line 134: '... interface MAY be excluded if it is ...' RFC 2119 keyword, line 137: '...IS-IS interfaces MUST be auto-configur...' RFC 2119 keyword, line 143: '...ation interfaces MUST be configured wi...' RFC 2119 keyword, line 157: '...ring, this field MUST be 0 in 13 octet...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 3, 2014) is 3516 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 313, but not defined == Missing Reference: 'TBD' is mentioned on line 272, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group B. Liu 2 Internet Draft Huawei Technologies 3 Intended status: Standards Track Bruno Decraene 4 Expires: March 6, 2015 Orange 5 I. Farrer 6 Deutsche Telekom AG 7 M. Abrahamsson 8 T-System 9 September 3, 2014 11 ISIS Auto-Configuration 12 draft-liu-isis-auto-conf-02.txt 14 Status of this Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute working 21 documents as Internet-Drafts. The list of current Internet-Drafts is 22 at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 This Internet-Draft will expire on March 6, 2015. 31 Copyright Notice0 33 Copyright (c) 2014 IETF Trust and the persons identified as the 34 document authors. All rights reserved. 36 This document is subject to BCP 78 and the IETF Trust's Legal 37 Provisions Relating to IETF Documents 38 (http://trustee.ietf.org/license-info) in effect on the date of 39 publication of this document. Please review these documents 40 carefully, as they describe your rights and restrictions with respect 41 to this document. Code Components extracted from this document must 42 include Simplified BSD License text as described in Section 4.e of 43 the Trust Legal Provisions and are provided without warranty as 44 described in the Simplified BSD License. 46 Abstract 48 This document describes mechanisms for IS-IS to be self-configuring. 49 Such mechanisms could reduce the management burden to configure a 50 network. One obvious environment that could benefit from these 51 mechanisms is IPv6 home network where plug-and-play would be expected. 52 Besides home network, some simple enterprise/ISP networks might also 53 benefit from the self-configuring mechanisms. 55 Table of Contents 57 1. Introduction ................................................. 3 58 2. Design Scope ................................................. 3 59 3. Protocol Specification ....................................... 4 60 3.1. IS-IS Default Configuration ............................. 4 61 3.2. IS-IS NET Generation .................................... 4 62 3.3. IS-IS NET Duplication Detection and Resolution........... 5 63 3.3.1. Router-Hardware-Fingerprint TLV .................... 5 64 3.3.2. NET Duplication Detection and Resolution Procedures. 5 65 3.4. Authentication TLV ...................................... 6 66 3.5. Wide Metric ............................................. 7 67 3.6. Adjacency Formation Consideration ....................... 7 68 4. Co-existence with Other IGP Auto-configuration ............... 7 69 5. Security Considerations ...................................... 7 70 6. IANA Considerations .......................................... 8 71 7. Acknowledgments .............................................. 8 72 8. References ................................................... 8 73 8.1. Normative References .................................... 8 74 8.2. Informative References .................................. 8 76 1. Introduction 78 This memo describes mechanisms for IS-IS [RFC1195][RFC5308] to be 79 auto-configuring. Such mechanisms could reduce the management burden 80 to configure a network. One example is home network where plug-and- 81 play would be expected. Besides home network, some simple 82 enterprise/ISP networks might also potentially benefit from the auto- 83 configuring mechanisms. 85 In addition, this memo defines how such un-configured routers should 86 behave, also limits the risk on existing network using IS-IS (Setcion 87 3.4 & 3.5). 89 IS-IS auto-configuration mainly contains the following aspects: 91 1. IS-IS Default Configuration 93 2. IS-IS NET self-generation 95 3. NET duplication detection and resolution 97 4. Authentication and Wide Metric TLV 99 2. Design Scope 101 The auto-configuring mechanisms are not specifically designed based 102 on IPv4 or IPv6. 104 The auto-configuring mechanisms enabled interfaces are assumed to 105 have a 48-bit MAC address. 107 The main targeted application scenarios are supposed to be home 108 networks or small enterprise networks .etc. where plug-n-play is 109 expected and complex topology/hierarchy is not needed. Sophisticate 110 requirements from service provider networks are out of scope. 112 So this document does not provide a complete configuration-free 113 alternative to the IS-IS protocol. The following features of IS-IS 114 are NOT supported by this document: 116 o Auto-configuring multiple IS-IS processes. The auto-configuration 117 mechanisms only support configuring a single process. 119 o Route between multiple IS-IS areas. The auto-configuration 120 mechanisms only support routers that are within a single area. 122 o Auto-configuring multiple operation levels. The auto-configuration 123 mechanisms only support level-1 operation mode. 125 o This document does not consider interoperability with other routing 126 protocols. 128 3. Protocol Specification 130 3.1. IS-IS Default Configuration 132 o IS-IS SHOULD be enabled on all interfaces in a router that requires 133 the IS-IS auto-configuration as default. For some specific situations, 134 interface MAY be excluded if it is a clear that running IS-IS on the 135 interface is not required. 137 o IS-IS interfaces MUST be auto-configured to an interface type 138 corresponding to their layer-2 capability. For example, Ethernet 139 interfaces will be auto-configured as broadcast networks and Point- 140 to-Point Protocol (PPP) interfaces will be auto-configured as Point- 141 to-Point interfaces. 143 o IS-IS auto-configuration interfaces MUST be configured with level-1. 145 3.2. IS-IS NET Generation 147 In IS-IS, a router (known as an IS) is identified by an Network 148 Entity Title (NET) which is the address of a Network Service Access 149 Point (NSAP) and represented with an IS-IS specific address format. 150 The NSAP is a logical entity which represents an instance of the IS- 151 IS protocol running on an IS. 153 The NET consists of three parts. The auto-generation mechanisms of 154 each part are described as the following: 156 Area address: This field is 1 to 13 octets in length. In IS-IS auto- 157 configuring, this field MUST be 0 in 13 octets length. 159 System ID: This field follows the area address field, and is 6 octets 160 in length. As specified in IS-IS protocol, this field must be unique 161 among all level-1 routers in the same area when the IS operates at 162 Level 1. In IS-IS auto-configuring, this field SHOULD be the MAC 163 address of one IS-IS enabled interface. 165 NSEL: This field is the N-selector, and is 1 octet in length. In IS- 166 IS auto-configuring, it must be set to "00". 168 3.3. IS-IS NET Duplication Detection and Resolution 170 As described in Section 3, in IS-IS auto-configuring the NETs are 171 distinguished by the System ID field in which it is a MAC address. So 172 for IS-IS neighbors' NET duplication, it is equal to MAC address 173 duplication in a LAN, which means a serious problem that devices need 174 to be changed. So the NET duplication detection and resolution 175 mechanism is actually used between non-neighbors which are within 176 the same IS-IS area. 178 The rational of IS-IS NET duplication detection and resolution is 179 described as the following. 181 3.3.1. Router-Hardware-Fingerprint TLV 183 The Router-Hardware-Fingerprint TLV is defined in [OSPFv3AC]. This 184 document re-uses it to achieve NET duplication detection. 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Length | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Router Hardware Fingerprint (Variable) | 192 . . 193 . . 194 . . 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 1 Router-Hardware-Fingerprint TLV Format 198 As defined in [OSPFv3AC], the contents of the hardware fingerprint 199 should be some combination of CPU ID, or serial number(s) that 200 provides an extremely high probability of uniqueness. It MUST be 201 based on hardware attributes that will not change across hard and 202 soft restarts. The length of the Router-Hardware-Fingerprint is 203 variable but must be 32 octets or greater. 205 Note that, since the TLV is to detect MAC address based NET 206 duplication, the TLV content MUST NOT only use MAC address. MAC 207 address plus other information are also not recommended to use. 209 3.3.2. NET Duplication Detection and Resolution Procedures 211 1) Flood the Router-Hardware-Fingerprint TLVs 213 When an IS-IS auto-configuration router gets online, it MUST include 214 the Router-Hardware-Fingerprint TLV in the first originated level-1 215 LSP. Then all the routers in the area could receive the information 216 in the TLV. 218 2) Compare the received Router-Hardware-Fingerprint TLVs 220 An IS-IS auto-configuring router MUST compare a received self- 221 originated LSP's Router-Hardware-Fingerprint TLV against its own one. 222 If they are equal, it means the LSP was indeed originated by the 223 router itself; if they are not equal, it means some other router has 224 the same NET originated the LSP, thus there is a NET duplication. 226 3) Duplication resolution 228 When NET duplication occurs, the router with the numerically smaller 229 router hardware fingerprint MUST generate a new NET. 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. Authentication TLV 244 Every IS-IS auto-configuration message MUST include an authentication 245 TLV (TLV 10, [RFC5304]) with the Type 1 authentication mode 246 ("Cleartext Password") in order to avoid the auto-conf router to 247 accidentally join an existing IS-IS network which is not intended to 248 be auto-configured. 250 This feature is necessary because a low end CPE joining an existing 251 IS-IS network might seriously break it or cause unnecessary 252 management confusion. 254 The cleartext password is specified as "isis-autoconf". Routers that 255 implement IS-IS auto-configuration MUST use this password as default, 256 so that different routers could authenticate each other with no human 257 intervene as default. And routers MUST be able to set manual password 258 by the users. 260 3.5. Wide Metric 262 IS-IS auto-configuration routers SHOULD support wide metric (TLV 22, 263 [RFC5305]). It is recommended that IS-IS auto-configuration routers 264 use a high metric value (e.g. 1000000) as default in order to 265 typically prefer the manually configured adjacencies rather than the 266 auto-conf ones. 268 3.6. Adjacency Formation Consideration 270 ISIS does not require strict hold timers matching to form adjacency. 271 But a reasonable range might be needed. Whether we need to specify a 272 best practice timers in ISIS-AC is an open question.[TBD]. 274 4. Co-existence with Other IGP Auto-configuration 276 If a router supports multiple IGP auto-configuration mechanisms (e.g. 277 both IS-IS auto-configuration and OSPF auto-configuration), then in 278 practice it is a problem that there should be a mechanism to decide 279 which IGP to be used, or even both. 281 However, it is not proper to specify choice/interaction of multiple 282 IGPs in any standalone IGP auto-configuration protocols. It should be 283 done in the CPE level. Currently, there is some relevant work 284 emerging, for example, the suggestion from [HOMENET-HNCP] is to have 285 the proposed HNCP (Home Network Control Protocol) choose what IGP 286 should be used. 288 5. Security Considerations 290 Unwanted routers could easily join in an existing IS-IS auto- 291 configuration network by setting the authentication password as 292 "isis-autoconf" default value or sniff the cleartext password online. 293 However, this is a common security risk shared by other IS-IS 294 networks that don't set proper authentication mechanisms. For wired 295 deployment, the wired line itself could be considered as an implicit 296 authentication that normally unwanted routers are not able to connect 297 to the wire line; for wireless deployment, the authentication could 298 be achieve at the lower wireless link layer. 300 Malicious router could modify the SystemID field to cause NET 301 duplication detection and resolution vibrate thus cause the routing 302 system vibrate. 304 6. IANA Considerations 306 The Router Hardware Fingerprint TLV type code needs an assignment by 307 IANA. 309 7. Acknowledgments 311 Many useful comments and contributions were made by Sheng Jiang. 313 This document was inspired by [OSPFv3AC]. 315 8. References 317 8.1. Normative References 319 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 320 dual environments", RFC 1195, December 1990. 322 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 323 Authentication", RFC 5304, October 2008. 325 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 326 Engineering", RFC 5305, October 2008. 328 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 329 2008. 331 8.2. Informative References 333 [OSPFv3AC]Lindem, A., and J. Arkko, "OSPFv3 Auto-Configuration", Work 334 in Progress, October 2013 336 [HOMENET-HNCP] 337 Stenberg, M., and S. Barth, "Home Networking Control 338 Protocol", Work in Progress, February 05 340 Authors' Addresses 342 Bing Liu 343 Huawei Technologies Co., Ltd 344 Q14, Huawei Campus 345 No.156 Beiqing Rd. 346 Hai-Dian District, Beijing 100095 347 P.R. China 349 Email: leo.liubing@huawei.com 351 Bruno Decraene 352 Orange 353 Issy-les-Moulineaux 354 FR 356 Email: bruno.decraene@orange.com 358 Ian Farrer 359 Deutsche Telekom AG 360 Bonn, 361 Germany 363 Email: ian.farrer@telekom.de 365 Mikael Abrahamsson 366 T-Systems 367 Stockholm, 368 Sweden 370 Email: mikael.abrahamsson@t-systems.se