draft-ietf-isis-auto-conf-03.txt   draft-ietf-isis-auto-conf-04.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: May 4, 2017 Orange Expires: May 26, 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
October 31, 2016 November 22, 2016
ISIS Auto-Configuration ISIS Auto-Configuration
draft-ietf-isis-auto-conf-03 draft-ietf-isis-auto-conf-04
Abstract Abstract
This document specifies IS-IS auto-configuration mechanisms. The key This document specifies IS-IS auto-configuration mechanisms. The key
components are IS-IS System ID self-generation, duplication detection components are IS-IS System ID self-generation, duplication detection
and duplication resolution. These mechanisms provide limited IS-IS and duplication resolution. These mechanisms provide limited IS-IS
functions, and so are suitable for networks where plug-and-play functions, and so are suitable for networks where plug-and-play
configuration is expected. configuration is expected.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
[RFC2119] when they appear in ALL CAPS. When these words are not in
ALL CAPS (such as "should" or "Should"), they have their usual
English meanings, and are not to be interpreted as [RFC2119] key
words.
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 May 26, 2017.
This Internet-Draft will expire on May 4, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . . . . 4
3.3. IS-IS System ID Duplication Detection and Resolution . . 4 3.3. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . 5
3.3.1. Router-Fingerprint TLV . . . . . . . . . . . . . . . 4 3.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 6
3.3.2. Duplicate System ID Detection and Resolution 3.4.1. Start-Up mode . . . . . . . . . . . . . . . . . . . . 6
Procedures . . . . . . . . . . . . . . . . . . . . . 5 3.4.2. Adjacency Formation . . . . . . . . . . . . . . . . . 6
3.3.3. System ID and Router-Fingerprint Generation 3.4.3. IS-IS System ID Duplication Detection and Resolution 7
Considerations . . . . . . . . . . . . . . . . . . . 10 3.4.4. Duplicate System ID Resolution Procedures . . . . . . 7
3.3.4. Double-Duplication of both System ID and Router- 3.4.5. System ID and Router-Fingerprint Generation
Fingerprint . . . . . . . . . . . . . . . . . . . . . 11 Considerations . . . . . . . . . . . . . . . . . . . 8
3.4. IS-IS TLVs Usage . . . . . . . . . . . . . . . . . . . . 11 3.4.6. Double-Duplication of both System ID and Router-
3.4.1. Authentication TLV . . . . . . . . . . . . . . . . . 11 Fingerprint . . . . . . . . . . . . . . . . . . . . . 9
3.4.2. Wide Metric TLV . . . . . . . . . . . . . . . . . . . 11 3.5. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . 10
3.4.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 12 3.5.1. Authentication TLV . . . . . . . . . . . . . . . . . 10
3.5. Routing Behavior Considerations . . . . . . . . . . . . . 12 3.5.2. Metric Used in Reachability TLVs . . . . . . . . . . 11
3.5.1. Adjacency Formation . . . . . . . . . . . . . . . . . 12 3.5.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 11
4. Security Considerations . . . . . . . . . . . . . . . . . . . 12 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 13 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 14 7.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document specifies 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 for configuring a network, could reduce the management burden for configuring a network,
especially where plug-and-play device configuration is required. especially where plug-and-play device configuration is required.
IS-IS auto-configuration is comprised of the following functions: IS-IS auto-configuration is comprised of the following functions:
1. IS-IS default configurations. 1. IS-IS default configuration.
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 4. ISIS TLV utilization (Authentication TLV, metrics in reachability
Dynamic Host Name TLV). advertisements, and Dynamic Host Name TLV).
This document also defines mechanisms to prevent the unintentional This document also defines mechanisms to prevent the unintentional
interoperation of auto-configured routers with non-autoconfigured interoperation of auto-configured routers with non-autoconfigured
routers. See Section 3.3.1. routers. See Section 3.3.
2. Scope 2. Scope
The auto-configuration mechanism supports both IPv4 and IPv6 The auto-configuration mechanisms support both IPv4 and IPv6
deployments. deployments.
These auto-configuration mechanisms aim to cover simple deployment These auto-configuration mechanisms aim to cover simple deployment
cases. The following important features are not supported: 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.
IS-IS auto-configuration is primarily intended for use in small (i.e. IS-IS auto-configuration is primarily intended for use in small (i.e.
10s of devices) and unmanaged deployments. Its allows IS-IS to be 10s of devices) and unmanaged deployments. It allows IS-IS to be
used as the IGP without the need for any configuration by the user. used without the need for any configuration by the user. It is not
It is not recommended for larger deployments. recommended for larger deployments.
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 as level-1, o IS-IS auto-configuration instances MUST be configured as level-1,
so that the interfaces operate as level-1 only. so that the interfaces operate as level-1 only.
o originatingLSPBufferSize is set to 512.
o MaxAreaAddresses is set to 3
o Extended IS Reachability and IP Reachability TLVs [RFC5305] MUST
be used i.e. a router operating in auto configuration mode MUST
NOT use any of the following TLVs:
* IS Neighbors (2)
* IP Internal Reachability (128)
* IP External Reachability (130)
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
a NET which is the address of a Network Service Access Point (NSAP) a Network Entity Title (NET) which is a type of Network Service
and represented with an IS-IS specific address format. The NSAP is a Access Point (NSAP). The NET is the address of an instance of the
logical entity which represents an instance of the IS-IS protocol IS-IS protocol running on an Intermediate System (IS).
running on an Intermediate System.
The auto-configuration 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
In IS-IS auto-configuration, this field MUST be 13 octets long In IS-IS auto-configuration, this field MUST be 13 octets long
and set to 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 by the IS-IS protocol, this field must be - As specified by the IS-IS protocol, this field must be
unique among all routers in the same area. unique among all routers in the same area.
- After its initial generation, the System ID SHOULD remain - After its initial generation, the System ID SHOULD remain
stable to improve the stability of the routing system. It stable. It SHOULD NOT be changed due to device status
SHOULD not be changed due to device status change (such as change (such as interface enable/disable, interface connect/
interface enable/disable, interface connect/disconnect, disconnect, device reboot, firmware update etc.) or
device reboot, firmware update etc.) or configuration change configuration change (such as changing system configuration
(such as changing system configuration or IS-IS or IS-IS configuration); but MUST support change as part of
configuration); but MUST support change as part of the the System ID collision resolution process and SHOULD allow
System ID collision resolution process and SHOULD allow
being cleared by a user initiated system reset. 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.4.5.
3.3. IS-IS System ID Duplication Detection and Resolution
The System ID of each node MUST be unique. As described in
Section 3.3.3, the System ID is generated based on entropies (e.g.
MAC address) which are generally expected to be unique. However,
since there may be limitations to the available entropies, there is
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. Router-Fingerprint TLV
The Router-Fingerprint TLV essentially re-uses the design of Router- The Router-Fingerprint TLV is similar to the Router-Hardware-
Hardware-Fingerprint TLV defined in [RFC7503]. However, there is one Fingerprint TLV defined in [RFC7503]. However, the TLV defined here
difference in that a flag is added to indicate that the node is in includes a flags field to support indicating that the router is in
"start-up mode", which is defined in Section 3.3.2. Start-up mode and is operating in auto-configuration mode.
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) .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router Fingerprint TLV Format Router Fingerprint TLV Format
The length of the Router-Fingerprint is variable but MUST be 32 The length of the Router-Fingerprint is variable but MUST be 32
octets or greater. For correct operation, the Router-Fingerprint octets or greater. For correct operation, the Router-Fingerprint
MUST be unique among all the routers participating in the IS-IS area. 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. As the Router Fingerprint o Length: the length of the value field. Must be >= 33.
length is variable, the field length is also variable.
o S flag: when set, indicates the router is in "start-up" mode. o Flags field (1 octet)
o A flag: when set, indicates that the router is operating in auto- S flag: when set, indicates the router is in "start-up" mode.
configuration mode. The purpose of the flag is so that two
routers can identify if they are both using auto-configuration.
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 by A flag: when set, indicates that the router is operating in
the receiver. auto-configuration mode. The purpose of the flag is so that
two routers can identify if they are both using auto-
configuration. If the A flag setting does not match in hellos
then no adjacency should be formed.
Reserved: these bits MUST be set to zero and MUST be ignored by
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 are described in More specific considerations for Router-Fingerprint are described in
Section 3.3.3 . Section 3.4.5.
3.3.2. Duplicate System ID Detection and Resolution Procedures
This section describes the duplicate System ID detection and
resolution process between two neighbors and two non-neighbors
respectively. This is due to difference in the the routing messages
between neighbors and non-neighbors.
3.3.2.1. Start-up Mode
While in Start-up Mode, an auto-configuration router forms
adjacencies but generates only LSP #0 which contains only the Router-
Fingerprint TLV. A router remains in startup-mode until it has
successfully completed LSPDB synchronization with all neighbors or
until 1 minute has elapsed - whichever is longer. If a duplicate
System ID is detected while in Start-up Mode stage, the Start-up Mode
router MUST clear all adjacencies, select a new System ID (subject to
rules defined in Section 3.3.2.2 ), and re-enter Start-up Mode.
The purpose of the Start-up Mode is to minimize the occurrence of
System ID changes for a router once it has become fully operational.
It has minimal impact on a running network because the Start-up Mode
node is not yet being used for forwarding traffic. Once duplicate
System IDs have been resolved the router begins normal operation. If
two routers are both in Start-up Mode and duplicate System ID is
detected, they follow the duplication resolution as specified in
Section 3.3.2.2 and Section 3.3.2.3.
When an IS-IS auto-configuration router boots up, it MUST operate in
Startup-Mode until duplicate System ID detection has successfully
completed.
3.3.2.2. Duplication Between Neighbors
In the case of duplicate System IDs being detected between neighbors,
an IS-IS auto-configuration router MUST include the Router-
Fingerprint TLV in the Hello messages, so that the duplication can be
detected before an adjacency is formed.
Start-up Mode procedures:
1. Boot up and advertisement of the Router-Fingerprint TLV in Hello
messages
The router sends Hello messages which include the Router-
Fingerprint TLV. Adjacencies are formed as normal but MUST
NOT be advertised in LSPs until the router exits Start-up
Mode.
2. Receiving Hello message(s), and System ID duplication detection
Received Hello messages are inspected for a possible duplicate
System ID. If a duplicate is detected, the router MUST check
the S flag of the Router-Fingerprint TLV.
+ If the S flag is NOT set (which means the Hello message was
NOT generated by a Start-up Mode neighbor), then the router
MUST re-generate the System ID and re-enter Start-up Mode.
+ If the S flag is set (meaning the neighbor is also in
Start-up Mode),
- The router which has a numerically smaller Router-
Fingerprint MUST re-generate its System ID and re-enter
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.
- If the Router Fingerprints are identical, both routers
MUST re-generate the System ID and the Router
Fingerprint, and re-enter Start-up Mode.
3. Normal operation
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
When receiving a Hello message, the router MUST check the
System ID of the Hello. If the System ID is the same as its
own, it indicates that System ID duplication has occurred.
If there is no Router-Fingerprint TLV in the received Hello
message, this is interpreted as the attached router either
does not support auto-configuration, or does not have it
enabled. In this case, the auto-configuration router MUST NOT
form adjacency with the non-autoconfiguration router.
2. Duplication resolution
When duplicate System IDs are detected, the non-startup mode
router MUST check the S flag of the duplicated Router-
Fingerprint TLV:
+ If the S flag is NOT set, then the router with the
numerically smaller or equal Router-Fingerprint MUST
generate a new System ID. Note that, the router MUST
compare the two Router-Fingerprint octet by octet until
difference is found.
+ If the S flag is set, no further action is necessary in the
Duplication resolution process.
3. Re-joining the network with a new System ID (if required) Router Fingerprint TLV MUST be included in Intermediate System to
Intermediate System Hellos (IIHs) originated by a router operating in
auto-configuration mode.
The router that has changed its System ID advertises new Router Fingerprint TLV MUST be included in Link State PDU (LSP) #0
Hellos containing the newly generated System ID to re-join the originated by a router operating in auto-configuration mode. The
IS-IS auto-configuration network. The conflicting SysID- router fingerprint TLV MUST NOT be included in an LSP with a non-zero
duplicated router also MUST increase the sequence number and number.
re-advertise its own Hellos.
The Duplication Detection process SHOULD be repeated with the 3.4. Protocol Operation
newly generated System.
3.3.2.3. Duplication Between Non-neighbors This section describes the operation of a router supporting auto-
configuration mode.
System ID duplication may also occur between non-neighbors, therefore 3.4.1. Start-Up mode
an IS-IS auto-configuration router MUST also include the Router-
Fingerprint TLV in its LSP messages. The specific procedures are as
follows:
Start-up Mode procedures: When a router starts operation in auto-configuration mode, both the S
and A bits MUST be set in the Router Fingerprint TLV included in both
hellos and LSP #0. During this mode only LSP #0 is generated and IS
or IP/IPv6 reachability TLVs MUST NOT be included in LSP #0. A
router remains in Start-up mode for a minimum period of time
(recommended to be 1 minute). This time should be sufficient to
bring up adjacencies to all expected neighbors. A router leaves
Start-up mode once the minimum time has elapsed and full LSP database
synchronization is achieved with all neighbors in the UP state.
1. Boot up, adjacency formation When a router exits startup-mode it clears the S bit in Router
Fingerprint TLVs it sends in hellos and LSP#0. The router MAY now
advertise IS neighbor and IP/IPv6 prefix reachability in its LSPs and
MAY generate LSPs with a non-zero number.
2. Acquiring LSPDB and checking System ID duplication The purpose of Start-up Mode is to minimize the occurrence of System
ID changes for a router once it has become fully operational. Any
System ID change during Start-up mode will have minimal impact on a
running network because while in Start-up mode the router is not yet
being used for forwarding traffic.
The router generates only an LSP #0 which contains only the 3.4.2. Adjacency Formation
Fingerprint TLV; and that Fingerprint is only sent in LSP #0.
A router remains in Start-up Mode until it has successfully
completed LSPDB synchronization with all neighbors or until 1
minute has elapsed - whichever is longer. If duplicate
system-ID is detected, the router MUST check the S flag of the
Router-Fingerprint TLV of the LSP that contains the duplicated
System ID.
+ If the S flag is not set, it means the LSP was generated by Routers operating in auto-configuration mode MUST NOT form
a Non Start-up Mode node, then the router itself MUST clear adjacencies with routers which are NOT operating in auto-
all adjacencies, re-generate a new system-id and reenter configuration mode. The presence of the Router Fingerprint TLV with
Start-up Mode. the A bit set indicates the router is operating in auto-configuration
mode.
+ If the S flag is set, then the router which has a NOTE: The use of the special area address of all 0's makes it
numerically smaller Router-Fingerprint MUST generate a new unlikely that a router which is not operating in auto-configuration
System ID and reenter Start-up Mode. mode will be in the same area as a router operating in auto-
configuration mode. However, the check for the Router Fingerprint
TLV with A bit set provides additional protection.
3. Running in normal operation 3.4.3. IS-IS System ID Duplication Detection and Resolution
After the System ID duplication procedure is done, the router The System ID of each node MUST be unique. As described in
begins to run in normal operation. The router MUST re- Section 3.4.5, the System ID is generated based on entropies (e.g.
advertise the Router-Fingerprint TLV with the S flag off. MAC address) which are generally expected to be unique. However,
since there may be limitations to the available entropies, there is
still the possibility of System ID duplication. This section defines
how IS-IS detects and resolves System ID duplication. Duplicate
System ID may occur between neighbors or between routers in the same
area which are not neighbors.
Non Start-up Mode procedures: Duplicate System ID with a neighbor is detected when the System ID
received in an IIH is identical to the local System ID and the
Router-Fingerprint in the received Router-Fingerprint TLV does NOT
match the locally generated Router-Fingerprint.
1. Checking the received Router-Fingerprint TLVs Duplicate System ID with a non-neighbor is detected when an LSP #0 is
received, the System ID of the originator is identical to the local
System ID, and the Router-Fingerprint in the Router-Fingerprint TLV
does NOT match the locally generated Router-Fingerprint.
When receiving a LSP containing its own System ID, the router 3.4.4. Duplicate System ID Resolution Procedures
MUST check the Router-Fingerprint TLV. If the Router-
Fingerprint TLV is different from its own, it indicates a
System ID duplication occurs.
2. Duplication resolution When duplicate System ID is detected one of the systems MUST assign
itself a different System ID and perform a protocol restart. The
resolution procedure attempts to minimize disruption to a running
network by choosing a router which is in Start-up mode to be
restarted whenever possible.
When System ID duplication occurs, the non-startup mode router The contents of the Router-Fingerprint TLVs for the two routers with
MUST check the S flag of the duplicated Router-Fingerprint duplicate System IDs are compared.
TLV:
+ If the S flag is NOT set, then the router with the If one TLV has the S bit set (router is in Start-up mode) and one TLV
numerically smaller Router-Fingerprint MUST generate a new has the S bit clear (router is NOT in Start-up mode) the router in
System ID. Note that, the router MUST compare the two Start-up mode MUST generate a new System ID and restart the protocol.
Router-Fingerprint octet by octet until difference is
found.
+ If the S flag is set, then router does nothing. If both TLVs have the S bit set (both routers are in Start-up mode)
or both TLVs have the S bit clear (neither router is in Start-up
mode) then the router with numerically smaller Router-Fingerprint
MUST generate a new System ID and restart the protocol.
3. Re-joining the network with the new System ID Fingerprint comparison is performed octet by octet starting from the
first received octet until a difference is detected. If the
fingerprints have different lengths and all octets up to the shortest
length are identical then the fingerprint with smaller length is
considered smaller.
The router changing its System ID advertises new LSPs based on If the fingerprints are identical in both content and length (and
the newly generated System ID to re-join the IS-IS auto- state of the S bit is identical) and the duplication is detected in
configuration network. The other SysID-duplicated router also hellos then the both routers MUST generate a new System ID and
MUST re-advertise its own LSP (after increasing the sequence restart the protocol.
number).
The newly generated System ID SHOULD perform duplication If fingerprints are identical in both content and length and the
detection as well. duplication is detected in LSP #0 then the procedures defined in
Section 3.4.6 MUST be followed.
3.3.3. System ID and Router-Fingerprint Generation Considerations 3.4.5. System ID and Router-Fingerprint Generation Considerations
As specified in this document, there are two distinguishing items As specified in this document, there are two distinguishing items
that need to be self-generated: the System ID and Router-Fingerprint. that need to be self-generated: the System ID and Router-Fingerprint.
In a network device, normally there are some resources which can In a network device, normally there are some resources which can
provide an extremely high probability of uniqueness thus could be provide an extremely high probability of uniqueness thus could be
used as seeds to derive distinguisher (e.g. hashing or generating used as seeds to derive distinguisher (e.g. hashing or generating
pseudo-random numbers), such as: pseudo-random numbers), such as:
o MAC address(es) o MAC address(es)
skipping to change at page 10, line 32 skipping to change at page 8, line 49
o System clock at a certain specific time o System clock at a certain specific time
o Arbitrary received packet(s) on an interface(s) o Arbitrary received packet(s) on an interface(s)
This document recommends the use of 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.
Fingerprint MUST be based on different seeds so that the two
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 hardware/software limitations and the routers. This is because of hardware/software limitations and the
lack of sufficient communication packets at the initial stage in home lack of sufficient communication packets at the initial stage in home
routers when doing ISIS auto-configuration. In this case, this routers when doing ISIS auto-configuration. In this case, this
document suggests using the MAC address as System ID and generating 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 the Router- address of a certain variable in the program) as the Router-
Fingerprint. The pseudo-random number might not have a very high Fingerprint. The pseudo-random number might not have a very high
probability of uniqueness in this solution, but should be sufficient probability of uniqueness in this solution, but should be sufficient
in home networks scenarios. in home networks scenarios.
The considerations surrounding System ID stability described in The considerations surrounding System ID stability described in
section Section 3.2 also need to be applied. section Section 3.2 also need to be applied.
3.3.4. Double-Duplication of both System ID and Router-Fingerprint 3.4.6. 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 System ID/
might be very constrained during the initial stages. Hence, the Fingerprint might be very constrained during the initial stages.
double-duplication of both System ID and Router-Fingerprint needs to Hence, the double-duplication of both System ID and Router-
be considered. Fingerprint needs to be considered. In such a case it is possible
that a router will receive an LSP with System ID and Router-
Fingerprint identical to the local values but the LSP is NOT
identical to the locally generated copy i.e. sequence number is newer
or sequence number is the same but the LSP has a valid checksum which
does not match. The term DD-LSP is used to describe such an LSP.
ISIS-autoconfiguring routers SHOULD support detecting System ID In a benign case, this will occur if a router restarts and it
duplication by LSP war. LSP war is a phenomenon whereby a router receives copies of its own LSPs from its previous incarnation. This
receives a LSP originated with its System ID, but it doesn't find it benign case needs to be distinguished from the pathological case
in the database, or it does not match the one the router has (e.g. where there are two different routers with the same System ID and the
it advertises IP prefixes that the router does not own, or IS same Router-Fingerprint.
neighbors that the router does not see), then per the ISIS
specification, the router must re-originate its LSP with an increased
sequence number. If double-duplication happens, the duplicated two
routers will both continuously repeat the above behavior. After
multiples iterations, the program should be able to deduce that
double-duplication is occurring.
When this condition is detected, routers should have much more In the benign case, the restarting router will generate a new version
entropies available. Thus, the router is able to extend or re- of its own LSP with higher sequence number and flood the new LSP
generate its Router-Fingerprint (one simple way is just adding the version. This will cause other routers in the network to update
LSP sequence number of the next LSP it will send to the Router- their LSPDB and synchronization will be achieved.
Fingerprint).
3.4. IS-IS TLVs Usage In the pathological case the generation of a new version of an LSP by
one of the "twins" will cause the other twin to generate the same LSP
with a higher sequence number - and oscillation will continue without
achieving LSPDB synchronization.
This section describes the TLVs that are necessary for IS-IS auto- Note that comparison of S bit in the Router-Fingerprint TLV cannot be
configuration. performed as in the benign case it is expected that the S bit will be
clear. Also note that the conditions for detecting duplicate System
ID will NOT be satisfied because both the System ID and the Router-
Fingerprint will be identical.
3.4.1. Authentication TLV The following procedure is defined:
It is RECOMMENDED that IS-IS routers supporting this specification DD-state is a boolean which indicates if a
minimally offer an option to explicitly configure a single password DD-LSP #0 has been received
for HMAC-MD5 authentication, which is Type 54 authentication mode of DD-count is the count of the number of occurences
[RFC5304]. In this case, the Authentication TLV (TLV 10) is needed. of reception of a DD-LSP
DD-timer is a timer associated with reception of
DD-LSPs. Recommended value is 60 seconds.
DD-max is the maximum number of DD-LSPs allowed
to be received in DD-timer interval.
Recommended value is 3.
3.4.2. Wide Metric TLV When a DD-LSP is received:
IS-IS auto-configuration routers MUST support TLVs using wide metrics If DD-state is FALSE:
as defined in [RFC5305]). DD-state is set to TRUE
DD-timer is started
DD-count is initialized to 1.
It is RECOMMENDED that IS-IS auto-configuration routers use a high If DD-state is TRUE:
metric value (e.g. 1000000) as default in order to typically prefer DD-count is incremented
manually configured adjacencies over auto-configuringed. If DD-count is >= DD-max:
Local system MUST generate a new System ID
and Router-Fingerprint and restart the protocol
DD-state is (re)initialized to FALSE and
DD-timer cancelled.
3.4.3. Dynamic Host Name TLV If DD-timer expires:
DD-state is set to FALSE.
IS-IS auto-configuration routers MAY advertise their Dynamic Host Note that to minimze the likelihood of double-duplication reoccuring,
Names TLV (TLV 137, [RFC5301]). The host names could be provisioned routers SHOULD have more entropies available. One simple way to
by an IT system, or just use the name of vendor, device type or achieve this is to add the LSP sequence number of the next LSP it
serial number, etc. will send to the Router-Fingerprint.
To guarantee the uniqueness of the host names, the System ID SHOULD 3.5. Additional IS-IS TLVs Usage Guidelines
be appended as a suffix in the names.
3.5. Routing Behavior Considerations This section describes the behavior of selected TLVs when used by a
router supporting IS-IS auto-configuration.
3.5.1. Adjacency Formation 3.5.1. Authentication TLV
Since IS-IS does not require strict hold timer matching to form It is RECOMMENDED that IS-IS routers supporting this specification
adjacency, this document does not specify specific hold timers. offer an option to explicitly configure a single password for HMAC-
However, the timers should be within a reasonable range based on MD5 authentication as specified in[RFC5304].
current practise in the industry. (For example, the defaults defined
in [ISO_IEC10589] .) 3.5.2. Metric Used in Reachability TLVs
It is RECOMMENDED that IS-IS auto-configuration routers use a high
metric value (e.g. 100000) as default in order to allow manually
configured adjacencies to be preferred over auto-configured.
3.5.3. Dynamic Host Name TLV
IS-IS auto-configuration routers MAY advertise their Dynamic Host
Name TLV (TLV 137, [RFC5301]). The host name could be provisioned by
an IT system, or just use the name of vendor, device type or serial
number, etc.
To guarantee the uniqueness of the host name, the System ID SHOULD be
appended as a suffix in the names.
4. Security Considerations 4. Security Considerations
In general, auto-configuration is mutually incompatible with In general, the use of authentication is incompatible with auto-
authentication. This is a common problem that IS-IS auto- configuration as it requires some manual configuration.
configuration can not avoid.
For wired deployment, the wired connection itself could be considered For wired deployment, the wired connection itself could be considered
as an implicit authentication in that unwanted routers are usually as an implicit authentication in that unwanted routers are usually
not able to connect (i.e. there is some kind of physical security in not able to connect (i.e. there is some kind of physical security in
place preventing the connection of rogue devices); for wireless place preventing the connection of rogue devices); for wireless
deployment, the authentication could be achieved at the lower deployment, the authentication could be achieved at the lower
wireless link layer. wireless link layer.
A malicious router could modify the System ID field to keep causing
System ID duplication detection and resolution thus cause the routing
system to oscillate. However, this is not a new attack vector as
without this document the consequences would be higher as other
routers would not have a mechanism to try and resolve this case.
5. IANA Considerations 5. IANA Considerations
IANA is kindly requested to assign a new TLV for the Router- This document requires the definition of a new IS-IS TLV to be
Fingerprint from the IS-IS TLV Codepoint registry. reflected in the "IS-IS TLV Codepoints" registry:
Type Description IIH LSP SNP Purge
---- ------------ --- --- --- -----
TBA Router-Fingerprint Y Y N Y
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 Thomann, 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 [RFC7749].
(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
[ISO_IEC10589] [ISO_IEC10589]
""Intermediate System to Intermediate System intra-domain "Intermediate system to Intermediate system intra-domain
routeing information exchange protocol for use in routeing information exchange protocol for use in
conjunction with the protocol for providing the conjunction with the protocol for providing the
connectionless-mode network service (ISO 8473)", ISO/IEC connectionless-mode Network Service (ISO 8473), ISO/IEC
10589", November 2002. 10589:2002, Second Edition.", Nov 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", RFC 1195, DOI 10.17487/RFC1195, dual environments", RFC 1195, DOI 10.17487/RFC1195,
December 1990, <http://www.rfc-editor.org/info/rfc1195>. December 1990, <http://www.rfc-editor.org/info/rfc1195>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
DOI 10.17487/RFC2629, June 1999, Requirement Levels", BCP 14, RFC 2119,
<http://www.rfc-editor.org/info/rfc2629>. DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
October 2008, <http://www.rfc-editor.org/info/rfc5301>. October 2008, <http://www.rfc-editor.org/info/rfc5301>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <http://www.rfc-editor.org/info/rfc5304>. 2008, <http://www.rfc-editor.org/info/rfc5304>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", RFC 5305, DOI 10.17487/RFC5305, October Engineering", RFC 5305, DOI 10.17487/RFC5305, October
2008, <http://www.rfc-editor.org/info/rfc5305>. 2008, <http://www.rfc-editor.org/info/rfc5305>.
[RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
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
Originator Identification TLV for IS-IS", RFC 6232,
DOI 10.17487/RFC6232, May 2011,
<http://www.rfc-editor.org/info/rfc6232>.
7.2. Informative References 7.2. Informative References
[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>.
[RFC7749] Reschke, J., "The "xml2rfc" Version 2 Vocabulary",
RFC 7749, DOI 10.17487/RFC7749, February 2016,
<http://www.rfc-editor.org/info/rfc7749>.
Authors' Addresses Authors' Addresses
Bing Liu Bing Liu (editor)
Huawei Technologies Huawei Technologies
Q10, 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
France France
skipping to change at page 15, line 4 skipping to change at page 13, line 38
Germany Germany
Email: ian.farrer@telekom.de Email: ian.farrer@telekom.de
Mikael Abrahamsson Mikael Abrahamsson
T-Systems T-Systems
Stockholm Stockholm
Sweden Sweden
Email: mikael.abrahamsson@t-systems.se Email: mikael.abrahamsson@t-systems.se
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
510 McCarthy Blvd. 821 Alder Drive
Milpitas CA 95035 Milpitas CA 95035
USA USA
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
 End of changes. 78 change blocks. 
322 lines changed or deleted 275 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/