isis                                                         B. Liu, Ed.
Internet-Draft                                       Huawei Technologies
Intended status: Standards Track                             B. Decraene
Expires: May 4, 26, 2017                                             Orange
                                                               I. Farrer
                                                     Deutsche Telekom AG
                                                          M. Abrahamsson
                                                               T-Systems
                                                             L. Ginsberg
                                                           Cisco Systems
                                                        October 31,
                                                       November 22, 2016

                        ISIS Auto-Configuration
                      draft-ietf-isis-auto-conf-03
                      draft-ietf-isis-auto-conf-04

Abstract

   This document specifies IS-IS auto-configuration mechanisms.  The key
   components are IS-IS System ID self-generation, duplication detection
   and duplication resolution.  These mechanisms provide limited IS-IS
   functions, and so are suitable for networks where 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

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on May 4, 26, 2017.

Copyright Notice

   Copyright (c) 2016 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
   2.  Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Protocol Specification  . . . . . . . . . . . . . . . . . . .   3
     3.1.  IS-IS Default Configuration . . . . . . . . . . . . . . .   3
     3.2.  IS-IS NET Generation  . . . . . . . . . . . . . . . . . .   3
     3.3.  IS-IS System ID Duplication Detection and Resolution  . .   4
       3.3.1.
     3.3.  Router-Fingerprint TLV  . . . . . . . . . . . . . . .   4
       3.3.2.  Duplicate System ID Detection and Resolution
               Procedures  . . . . .   5
     3.4.  Protocol Operation  . . . . . . . . . . . . . . . .   5
       3.3.3.  System ID and Router-Fingerprint Generation
               Considerations . . .   6
       3.4.1.  Start-Up mode . . . . . . . . . . . . . . . .  10
       3.3.4.  Double-Duplication of both System ID and Router-
               Fingerprint . . . .   6
       3.4.2.  Adjacency Formation . . . . . . . . . . . . . . . . .  11
     3.4.   6
       3.4.3.  IS-IS TLVs Usage  . System ID Duplication Detection and Resolution    7
       3.4.4.  Duplicate System ID Resolution Procedures . . . . . .   7
       3.4.5.  System ID and Router-Fingerprint Generation
               Considerations  . . . . . . . . . . . . .  11
       3.4.1.  Authentication TLV . . . . . .   8
       3.4.6.  Double-Duplication of both System ID and Router-
               Fingerprint . . . . . . . . . . .  11
       3.4.2.  Wide Metric TLV . . . . . . . . . .   9
     3.5.  Additional IS-IS TLVs Usage Guidelines  . . . . . . . . .  11
       3.4.3.  Dynamic Host Name  10
       3.5.1.  Authentication TLV  . . . . . . . . . . . . . . . .  12
     3.5.  Routing Behavior Considerations . . . .  10
       3.5.2.  Metric Used in Reachability TLVs  . . . . . . . . .  12
       3.5.1.  Adjacency Formation .  11
       3.5.3.  Dynamic Host Name TLV . . . . . . . . . . . . . . . .  12  11
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12  11
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12  11
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  13  11
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13  12
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13  12
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  14  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14  13

1.  Introduction

   This document specifies mechanisms for IS-IS [RFC1195]
   [ISO_IEC10589][RFC5308] to be auto-configuring.  Such mechanisms
   could reduce the management burden for configuring a network,
   especially where plug-and-play device configuration is required.

   IS-IS auto-configuration is comprised of the following functions:

   1.  IS-IS default configurations. configuration.

   2.  IS-IS System ID self-generation.

   3.  System ID duplication detection and resolution.

   4.  ISIS TLV utilization (Authentication TLV, Wide Metric TLV, metrics in reachability
       advertisements, and Dynamic Host Name TLV).

   This document also defines mechanisms to prevent the unintentional
   interoperation of auto-configured routers with non-autoconfigured
   routers.  See Section 3.3.1. 3.3.

2.  Scope

   The auto-configuration mechanism supports mechanisms support both IPv4 and IPv6
   deployments.

   These auto-configuration mechanisms aim to cover simple deployment
   cases.  The following important features are not supported:

   o  Multiple IS-IS instances.

   o  Multi-area and level-2 routing.

   o  Interworking with other routing protocols.

   IS-IS auto-configuration is primarily intended for use in small (i.e.
   10s of devices) and unmanaged deployments.  Its  It allows IS-IS to be
   used as the IGP without the need for any configuration by the user.  It is not
   recommended for larger deployments.

3.  Protocol Specification

3.1.  IS-IS Default Configuration

   o  IS-IS interfaces MUST be auto-configured to an interface type
      corresponding to their layer-2 capability.  For example, Ethernet
      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 instance instances MUST be configured as level-1,
      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

   In IS-IS, a router (known as an Intermediate System) is identified by
   a NET Network Entity Title (NET) which is the address of a type of Network Service
   Access Point (NSAP)
   and represented with an IS-IS specific address format. (NSAP).  The NSAP NET is a
   logical entity which represents the address of an instance of the
   IS-IS protocol running on an Intermediate System. System (IS).

   The auto-configuration mechanism generates the IS-IS NET as the
   following:

   o  Area address

         In IS-IS auto-configuration, this field MUST be 13 octets long
         and set to all 0.

   o  System ID

         This field follows the area address field, and is 6 octets in
         length.  There are two basic requirements for the System ID
         generation:

         -  As specified by the IS-IS protocol, this field must be
            unique among all routers in the same area.

         -  After its initial generation, the System ID SHOULD remain
            stable to improve the stability of the routing system.
            stable.  It SHOULD not NOT be changed due to device status
            change (such as interface enable/disable, interface connect/disconnect, connect/
            disconnect, device reboot, firmware update etc.) or
            configuration change (such as changing system configuration
            or IS-IS configuration); but MUST support change as part of
            the System ID collision resolution process and SHOULD allow
            being cleared by a user initiated system reset.

         More specific considerations for System ID generation are
         described in Section 3.3.3 . 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

   The Router-Fingerprint TLV essentially re-uses is similar to the design of Router-
   Hardware-Fingerprint Router-Hardware-
   Fingerprint TLV defined in [RFC7503].  However, there is one
   difference in that the TLV defined here
   includes a flag is added flags field to indicate support indicating that the node router is in
   "start-up mode", which
   Start-up mode and is defined operating in Section 3.3.2. auto-configuration mode.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |S|A| Reserved  |                                               |
      +-+-+-+-+-+-+-+-+        Router Fingerprint (Variable)          .
      .                                                               .
      .                                                               .
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Router Fingerprint TLV Format

   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  Length: the length of the value field.  As the Router Fingerprint
      length is variable, the field length is also variable.  Must be >= 33.

   o  Flags field (1 octet)

         S flag: when set, indicates the router is in "start-up" mode.

   o

         A flag: when set, indicates that the router is operating in auto-
      configuration
         auto-configuration mode.  The purpose of the flag is so that
         two routers can identify if they are both using auto-configuration. 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
         the receiver.

   o  Router Fingerprint: uniquely identifies a router, variable length.

   More specific considerations for Router-Fingerprint are described in
   Section 3.3.3 .

3.3.2.  Duplicate 3.4.5.

   Router Fingerprint TLV MUST be included in Intermediate System ID Detection and Resolution Procedures to
   Intermediate System Hellos (IIHs) originated by a router operating in
   auto-configuration mode.

   Router Fingerprint TLV MUST be included in Link State PDU (LSP) #0
   originated by a router operating in auto-configuration mode.  The
   router fingerprint TLV MUST NOT be included in an LSP with a non-zero
   number.

3.4.  Protocol Operation

   This section describes the duplicate System ID detection and
   resolution process between two neighbors and two non-neighbors
   respectively.  This is due to difference operation of a router supporting auto-
   configuration mode.

3.4.1.  Start-Up mode

   When a router starts operation in auto-configuration mode, both the the routing messages
   between neighbors S
   and non-neighbors.

3.3.2.1.  Start-up Mode

   While A bits MUST be set in Start-up Mode, an auto-configuration router forms
   adjacencies but generates the Router Fingerprint TLV included in both
   hellos and LSP #0.  During this mode only LSP #0 which contains only the Router-
   Fingerprint TLV. is generated and IS
   or IP/IPv6 reachability TLVs MUST NOT be included in LSP #0.  A
   router remains in startup-mode until it 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
   successfully completed LSPDB elapsed and full LSP database
   synchronization is achieved 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 UP state.

   When a new System ID (subject to
   rules defined router exits startup-mode it clears the S bit in Section 3.3.2.2 ), Router
   Fingerprint TLVs it sends in hellos and re-enter Start-up Mode. 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.

   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  Any
   System ID change during Start-up mode will have minimal impact on a
   running network because the while in Start-up Mode
   node mode the router 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

3.4.2.  Adjacency Formation

   Routers operating in
   Section 3.3.2.2 and Section 3.3.2.3.

   When an IS-IS auto-configuration router boots up, it mode MUST operate NOT form
   adjacencies with routers which are NOT operating in
   Startup-Mode until duplicate System ID detection has successfully
   completed.

3.3.2.2.  Duplication Between Neighbors

   In the case auto-
   configuration mode.  The presence of duplicate System IDs being detected between neighbors,
   an IS-IS auto-configuration router MUST include the Router- Router Fingerprint TLV in with
   the Hello messages, so that A bit set indicates the duplication can be
   detected before an adjacency router is formed.

   Start-up Mode procedures:

   1.  Boot up and advertisement of the Router-Fingerprint TLV operating in Hello
       messages auto-configuration
   mode.

   NOTE: The use of the special area address of all 0's makes it
   unlikely that a router sends Hello messages which include the Router-
          Fingerprint TLV.  Adjacencies are formed as normal but MUST
          NOT is not operating in auto-configuration
   mode will be advertised in LSPs until the same area as a 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, operating in auto-
   configuration mode.  However, the router MUST check for the S flag of the Router-Fingerprint TLV.

          +  If the S flag is NOT Router Fingerprint
   TLV with A bit set (which means the Hello message was
             NOT generated by a Start-up Mode neighbor), then the router
             MUST re-generate the provides additional protection.

3.4.3.  IS-IS System ID Duplication Detection and re-enter Start-up Mode.

          +  If the S flag is set (meaning the neighbor is also in
             Start-up Mode),

             - Resolution

   The router which has a numerically smaller Router-
                Fingerprint MUST re-generate its System ID and re-enter
                Start-up Mode.  Fingerprint comparison of each node MUST be performed
                octet by octet starts from the left until a difference
                is found.  Then, unique.  As described in
   Section 3.4.5, the numeric smaller fingerprint System ID is the
                one with the lowest value.  If the fingerprints have
                different lengths, then the shorter length fingerprint
                MUST generated based on entropies (e.g.
   MAC address) which are generally expected to be padding with zero at the left side for
                comparison.

             -  If unique.  However,
   since there may be limitations to the Router Fingerprints are identical, both routers
                MUST re-generate available entropies, there is
   still the possibility of System ID duplication.  This section defines
   how IS-IS detects and the Router
                Fingerprint, and re-enter Start-up Mode.

   3.  Normal operation

          After the resolves 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 duplication.  Duplicate
   System ID may occur between neighbors or between routers in received Hello messages

          When receiving a Hello message, the router MUST check the same
   area which are not neighbors.

   Duplicate System ID of the Hello.  If with a neighbor is detected when the System ID
   received in an IIH is identical to the same as its
          own, it indicates that local System ID duplication has occurred.

          If there is no and the
   Router-Fingerprint TLV in the received Hello
          message, this is interpreted as the attached router either
          does not support auto-configuration, or Router-Fingerprint TLV does not have it
          enabled.  In this case, the auto-configuration router MUST NOT
          form adjacency
   match the locally generated Router-Fingerprint.

   Duplicate System ID with a non-neighbor is detected when an LSP #0 is
   received, the non-autoconfiguration router.

   2.  Duplication resolution 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.

3.4.4.  Duplicate System ID Resolution Procedures

   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.

   The contents of the Router-Fingerprint TLVs for the two routers with
   duplicate System IDs are detected, compared.

   If one TLV has the non-startup mode
          router MUST check S bit set (router is in Start-up mode) and one TLV
   has the S flag of bit clear (router is NOT in Start-up mode) the duplicated Router-
          Fingerprint TLV:

          + router in
   Start-up mode MUST generate a new System ID and restart the protocol.

   If both TLVs have the S flag bit set (both routers are in Start-up mode)
   or both TLVs have the S bit clear (neither router is NOT set, in Start-up
   mode) then the router with the numerically smaller or equal Router-Fingerprint
   MUST generate a new System ID.  Note that, the router MUST
             compare ID and restart the two Router-Fingerprint protocol.

   Fingerprint comparison is performed octet by octet starting from the
   first received octet until a difference is found.

          + 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.

   If the fingerprints are identical in both content and length (and
   state of the S flag bit is set, no further action identical) and the duplication is necessary detected in
   hellos then the
             Duplication resolution process.

   3.  Re-joining the network with both routers MUST generate a new System ID (if required)

          The router that has changed its System ID advertises new
          Hellos containing and
   restart the newly generated System ID to re-join the
          IS-IS auto-configuration network.  The conflicting SysID-
          duplicated router also MUST increase the sequence number and
          re-advertise its own Hellos.

          The Duplication Detection process SHOULD be repeated with the
          newly generated System.

3.3.2.3.  Duplication Between Non-neighbors

   System ID duplication may also occur between non-neighbors, therefore
   an IS-IS auto-configuration router MUST also include the Router-
   Fingerprint TLV in its LSP messages.  The specific procedures protocol.

   If fingerprints are as
   follows:

   Start-up Mode procedures:

   1.  Boot up, adjacency formation

   2.  Acquiring LSPDB and checking System ID duplication

          The router generates only an LSP #0 which contains only the
          Fingerprint TLV; and that Fingerprint is only sent in LSP #0.
          A router remains identical 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
             a Non Start-up Mode node, then the router itself MUST clear
             all adjacencies, re-generate a new system-id both content and reenter
             Start-up Mode.

          +  If the S flag is set, then the router which has a
             numerically smaller Router-Fingerprint MUST generate a new
             System ID length and reenter Start-up Mode.

   3.  Running in normal operation

          After the System ID
   duplication procedure is done, the router
          begins to run detected in normal operation.  The router MUST re-
          advertise the Router-Fingerprint TLV with the S flag off.

   Non Start-up Mode procedures:

   1.  Checking the received Router-Fingerprint TLVs

          When receiving a LSP containing its own System ID, the router
          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 System ID duplication occurs, 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 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, then router does nothing.

   3.  Re-joining the network with the new System ID

          The router changing its System ID advertises new LSPs based on
          the newly generated System ID to re-join the IS-IS auto-
          configuration network.  The other SysID-duplicated router also
          MUST re-advertise its own LSP (after increasing the sequence
          number).

          The newly generated System ID SHOULD perform duplication
          detection as well.

3.3.3. #0 then the procedures defined in
   Section 3.4.6 MUST be followed.

3.4.5.  System ID and Router-Fingerprint Generation Considerations

   As specified in this document, there are two distinguishing items
   that need to be self-generated: the System ID and Router-Fingerprint.
   In a network device, normally there are some resources which can
   provide an extremely high probability of uniqueness thus could be
   used as seeds to derive distinguisher (e.g.  hashing or generating
   pseudo-random numbers), such as:

   o  MAC address(es)

   o  Configured IP address(es)

   o  Hardware IDs (e.g.  CPU ID)

   o  Device serial number(s)

   o  System clock at a certain specific time

   o  Arbitrary received packet(s) on an interface(s)

   This document recommends the use of an IEEE 802 48-bit MAC address
   associated with the router as the initial System ID.  This document
   does not specify a specific method to re-generate the System ID when
   duplication happens.

   This document also does not specify a specific method to generate the
   Router-Fingerprint.  However, the generation of System ID and Router-
   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
   address) might not be available in some small devices such as home
   routers.  This is because of hardware/software limitations and the
   lack of sufficient communication packets at the initial stage in home
   routers when doing ISIS auto-configuration.  In this case, this
   document suggests using the MAC address as System ID MAC address as System ID and generating a
   pseudo-random number based on another seed (such as the memory
   address of a certain variable in the program) as the Router-
   Fingerprint.  The pseudo-random number might not have a very high
   probability of uniqueness in this solution, but should be sufficient
   in home networks scenarios.

   The considerations surrounding System ID stability described in
   section Section 3.2 also need to be applied.

3.4.6.  Double-Duplication of both System ID and Router-Fingerprint

   As described above, the resources for generating System ID/
   Fingerprint might be very constrained during the initial stages.
   Hence, the double-duplication of both System ID and Router-
   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.

   In a benign case, this will occur if a router restarts and it
   receives copies of its own LSPs from its previous incarnation.  This
   benign case needs to be distinguished from the pathological case
   where there are two different routers with the same System ID and the
   same Router-Fingerprint.

   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
   version.  This will cause other routers in the network to update
   their LSPDB and generating a
   pseudo-random number based on another seed (such as synchronization will be achieved.

   In the memory
   address pathological case the generation of a certain variable in new version of an LSP by
   one of the program) as "twins" will cause the Router-
   Fingerprint.  The pseudo-random number might not have other twin to generate the same LSP
   with a very high
   probability higher sequence number - and oscillation will continue without
   achieving LSPDB synchronization.

   Note that comparison of uniqueness S bit in this solution, but should the Router-Fingerprint TLV cannot be sufficient
   in home networks scenarios.

   The considerations surrounding System ID stability described
   performed as in
   section Section 3.2 also need to be applied.

3.3.4.  Double-Duplication of both System ID and Router-Fingerprint

   As described above, the resources for generating benign case it is expected that the distinguisher
   might S bit will be very constrained during the initial stages.  Hence,
   clear.  Also note that the
   double-duplication of both conditions for detecting duplicate System
   ID and Router-Fingerprint needs to will NOT be considered.

   ISIS-autoconfiguring routers SHOULD support detecting satisfied because both the System ID
   duplication by LSP war.  LSP war and the Router-
   Fingerprint will be identical.

   The following procedure is defined:

       DD-state is a phenomenon whereby a router
   receives boolean which indicates if 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
         DD-LSP #0 has (e.g.
   it advertises IP prefixes that the router does not own, or IS
   neighbors that the router does not see), then per been received
       DD-count is the ISIS
   specification, count of the router must re-originate its LSP number of occurences
         of reception of a DD-LSP
       DD-timer is a timer associated with an increased
   sequence number. 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.

   When a DD-LSP is received:

     If DD-state is FALSE:
       DD-state is set to TRUE
       DD-timer is started
       DD-count is initialized to 1.

     If double-duplication happens, the duplicated two
   routers will both continuously repeat the above behavior.  After
   multiples iterations, DD-state is TRUE:
       DD-count is incremented
       If DD-count is >= DD-max:
          Local system MUST generate a new System ID
           and Router-Fingerprint and restart the program should be able protocol
          DD-state is (re)initialized to FALSE and
           DD-timer cancelled.

     If DD-timer expires:
       DD-state is set to deduce FALSE.

   Note that to minimze the likelihood of double-duplication is occurring.

   When this condition is detected, reoccuring,
   routers should SHOULD have much more entropies available.  Thus, the router is able to extend or re-
   generate its Router-Fingerprint (one  One simple way to
   achieve this is just adding to add the LSP sequence number of the next LSP it
   will send to the Router-
   Fingerprint).

3.4. Router-Fingerprint.

3.5.  Additional IS-IS TLVs Usage Guidelines

   This section describes the behavior of selected TLVs that are necessary for when used by a
   router supporting IS-IS auto-
   configuration.

3.4.1. auto-configuration.

3.5.1.  Authentication TLV

   It is RECOMMENDED that IS-IS routers supporting this specification
   minimally
   offer an option to explicitly configure a single password for HMAC-MD5 authentication, which is Type 54 HMAC-
   MD5 authentication mode of
   [RFC5304].  In this case, the Authentication TLV (TLV 10) is needed.

3.4.2.  Wide Metric TLV

   IS-IS auto-configuration routers MUST support TLVs using wide metrics as defined specified in[RFC5304].

3.5.2.  Metric Used in [RFC5305]). Reachability TLVs

   It is RECOMMENDED that IS-IS auto-configuration routers use a high
   metric value (e.g. 1000000) 100000) as default in order to typically prefer allow manually
   configured adjacencies to be preferred over auto-configuringed.

3.4.3. auto-configured.

3.5.3.  Dynamic Host Name TLV

   IS-IS auto-configuration routers MAY advertise their Dynamic Host
   Names
   Name TLV (TLV 137, [RFC5301]).  The host names 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 names, name, the System ID SHOULD be
   appended as a suffix in the names.

3.5.  Routing Behavior Considerations

3.5.1.  Adjacency Formation

   Since IS-IS does not require strict hold timer matching to form
   adjacency, this document does not specify specific hold timers.
   However, the timers should be within a reasonable range based on
   current practise in the industry.  (For example, the defaults defined
   in [ISO_IEC10589] .)

4.  Security Considerations

   In general, auto-configuration the use of authentication is mutually incompatible with
   authentication.  This is a common problem that IS-IS auto-
   configuration can not avoid. as it requires some manual configuration.

   For wired deployment, the wired connection itself could be considered
   as an implicit authentication in that unwanted routers are usually
   not able to connect (i.e. there is some kind of physical security in
   place preventing the connection of rogue devices); for wireless
   deployment, the authentication could be achieved at the lower
   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

   IANA is kindly requested to assign

   This document requires the definition of a new IS-IS TLV for the Router-
   Fingerprint from to be
   reflected in the IS-IS "IS-IS TLV Codepoint registry. Codepoints" registry:

   Type  Description                       IIH LSP SNP Purge
   ----  ------------                      --- --- --- -----
   TBA   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 [RFC2629]. [RFC7749].
   (initially prepared using 2-Word-v2.0.template.dot.  )

7.  References

7.1.  Normative References

   [ISO_IEC10589]
              ""Intermediate System
              "Intermediate system to Intermediate System system intra-domain
              routeing information exchange protocol for use in
              conjunction with the protocol for providing the
              connectionless-mode network service Network Service (ISO 8473)", 8473), ISO/IEC
              10589", November
              10589:2002, Second Edition.", Nov 2002.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <http://www.rfc-editor.org/info/rfc1195>.

   [RFC2629]  Rose, M., "Writing I-Ds and

   [RFC2119]  Bradner, S., "Key words for use in RFCs using XML", to Indicate
              Requirement Levels", BCP 14, RFC 2629, 2119,
              DOI 10.17487/RFC2629, June 1999,
              <http://www.rfc-editor.org/info/rfc2629>. 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC5301]  McPherson, D. and N. Shen, "Dynamic Hostname Exchange
              Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301,
              October 2008, <http://www.rfc-editor.org/info/rfc5301>.

   [RFC5304]  Li, T. and R. Atkinson, "IS-IS Cryptographic
              Authentication", RFC 5304, DOI 10.17487/RFC5304, October
              2008, <http://www.rfc-editor.org/info/rfc5304>.

   [RFC5305]  Li, T. and H. Smit, "IS-IS Extensions for Traffic
              Engineering", RFC 5305, DOI 10.17487/RFC5305, October
              2008, <http://www.rfc-editor.org/info/rfc5305>.

   [RFC5308]  Hopps, C., "Routing IPv6 with IS-IS", RFC 5308,
              DOI 10.17487/RFC5308, October 2008,
              <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

   [RFC7503]  Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration",
              RFC 7503, DOI 10.17487/RFC7503, April 2015,
              <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

   Bing Liu (editor)
   Huawei Technologies
   Q10, Huawei Campus, No.156 Beiqing Road
   Hai-Dian District, Beijing, 100095
   P.R. China

   Email: leo.liubing@huawei.com

   Bruno Decraene
   Orange
   France

   Email: bruno.decraene@orange.com

   Ian Farrer
   Deutsche Telekom AG
   Bonn
   Germany

   Email: ian.farrer@telekom.de

   Mikael Abrahamsson
   T-Systems
   Stockholm
   Sweden

   Email: mikael.abrahamsson@t-systems.se

   Les Ginsberg
   Cisco Systems
   510 McCarthy Blvd.
   821 Alder Drive
   Milpitas  CA 95035
   USA

   Email: ginsberg@cisco.com