draft-ietf-isis-auto-conf-05.txt   rfc8196.txt 
isis B. Liu, Ed. Internet Engineering Task Force (IETF) B. Liu, Ed.
Internet-Draft Huawei Technologies Request for Comments: 8196 Huawei Technologies
Intended status: Standards Track L. Ginsberg Category: Standards Track L. Ginsberg
Expires: November 10, 2017 Cisco Systems ISSN: 2070-1721 Cisco Systems
B. Decraene B. Decraene
Orange Orange
I. Farrer I. Farrer
Deutsche Telekom AG Deutsche Telekom AG
M. Abrahamsson M. Abrahamsson
T-Systems T-Systems
May 9, 2017 July 2017
ISIS Auto-Configuration IS-IS Autoconfiguration
draft-ietf-isis-auto-conf-05
Abstract Abstract
This document specifies IS-IS auto-configuration mechanisms. The key This document specifies IS-IS autoconfiguration mechanisms. The key
components are IS-IS System ID self-generation, duplication detection components are IS-IS System ID self-generation, duplication
and duplication resolution. These mechanisms provide limited IS-IS detection, and duplication resolution. These mechanisms provide
functions, and so are suitable for networks where plug-and-play limited IS-IS functions and are therefore suitable for networks where
configuration is expected. plug-and-play 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 is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This document is a product of the Internet Engineering Task Force
Task Force (IETF). Note that other groups may also distribute (IETF). It represents the consensus of the IETF community. It has
working documents as Internet-Drafts. The list of current Internet- received public review and has been approved for publication by the
Drafts is at http://datatracker.ietf.org/drafts/current/. Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Internet-Drafts are draft documents valid for a maximum of six months Information about the current status of this document, any errata,
and may be updated, replaced, or obsoleted by other documents at any and how to provide feedback on it may be obtained at
time. It is inappropriate to use Internet-Drafts as reference http://www.rfc-editor.org/info/rfc8196.
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Specification . . . . . . . . . . . . . . . . . . . 3 3. Protocol Specification . . . . . . . . . . . . . . . . . . . 4
3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 3 3.1. IS-IS Default Configuration . . . . . . . . . . . . . . . 4
3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 4 3.2. IS-IS NET Generation . . . . . . . . . . . . . . . . . . 4
3.3. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . 5 3.3. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . 6
3.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 3.4. Protocol Operation . . . . . . . . . . . . . . . . . . . 7
3.4.1. Start-Up mode . . . . . . . . . . . . . . . . . . . . 6 3.4.1. Startup Mode . . . . . . . . . . . . . . . . . . . . 7
3.4.2. Adjacency Formation . . . . . . . . . . . . . . . . . 7 3.4.2. Adjacency Formation . . . . . . . . . . . . . . . . . 8
3.4.3. IS-IS System ID Duplication Detection . . . . . . . . 7 3.4.3. IS-IS System ID Duplication Detection . . . . . . . . 8
3.4.4. Duplicate System ID Resolution Procedures . . . . . . 7 3.4.4. Duplicate System ID Resolution Procedures . . . . . . 8
3.4.5. System ID and Router-Fingerprint Generation 3.4.5. System ID and Router-Fingerprint Generation
Considerations . . . . . . . . . . . . . . . . . . . 8 Considerations . . . . . . . . . . . . . . . . . . . 9
3.4.6. Duplication of both System ID and Router-Fingerprint 9 3.4.6. Duplication of Both System ID and Router-Fingerprint 10
3.5. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . 10 3.5. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . 12
3.5.1. Authentication TLV . . . . . . . . . . . . . . . . . 11 3.5.1. Authentication TLV . . . . . . . . . . . . . . . . . 12
3.5.2. Metric Used in Reachability TLVs . . . . . . . . . . 11 3.5.2. Metric Used in Reachability TLVs . . . . . . . . . . 12
3.5.3. Dynamic Host Name TLV . . . . . . . . . . . . . . . . 11 3.5.3. Dynamic Name TLV . . . . . . . . . . . . . . . . . . 12
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . 13 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document specifies mechanisms for IS-IS [RFC1195] This document specifies mechanisms for IS-IS [RFC1195] [ISO_IEC10589]
[ISO_IEC10589][RFC5308] to be auto-configuring. Such mechanisms [RFC5308] to be autoconfiguring. Such mechanisms could reduce the
could reduce the management burden for configuring a network, management burden for configuring a network, especially where plug-
especially where plug-and-play device configuration is required. and-play device configuration is required.
IS-IS auto-configuration is comprised of the following functions: IS-IS autoconfiguration is comprised of the following functions:
1. IS-IS default configuration. 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, metrics in reachability 4. IS-IS TLV utilization (authentication TLV, metrics in
advertisements, and Dynamic Host Name TLV). reachability advertisements, and Dynamic 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 autoconfigured routers with non-autoconfigured
routers. See Section 3.3. routers. See Section 3.3.
1.1. 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 BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. 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.
2. Scope 2. Scope
The auto-configuration mechanisms support both IPv4 and IPv6 The autoconfiguration mechanisms support both IPv4 and IPv6
deployments. deployments.
These auto-configuration mechanisms aim to cover simple deployment These autoconfiguration 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 Interworking with other routing protocols. o multi-area and level-2 routing
IS-IS auto-configuration is primarily intended for use in small (i.e. o interworking with other routing protocols
IS-IS autoconfiguration is primarily intended for use in small (i.e.,
10s of devices) and unmanaged deployments. It allows IS-IS to be 10s of devices) and unmanaged deployments. It allows IS-IS to be
used without the need for any configuration by the user. It is not used without the need for any configuration by the user. 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 This section defines the default configuration for an autoconfigured
corresponding to their layer-2 capability. For example, Ethernet router.
interfaces will be auto-configured as broadcast networks and
Point-to-Point Protocol (PPP) interfaces will be auto-configured
as Point-to-Point interfaces.
o IS-IS auto-configuration instances MUST be configured as level-1, o IS-IS interfaces MUST be autoconfigured to an interface type
so that the interfaces operate as level-1 only. corresponding to their Layer 2 capability. For example, Ethernet
interfaces will be autoconfigured as broadcast networks and Point-
to-Point Protocol (PPP) interfaces will be autoconfigured as
Point-to-Point interfaces.
o IS-IS autoconfiguration instances MUST be configured as level-1 so
that the interfaces operate as level-1 only.
o originatingLSPBufferSize is set to 512. o originatingLSPBufferSize is set to 512.
o MaxAreaAddresses is set to 3 o MaxAreaAddresses is set to 3.
o Extended IS Reachability and IP Reachability TLVs [RFC5305] MUST o Extended IS reachability (TLV 22) and IP reachability (TLV 135)
be used i.e. a router operating in auto configuration mode MUST TLVs [RFC5305] MUST be used, i.e., a router operating in
NOT use any of the following TLVs: autoconfiguration mode MUST NOT use any of the following TLVs:
* IS Neighbors (2) * IIS Neighbors (TLV 2)
* IP Internal Reachability (128) * IP Int. Reach (TLV 128)
* IP External Reachability (130) * IP Ext. Address (TLV 130)
TLVs listed above MUST be ignored on receipt. The TLVs listed above MUST be ignored on receipt.
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 Network Entity Title (NET) which is a type of Network Service a Network Entity Title (NET), which is a type of Network Service
Access Point (NSAP). The NET is the address of an instance of the Access Point (NSAP). The NET is the address of an instance of the
IS-IS protocol running on an Intermediate System (IS). IS-IS protocol running on an IS.
The auto-configuration mechanism generates the IS-IS NET as the The autoconfiguration 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 autoconfiguration, this field MUST be 13 octets long
and set to all 0. and set to all 0s.
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. Changes such as interface enable/disable, interface stable. Changes such as interface enable/disable, interface
connect/disconnect, device reboot, firmware update, or connect/disconnect, device reboot, firmware update, or
configuration changes SHOULD NOT cause the system ID to configuration changes SHOULD NOT cause the System ID to
change. System ID change as part of the System ID collision change. System ID change as part of the System ID collision
resolution process MUST be supported. Implementations resolution process MUST be supported. Implementations
SHOULD allow the System ID to be cleared by a user initiated SHOULD allow the System ID to be cleared by a user-initiated
system reset. system reset.
More specific considerations for System ID generation are More specific considerations for System ID generation are
described in Section 3.4.5. described in Section 3.4.5.
3.3. Router-Fingerprint TLV 3.3. Router-Fingerprint TLV
The Router-Fingerprint TLV is similar to the Router-Hardware- The Router-Fingerprint TLV is similar to the Router-Hardware-
Fingerprint TLV defined in [RFC7503]. However, the TLV defined here Fingerprint TLV defined in [RFC7503]. However, the TLV defined here
includes a flags field to support indicating that the router is in includes a Flags field to support indicating that the router is in
Start-up mode and is operating in auto-configuration mode. startup mode and is operating in autoconfiguration 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags Field | | | Flags | |
+-+-+-+-+-+-+-+-+ Router Fingerprint (Variable) . +-+-+-+-+-+-+-+-+ Router-Fingerprint (Variable) .
. . . .
. . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: to be assigned by IANA. Type: 15.
Length: the length of the value field. Must be >= 33.
Flags field (1 octet)
0 1 2 3 4 5 6 7 Length: The length, in octets, of the "Flags" and "Router-
+-+-+-+-+-+-+-+-+ Fingerprint" fields.
|S|A| Reserved |
+-+-+-+-+-+-+-+-+
S flag: when set, indicates the router is in "start-up" mode. Flags: 1 octet.
A flag: when set, indicates that the router is operating in
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.
Router Fingerprint: 32 or more octets. 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|S|A| Reserved |
+-+-+-+-+-+-+-+-+
S flag: When set, indicates the router is in "startup" mode.
A flag: When set, indicates that the router is operating in
autoconfiguration mode. The purpose of the flag is so that two
routers can identify if they are both using autoconfiguration.
If the A flag setting does not match in hellos, then no
adjacency should be formed.
Reserved: These flags MUST be set to zero and MUST be ignored by the
receiver.
Router-Fingerprint: 32 or more octets.
More specific considerations for Router-Fingerprint are described in More specific considerations for Router-Fingerprint are described in
Section 3.4.5. Section 3.4.5.
Router Fingerprint TLV MUST be included in Intermediate System to The Router-Fingerprint TLV with the A flag set MUST be included in
Intermediate System Hellos (IIHs) originated by a router operating in IS-IS Hellos (IIHs) originated by a router operating in
auto-configuration mode. An auto-configuration mode router MUST autoconfiguration mode. An autoconfiguration mode router MUST ignore
ignore IIHs that don't contain the Router Fingerprint TLV. IIHs that don't contain the Router-Fingerprint TLV with the A flag
set.
Router Fingerprint TLV MUST be included in Link State PDU (LSP) #0 The Router-Fingerprint TLV with the A flag set MUST be included in
originated by a router operating in auto-configuration mode. If an Link State PDU (LSP) #0 originated by a router operating in
LSP #0 which does NOT contain a Router Fingerprint TLV is received by autoconfiguration mode. If an LSP #0 is received by a router
a Router operating in auto-configuration mode the LSP is flooded as operating in autoconfiguration mode and the LSP either does NOT
contain a Router-Fingerprint TLV or it does contain a Router-
Fingerprint TLV but the A flag is NOT set, then the LSP is flooded as
normal, but the entire LSP set originated by the sending router MUST normal, but the entire LSP set originated by the sending router MUST
be ignored when running the Decision process. be ignored when running the Decision Process.
The router fingerprint TLV MUST NOT be included in an LSP with a non- The Router-Fingerprint TLV MUST NOT be included in an LSP with a non-
zero number and when received MUST be ignored. zero number and when received MUST be ignored.
3.4. Protocol Operation 3.4. Protocol Operation
This section describes the operation of a router supporting auto- This section describes the operation of a router supporting
configuration mode. autoconfiguration mode.
3.4.1. Start-Up mode 3.4.1. Startup Mode
When a router starts operation in auto-configuration mode, both the S When a router starts operation in autoconfiguration mode, both the S
and A bits MUST be set in the Router Fingerprint TLV included in both and A flags MUST be set in the Router-Fingerprint TLV included in
hellos and LSP #0. During this mode only LSP #0 is generated and IS both hellos and LSP #0. During this mode, only LSP #0 is generated
or IP/IPv6 reachability TLVs MUST NOT be included in LSP #0. A and IS or IP/IPv6 reachability TLVs MUST NOT be included in LSP #0.
router remains in Start-up mode for a minimum period of time A router remains in startup mode for a minimum period of time
(recommended to be 1 minute). This time should be sufficient to (recommended to be 1 minute). This time should be sufficient to
bring up adjacencies to all expected neighbors. A router leaves bring up adjacencies to all expected neighbors. A router leaves
Start-up mode once the minimum time has elapsed and full LSP database startup mode once the minimum time has elapsed and full LSP database
synchronization is achieved with all neighbors in the UP state. synchronization is achieved with all neighbors in the UP state.
When a router exits startup-mode it clears the S bit in Router When a router exits startup mode, it clears the S flag in Router-
Fingerprint TLVs it sends in hellos and LSP#0. The router MAY now Fingerprint TLVs that it sends in hellos and LSP #0. The router MAY
advertise IS neighbor and IP/IPv6 prefix reachability in its LSPs and now advertise the IS neighbor and IP/IPv6 prefix reachability in its
MAY generate LSPs with a non-zero number. LSPs and MAY generate LSPs with a non-zero number.
The purpose of Start-up Mode is to minimize the occurrence of System The purpose of startup mode is to minimize the occurrence of System
ID changes for a router once it has become fully operational. Any 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 System ID change during startup mode will have minimal impact on a
running network because while in Start-up mode the router is not yet running network because, while in startup mode, the router is not yet
being used for forwarding traffic. being used for forwarding traffic.
3.4.2. Adjacency Formation 3.4.2. Adjacency Formation
Routers operating in auto-configuration mode MUST NOT form Routers operating in autoconfiguration mode MUST NOT form adjacencies
adjacencies with routers which are NOT operating in auto- with routers that are NOT operating in autoconfiguration mode. The
configuration mode. The presence of the Router Fingerprint TLV with presence of the Router-Fingerprint TLV with the A flag set indicates
the A bit set indicates the router is operating in auto-configuration the router is operating in autoconfiguration mode.
mode.
NOTE: The use of the special area address of all 0's makes it NOTE: The use of the special area address of all 0s makes it unlikely
unlikely that a router which is not operating in auto-configuration that a router that is not operating in autoconfiguration mode will be
mode will be in the same area as a router operating in auto- in the same area as a router operating in autoconfiguration mode.
configuration mode. However, the check for the Router Fingerprint However, the check for the Router-Fingerprint TLV with the A flag set
TLV with A bit set provides additional protection. provides additional protection.
3.4.3. IS-IS System ID Duplication Detection 3.4.3. IS-IS System ID Duplication Detection
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.4.5, the System ID is generated based on entropies (e.g. Section 3.4.5, the System ID is generated based on entropies (e.g.,
MAC address) which are generally expected to be unique. However, Media Access Control (MAC) address) that are generally expected to be
since there may be limitations to the available entropies, there is unique. However, since there may be limitations to the available
still the possibility of System ID duplication. This section defines entropies, there is still the possibility of System ID duplication.
how IS-IS detects and resolves System ID duplication. Duplicate This section defines how IS-IS detects and resolves System ID
System ID may occur between neighbors or between routers in the same duplication. A duplicate system ID may occur between neighbors or
area which are not neighbors. between routers in the same area that are not neighbors.
Duplicate System ID with a neighbor is detected when the System ID A 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 received in an IIH is identical to the local System ID and the
Router-Fingerprint in the received Router-Fingerprint TLV does NOT Router-Fingerprint in the received Router-Fingerprint TLV does NOT
match the locally generated Router-Fingerprint. match the locally generated Router-Fingerprint.
Duplicate System ID with a non-neighbor is detected when an LSP #0 is A duplicate system ID with a non-neighbor is detected when an LSP #0
received, the System ID of the originator is identical to the local is received, the System ID of the originator is identical to the
System ID, and the Router-Fingerprint in the Router-Fingerprint TLV local System ID, and the Router-Fingerprint in the Router-Fingerprint
does NOT match the locally generated Router-Fingerprint. TLV does NOT match the locally generated Router-Fingerprint.
3.4.4. Duplicate System ID Resolution Procedures 3.4.4. Duplicate System ID Resolution Procedures
When duplicate System ID is detected one of the systems MUST assign When a duplicate system ID is detected, one of the systems MUST
itself a different System ID and perform a protocol restart. The assign itself a different System ID and perform a protocol restart.
resolution procedure attempts to minimize disruption to a running The resolution procedure attempts to minimize disruption to a running
network by choosing a router which is in Start-up mode to be network by choosing, whenever possible, to restart a router that is
restarted whenever possible. in startup mode.
The contents of the Router-Fingerprint TLVs for the two routers with The contents of the Router-Fingerprint TLVs for the two routers with
duplicate System IDs are compared. duplicate system IDs are compared.
If one TLV has the S bit set (router is in Start-up mode) and one TLV If one TLV has the S flag set (the router is in startup mode) and one
has the S bit clear (router is NOT in Start-up mode) the router in TLV has the S flag clear (the router is NOT in startup mode), the
Start-up mode MUST generate a new System ID and restart the protocol. router in startup mode MUST generate a new System ID and restart the
protocol.
If both TLVs have the S bit set (both routers are in Start-up mode) If both TLVs have the S flag set (both routers are in startup mode)
or both TLVs have the S bit clear (neither router is in Start-up or both TLVs have the S flag clear (neither router is in startup
mode) then the router with numerically smaller Router-Fingerprint mode), then the router with the numerically smaller Router-
MUST generate a new System ID and restart the protocol. Fingerprint MUST generate a new System ID and restart the protocol.
Fingerprint comparison is performed octet by octet starting from the Fingerprint comparison is performed octet by octet starting from the
first received octet until a difference is detected. If the first received octet until a difference is detected. If the
fingerprints have different lengths and all octets up to the shortest fingerprints have different lengths and all octets up to the shortest
length are identical then the fingerprint with smaller length is length are identical, then the fingerprint with smaller length is
considered smaller. considered smaller on the whole.
If the fingerprints are identical in both content and length (and If the fingerprints are identical in both content and length (and the
state of the S bit is identical) and the duplication is detected in state of the S flag is identical), and the duplication is detected in
hellos then the both routers MUST generate a new System ID and hellos, then both routers MUST generate a new System ID and restart
restart the protocol. the protocol.
If fingerprints are identical in both content and length and the If fingerprints are identical in both content and length, and the
duplication is detected in LSP #0 then the procedures defined in duplication is detected in LSP #0, then the procedures defined in
Section 3.4.6 MUST be followed. Section 3.4.6 MUST be followed.
3.4.5. 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 that can
provide an extremely high probability of uniqueness (some examples provide an extremely high probability of uniqueness (some examples
listed below). These resources can be used as seeds to derive listed below). These resources can be used as seeds to derive
identifiers. identifiers:
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(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 regenerate 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 method to generate the Router-
Router-Fingerprint. Fingerprint.
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 IS-IS autoconfiguration. In this case, this
document suggests using the MAC address as System ID and generating a document suggests using the MAC address as the System ID and
pseudo-random number based on another seed (such as the memory generating a pseudorandom number based on another seed (such as the
address of a certain variable in the program) as the Router- memory address of a certain variable in the program) as the Router-
Fingerprint. The pseudo-random number might not have a very high Fingerprint. The pseudorandom 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 network 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 3.2 also need to be applied.
3.4.6. Duplication of both System ID and Router-Fingerprint 3.4.6. Duplication of Both System ID and Router-Fingerprint
As described above, the resources for generating System ID/ As described above, the resources for generating a System ID /
Fingerprint might be very constrained during the initial stages. Router-Fingerprint might be very constrained during the initial
Hence, the duplication of both System ID and Router-Fingerprint needs stages. Hence, the duplication of both System ID and Router-
to be considered. In such a case it is possible that a router will Fingerprint need to be considered. In such a case, it is possible
receive an LSP with System ID and Router-Fingerprint identical to the that a router will receive an LSP with a System ID and Router-
local values but the LSP is NOT identical to the locally generated Fingerprint identical to the local values, but the LSP is NOT
copy i.e. sequence number is newer or sequence number is the same but identical to the locally generated copy, i.e., the sequence number is
the LSP has a valid checksum which does not match. The term DD-LSP newer or the sequence number is the same, but the LSP has a valid
is used to describe such an LSP. checksum that does not match. The term DD-LSP (Duplication Detection
LSP) is used to describe such an LSP.
In a benign case, this will occur if a router restarts and it In a benign case, this will occur if a router restarts and it
receives copies of its own LSPs from its previous incarnation. This receives copies of its own LSPs from its previous incarnation. This
benign case needs to be distinguished from the pathological case benign case needs to be distinguished from the pathological case
where there are two different routers with the same System ID and the where there are two different routers with the same System ID and the
same Router-Fingerprint. same Router-Fingerprint.
In the benign case, the restarting router will generate a new version In the benign case, the restarting router will generate a new version
of its own LSP with higher sequence number and flood the new LSP of its own LSP with a higher sequence number and flood the new LSP
version. This will cause other routers in the network to update version. This will cause other routers in the network to update
their LSPDB and synchronization will be achieved. their LSP Database (LSPDB) and synchronization will be achieved.
In the pathological case the generation of a new version of an LSP by In the pathological case, the generation of a new version of an LSP
one of the "twins" will cause the other twin to generate the same LSP by one of the "twins" will cause the other twin to generate the same
with a higher sequence number - and oscillation will continue without LSP with a higher sequence number -- and oscillation will continue
achieving LSPDB synchronization. without achieving LSPDB synchronization.
Note that comparison of S bit in the Router-Fingerprint TLV cannot be Note that a comparison of the S flag in the Router-Fingerprint TLV
performed as in the benign case it is expected that the S bit will be cannot be performed, as in the benign case it is expected that the S
clear. Also note that the conditions for detecting duplicate System flag will be clear. Also note that the conditions for detecting a
ID will NOT be satisfied because both the System ID and the Router- duplicate system ID will NOT be satisfied because both the System ID
Fingerprint will be identical. and the Router-Fingerprint will be identical.
The following procedure is defined: The following procedure is defined:
DD-state is a boolean which indicates if a DD-state is a boolean that indicates if a
DD-LSP #0 has been received DD-LSP #0 has been received.
DD-count is the count of the number of occurences DD-count is the count of the number of occurrences
of reception of a DD-LSP of reception of a DD-LSP.
DD-timer is a timer associated with reception of DD-timer is a timer associated with reception of
DD-LSPs. Recommended value is 60 seconds. DD-LSPs; the recommended value is 60 seconds.
DD-max is the maximum number of DD-LSPs allowed DD-max is the maximum number of DD-LSPs allowed
to be received in DD-timer interval. to be received in DD-timer interval;
Recommended value is 3. the recommended value is 3.
When a DD-LSP is received: When a DD-LSP is received:
If DD-state is FALSE: If DD-state is FALSE:
DD-state is set to TRUE DD-state is set to TRUE.
DD-timer is started DD-timer is started.
DD-count is initialized to 1. DD-count is initialized to 1.
If DD-state is TRUE: If DD-state is TRUE:
DD-count is incremented DD-count is incremented.
If DD-count is >= DD-max: If DD-count is >= DD-max:
Local system MUST generate a new System ID The local system MUST generate a new System ID
and Router-Fingerprint and restart the protocol and Router-Fingerprint and restart the protocol.
DD-state is (re)initialized to FALSE and DD-state is (re)initialized to FALSE and
DD-timer cancelled. DD-timer is canceled.
If DD-timer expires: If DD-timer expires:
DD-state is set to FALSE. DD-state is set to FALSE.
Note that to minimze the likelihood of duplication of both System ID Note that to minimize the likelihood of duplication of both System ID
and Router-fingerprint reoccuring, routers SHOULD have more entropies and Router-Fingerprint reoccurring, routers SHOULD have more
available. One simple way to achieve this is to add the LSP sequence entropies available. One simple way to achieve this is to add the
number of the next LSP it will send to the Router-Fingerprint. LSP sequence number of the next LSP it will send to the Router-
Fingerprint.
3.5. Additional IS-IS TLVs Usage Guidelines 3.5. Additional IS-IS TLVs Usage Guidelines
This section describes the behavior of selected TLVs when used by a This section describes the behavior of selected TLVs when used by a
router supporting IS-IS auto-configuration. router supporting IS-IS autoconfiguration.
3.5.1. Authentication TLV 3.5.1. Authentication TLV
It is RECOMMENDED that IS-IS routers supporting this specification It is RECOMMENDED that IS-IS routers supporting this specification
offer an option to explicitly configure a single password for HMAC- offer an option to explicitly configure a single password for HMAC-
MD5 authentication as specified in[RFC5304]. MD5 authentication as specified in [RFC5304].
3.5.2. Metric Used in Reachability TLVs 3.5.2. Metric Used in Reachability TLVs
It is RECOMMENDED that IS-IS auto-configuration routers use a high It is RECOMMENDED that IS-IS autoconfiguration routers use a high
metric value (e.g. 100000) as default in order to allow manually metric value (e.g., 100000) as default in order to allow manually
configured adjacencies to be preferred over auto-configured. configured adjacencies to be preferred over autoconfigured.
3.5.3. Dynamic Host Name TLV 3.5.3. Dynamic Name TLV
IS-IS auto-configuration routers MAY advertise their Dynamic Host IS-IS autoconfiguration routers MAY advertise their Dynamic Name TLV
Name TLV (TLV 137, [RFC5301]). The host name could be provisioned by (TLV 137 [RFC5301]). The hostname could be provisioned by an IT
an IT system, or just use the name of vendor, device type or serial system or just use the name of vendor, device type, or serial number,
number, etc. etc.
To guarantee the uniqueness of the host name, the System ID SHOULD be To guarantee the uniqueness of the hostname, the System ID SHOULD be
appended as a suffix in the names. appended as a suffix in the names.
4. Security Considerations 4. Security Considerations
In the absence of cryptographic authentication it is possible for an In the absence of cryptographic authentication, it is possible for an
attacker to inject a PDU falsely indicating there is a duplicate attacker to inject a PDU falsely indicating there is a duplicate
system-id. This may trigger automatic restart of the protocol using system ID. This may trigger automatic restart of the protocol using
the duplicate-id resolution procedures defined in this document. the duplicate-id resolution procedures defined in this document.
Note that the use of authentication is incompatible with auto- Note that the use of authentication is incompatible with
configuration as it requires some manual configuration. autoconfiguration as it requires some manual configuration.
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.
5. IANA Considerations 5. IANA Considerations
This document requires the definition of a new IS-IS TLV to be This document details a new IS-IS TLV reflected in the "IS-IS TLV
reflected in the "IS-IS TLV Codepoints" registry: Codepoints" registry:
Type Description IIH LSP SNP Purge Value Name IIH LSP SNP Purge
---- ------------ --- --- --- ----- ---- ------------ --- --- --- -----
TBA Router-Fingerprint Y Y N Y 15 Router-Fingerprint Y Y N Y
6. Acknowledgements
This document was heavily inspired by [RFC7503].
Martin Winter, Christian Franke and David Lamparter gave essential
feedback to improve the technical design based on their
implementation experience.
Many useful comments were made by Acee Lindem, Karsten Thomann,
Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang and
Nan Wu, etc.
This document was produced using the xml2rfc tool [RFC7991].
(initially prepared using 2-Word-v2.0.template.dot. )
7. References 6. References
7.1. Normative References 6.1. Normative References
[ISO_IEC10589] [ISO_IEC10589]
"Intermediate system to Intermediate system intra-domain International Organization for Standardization,
routeing information exchange protocol for use in "Information technology -- Telecommunications and
conjunction with the protocol for providing the information exchange between systems -- Intermediate
connectionless-mode Network Service (ISO 8473), ISO/IEC System to Intermediate System intra-domain routeing
10589:2002, Second Edition.", Nov 2002. information exchange protocol for use in conjunction with
the protocol for providing the connectionless-mode network
service (ISO 8473)", ISO/IEC 10589:2002, Second Edition,
November 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>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 13, line 9 skipping to change at page 14, line 5
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>.
7.2. Informative References [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
6.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>.
[RFC7991] Hoffman, P., "The "xml2rfc" Version 3 Vocabulary", Acknowledgements
RFC 7991, DOI 10.17487/RFC7991, December 2016,
<http://www.rfc-editor.org/info/rfc7991>. This document was heavily inspired by [RFC7503].
Martin Winter, Christian Franke, and David Lamparter gave essential
feedback to improve the technical design based on their
implementation experience.
Many useful comments were made by Acee Lindem, Karsten Thomann,
Hannes Gredler, Peter Lothberg, Uma Chundury, Qin Wu, Sheng Jiang,
and Nan Wu, etc.
Authors' Addresses Authors' Addresses
Bing Liu (editor) 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
Les Ginsberg Les Ginsberg
Cisco Systems Cisco Systems
821 Alder Drive 821 Alder Drive
Milpitas CA 95035 Milpitas CA 95035
USA United States of America
Email: ginsberg@cisco.com Email: ginsberg@cisco.com
Bruno Decraene Bruno Decraene
Orange Orange
France France
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Ian Farrer Ian Farrer
 End of changes. 110 change blocks. 
293 lines changed or deleted 302 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/