draft-ietf-isis-auto-conf-01.txt   draft-ietf-isis-auto-conf-02.txt 
isis B. Liu, Ed. isis B. Liu, Ed.
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Standards Track B. Decraene Intended status: Standards Track B. Decraene
Expires: December 3, 2016 Orange Expires: January 21, 2017 Orange
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
M. Abrahamsson M. Abrahamsson
T-Systems T-Systems
L. Ginsberg L. Ginsberg
Cisco Systems Cisco Systems
June 1, 2016 July 20, 2016
ISIS Auto-Configuration ISIS Auto-Configuration
draft-ietf-isis-auto-conf-01 draft-ietf-isis-auto-conf-02
Abstract Abstract
This document specifies an IS-IS auto-configuration technology. The This document specifies IS-IS auto-configuration mechanisms. The key
key mechanisms of this technology are IS-IS System ID self- components are IS-IS System ID self-generation, duplication detection
generation, duplication detection and duplication resolution. This and duplication resolution. These mechanisms provide limited IS-IS
technology fits the environment where plug-and-play is expected. functions, thus they are fit for the networks where plug-and-play
configuration is expected.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 3, 2016. This Internet-Draft will expire on January 21, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3
3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3 3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3
3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 3 3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 3
3.3. IS-IS System ID Duplication Detection and Resolution . . 4 3.3. IS-IS System ID Duplication Detection and Resolution . . 4
3.3.1. Router-Fingerprint TLV . . . . . . . . . . . . . . . 4 3.3.1. Router-Fingerprint TLV . . . . . . . . . . . . . . . 4
3.3.2. System ID Duplication Detection and Resolution 3.3.2. Duplicate System ID Detection and Resolution
Procedures . . . . . . . . . . . . . . . . . . . . . 5 Procedures . . . . . . . . . . . . . . . . . . . . . 5
3.3.3. System ID and Router-Fingerprint Generation 3.3.3. System ID and Router-Fingerprint Generation
Considerations . . . . . . . . . . . . . . . . . . . 9 Considerations . . . . . . . . . . . . . . . . . . . 10
3.3.4. Double-Duplication of both System ID and Router- 3.3.4. Double-Duplication of both System ID and Router-
Fingerprint . . . . . . . . . . . . . . . . . . . . . 10 Fingerprint . . . . . . . . . . . . . . . . . . . . . 11
3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 11 3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 11
3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 11 3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 11
3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 11 3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 11
3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 11 3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 12
3.5. Routing Behavior Considerations . . . . . . . . . . . . . 12 3.5. Routing Behavior Considerations . . . . . . . . . . . . . 12
3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 12 3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document describes mechanisms for IS-IS [RFC1195] This document specifies mechanisms for IS-IS [RFC1195]
[ISO_IEC10589][RFC5308] to be auto-configuring. Such mechanisms [ISO_IEC10589][RFC5308] to be auto-configuring. Such mechanisms
could reduce the management burden to configure a network. Home could reduce the management burden for configuring a network,
networks and small or medium size enterprise networks where plug-and- especially where plug-and-play device configuration is required.
play is expected can benefit from these mechanisms.
This document also defines mechanisms which prevent unintentional IS-IS auto-configuration is comprised of the following functions:
interoperation of autoconfigured routers with non-autoconfigured
routers. See Section 3.3.1 .
IS-IS auto-configuration contains the following aspects: 1. IS-IS default configurations.
1. IS-IS default configurations 2. IS-IS System ID self-generation.
2. IS-IS System ID self-generation 3. System ID duplication detection and resolution.
3. System ID duplication detection and resolution 4. ISIS TLV utilization (Authentication TLV, Wide Metric TLV, and
Dynamic Host Name TLV).
4. ISIS TLVs utilization such as Authentication TLV, Wide Metric TLV This document also defines mechanisms to prevent the unintentional
etc. interoperation of auto-configured routers with non-autoconfigured
routers. See Section 3.3.1.
2. Scope 2. Scope
The auto-configuring mechanisms support both IPv4 and IPv6 The auto-configuring mechanisms support both IPv4 and IPv6
deployments. deployments.
This auto-configuration mechanism aims at simple case. The following These auto-configuration mechanisms aim to cover simple deployment
advanced features are out of scope: cases. The following important features are not supported:
o Multiple IS-IS instances o Multiple IS-IS instances.
o Multi-area and level-2 routing o Multi-area and level-2 routing.
o Interworking with other routing protocols o Interworking with other routing protocols.
3. Protocol Specification 3. Protocol Specification
3.1. IS-IS Default Configuration 3.1. IS-IS Default Configuration
o IS-IS interfaces MUST be auto-configured to an interface type o IS-IS interfaces MUST be auto-configured to an interface type
corresponding to their layer-2 capability. For example, Ethernet corresponding to their layer-2 capability. For example, Ethernet
interfaces will be auto-configured as broadcast networks and interfaces will be auto-configured as broadcast networks and
Point-to-Point Protocol (PPP) interfaces will be auto-configured Point-to-Point Protocol (PPP) interfaces will be auto-configured
as Point-to-Point interfaces. as Point-to-Point interfaces.
o IS-IS auto-configuration instance MUST be configured with level-1, o IS-IS auto-configuration instance MUST be configured as level-1,
so that the interfaces operate at level-1 only. so that the interfaces operate as level-1 only.
o IS-IS auto-configuration SHOULD allow P2P mode on Ethernet
interfaces.
3.2. IS-IS NET Generation 3.2. IS-IS NET Generation
In IS-IS, a router (known as an Intermediate System) is identified by In IS-IS, a router (known as an Intermediate System) is identified by
an NET which is the address of a Network Service Access Point (NSAP) a NET which is the address of a Network Service Access Point (NSAP)
and represented with an IS-IS specific address format. The NSAP is a and represented with an IS-IS specific address format. The NSAP is a
logical entity which represents an instance of the IS-IS protocol logical entity which represents an instance of the IS-IS protocol
running on an Intermediate System. running on an Intermediate System.
The autoconfiguration mechanism generates the IS-IS NET as the The auto-configuration mechanism generates the IS-IS NET as the
following: following:
o Area address o Area address
This field is 1 to 13 octets in length. In IS-IS auto- In IS-IS auto-configuration, this field MUST be 13 octets long
configuration, this field MUST be 13 octets of all 0. and set to all 0.
o System ID o System ID
This field follows the area address field, and is 6 octets in This field follows the area address field, and is 6 octets in
length. There are two basic requirements for the System ID length. There are two basic requirements for the System ID
generation: generation:
- As specified in IS-IS protocol, this field must be unique - As specified by the IS-IS protocol, this field must be
among all routers in the same area. unique among all routers in the same area.
- In order to make the routing system stable, the System ID - After its initial generation, the System ID SHOULD remain
SHOULD remain the same after it is firstly generated. It stable to improve the stability of the routing system. It
SHOULD not be changed due to device status change (such as SHOULD not be changed due to device status change (such as
interface enable/disable, interface plug in/off, device interface enable/disable, interface connect/disconnect,
reboot, firmware update etc.) or configuration change (such device reboot, firmware update etc.) or configuration change
as changing system configurations or IS-IS configurations (such as changing system configuration or IS-IS
etc.); but it MUST allow be changed by collision resolution configuration); but MUST support change as part of the
and SHOULD allow be cleared by user enforced system reset. System ID collision resolution process and SHOULD allow
being cleared by a user initiated system reset.
More specific considerations for System ID generation are More specific considerations for System ID generation are
described in Section 3.3.3 . described in Section 3.3.3 .
3.3. IS-IS System ID Duplication Detection and Resolution 3.3. IS-IS System ID Duplication Detection and Resolution
The System ID of each node MUST be unique. As described in The System ID of each node MUST be unique. As described in
Section 3.3.3, the System ID is generated based on entropies such as Section 3.3.3, the System ID is generated based on entropies (e.g.
MAC address which are supposed to be unique, but in theory there is MAC address) which are generally expected to be unique. However,
still possibility of duplication. This section defines how IS-IS since there may be limitations to the available entropies, there is
detects and resolves System ID duplication. still the possibility of System ID duplication. This section defines
how IS-IS detects and resolves System ID duplication.
3.3.1. Router-Fingerprint TLV 3.3.1. Router-Fingerprint TLV
The Router-Fingerprint TLV basically re-uses the design of Router- The Router-Fingerprint TLV essentially re-uses the design of Router-
Hardware-Fingerprint TLV defined in [RFC7503]. However, there is one Hardware-Fingerprint TLV defined in [RFC7503]. However, there is one
difference that one flag is added to indicate the node is in "start- difference in that a flag is added to indicate that the node is in
up mode" which is defined in Section 3.3.2 . "start-up mode", which is defined in Section 3.3.2.
0 1 2 3 0 1 2 3
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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|S|A| Reserved | | |S|A| Reserved | |
+-+-+-+-+-+-+-+-+ Router Fingerprint (Variable) . +-+-+-+-+-+-+-+-+ Router Fingerprint (Variable) .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the Router-Fingerprint is variable but must be 32 Router Fingerprint TLV Format
octets or greater; and the content is also supposed to be unique
among all the routers. The length of the Router-Fingerprint is variable but MUST be 32
octets or greater. For correct operation, the Router-Fingerprint
MUST be unique among all the routers participating in the IS-IS area.
o Type: to be assigned by IANA. o Type: to be assigned by IANA.
o Length: the length of the value field. o Length: the length of the value field. As the Router Fingerprint
length is variable, the field length is also variable.
o S flag: indicates the router is in "start-up" mode as described o S flag: when set, indicates the router is in "start-up" mode.
below.
o A flag: indicates the router is operating in autoconfiguration o A flag: when set, indicates that the router is operating in auto-
mode. This flag is in case the TLV gets used outside of configuration mode. The purpose of the flag is so that two
autoconfiguration. If A flag setting does not match in hellos routers can identify if they are both using auto-configuration.
then no adjacency should be formed. If the A flag setting does not match in hellos then no adjacency
should be formed.
o Reserved: these bits MUST be set to zero and MUST be ignored when o Reserved: these bits MUST be set to zero and MUST be ignored by
received. the receiver.
o Router Fingerprint: uniquely identifies a router, variable length. o Router Fingerprint: uniquely identifies a router, variable length.
More specific considerations for Router-Fingerprint is described in More specific considerations for Router-Fingerprint are described in
Section 3.3.3 . Section 3.3.3 .
3.3.2. System ID Duplication Detection and Resolution Procedures 3.3.2. Duplicate System ID Detection and Resolution Procedures
This section describes the System ID duplication detection and This section describes the duplicate System ID detection and
resolution between two neighbors and two non-neighbors respectively. resolution process between two neighbors and two non-neighbors
This is because the routing messages between neighbors and non- respectively. This is due to difference in the the routing messages
neighbors are a bit different. between neighbors and non-neighbors.
3.3.2.1. Start-up Mode 3.3.2.1. Start-up Mode
While in startup-mode, an auto-configuration router forms adjacencies While in Start-up Mode, an auto-configuration router forms
but generates only LSP #0 which contains only the Router-Fingerprint adjacencies but generates only LSP #0 which contains only the Router-
TLV. A router remains in startup-mode until it has successfully Fingerprint TLV. A router remains in startup-mode until it has
completed LSPDB synchronization with all neighbors or until 1 minute successfully completed LSPDB synchronization with all neighbors or
has elapsed - whichever is longer. If duplicate system-ID is until 1 minute has elapsed - whichever is longer. If a duplicate
detected while in startup-mode the router MUST clear all adjacencies, System ID is detected while in Start-up Mode stage, the Start-up Mode
select a new system-id (subject to rules defined in Section 3.3.2.2 router MUST clear all adjacencies, select a new System ID (subject to
), and reenter Startup-mode. rules defined in Section 3.3.2.2 ), and re-enter Start-up Mode.
The start-up mode is to minimize the occurrence of System ID changes The purpose of the Start-up Mode is to minimize the occurrence of
for a router once it has become fully operational. It has minimal System ID changes for a router once it has become fully operational.
impact on a running network because the startup node is not yet being It has minimal impact on a running network because the Start-up Mode
used for forwarding traffic. Once duplicate System ID has been node is not yet being used for forwarding traffic. Once duplicate
resolved the router begins normal operation. If two routers are both System IDs have been resolved the router begins normal operation. If
in startup mode (or both NOT in startup mode) and duplicate system-id two routers are both in Start-up Mode and duplicate System ID is
is detected then they determine which one changes its system-id based detected, they follow the duplication resolution as specified in
on fingerprint. Section 3.3.2.2 and Section 3.3.2.3.
When an IS-IS auto-configuration router boots up, it MUST operate in When an IS-IS auto-configuration router boots up, it MUST operate in
start-up mode until duplicate system-id detection has successfully Startup-Mode until duplicate System ID detection has successfully
completed. completed.
3.3.2.2. Duplication Between Neighbors 3.3.2.2. Duplication Between Neighbors
In case of System ID duplication occurs between neighbors, an IS-IS In the case of duplicate System IDs being detected between neighbors,
auto-configuration router MUST include the Router-Fingerprint TLV in an IS-IS auto-configuration router MUST include the Router-
the Hello messages, so that the duplication could be detected before Fingerprint TLV in the Hello messages, so that the duplication can be
adjacency forming. detected before an adjacency is formed.
Procedures of the nodes in Start-up Mode: Start-up Mode procedures:
1. Boot up, advertise the Router-Fingerprint TLV in Hello message 1. Boot up and advertisement of the Router-Fingerprint TLV in Hello
messages
The router sends Hellos which include the Router-Fingerprint The router sends Hello messages which include the Router-
TLV. Adjacencies are formed as normal but MUST NOT be Fingerprint TLV. Adjacencies are formed as normal but MUST
advertised in LSPs until the router exits startup-mode. NOT be advertised in LSPs until the router exits Start-up
Mode.
2. Receive Hello message(s), and verifies System ID duplication 2. Receiving Hello message(s), and System ID duplication detection
Received hellos are inspected for possible duplicate System Received Hello messages are inspected for a possible duplicate
ID. If duplication is detected, the router MUST check the S System ID. If a duplicate is detected, the router MUST check
flag of the Router-Fingerprint TLV. the S flag of the Router-Fingerprint TLV.
+ If the S flag is NOT set (which means the Hello was NOT + If the S flag is NOT set (which means the Hello message was
generated by a neighbor also in Start-up mode), then the NOT generated by a Start-up Mode neighbor), then the router
router MUST re-generate the System ID and reenter Startup- MUST re-generate the System ID and re-enter Start-up Mode.
mode.
+ If the S flag is set (which means the neighbor is also in + If the S flag is set (meaning the neighbor is also in
Startup-mode), Start-up Mode),
- the router which has a numerically smaller Router-
Fingerprint MUST re-generate the System ID and reenter
Startup-mode. Fingerprint comparison is performed octet
by octet until octets are different. Then the smaller
fingerprint is the one with the smaller octet (unsigned
integer). If the fingerprints have different lengths,
then the shorter length fingerprint MUST be padding with
zero for comparison.
- If Router Fingerprints are identical, both routers MUST - The router which has a numerically smaller Router-
re-generate the System ID and the Router Fingerprint, Fingerprint MUST re-generate its System ID and re-enter
and reenter Startup-mode. Start-up Mode. Fingerprint comparison MUST be performed
octet by octet starts from the left until a difference
is found. Then, the numeric smaller fingerprint is the
one with the lowest value. If the fingerprints have
different lengths, then the shorter length fingerprint
MUST be padding with zero at the left side for
comparison.
3. Run in normal operation - If the Router Fingerprints are identical, both routers
MUST re-generate the System ID and the Router
Fingerprint, and re-enter Start-up Mode.
After the System ID duplication procedure is done, the router 3. Normal operation
begins to run in normal operation. The router MUST re-
advertise the Router-Fingerprint TLV with the S flag off.
Procedures of the nodes NOT in Start-up Mode: After the System ID duplication procedure is successfully
completed, the router begins normal operation. The router
MUST re-advertise the Router-Fingerprint TLV with the S flag
disabled.
Non Start-up Mode procedures:
1. Compare the System ID in received Hello messages 1. Compare the System ID in received Hello messages
When receiving a Hello message, the router MUST check the When receiving a Hello message, the router MUST check the
System ID of the Hello. If the System ID is the same as its System ID of the Hello. If the System ID is the same as its
own, it indicates a System ID duplication occurs. own, it indicates that System ID duplication has occurred.
If there is no Router-Fingerprint TLV in the Hello message, it If there is no Router-Fingerprint TLV in the received Hello
means a non-autoconfiguration router by accident connected to message, this is interpreted as the attached router either
the auto-configuration domain or other unexpected bad does not support auto-configuration, or does not have it
behaviors. In this case, the auto-configuration router MUST enabled. In this case, the auto-configuration router MUST NOT
NOT form adjacency with the non-autoconfiguration router. form adjacency with the non-autoconfiguration router.
2. Duplication resolution 2. Duplication resolution
When System ID duplication occurs, the non-startup mode router When duplicate System IDs are detected, the non-startup mode
MUST check the S flag of the duplicated Router-Fingerprint router MUST check the S flag of the duplicated Router-
TLV: Fingerprint TLV:
+ If the S flag is NOT set, then the router with the + If the S flag is NOT set, then the router with the
numerically smaller or equal Router-Fingerprint MUST numerically smaller or equal Router-Fingerprint MUST
generate a new System ID. Note that, the router MUST generate a new System ID. Note that, the router MUST
compare the two Router-Fingerprint in terms of two numeric compare the two Router-Fingerprint octet by octet until
numbers. difference is found.
+ If the S flag is set, then router does nothing, because it + If the S flag is set, no further action is necessary in the
MUST be the node which is in start-up mode re-generates the Duplication resolution process.
System ID.
3. Re-join the network with the new System ID (if required) 3. Re-joining the network with a new System ID (if required)
The router with the smaller Router-Fingerprint advertise new The router that has changed its System ID advertises new
Hellos based on the newly generated NET to re-join the IS-IS Hellos containing the newly generated System ID to re-join the
auto-configuration network. The router with the highest IS-IS auto-configuration network. The conflicting SysID-
Router-Fingerprint MUST re-advertise its own LSP (after duplicated router also MUST increase the sequence number and
increasing the sequence number). re-advertise its own Hellos.
The newly generated System ID SHOULD take a duplication The Duplication Detection process SHOULD be repeated with the
detection as well. newly generated System.
3.3.2.3. Duplication Between Non-neighbors 3.3.2.3. Duplication Between Non-neighbors
System ID duplication may also occur between non-neighbors, so an IS- System ID duplication may also occur between non-neighbors, therefore
IS auto-configuration router MUST also include the Router-Fingerprint an IS-IS auto-configuration router MUST also include the Router-
TLV in the LSP messages. Specific procedures are as the following. Fingerprint TLV in its LSP messages. The specific procedures are as
follows:
Procedures of the nodes in Start-up Mode: Start-up Mode procedures:
1. Boot up, form adjacency 1. Boot up, adjacency formation
2. Acquire LSPDB and verifies System ID duplication 2. Acquiring LSPDB and checking System ID duplication
The router generates only LSP #0 which contains only the The router generates only an LSP #0 which contains only the
Fingerprint TLV; and that Fingerprint is only sent in LSP #0. Fingerprint TLV; and that Fingerprint is only sent in LSP #0.
A router remains in startup-mode until it has successfully A router remains in Start-up Mode until it has successfully
completed LSPDB synchronization with all neighbors or until 1 completed LSPDB synchronization with all neighbors or until 1
minute has elapsed - whichever is longer. If duplicate minute has elapsed - whichever is longer. If duplicate
system-ID is detected, the router MUST check the S flag of the system-ID is detected, the router MUST check the S flag of the
Router-Fingerprint TLV of the LSP that contains the duplicated Router-Fingerprint TLV of the LSP that contains the duplicated
System ID. System ID.
+ If the S flag is not set, it means the LSP was not + If the S flag is not set, it means the LSP was generated by
generated at the Start-up Mode, then the router itself MUST a Non Start-up Mode node, then the router itself MUST clear
clear all adjacencies, re-generate a new system-id and all adjacencies, re-generate a new system-id and reenter
reenter Startup-mode. Start-up Mode.
+ If the S flag is set, then the router which has a + If the S flag is set, then the router which has a
numerically smaller Router-Fingerprint MUST generate a new numerically smaller Router-Fingerprint MUST generate a new
System ID and reenter Startup-mode. System ID and reenter Start-up Mode.
3. Run in normal operation 3. Running in normal operation
After the System ID duplication procedure is done, the router After the System ID duplication procedure is done, the router
begins to run in normal operation. The router MUST re- begins to run in normal operation. The router MUST re-
advertise the Router-Fingerprint TLV with the S flag off. advertise the Router-Fingerprint TLV with the S flag off.
Procedures of the nodes not in Start-up Mode: Non Start-up Mode procedures:
1. Compare the received Router-Fingerprint TLVs 1. Checking the received Router-Fingerprint TLVs
When receiving a LSP containing its own System ID, the router When receiving a LSP containing its own System ID, the router
MUST check the Router-Fingerprint TLV. If the Router- MUST check the Router-Fingerprint TLV. If the Router-
Fingerprint TLV is different from its own, it indicates a Fingerprint TLV is different from its own, it indicates a
System ID duplication occurs. System ID duplication occurs.
2. Duplication resolution 2. Duplication resolution
When System ID duplication occurs, the non-startup mode router When System ID duplication occurs, the non-startup mode router
MUST check the S flag of the duplicated Router-Fingerprint MUST check the S flag of the duplicated Router-Fingerprint
TLV: TLV:
+ If the S flag is NOT set, then the router with the + If the S flag is NOT set, then the router with the
numerically smaller Router-Fingerprint MUST generate a new numerically smaller Router-Fingerprint MUST generate a new
System ID. Note that, the router MUST compare the two System ID. Note that, the router MUST compare the two
Router-Fingerprint in terms of two numeric numbers. Router-Fingerprint octet by octet until difference is
found.
+ If the S flag is set, then router does nothing, because + If the S flag is set, then router does nothing.
according to the start-up mode procedure, the start-up node
MUST re-generate the System ID.
3. Re-join the network with the new System ID 3. Re-joining the network with the new System ID
The router changing its system ID advertise new LSPs based on The router changing its System ID advertises new LSPs based on
the newly generated System ID to re-join the IS-IS auto- the newly generated System ID to re-join the IS-IS auto-
configuration network. The router with the highest Router- configuration network. The other SysID-duplicated router also
Fingerprint MUST re-advertise its own LSP (after increasing MUST re-advertise its own LSP (after increasing the sequence
the sequence number). number).
The newly generated System SHOULD take a duplication detection The newly generated System ID SHOULD perform duplication
as well. detection as well.
3.3.3. System ID and Router-Fingerprint Generation Considerations 3.3.3. System ID and Router-Fingerprint Generation Considerations
As specified in this document, there are two distinguisher need to be As specified in this document, there are two distinguishing items
self-generated, which is System ID and Router-Fingerprint. In a that need to be self-generated: the System ID and Router-Fingerprint.
network device, normally there are resources which provide an In a network device, normally there are some resources which can
extremely high probability of uniqueness thus could be used as seeds provide an extremely high probability of uniqueness thus could be
to derive distinguisher (e.g. hashing or generating pseudo-random used as seeds to derive distinguisher (e.g. hashing or generating
numbers), such as: pseudo-random numbers), such as:
o MAC address(es) o MAC address(es)
o Configured IP address(es) o Configured IP address(es)
o Hardware IDs (e.g. CPU ID) o Hardware IDs (e.g. CPU ID)
o Device serial number(s) o Device serial number(s)
o System clock at a certain specific time o System clock at a certain specific time
o Arbitrary received packet o Arbitrary received packet(s) on an interface(s)
This document recommends to use an IEEE 802 48-bit MAC address This document recommends the use of an IEEE 802 48-bit MAC address
associated with the router as the initial System ID. This document associated with the router as the initial System ID. This document
does not specify a specific method to re-generate the System ID when does not specify a specific method to re-generate the System ID when
duplication happens. duplication happens.
This document also does not specify a specific method to generate the This document also does not specify a specific method to generate the
Router-Fingerprint. However, the generation of System ID and Router- Router-Fingerprint. However, the generation of System ID and Router-
Fingerprint MUST be based on different seeds so that the two Fingerprint MUST be based on different seeds so that the two
distinguisher would not collide. distinguisher would not collide.
There is an important concern that the seeds listed above (except MAC There is an important concern that the seeds listed above (except MAC
address) might not be available in some small devices such as home address) might not be available in some small devices such as home
routers. This is because of the hardware/software limitation and the routers. This is because of hardware/software limitations and the
lack of sufficient communication packets at the initial stage in the lack of sufficient communication packets at the initial stage in home
home routers when doing ISIS-autoconfiguration. In this case, this routers when doing ISIS auto-configuration. In this case, this
document suggests to use MAC address as System ID and generate a document suggests using the MAC address as System ID and generating a
pseudo-random number based on another seed (such as the memory pseudo-random number based on another seed (such as the memory
address of a certain variable in the program) as Router-Fingerprint. address of a certain variable in the program) as the Router-
The pseudo-random number might not have a very high quality in this Fingerprint. The pseudo-random number might not have a very high
solution, but should be sufficient in home networks scenarios. probability of uniqueness in this solution, but should be sufficient
in home networks scenarios.
Note that, the Router-Fingerprint SHOULD also remain the same after The considerations surrounding System ID stability described in
it is firstly generated. It SHOULD not be changed due to device section Section 3.2 also need to be applied.
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.
3.3.4. Double-Duplication of both System ID and Router-Fingerprint 3.3.4. Double-Duplication of both System ID and Router-Fingerprint
As described above, the resources for generating the distinguisher As described above, the resources for generating the distinguisher
might be very constrained at the initial stage. Hence, the double- might be very constrained during the initial stages. Hence, the
duplication of both System ID and Router-Fingerprint needs to be double-duplication of both System ID and Router-Fingerprint needs to
considered. be considered.
ISIS-autoconfiguring routers SHOULD support detecting System ID ISIS-autoconfiguring routers SHOULD support detecting System ID
duplication by LSP war. LSP war is a phenomenon that if a router duplication by LSP war. LSP war is a phenomenon whereby a router
receives a LSP originated with its System ID, but it doesn't find it receives a LSP originated with its System ID, but it doesn't find it
in the database, or it does not match the one the router has (e.g. in the database, or it does not match the one the router has (e.g.
It advertises IP prefixes that the router doesn't own, or IS it advertises IP prefixes that the router does not own, or IS
neighbors that the router doesn't see), then per ISIS specification, neighbors that the router does not see), then per the ISIS
the router must re-originate its LSP with an increased sequence specification, the router must re-originate its LSP with an increased
number. If double-duplication happens, the duplicated two routers sequence number. If double-duplication happens, the duplicated two
will both continuously have the above behavior. After multiples routers will both continuously repeat the above behavior. After
iterations, the program should be able to deduce that double- multiples iterations, the program should be able to deduce that
duplication happens. double-duplication is occurring.
At the point when double-duplication happens, routers should have When this condition is detected, routers should have much more
much more entropies available. Thus, the router is to extend or re- entropies available. Thus, the router is able to extend or re-
generate its Router-Fingerprint (one simple way is just adding the generate its Router-Fingerprint (one simple way is just adding the
LSP sequence number of the next LSP it will send to the Router- LSP sequence number of the next LSP it will send to the Router-
Fingerprint). (Optimized solution TBD.) Fingerprint).
3.4. IS-IS TLVs Usage 3.4. IS-IS TLVs Usage
This section describes several TLVs that are utilized by IS-IS auto- This section describes the TLVs that are necessary for IS-IS auto-
configuration. configuration.
3.4.1. Authentication TLV 3.4.1. Authentication TLV
It is RECOMMENDED that IS-IS routers supporting this specification It is RECOMMENDED that IS-IS routers supporting this specification
minimally offer an option to explicitly configure a single password minimally offer an option to explicitly configure a single password
for HMAC-MD5 authentication, which is Type 54 authentication mode of for HMAC-MD5 authentication, which is Type 54 authentication mode of
[RFC5304]. In this case, the Authentication TLV (TLV 10) is needed. [RFC5304]. In this case, the Authentication TLV (TLV 10) is needed.
3.4.2. Wide Metric TLV 3.4.2. Wide Metric TLV
IS-IS auto-configuration routers MUST support TLVs using wide metric IS-IS auto-configuration routers MUST support TLVs using wide metrics
as defined in [RFC5305]). as defined in [RFC5305]).
It is recommended that IS-IS auto-configuration routers use a high It is RECOMMENDED that IS-IS auto-configuration routers use a high
metric value (e.g. 1000000) as default in order to typically prefer metric value (e.g. 1000000) as default in order to typically prefer
the manually configured adjacencies rather than the auto-configuring manually configured adjacencies over auto-configuringed.
ones.
3.4.3. Dynamic Host Name TLV 3.4.3. Dynamic Host Name TLV
IS-IS auto-configuration routers MAY advertise their Dynamic Host IS-IS auto-configuration routers MAY advertise their Dynamic Host
Names TLV (TLV 137, [RFC5301]). The host names could be provisioned Names TLV (TLV 137, [RFC5301]). The host names could be provisioned
by an IT system, or just use the name of vendor, device type or by an IT system, or just use the name of vendor, device type or
serial number etc. Note that, the hostname needs to be unique so serial number, etc.
that it could be useful.
To guarantee the uniqueness of the host names, the System ID SHOULD
be appended as a suffix in the names.
3.5. Routing Behavior Considerations 3.5. Routing Behavior Considerations
3.5.1. Adjacency Formation 3.5.1. Adjacency Formation
Since ISIS does not require strict hold timers matching to form Since IS-IS does not require strict hold timer matching to form
adjacency, this document does not specify specific hold timers. adjacency, this document does not specify specific hold timers.
However, the timers should be within a reasonable range based on However, the timers should be within a reasonable range based on
current practise in the industry. (For example, the defaults defined current practise in the industry. (For example, the defaults defined
in [ISO_IEC10589] .) in [ISO_IEC10589] .)
4. Security Considerations 4. Security Considerations
In general, auto-configuration is mutually incompatible with In general, auto-configuration is mutually incompatible with
authentication. This is a common problem that IS-IS auto- authentication. This is a common problem that IS-IS auto-
configuration can not avoid. configuration can not avoid.
For wired deployment, the wired line itself could be considered as an For wired deployment, the wired connection itself could be considered
implicit authentication that normally unwanted routers are not able as an implicit authentication in that unwanted routers are usually
to connect to the wire line; for wireless deployment, the not able to connect (i.e. there is some kind of physical security in
authentication could be achieve at the lower wireless link layer. place preventing the connection of rogue devices); for wireless
deployment, the authentication could be achieved at the lower
wireless link layer.
Malicious router could modify the System ID field to keep causing A malicious router could modify the System ID field to keep causing
System ID duplication detection and resolution thus cause the routing System ID duplication detection and resolution thus cause the routing
system oscillate. However, this is not a new attack vector as system to oscillate. However, this is not a new attack vector as
without this document the consequences would be higher as other without this document the consequences would be higher as other
routers would not try to adapt. routers would not have a mechanism to try and resolve this case.
5. IANA Considerations 5. IANA Considerations
The Router-Fingerprint TLV type code needs an assignment by IANA. IANA is kindly requested to assign a new TLV for the Router-
Fingerprint from the IS-IS TLV Codepoint registry.
6. Acknowledgements 6. Acknowledgements
This document was heavily inspired by [RFC7503]. This document was heavily inspired by [RFC7503].
Martin Winter, Christian Franke and David Lamparter gave essential Martin Winter, Christian Franke and David Lamparter gave essential
feedback to improve the technical design based on their feedback to improve the technical design based on their
implementation experience. implementation experience.
Many useful comments were made by Acee Lindem, Karsten Thomannby, Many useful comments were made by Acee Lindem, Karsten Thomann,
Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and
Nan Wu, etc. Nan Wu, etc.
This document was produced using the xml2rfc tool [RFC2629]. This document was produced using the xml2rfc tool [RFC2629].
(initially prepared using 2-Word-v2.0.template.dot. ) (initially prepared using 2-Word-v2.0.template.dot. )
7. References 7. References
7.1. Normative References 7.1. Normative References
skipping to change at page 13, line 47 skipping to change at page 14, line 16
DOI 10.17487/RFC5308, October 2008, DOI 10.17487/RFC5308, October 2008,
<http://www.rfc-editor.org/info/rfc5308>. <http://www.rfc-editor.org/info/rfc5308>.
[RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge [RFC6232] Wei, F., Qin, Y., Li, Z., Li, T., and J. Dong, "Purge
Originator Identification TLV for IS-IS", RFC 6232, Originator Identification TLV for IS-IS", RFC 6232,
DOI 10.17487/RFC6232, May 2011, DOI 10.17487/RFC6232, May 2011,
<http://www.rfc-editor.org/info/rfc6232>. <http://www.rfc-editor.org/info/rfc6232>.
7.2. Informative References 7.2. Informative References
[I-D.ietf-homenet-hncp]
Stenberg, M., Barth, S., and P. Pfister, "Home Networking
Control Protocol", draft-ietf-homenet-hncp-10 (work in
progress), November 2015.
[RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration", [RFC7503] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration",
RFC 7503, DOI 10.17487/RFC7503, April 2015, RFC 7503, DOI 10.17487/RFC7503, April 2015,
<http://www.rfc-editor.org/info/rfc7503>. <http://www.rfc-editor.org/info/rfc7503>.
Authors' Addresses Authors' Addresses
Bing Liu Bing Liu
Huawei Technologies Huawei Technologies
Q14, Huawei Campus, No.156 Beiqing Road Q10, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095 Hai-Dian District, Beijing, 100095
P.R. China P.R. China
Email: leo.liubing@huawei.com Email: leo.liubing@huawei.com
Bruno Decraene Bruno Decraene
Orange Orange
38 rue du General Leclerc France
Issy-les-Moulineaux FR
FR
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Ian Farrer Ian Farrer
Deutsche Telekom AG Deutsche Telekom AG
Bonn Bonn
Germany Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
 End of changes. 109 change blocks. 
241 lines changed or deleted 239 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/