idnits 2.17.1 draft-ietf-isis-auto-conf-00.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 is 1 instance of too long lines in the document, the longest one being 25 characters 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 126: '...IS-IS interfaces MUST be auto-configur...' RFC 2119 keyword, line 132: '...uration instance MUST be configured wi...' RFC 2119 keyword, line 135: '...to-configuration SHOULD allow P2P mode...' RFC 2119 keyword, line 152: '...tion, this field MUST be 13 octets of ...' RFC 2119 keyword, line 164: '... SHOULD remain the same aft...' (44 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 (November 30, 2015) is 3070 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 601, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-homenet-hncp' is defined on line 608, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 5 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: June 2, 2016 Orange 6 I. Farrer 7 Deutsche Telekom AG 8 M. Abrahamsson 9 T-Systems 10 L. Ginsberg 11 Cisco Systems 12 November 30, 2015 14 ISIS Auto-Configuration 15 draft-ietf-isis-auto-conf-00 17 Abstract 19 This document specifies an IS-IS auto-configuration technology. The 20 key mechanisms of this technology are IS-IS System ID self- 21 generation, duplication detection and duplication resolution. This 22 technology fits the environment where plug-and-play is expected. 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 June 2, 2016. 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 System ID Duplication Detection and Resolution . . 4 64 3.3.1. Router-Fingerprint TLV . . . . . . . . . . . . . . . 4 65 3.3.2. System ID Duplication Detection and Resolution 66 Procedures . . . . . . . . . . . . . . . . . . . . . 5 67 3.3.3. System ID and Router-Fingerprint Generation 68 Considerations . . . . . . . . . . . . . . . . . . . 9 69 3.3.4. Double-Duplication of both System ID and Router- 70 Fingerprint . . . . . . . . . . . . . . . . . . . . . 10 71 3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 11 72 3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 11 73 3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 11 74 3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 11 75 3.5. Routing Behavior Considerations . . . . . . . . . . . . . 12 76 3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 12 77 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 7.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 7.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 This document describes mechanisms for IS-IS [RFC1195] 88 [ISO_IEC10589][RFC5308] to be auto-configuring. Such mechanisms 89 could reduce the management burden to configure a network. Home 90 networks and small or medium size enterprise networks where plug-and- 91 play is expected can benefit from these mechanisms. 93 This document also defines mechanisms which prevent unintentional 94 interoperation of autoconfigured routers with non-autoconfigured 95 routers. See Section 3.3.1 . 97 IS-IS auto-configuration contains the following aspects: 99 1. IS-IS default configurations 101 2. IS-IS System ID self-generation 103 3. System ID 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 support both IPv4 and IPv6 111 deployments. 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 routing 120 o Interworking with other routing protocols 122 3. Protocol Specification 124 3.1. IS-IS Default Configuration 126 o IS-IS interfaces MUST be auto-configured to an interface type 127 corresponding to their layer-2 capability. For example, Ethernet 128 interfaces will be auto-configured as broadcast networks and 129 Point-to-Point Protocol (PPP) interfaces will be auto-configured 130 as Point-to-Point interfaces. 132 o IS-IS auto-configuration instance MUST be configured with level-1, 133 so that the interfaces operate at level-1 only. 135 o IS-IS auto-configuration SHOULD allow P2P mode on Ethernet 136 interfaces. 138 3.2. IS-IS NET Generation 140 In IS-IS, a router (known as an Intermediate System) is identified by 141 an NET which is the address of a Network Service Access Point (NSAP) 142 and represented with an IS-IS specific address format. The NSAP is a 143 logical entity which represents an instance of the IS-IS protocol 144 running on an Intermediate System. 146 The autoconfiguration mechanism generates the IS-IS NET as the 147 following: 149 o Area address 151 This field is 1 to 13 octets in length. In IS-IS auto- 152 configuration, this field MUST be 13 octets of all 0. 154 o System ID 156 This field follows the area address field, and is 6 octets in 157 length. There are two basic requirements for the System ID 158 generation: 160 - As specified in IS-IS protocol, this field must be unique 161 among all routers in the same area. 163 - In order to make the routing system stable, the System ID 164 SHOULD remain the same after it is firstly generated. It 165 SHOULD not be changed due to device status change (such as 166 interface enable/disable, interface plug in/off, device 167 reboot, firmware update etc.) or configuration change (such 168 as changing system configurations or IS-IS configurations 169 etc.); but it MUST allow be changed by collision resolution 170 and SHOULD allow be cleared by user enforced system reset. 172 More specific considerations for System ID generation are 173 described in Section 3.3.3 . 175 3.3. IS-IS System ID Duplication Detection and Resolution 177 The System ID of each node MUST be unique. As described in 178 Section 3.3.3, the System ID is generated based on entropies such as 179 MAC address which are supposed to be unique, but in theory there is 180 still possibility of duplication. This section defines how IS-IS 181 detects and resolves System ID duplication. 183 3.3.1. Router-Fingerprint TLV 185 The Router-Fingerprint TLV basically re-uses the design of Router- 186 Hardware-Fingerprint TLV defined in [RFC7503]. However, there is one 187 difference that one flag is added to indicate the node is in "start- 188 up mode" which is defined in Section 3.3.2 . 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 |S|A| Reserved | | 196 +-+-+-+-+-+-+-+-+ Router Fingerprint (Variable) . 197 . . 198 . . 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 The length of the Router-Fingerprint is variable but must be 32 202 octets or greater; and the content is also supposed to be unique 203 among all the routers. 205 o Type: to be assigned by IANA. 207 o Length: the length of the value field. 209 o S flag: indicates the router is in "start-up" mode as described 210 below. 212 o A flag: indicates the router is operating in autoconfiguration 213 mode. This flag is in case the TLV gets used outside of 214 autoconfiguration. If A flag setting does not match in hellos 215 then no adjacency should be formed. 217 o Reserved: these bits MUST be set to zero and MUST be ignored when 218 received. 220 o Router Fingerprint: uniquely identifies a router, variable length. 222 More specific considerations for Router-Fingerprint is described in 223 Section 3.3.3 . 225 3.3.2. System ID Duplication Detection and Resolution Procedures 227 This section describes the System ID duplication detection and 228 resolution between two neighbors and two non-neighbors respectively. 229 This is because the routing messages between neighbors and non- 230 neighbors are a bit different. 232 3.3.2.1. Start-up Mode 234 While in startup-mode, an auto-configuration router forms adjacencies 235 but generates only LSP #0 which contains only the Router-Fingerprint 236 TLV. A router remains in startup-mode until it has successfully 237 completed LSPDB synchronization with all neighbors or until 1 minute 238 has elapsed - whichever is longer. If duplicate system-ID is 239 detected while in startup-mode the router MUST clear all adjacencies, 240 select a new system-id (subject to rules defined in Section 3.3.2.2 241 ), and reenter Startup-mode. 243 The start-up mode is to minimize the occurrence of System ID changes 244 for a router once it has become fully operational. It has minimal 245 impact on a running network because the startup node is not yet being 246 used for forwarding traffic. Once duplicate System ID has been 247 resolved the router begins normal operation. If two routers are both 248 in startup mode (or both NOT in startup mode) and duplicate system-id 249 is detected then they determine which one changes its system-id based 250 on fingerprint. 252 When an IS-IS auto-configuration router boots up, it MUST operate in 253 start-up mode until duplicate system-id detection has successfully 254 completed. 256 3.3.2.2. Duplication Between Neighbors 258 In case of System ID duplication occurs between neighbors, an IS-IS 259 auto-configuration router MUST include the Router-Fingerprint TLV in 260 the Hello messages, so that the duplication could be detected before 261 adjacency forming. 263 Procedures of the nodes in Start-up Mode: 265 1. Boot up, advertise the Router-Fingerprint TLV in Hello message 267 The router sends Hellos which include the Router-Fingerprint 268 TLV. Adjacencies are formed as normal but MUST NOT be 269 advertised in LSPs until the router exits startup-mode. 271 2. Receive Hello message(s), and verifies System ID duplication 273 Received hellos are inspected for possible duplicate System 274 ID. If duplication is detected, the router MUST check the S 275 flag of the Router-Fingerprint TLV. 277 + If the S flag is NOT set (which means the Hello was NOT 278 generated by a neighbor also in Start-up mode), then the 279 router MUST re-generate the System ID and reenter Startup- 280 mode. 282 + If the S flag is set (which means the neighbor is also in 283 Startup-mode), 284 - the router which has a numerically smaller Router- 285 Fingerprint MUST re-generate the System ID and reenter 286 Startup-mode. Fingerprint comparison is performed octet 287 by octet until octets are different. Then the smaller 288 fingerprint is the one with the smaller octet (unsigned 289 integer). If the fingerprints have different lengths, 290 then the shorter length fingerprint MUST be padding with 291 zero for comparison. 293 - If Router Fingerprints are identical, both routers MUST 294 re-generate the System ID and the Router Fingerprint, 295 and reenter Startup-mode. 297 3. Run in normal operation 299 After the System ID duplication procedure is done, the router 300 begins to run in normal operation. The router MUST re- 301 advertise the Router-Fingerprint TLV with the S flag off. 303 Procedures of the nodes NOT in Start-up Mode: 305 1. Compare the System ID in received Hello messages 307 When receiving a Hello message, the router MUST check the 308 System ID of the Hello. If the System ID is the same as its 309 own, it indicates a System ID duplication occurs. 311 If there is no Router-Fingerprint TLV in the Hello message, it 312 means a non-autoconfiguration router by accident connected to 313 the auto-configuration domain or other unexpected bad 314 behaviors. In this case, the auto-configuration router MUST 315 NOT form adjacency with the non-autoconfiguration router. 317 2. Duplication resolution 319 When System ID duplication occurs, the non-startup mode router 320 MUST check the S flag of the duplicated Router-Fingerprint 321 TLV: 323 + If the S flag is NOT set, then the router with the 324 numerically smaller or equal Router-Fingerprint MUST 325 generate a new System ID. Note that, the router MUST 326 compare the two Router-Fingerprint in terms of two numeric 327 numbers. 329 + If the S flag is set, then router does nothing, because it 330 MUST be the node which is in start-up mode re-generates the 331 System ID. 333 3. Re-join the network with the new System ID (if required) 335 The router with the smaller Router-Fingerprint advertise new 336 Hellos based on the newly generated NET to re-join the IS-IS 337 auto-configuration network. The router with the highest 338 Router-Fingerprint MUST re-advertise its own LSP (after 339 increasing the sequence number). 341 The newly generated System ID SHOULD take a duplication 342 detection as well. 344 3.3.2.3. Duplication Between Non-neighbors 346 System ID duplication may also occur between non-neighbors, so an IS- 347 IS auto-configuration router MUST also include the Router-Fingerprint 348 TLV in the LSP messages. Specific procedures are as the following. 350 Procedures of the nodes in Start-up Mode: 352 1. Boot up, form adjacency 354 2. Acquire LSPDB and verifies System ID duplication 356 The router generates only LSP #0 which contains only the 357 Fingerprint TLV; and that Fingerprint is only sent in LSP #0. 358 A router remains in startup-mode until it has successfully 359 completed LSPDB synchronization with all neighbors or until 1 360 minute has elapsed - whichever is longer. If duplicate 361 system-ID is detected, the router MUST check the S flag of the 362 Router-Fingerprint TLV of the LSP that contains the duplicated 363 System ID. 365 + If the S flag is not set, it means the LSP was not 366 generated at the Start-up Mode, then the router itself MUST 367 clear all adjacencies, re-generate a new system-id and 368 reenter Startup-mode. 370 + If the S flag is set, then the router which has a 371 numerically smaller Router-Fingerprint MUST generate a new 372 System ID and reenter Startup-mode. 374 3. Run in normal operation 376 After the System ID duplication procedure is done, the router 377 begins to run in normal operation. The router MUST re- 378 advertise the Router-Fingerprint TLV with the S flag off. 380 Procedures of the nodes not in Start-up Mode: 382 1. Compare the received Router-Fingerprint TLVs 384 When receiving a LSP containing its own System ID, the router 385 MUST check the Router-Fingerprint TLV. If the Router- 386 Fingerprint TLV is different from its own, it indicates a 387 System ID duplication occurs. 389 2. Duplication resolution 391 When System ID duplication occurs, the non-startup mode router 392 MUST check the S flag of the duplicated Router-Fingerprint 393 TLV: 395 + If the S flag is NOT set, then the router with the 396 numerically smaller Router-Fingerprint MUST generate a new 397 System ID. Note that, the router MUST compare the two 398 Router-Fingerprint in terms of two numeric numbers. 400 + If the S flag is set, then router does nothing, because 401 according to the start-up mode procedure, the start-up node 402 MUST re-generate the System ID. 404 3. Re-join the network with the new System ID 406 The router changing its system ID advertise new LSPs based on 407 the newly generated System ID to re-join the IS-IS auto- 408 configuration network. The router with the highest Router- 409 Fingerprint MUST re-advertise its own LSP (after increasing 410 the sequence number). 412 The newly generated System SHOULD take a duplication detection 413 as well. 415 3.3.3. System ID and Router-Fingerprint Generation Considerations 417 As specified in this document, there are two distinguisher need to be 418 self-generated, which is System ID and Router-Fingerprint. In a 419 network device, normally there are resources which provide an 420 extremely high probability of uniqueness thus could be used as seeds 421 to derive distinguisher (e.g. hashing or generating pseudo-random 422 numbers), such as: 424 o MAC address(es) 426 o Configured IP address(es) 427 o Hardware IDs (e.g. CPU ID) 429 o Device serial number(s) 431 o System clock at a certain specific time 433 o Arbitrary received packet 435 This document recommends to use an IEEE 802 48-bit MAC address 436 associated with the router as the initial System ID. This document 437 does not specify a specific method to re-generate the System ID when 438 duplication happens. 440 This document also does not specify a specific method to generate the 441 Router-Fingerprint. However, the generation of System ID and Router- 442 Fingerprint MUST be based on different seeds so that the two 443 distinguisher would not collide. 445 There is an important concern that the seeds listed above (except MAC 446 address) might not be available in some small devices such as home 447 routers. This is because of the hardware/software limitation and the 448 lack of sufficient communication packets at the initial stage in the 449 home routers when doing ISIS-autoconfiguration. In this case, this 450 document suggests to use MAC address as System ID and generate a 451 pseudo-random number based on another seed (such as the memory 452 address of a certain variable in the program) as Router-Fingerprint. 453 The pseudo-random number might not have a very high quality in this 454 solution, but should be sufficient in home networks scenarios. 456 Note that, the Router-Fingerprint SHOULD also remain the same after 457 it is firstly generated. It SHOULD not be changed due to device 458 status change (such as interface enable/disable, interface plug in/ 459 off, device reboot, firmware update etc.) or configuration change 460 (such as changing system configurations or IS-IS configurations 461 etc.); but it MUST allow be changed by double-duplication resolution 462 Section 3.3.4 and SHOULD allow be cleared by user enforced system 463 reset. 465 3.3.4. Double-Duplication of both System ID and Router-Fingerprint 467 As described above, the resources for generating the distinguisher 468 might be very constrained at the initial stage. Hence, the double- 469 duplication of both System ID and Router-Fingerprint needs to be 470 considered. 472 ISIS-autoconfiguring routers SHOULD support detecting System ID 473 duplication by LSP war. LSP war is a phenomenon that if a router 474 receives a LSP originated with its System ID, but it doesn't find it 475 in the database, or it does not match the one the router has (e.g. 476 It advertises IP prefixes that the router doesn't own, or IS 477 neighbors that the router doesn't see), then per ISIS specification, 478 the router must re-originate its LSP with an increased sequence 479 number. If double-duplication happens, the duplicated two routers 480 will both continuously have the above behavior. After multiples 481 iterations, the program should be able to deduce that double- 482 duplication happens. 484 At the point when double-duplication happens, routers should have 485 much more entropies available. Thus, the router is to extend or re- 486 generate its Router-Fingerprint (one simple way is just adding the 487 LSP sequence number of the next LSP it will send to the Router- 488 Fingerprint). (Optimized solution TBD.) 490 3.4. IS-IS TLVs Usage 492 This section describes several TLVs that are utilized by IS-IS auto- 493 configuration. 495 3.4.1. Authentication TLV 497 It is RECOMMENDED that IS-IS routers supporting this specification 498 minimally offer an option to explicitly configure a single password 499 for HMAC-MD5 authentication, which is Type 54 authentication mode of 500 [RFC5304]. In this case, the Authentication TLV (TLV 10) is needed. 502 3.4.2. Wide Metric TLV 504 IS-IS auto-configuration routers MUST support TLVs using wide metric 505 as defined in [RFC5305]). 507 It is recommended that IS-IS auto-configuration routers use a high 508 metric value (e.g. 1000000) as default in order to typically prefer 509 the manually configured adjacencies rather than the auto-configuring 510 ones. 512 3.4.3. Dynamic Host Name TLV 514 IS-IS auto-configuration routers MAY advertise their Dynamic Host 515 Names TLV (TLV 137, [RFC5301]). The host names could be provisioned 516 by an IT system, or just use the name of vendor, device type or 517 serial number etc. Note that, the hostname needs to be unique so 518 that it could be useful. 520 3.5. Routing Behavior Considerations 522 3.5.1. Adjacency Formation 524 Since ISIS does not require strict hold timers matching to form 525 adjacency, this document does not specify specific hold timers. 526 However, the timers should be within a reasonable range based on 527 current practise in the industry. (For example, the defaults defined 528 in [ISO_IEC10589] .) 530 4. Security Considerations 532 In general, auto-configuration is mutually incompatible with 533 authentication. This is a common problem that IS-IS auto- 534 configuration can not avoid. 536 For wired deployment, the wired line itself could be considered as an 537 implicit authentication that normally unwanted routers are not able 538 to connect to the wire line; for wireless deployment, the 539 authentication could be achieve at the lower wireless link layer. 541 Malicious router could modify the System ID field to keep causing 542 System ID duplication detection and resolution thus cause the routing 543 system oscillate. However, this is not a new attack vector as 544 without this document the consequences would be higher as other 545 routers would not try to adapt. 547 5. IANA Considerations 549 The Router-Fingerprint TLV type code needs an assignment by IANA. 551 6. Acknowledgements 553 This document was heavily inspired by [RFC7503]. 555 Martin Winter, Christian Franke and David Lamparter gave essential 556 feedback to improve the technical design based on their 557 implementation experience. 559 Many useful comments were made by Acee Lindem, Karsten Thomannby, 560 Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and 561 Nan Wu, etc. 563 This document was produced using the xml2rfc tool [RFC2629]. 564 (initially prepared using 2-Word-v2.0.template.dot. ) 566 7. References 568 7.1. Normative References 570 [ISO_IEC10589] 571 ""Intermediate System to Intermediate System intra-domain 572 routeing information exchange protocol for use in 573 conjunction with the protocol for providing the 574 connectionless-mode network service (ISO 8473)", ISO/IEC 575 10589", November 2002. 577 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 578 dual environments", RFC 1195, DOI 10.17487/RFC1195, 579 December 1990, . 581 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 582 DOI 10.17487/RFC2629, June 1999, 583 . 585 [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange 586 Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, 587 October 2008, . 589 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 590 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 591 2008, . 593 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 594 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 595 2008, . 597 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 598 DOI 10.17487/RFC5308, October 2008, 599 . 601 [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge 602 Originator Identification TLV for IS-IS", RFC 6232, 603 DOI 10.17487/RFC6232, May 2011, 604 . 606 7.2. Informative References 608 [I-D.ietf-homenet-hncp] 609 Stenberg, M., Barth, S., and P. Pfister, "Home Networking 610 Control Protocol", draft-ietf-homenet-hncp-10 (work in 611 progress), November 2015. 613 [RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration", 614 RFC 7503, DOI 10.17487/RFC7503, April 2015, 615 . 617 Authors' Addresses 619 Bing Liu 620 Huawei Technologies 621 Q14, Huawei Campus, No.156 Beiqing Road 622 Hai-Dian District, Beijing, 100095 623 P.R. China 625 Email: leo.liubing@huawei.com 627 Bruno Decraene 628 Orange 629 38 rue du General Leclerc 630 Issy-les-Moulineaux FR 631 FR 633 Email: bruno.decraene@orange.com 635 Ian Farrer 636 Deutsche Telekom AG 637 Bonn 638 Germany 640 Email: ian.farrer@telekom.de 642 Mikael Abrahamsson 643 T-Systems 644 Stockholm 645 Sweden 647 Email: mikael.abrahamsson@t-systems.se 649 Les Ginsberg 650 Cisco Systems 651 510 McCarthy Blvd. 652 Milpitas CA 95035 653 USA 655 Email: ginsberg@cisco.com