One document matched: draft-liu-isis-auto-conf-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-liu-isis-auto-conf-04" ipr="trust200902">
<front>
<title abbrev="draft-liu-isis-auto-conf-04">ISIS
Auto-Configuration</title>
<author fullname="Bing Liu" initials="B." surname="Liu">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Q14, Huawei Campus, No.156 Beiqing Road</street>
<city>Hai-Dian District, Beijing, 100095</city>
<country>P.R. China</country>
</postal>
<email>leo.liubing@huawei.com</email>
</address>
</author>
<author fullname="Bruno Decraene" initials="B." surname="Decraene">
<organization>Orange</organization>
<address>
<postal>
<street/>
<city>Issy-les-Moulineaux FR</city>
<country>FR</country>
</postal>
<email>bruno.decraene@orange.com</email>
</address>
</author>
<author fullname="Ian Farrer" initials="I." surname="Farrer">
<organization>Deutsche Telekom AG</organization>
<address>
<postal>
<street/>
<city>Bonn</city>
<country>Germany</country>
</postal>
<email>ian.farrer@telekom.de</email>
</address>
</author>
<author fullname="Mikael Abrahamsson" initials="M." surname="Abrahamsson">
<organization>T-Systems</organization>
<address>
<postal>
<street/>
<city>Stockholm</city>
<country>Sweden</country>
</postal>
<email>mikael.abrahamsson@t-systems.se</email>
</address>
</author>
<date day="30" month="May" year="2015"/>
<area>Routing Area</area>
<workgroup>isis</workgroup>
<keyword>isis auto-configuration</keyword>
<abstract>
<t>This document specifies an IS-IS auto-configuration technology. The
key mechanisms of this technology are IS-IS NET (Network Entity Title)
self-generation, duplication detection and duplication resolution. This
technology fits the environment where plug-and-play is expected, e.g.,
home networks and small or medium size enterprise networks.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document describes mechanisms for IS-IS <xref target="RFC1195"/>
<xref target="RFC5308"/> to be auto-configuring. Such mechanisms could
reduce the management burden to configure a network. Home networks and
small or medium size enterprise networks where plug-n-play is expected
can benefit from these mechanisms.</t>
<t>In addition, this document defines how such un-configured routers
should behave, in order to limit the risk on existing network using
IS-IS (please refer to <xref target="AuthTLV"/> and<xref
target="behavior"> </xref>).</t>
<t>IS-IS auto-configuration contains the following aspects:<list
style="numbers">
<t hangText="-">IS-IS default configurations</t>
<t hangText="-">IS-IS NET (Network Entity Title) self-generation</t>
<t hangText="-">NET duplication detection and resolution</t>
<t hangText="-">ISIS TLVs utilization such as Authentication TLV,
Wide Metric TLV etc.</t>
</list></t>
</section>
<section title="Scope">
<t>The auto-configuring mechanisms does not specifically distinguish
IPv4 or IPv6.</t>
<t>This auto-configuration mechanism aims at simple case. The following
advanced features are out of scope:<list style="hanging">
<t hangText="o">Multiple IS-IS instances</t>
<t hangText="o">Multi-area and level-2 routers</t>
<t hangText="o">Interworking with other routing protocols</t>
</list></t>
</section>
<section title="Protocol Specification ">
<t/>
<section title="IS-IS Default Configuration">
<t><list style="hanging">
<t hangText="o">IS-IS SHOULD be enabled as default on all
interfaces in a router that requires the IS-IS auto-configuration.
For some specific situations, interface MAY be excluded if it is a
clear that running IS-IS auto-configuration on the interface is
not required.</t>
<t hangText="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.</t>
<t hangText="o">IS-IS auto-configuration interfaces MUST be
configured with level-1.</t>
</list></t>
</section>
<section title="IS-IS NET Generation">
<t>In IS-IS, a router (known as an Intermediate System) is identified
by an NET which is the address of a Network Service Access Point
(NSAP) and represented with an IS-IS specific address format. The NSAP
is a logical entity which represents an instance of the IS- IS
protocol running on an IS.</t>
<t>The NET consists of three parts. The auto-generation mechanisms of
each part are described as the following:</t>
<t><list style="hanging">
<t hangText="o">Area address<list style="empty">
<t>This field is 1 to 13 octets in length. In IS-IS
auto-configuration, this field MUST be 0 in 13 octets
length.</t>
</list></t>
<t hangText="o">System ID<list style="empty">
<t>This field follows the area address field, and is 6 octets
in length. There are two basic requirements for the System ID
generation:<list style="hanging">
<t hangText="-">As specified in IS-IS protocol, this field
must be unique among all routers in the same area.</t>
<t hangText="-">In order to make the routing system
stable, the System ID SHOULD remain the same after it is
firstly generated. It SHOULD not be changed due to device
status change (such as interface enable/disable, interface
plug in/off, device reboot, firmware update .etc) or
configuration change (such as changing system
configurations or IS-IS configurations .etc); but it MUST
allow be changed by collision resolution and SHOULD allow
be cleared by user enforced system reset.</t>
</list></t>
<t>More specific considerations for SysID generation are
described in <xref target="Unique"/> .</t>
</list></t>
<t hangText="o">NSEL<list style="empty">
<t>This field is the N-selector, and is 1 octet in length. In
IS- IS auto-configuration, it SHOULD be set to "00".</t>
</list></t>
</list></t>
</section>
<section title="IS-IS NET Duplication Detection and Resolution">
<t>NET addresses need to be distinct within one IS-IS area. As
described in <xref target="Unique"/>, the NET address is generated
based on entropies such as MAC address which are supposed to be
unique, but in theory there is still possibility of duplication. This
section defines how IS-IS detects and corrects NET duplication.</t>
<section title="Router-Fingerprint TLV">
<t>The Router-Fingerprint TLV re-uses the design of
Router-Hardware-Fingerprint TLV defined in <xref
target="RFC7503"/>.</t>
<t><figure>
<artwork align="center"><![CDATA[ 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Fingerprint (Variable) |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]></artwork>
</figure></t>
<t>The length of the Router-Fingerprint is variable but must be 32
octets or greater; and the content is also supposed to be unique
among all the routers.</t>
<t>More specific considerations for Router-Fingerprint is described
in <xref target="Unique"/> .</t>
</section>
<section title="NET Duplication Detection and Resolution Procedures">
<t>1) Flood the Router-Distinguisher TLVs<list style="empty">
<t>When an IS-IS auto-configuration router gets online, it MUST
include the Router-Fingerprint TLV in the first originated
level-1 LSP. Then all the routers in the area could receive the
information in the TLV.</t>
</list></t>
<t>2) Compare the received Router-Fingerprint TLVs<list
style="empty">
<t>When receiving a LSP having its own NET address, an IS-IS
router MUST check the Router-Fingerprint TLV. If the
Router-Fingerprint TLV is different from its own, there is a NET
duplication and the following procedure SHOULD be performed.
</t>
</list></t>
<t>3) Duplication resolution<list style="empty">
<t>When NET duplication occurs, the router with the numerically
smaller Router-Fingerprint MUST generate a new NET. Note that,
the router MUST compare the two Router-Fingerprint in terms of
two numeric numbers (e.g. Unsigned integer).</t>
</list></t>
<t>4) Re-join the network with the new NET<list style="empty">
<t>The router with the smaller Router-Fingerprint advertise new
LSPs based on the newly generated NET to re-join the IS-IS
auto-configuration network.</t>
<t>Note that, since the other router still uses the old NET, the
smaller Router-Distinguisher router MUST NOT purge it's LSPs;
the router with the highest Router-Distinguisher MUST
re-advertise its own LSP (after increasing the sequence
number).</t>
<t>The newly generated NET SHOULD take a NET duplication
detection as well.</t>
</list></t>
</section>
<section anchor="Unique"
title="SysID and Router-Fingerprint Generation Considerations">
<t>As specified in this document, there are two distinguisher need
to be self-generated, which is SysID and Router-Fingerprint. In a
network device, normally there are resources which 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:</t>
<t><list style="symbols">
<t>MAC address(es)</t>
<t>Configured IP address(es)</t>
<t>Hardware IDs (e.g. CPU ID)</t>
<t>Device serial number(s)</t>
<t>System clock at a certain specific time</t>
<t>Arbitrary received packet</t>
</list>This document does not specify a certain method to generate
the SysID and Router-Fingerprint. However, the generation of SysID
and Router-Fingerprint MUST be based on different seeds so that the
two distinguisher would not collide.</t>
<t>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 the hardware/software limitation
and the lack of sufficient communication packets at the initial
stage in the home routers when doing ISIS-autoconfiguration. In this
case, this document suggests to use MAC address as SysID and
generate a pseudo-random number based on another seed (such as the
memory address of a certain variable in the program) as
Router-Fingerprint. The pseudo-random number might not have a very
high quality in this solution, but should be sufficient in home
networks scenarios.</t>
<t>Note that, the Router-Fingerprint SHOULD also remain the same
after it is firstly generated. It SHOULD not be changed due to
device status change (such as interface enable/disable, interface
plug in/off, device reboot, firmware update .etc) or configuration
change (such as changing system configurations or IS-IS
configurations .etc); but it MUST allow be changed by
double-duplication resolution <xref target="DDuplct"/> and SHOULD
allow be cleared by user enforced system reset.</t>
<t/>
</section>
<section anchor="DDuplct"
title="Double-Duplication of both NET and Router-Fingerprint">
<t>As described above, the resources for generating the
distinguisher might be very constrained at the initial stage. Hence,
the double-duplication of both NET and Router-Fingerprint needs to
be considered. </t>
<t>ISIS-autoconfiguring routers SHOULD support detecting NET
duplication by LSP war. LSP war is a phenomenon that if a router
receives a LSP originated with it's NET, but it doesn't find it in
the database, or it does not match the one the router has (e.g. It
advertises IP prefixes that the router doesn't own, or IS neighbors
that the router doesn't see), then Per 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 have the above behavior. After multiples iterations,
the program should be able to deduce that double-duplication
happens.</t>
<t>At the point when double-duplication happens, routers should have
much more entropies available. Thus, the router is to extend or
re-generate its Router-Fingerprint (one simple way is just adding
the LSP sequence number of the next LSP it will send to the
Router-Fingerprint). </t>
<t> </t>
</section>
</section>
<section title="IS-IS TLVs Usage">
<t/>
<section anchor="AuthTLV" title="Authentication TLV">
<t>Every IS-IS auto-configuration message MUST include an
authentication TLV (TLV 10, <xref target="RFC5304"/>) with the Type
1 authentication mode ("Cleartext Password") in order to avoid the
auto-conf router to accidentally join an existing IS-IS network
which is not intended to be auto-configured.</t>
<t>This feature is necessary since it might seriously break an
existing IS-IS network or cause unnecessary management confusion if
a low end CPE (which might be the normal form of ISIS-autoconf
routers) occasionally joins the network.</t>
<t>The cleartext password is specified as "isis-autoconf". Routers
that implement IS-IS auto-configuration MUST use this password as
default, so that different routers could authenticate each other
with no human intervene as default. And routers MUST be able to set
manual password by the users.</t>
</section>
<section title="Wide Metric TLV">
<t>IS-IS auto-configuration routers SHOULD support wide metric (TLV
22, <xref target="RFC5305"/>). It is recommended that IS-IS
auto-configuration routers use a high metric value (e.g. 1000000) as
default in order to typically prefer the manually configured
adjacencies rather than the auto-conf ones.</t>
</section>
<section title="Dynamic Host Name TLV">
<t>IS-IS auto-configuration routers SHOULD advertise their Dynamic
Host Names TVL (TLV 137, <xref target="RFC5301"/>). The host names
could be provisioned by an IT system, or just use the name of
vendor, device type or serial number etc.</t>
</section>
<section title="Purge Originator Identification TLV">
<t>For troubleshooting purpose, the Purge Originator Identification
TLV (TLV 13, <xref target="RFC6232"/>) MAY be used to determine the
origin of the purge. Please refer to <xref target="RFC6232"/> for
details.</t>
</section>
</section>
<section anchor="behavior" title="Routing Behavior Considerations">
<t/>
<section title="Adjacency Formation">
<t>Since ISIS does not require strict hold timers 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, 30 seconds for
holdtime and 20 minutes for LSP lifetime.)</t>
</section>
<section title="Co-existing with Other IGP Auto-configuration">
<t>If a router supports multiple IGP auto-configuration mechanisms
(e.g. Both IS-IS auto-configuration and OSPF auto-configuration),
then in practice it is a problem that there should be a mechanism to
decide which IGP to be used, or even both.</t>
<t>However, the behavior of multiple IGP protocols interaction
should be done in the router level rather than in any IGP protocols.
For example, with the Home Network Control Protocol (<xref
target="I-D.ietf-homenet-hncp"/>), the routers could achieve a
consensus on what IGP to use.</t>
</section>
</section>
</section>
<section title="Security Considerations">
<t>In general, auto-configuration is mutually incompatible with
authentication. So we can't have both. This is not really specific to
IS-IS.</t>
<t>Unwanted routers could easily join in an existing IS-IS
auto-configuration network by setting the authentication password as
"isis-autoconf" default value or sniff the cleartext password online.
However, this is a common security risk shared by other IS-IS networks
that don't set proper authentication mechanisms. For wired deployment,
the wired line itself could be considered as an implicit authentication
that normally unwanted routers are not able to connect to the wire line;
for wireless deployment, the authentication could be achieve at the
lower wireless link layer.</t>
<t>Malicious router could modify the SysID field to cause NET
duplication detection and resolution vibrate thus cause the routing
system vibrate.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>The Router Hardware Fingerprint TLV type code needs an assignment by
IANA.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>This document was heavily inspired by [RFC7503].</t>
<t>Martin Winter, Christian Franke and David Lamparter gave essential
feedback to improve the technical design based on their implementation
experience. Many useful comments and contributions were made by Sheng
Jiang, Qin Wu, Hannes Gredler, Peter Lothberg, Uma Chundury, Nan Wu,
Acee Lindem, Les Ginsberg and some other people in ISIS working
group.</t>
<t>This document was produced using the xml2rfc tool <xref
target="RFC2629"/>. (initially prepared using 2-Word-v2.0.template.dot.
)</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.1195'?>
<?rfc include='reference.RFC.2629'?>
<?rfc include='reference.RFC.5301'?>
<?rfc include='reference.RFC.5304'?>
<?rfc include='reference.RFC.5305'?>
<?rfc include='reference.RFC.5308'?>
<?rfc include='reference.RFC.6232'?>
<?rfc ?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.7503'?>
<?rfc include='reference.I-D.ietf-homenet-hncp'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 06:12:53 |