idnits 2.17.1 draft-ietf-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 131: '...IS-IS interfaces MUST be auto-configur...' RFC 2119 keyword, line 137: '...uration instance MUST be configured as...' RFC 2119 keyword, line 153: '...tion, this field MUST be 13 octets lon...' RFC 2119 keyword, line 165: '...eneration, the System ID SHOULD remain...' RFC 2119 keyword, line 167: '... SHOULD not be changed due ...' (42 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: - After its initial generation, the System ID SHOULD remain stable to improve the stability of the routing system. It SHOULD not be changed due to device status change (such as interface enable/disable, interface connect/disconnect, device reboot, firmware update etc.) or configuration change (such as changing system configuration or IS-IS configuration); but MUST support change as part of the System ID collision resolution process and SHOULD allow being cleared by a user initiated system reset. -- The document date (October 31, 2016) is 2732 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: 'RFC6232' is defined on line 611, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 isis B. Liu, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track B. Decraene 5 Expires: May 4, 2017 Orange 6 I. Farrer 7 Deutsche Telekom AG 8 M. Abrahamsson 9 T-Systems 10 L. Ginsberg 11 Cisco Systems 12 October 31, 2016 14 ISIS Auto-Configuration 15 draft-ietf-isis-auto-conf-03 17 Abstract 19 This document specifies IS-IS auto-configuration mechanisms. The key 20 components are IS-IS System ID self-generation, duplication detection 21 and duplication resolution. These mechanisms provide limited IS-IS 22 functions, and so are suitable for networks where plug-and-play 23 configuration is expected. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 4, 2017. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 62 3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3 63 3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 3 64 3.3. IS-IS System ID Duplication Detection and Resolution . . 4 65 3.3.1. Router-Fingerprint TLV . . . . . . . . . . . . . . . 4 66 3.3.2. Duplicate System ID Detection and Resolution 67 Procedures . . . . . . . . . . . . . . . . . . . . . 5 68 3.3.3. System ID and Router-Fingerprint Generation 69 Considerations . . . . . . . . . . . . . . . . . . . 10 70 3.3.4. Double-Duplication of both System ID and Router- 71 Fingerprint . . . . . . . . . . . . . . . . . . . . . 11 72 3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 11 73 3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 11 74 3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 11 75 3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 12 76 3.5. Routing Behavior Considerations . . . . . . . . . . . . . 12 77 3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 12 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 83 7.2. Informative References . . . . . . . . . . . . . . . . . 14 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 86 1. Introduction 88 This document specifies mechanisms for IS-IS [RFC1195] 89 [ISO_IEC10589][RFC5308] to be auto-configuring. Such mechanisms 90 could reduce the management burden for configuring a network, 91 especially where plug-and-play device configuration is required. 93 IS-IS auto-configuration is comprised of the following functions: 95 1. IS-IS default configurations. 97 2. IS-IS System ID self-generation. 99 3. System ID duplication detection and resolution. 101 4. ISIS TLV utilization (Authentication TLV, Wide Metric TLV, and 102 Dynamic Host Name TLV). 104 This document also defines mechanisms to prevent the unintentional 105 interoperation of auto-configured routers with non-autoconfigured 106 routers. See Section 3.3.1. 108 2. Scope 110 The auto-configuration mechanism supports both IPv4 and IPv6 111 deployments. 113 These auto-configuration mechanisms aim to cover simple deployment 114 cases. The following important features are not supported: 116 o Multiple IS-IS instances. 118 o Multi-area and level-2 routing. 120 o Interworking with other routing protocols. 122 IS-IS auto-configuration is primarily intended for use in small (i.e. 123 10s of devices) and unmanaged deployments. Its allows IS-IS to be 124 used as the IGP without the need for any configuration by the user. 125 It is not recommended for larger deployments. 127 3. Protocol Specification 129 3.1. IS-IS Default Configuration 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 instance MUST be configured as level-1, 138 so that the interfaces operate as level-1 only. 140 3.2. IS-IS NET Generation 142 In IS-IS, a router (known as an Intermediate System) is identified by 143 a 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 Intermediate System. 148 The auto-configuration mechanism generates the IS-IS NET as the 149 following: 151 o Area address 153 In IS-IS auto-configuration, this field MUST be 13 octets long 154 and set to all 0. 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 by the IS-IS protocol, this field must be 163 unique among all routers in the same area. 165 - After its initial generation, the System ID SHOULD remain 166 stable to improve the stability of the routing system. It 167 SHOULD not be changed due to device status change (such as 168 interface enable/disable, interface connect/disconnect, 169 device reboot, firmware update etc.) or configuration change 170 (such as changing system configuration or IS-IS 171 configuration); but MUST support change as part of the 172 System ID collision resolution process and SHOULD allow 173 being cleared by a user initiated system reset. 175 More specific considerations for System ID generation are 176 described in Section 3.3.3 . 178 3.3. IS-IS System ID Duplication Detection and Resolution 180 The System ID of each node MUST be unique. As described in 181 Section 3.3.3, the System ID is generated based on entropies (e.g. 182 MAC address) which are generally expected to be unique. However, 183 since there may be limitations to the available entropies, there is 184 still the possibility of System ID duplication. This section defines 185 how IS-IS detects and resolves System ID duplication. 187 3.3.1. Router-Fingerprint TLV 189 The Router-Fingerprint TLV essentially re-uses the design of Router- 190 Hardware-Fingerprint TLV defined in [RFC7503]. However, there is one 191 difference in that a flag is added to indicate that the node is in 192 "start-up mode", which is defined in Section 3.3.2. 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 |S|A| Reserved | | 200 +-+-+-+-+-+-+-+-+ Router Fingerprint (Variable) . 201 . . 202 . . 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Router Fingerprint TLV Format 207 The length of the Router-Fingerprint is variable but MUST be 32 208 octets or greater. For correct operation, the Router-Fingerprint 209 MUST be unique among all the routers participating in the IS-IS area. 211 o Type: to be assigned by IANA. 213 o Length: the length of the value field. As the Router Fingerprint 214 length is variable, the field length is also variable. 216 o S flag: when set, indicates the router is in "start-up" mode. 218 o A flag: when set, indicates that the router is operating in auto- 219 configuration mode. The purpose of the flag is so that two 220 routers can identify if they are both using auto-configuration. 221 If the A flag setting does not match in hellos then no adjacency 222 should be formed. 224 o Reserved: these bits MUST be set to zero and MUST be ignored by 225 the receiver. 227 o Router Fingerprint: uniquely identifies a router, variable length. 229 More specific considerations for Router-Fingerprint are described in 230 Section 3.3.3 . 232 3.3.2. Duplicate System ID Detection and Resolution Procedures 234 This section describes the duplicate System ID detection and 235 resolution process between two neighbors and two non-neighbors 236 respectively. This is due to difference in the the routing messages 237 between neighbors and non-neighbors. 239 3.3.2.1. Start-up Mode 241 While in Start-up Mode, an auto-configuration router forms 242 adjacencies but generates only LSP #0 which contains only the Router- 243 Fingerprint TLV. A router remains in startup-mode until it has 244 successfully completed LSPDB synchronization with all neighbors or 245 until 1 minute has elapsed - whichever is longer. If a duplicate 246 System ID is detected while in Start-up Mode stage, the Start-up Mode 247 router MUST clear all adjacencies, select a new System ID (subject to 248 rules defined in Section 3.3.2.2 ), and re-enter Start-up Mode. 250 The purpose of the Start-up Mode is to minimize the occurrence of 251 System ID changes for a router once it has become fully operational. 252 It has minimal impact on a running network because the Start-up Mode 253 node is not yet being used for forwarding traffic. Once duplicate 254 System IDs have been resolved the router begins normal operation. If 255 two routers are both in Start-up Mode and duplicate System ID is 256 detected, they follow the duplication resolution as specified in 257 Section 3.3.2.2 and Section 3.3.2.3. 259 When an IS-IS auto-configuration router boots up, it MUST operate in 260 Startup-Mode until duplicate System ID detection has successfully 261 completed. 263 3.3.2.2. Duplication Between Neighbors 265 In the case of duplicate System IDs being detected between neighbors, 266 an IS-IS auto-configuration router MUST include the Router- 267 Fingerprint TLV in the Hello messages, so that the duplication can be 268 detected before an adjacency is formed. 270 Start-up Mode procedures: 272 1. Boot up and advertisement of the Router-Fingerprint TLV in Hello 273 messages 275 The router sends Hello messages which include the Router- 276 Fingerprint TLV. Adjacencies are formed as normal but MUST 277 NOT be advertised in LSPs until the router exits Start-up 278 Mode. 280 2. Receiving Hello message(s), and System ID duplication detection 282 Received Hello messages are inspected for a possible duplicate 283 System ID. If a duplicate is detected, the router MUST check 284 the S flag of the Router-Fingerprint TLV. 286 + If the S flag is NOT set (which means the Hello message was 287 NOT generated by a Start-up Mode neighbor), then the router 288 MUST re-generate the System ID and re-enter Start-up Mode. 290 + If the S flag is set (meaning the neighbor is also in 291 Start-up Mode), 293 - The router which has a numerically smaller Router- 294 Fingerprint MUST re-generate its System ID and re-enter 295 Start-up Mode. Fingerprint comparison MUST be performed 296 octet by octet starts from the left until a difference 297 is found. Then, the numeric smaller fingerprint is the 298 one with the lowest value. If the fingerprints have 299 different lengths, then the shorter length fingerprint 300 MUST be padding with zero at the left side for 301 comparison. 303 - If the Router Fingerprints are identical, both routers 304 MUST re-generate the System ID and the Router 305 Fingerprint, and re-enter Start-up Mode. 307 3. Normal operation 309 After the System ID duplication procedure is successfully 310 completed, the router begins normal operation. The router 311 MUST re-advertise the Router-Fingerprint TLV with the S flag 312 disabled. 314 Non Start-up Mode procedures: 316 1. Compare the System ID in received Hello messages 318 When receiving a Hello message, the router MUST check the 319 System ID of the Hello. If the System ID is the same as its 320 own, it indicates that System ID duplication has occurred. 322 If there is no Router-Fingerprint TLV in the received Hello 323 message, this is interpreted as the attached router either 324 does not support auto-configuration, or does not have it 325 enabled. In this case, the auto-configuration router MUST NOT 326 form adjacency with the non-autoconfiguration router. 328 2. Duplication resolution 330 When duplicate System IDs are detected, the non-startup mode 331 router MUST check the S flag of the duplicated Router- 332 Fingerprint TLV: 334 + If the S flag is NOT set, then the router with the 335 numerically smaller or equal Router-Fingerprint MUST 336 generate a new System ID. Note that, the router MUST 337 compare the two Router-Fingerprint octet by octet until 338 difference is found. 340 + If the S flag is set, no further action is necessary in the 341 Duplication resolution process. 343 3. Re-joining the network with a new System ID (if required) 345 The router that has changed its System ID advertises new 346 Hellos containing the newly generated System ID to re-join the 347 IS-IS auto-configuration network. The conflicting SysID- 348 duplicated router also MUST increase the sequence number and 349 re-advertise its own Hellos. 351 The Duplication Detection process SHOULD be repeated with the 352 newly generated System. 354 3.3.2.3. Duplication Between Non-neighbors 356 System ID duplication may also occur between non-neighbors, therefore 357 an IS-IS auto-configuration router MUST also include the Router- 358 Fingerprint TLV in its LSP messages. The specific procedures are as 359 follows: 361 Start-up Mode procedures: 363 1. Boot up, adjacency formation 365 2. Acquiring LSPDB and checking System ID duplication 367 The router generates only an LSP #0 which contains only the 368 Fingerprint TLV; and that Fingerprint is only sent in LSP #0. 369 A router remains in Start-up Mode until it has successfully 370 completed LSPDB synchronization with all neighbors or until 1 371 minute has elapsed - whichever is longer. If duplicate 372 system-ID is detected, the router MUST check the S flag of the 373 Router-Fingerprint TLV of the LSP that contains the duplicated 374 System ID. 376 + If the S flag is not set, it means the LSP was generated by 377 a Non Start-up Mode node, then the router itself MUST clear 378 all adjacencies, re-generate a new system-id and reenter 379 Start-up Mode. 381 + If the S flag is set, then the router which has a 382 numerically smaller Router-Fingerprint MUST generate a new 383 System ID and reenter Start-up Mode. 385 3. Running in normal operation 387 After the System ID duplication procedure is done, the router 388 begins to run in normal operation. The router MUST re- 389 advertise the Router-Fingerprint TLV with the S flag off. 391 Non Start-up Mode procedures: 393 1. Checking the received Router-Fingerprint TLVs 395 When receiving a LSP containing its own System ID, the router 396 MUST check the Router-Fingerprint TLV. If the Router- 397 Fingerprint TLV is different from its own, it indicates a 398 System ID duplication occurs. 400 2. Duplication resolution 402 When System ID duplication occurs, the non-startup mode router 403 MUST check the S flag of the duplicated Router-Fingerprint 404 TLV: 406 + If the S flag is NOT set, then the router with the 407 numerically smaller Router-Fingerprint MUST generate a new 408 System ID. Note that, the router MUST compare the two 409 Router-Fingerprint octet by octet until difference is 410 found. 412 + If the S flag is set, then router does nothing. 414 3. Re-joining the network with the new System ID 416 The router changing its System ID advertises new LSPs based on 417 the newly generated System ID to re-join the IS-IS auto- 418 configuration network. The other SysID-duplicated router also 419 MUST re-advertise its own LSP (after increasing the sequence 420 number). 422 The newly generated System ID SHOULD perform duplication 423 detection as well. 425 3.3.3. System ID and Router-Fingerprint Generation Considerations 427 As specified in this document, there are two distinguishing items 428 that need to be self-generated: the System ID and Router-Fingerprint. 429 In a network device, normally there are some resources which can 430 provide an extremely high probability of uniqueness thus could be 431 used as seeds to derive distinguisher (e.g. hashing or generating 432 pseudo-random numbers), such as: 434 o MAC address(es) 436 o Configured IP address(es) 438 o Hardware IDs (e.g. CPU ID) 440 o Device serial number(s) 442 o System clock at a certain specific time 444 o Arbitrary received packet(s) on an interface(s) 446 This document recommends the use of an IEEE 802 48-bit MAC address 447 associated with the router as the initial System ID. This document 448 does not specify a specific method to re-generate the System ID when 449 duplication happens. 451 This document also does not specify a specific method to generate the 452 Router-Fingerprint. However, the generation of System ID and Router- 453 Fingerprint MUST be based on different seeds so that the two 454 distinguisher would not collide. 456 There is an important concern that the seeds listed above (except MAC 457 address) might not be available in some small devices such as home 458 routers. This is because of hardware/software limitations and the 459 lack of sufficient communication packets at the initial stage in home 460 routers when doing ISIS auto-configuration. In this case, this 461 document suggests using the MAC address as System ID and generating a 462 pseudo-random number based on another seed (such as the memory 463 address of a certain variable in the program) as the Router- 464 Fingerprint. The pseudo-random number might not have a very high 465 probability of uniqueness in this solution, but should be sufficient 466 in home networks scenarios. 468 The considerations surrounding System ID stability described in 469 section Section 3.2 also need to be applied. 471 3.3.4. Double-Duplication of both System ID and Router-Fingerprint 473 As described above, the resources for generating the distinguisher 474 might be very constrained during the initial stages. Hence, the 475 double-duplication of both System ID and Router-Fingerprint needs to 476 be considered. 478 ISIS-autoconfiguring routers SHOULD support detecting System ID 479 duplication by LSP war. LSP war is a phenomenon whereby a router 480 receives a LSP originated with its System ID, but it doesn't find it 481 in the database, or it does not match the one the router has (e.g. 482 it advertises IP prefixes that the router does not own, or IS 483 neighbors that the router does not see), then per the ISIS 484 specification, the router must re-originate its LSP with an increased 485 sequence number. If double-duplication happens, the duplicated two 486 routers will both continuously repeat the above behavior. After 487 multiples iterations, the program should be able to deduce that 488 double-duplication is occurring. 490 When this condition is detected, routers should have much more 491 entropies available. Thus, the router is able to extend or re- 492 generate its Router-Fingerprint (one simple way is just adding the 493 LSP sequence number of the next LSP it will send to the Router- 494 Fingerprint). 496 3.4. IS-IS TLVs Usage 498 This section describes the TLVs that are necessary for IS-IS auto- 499 configuration. 501 3.4.1. Authentication TLV 503 It is RECOMMENDED that IS-IS routers supporting this specification 504 minimally offer an option to explicitly configure a single password 505 for HMAC-MD5 authentication, which is Type 54 authentication mode of 506 [RFC5304]. In this case, the Authentication TLV (TLV 10) is needed. 508 3.4.2. Wide Metric TLV 510 IS-IS auto-configuration routers MUST support TLVs using wide metrics 511 as defined in [RFC5305]). 513 It is RECOMMENDED that IS-IS auto-configuration routers use a high 514 metric value (e.g. 1000000) as default in order to typically prefer 515 manually configured adjacencies over auto-configuringed. 517 3.4.3. Dynamic Host Name TLV 519 IS-IS auto-configuration routers MAY advertise their Dynamic Host 520 Names TLV (TLV 137, [RFC5301]). The host names could be provisioned 521 by an IT system, or just use the name of vendor, device type or 522 serial number, etc. 524 To guarantee the uniqueness of the host names, the System ID SHOULD 525 be appended as a suffix in the names. 527 3.5. Routing Behavior Considerations 529 3.5.1. Adjacency Formation 531 Since IS-IS does not require strict hold timer matching to form 532 adjacency, this document does not specify specific hold timers. 533 However, the timers should be within a reasonable range based on 534 current practise in the industry. (For example, the defaults defined 535 in [ISO_IEC10589] .) 537 4. Security Considerations 539 In general, auto-configuration is mutually incompatible with 540 authentication. This is a common problem that IS-IS auto- 541 configuration can not avoid. 543 For wired deployment, the wired connection itself could be considered 544 as an implicit authentication in that unwanted routers are usually 545 not able to connect (i.e. there is some kind of physical security in 546 place preventing the connection of rogue devices); for wireless 547 deployment, the authentication could be achieved at the lower 548 wireless link layer. 550 A malicious router could modify the System ID field to keep causing 551 System ID duplication detection and resolution thus cause the routing 552 system to oscillate. However, this is not a new attack vector as 553 without this document the consequences would be higher as other 554 routers would not have a mechanism to try and resolve this case. 556 5. IANA Considerations 558 IANA is kindly requested to assign a new TLV for the Router- 559 Fingerprint from the IS-IS TLV Codepoint registry. 561 6. Acknowledgements 563 This document was heavily inspired by [RFC7503]. 565 Martin Winter, Christian Franke and David Lamparter gave essential 566 feedback to improve the technical design based on their 567 implementation experience. 569 Many useful comments were made by Acee Lindem, Karsten Thomann, 570 Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and 571 Nan Wu, etc. 573 This document was produced using the xml2rfc tool [RFC2629]. 574 (initially prepared using 2-Word-v2.0.template.dot. ) 576 7. References 578 7.1. Normative References 580 [ISO_IEC10589] 581 ""Intermediate System to Intermediate System intra-domain 582 routeing information exchange protocol for use in 583 conjunction with the protocol for providing the 584 connectionless-mode network service (ISO 8473)", ISO/IEC 585 10589", November 2002. 587 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 588 dual environments", RFC 1195, DOI 10.17487/RFC1195, 589 December 1990, . 591 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 592 DOI 10.17487/RFC2629, June 1999, 593 . 595 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 596 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 597 October 2008, . 599 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 600 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 601 2008, . 603 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 604 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 605 2008, . 607 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 608 DOI 10.17487/RFC5308, October 2008, 609 . 611 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 612 Originator Identification TLV for IS-IS", RFC 6232, 613 DOI 10.17487/RFC6232, May 2011, 614 . 616 7.2. Informative References 618 [RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration", 619 RFC 7503, DOI 10.17487/RFC7503, April 2015, 620 . 622 Authors' Addresses 624 Bing Liu 625 Huawei Technologies 626 Q10, Huawei Campus, No.156 Beiqing Road 627 Hai-Dian District, Beijing, 100095 628 P.R. China 630 Email: leo.liubing@huawei.com 632 Bruno Decraene 633 Orange 634 France 636 Email: bruno.decraene@orange.com 638 Ian Farrer 639 Deutsche Telekom AG 640 Bonn 641 Germany 643 Email: ian.farrer@telekom.de 645 Mikael Abrahamsson 646 T-Systems 647 Stockholm 648 Sweden 650 Email: mikael.abrahamsson@t-systems.se 651 Les Ginsberg 652 Cisco Systems 653 510 McCarthy Blvd. 654 Milpitas CA 95035 655 USA 657 Email: ginsberg@cisco.com