1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
|
<pre>Internet Engineering Task Force (IETF) B. Liu, Ed.
Request for Comments: 8196 Huawei Technologies
Category: Standards Track L. Ginsberg
ISSN: 2070-1721 Cisco Systems
B. Decraene
Orange
I. Farrer
Deutsche Telekom AG
M. Abrahamsson
T-Systems
July 2017
<span class="h1">IS-IS Autoconfiguration</span>
Abstract
This document specifies IS-IS autoconfiguration mechanisms. The key
components are IS-IS System ID self-generation, duplication
detection, and duplication resolution. These mechanisms provide
limited IS-IS functions and are therefore suitable for networks where
plug-and-play configuration is expected.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc8196">http://www.rfc-editor.org/info/rfc8196</a>.
<span class="grey">Liu, et al. Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-1.1">1.1</a>. Requirements Language . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-3">3</a>. Protocol Specification . . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.1">3.1</a>. IS-IS Default Configuration . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.2">3.2</a>. IS-IS NET Generation . . . . . . . . . . . . . . . . . . <a href="#page-4">4</a>
<a href="#section-3.3">3.3</a>. Router-Fingerprint TLV . . . . . . . . . . . . . . . . . <a href="#page-6">6</a>
<a href="#section-3.4">3.4</a>. Protocol Operation . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.4.1">3.4.1</a>. Startup Mode . . . . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3.4.2">3.4.2</a>. Adjacency Formation . . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.4.3">3.4.3</a>. IS-IS System ID Duplication Detection . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.4.4">3.4.4</a>. Duplicate System ID Resolution Procedures . . . . . . <a href="#page-8">8</a>
3.4.5. System ID and Router-Fingerprint Generation
Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
3.4.6. Duplication of Both System ID and Router-Fingerprint 10
<a href="#section-3.5">3.5</a>. Additional IS-IS TLVs Usage Guidelines . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-3.5.1">3.5.1</a>. Authentication TLV . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-3.5.2">3.5.2</a>. Metric Used in Reachability TLVs . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-3.5.3">3.5.3</a>. Dynamic Name TLV . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-4">4</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5">5</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6.1">6.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-13">13</a>
<a href="#section-6.2">6.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-14">14</a>
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-15">15</a>
<span class="grey">Liu, et al. Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies mechanisms for IS-IS [<a href="./rfc1195" title=""Use of OSI IS-IS for routing in TCP/IP and dual environments"">RFC1195</a>] [<a href="#ref-ISO_IEC10589">ISO_IEC10589</a>]
[<a href="./rfc5308" title=""Routing IPv6 with IS-IS"">RFC5308</a>] to be autoconfiguring. Such mechanisms could reduce the
management burden for configuring a network, especially where plug-
and-play device configuration is required.
IS-IS autoconfiguration is comprised of the following functions:
1. IS-IS default configuration
2. IS-IS System ID self-generation
3. System ID duplication detection and resolution
4. IS-IS TLV utilization (authentication TLV, metrics in
reachability advertisements, and Dynamic Name TLV)
This document also defines mechanisms to prevent the unintentional
interoperation of autoconfigured routers with non-autoconfigured
routers. See <a href="#section-3.3">Section 3.3</a>.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Requirements Language</span>
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 <a href="https://www.rfc-editor.org/bcp/bcp14">BCP</a>
<a href="https://www.rfc-editor.org/bcp/bcp14">14</a> [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] [<a href="./rfc8174" title=""Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"">RFC8174</a>] 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 [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>] key words.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Scope</span>
The autoconfiguration mechanisms support both IPv4 and IPv6
deployments.
These autoconfiguration 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
<span class="grey">Liu, et al. Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
IS-IS autoconfiguration is primarily intended for use in small (i.e.,
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
recommended for larger deployments.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Protocol Specification</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. IS-IS Default Configuration</span>
This section defines the default configuration for an autoconfigured
router.
o IS-IS interfaces MUST be autoconfigured to an interface type
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 MaxAreaAddresses is set to 3.
o Extended IS reachability (TLV 22) and IP reachability (TLV 135)
TLVs [<a href="./rfc5305" title=""IS-IS Extensions for Traffic Engineering"">RFC5305</a>] MUST be used, i.e., a router operating in
autoconfiguration mode MUST NOT use any of the following TLVs:
* IIS Neighbors (TLV 2)
* IP Int. Reach (TLV 128)
* IP Ext. Address (TLV 130)
The TLVs listed above MUST be ignored on receipt.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. IS-IS NET Generation</span>
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
Access Point (NSAP). The NET is the address of an instance of the
IS-IS protocol running on an IS.
<span class="grey">Liu, et al. Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
The autoconfiguration mechanism generates the IS-IS NET as the
following:
o Area address
In IS-IS autoconfiguration, this field MUST be 13 octets long
and set to all 0s.
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. Changes such as interface enable/disable, interface
connect/disconnect, device reboot, firmware update, or
configuration changes SHOULD NOT cause the System ID to
change. System ID change as part of the System ID collision
resolution process MUST be supported. Implementations
SHOULD allow the System ID to be cleared by a user-initiated
system reset.
More specific considerations for System ID generation are
described in <a href="#section-3.4.5">Section 3.4.5</a>.
<span class="grey">Liu, et al. Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. Router-Fingerprint TLV</span>
The Router-Fingerprint TLV is similar to the Router-Hardware-
Fingerprint TLV defined in [<a href="./rfc7503" title=""OSPFv3 Autoconfiguration"">RFC7503</a>]. However, the TLV defined here
includes a Flags field to support indicating that the router is in
startup mode and is operating in autoconfiguration 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Flags | |
+-+-+-+-+-+-+-+-+ Router-Fingerprint (Variable) .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: 15.
Length: The length, in octets, of the "Flags" and "Router-
Fingerprint" fields.
Flags: 1 octet.
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
<a href="#section-3.4.5">Section 3.4.5</a>.
<span class="grey">Liu, et al. Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
The Router-Fingerprint TLV with the A flag set MUST be included in
IS-IS Hellos (IIHs) originated by a router operating in
autoconfiguration mode. An autoconfiguration mode router MUST ignore
IIHs that don't contain the Router-Fingerprint TLV with the A flag
set.
The Router-Fingerprint TLV with the A flag set MUST be included in
Link State PDU (LSP) #0 originated by a router operating in
autoconfiguration mode. If an LSP #0 is received by a router
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
be ignored when running the Decision Process.
The Router-Fingerprint TLV MUST NOT be included in an LSP with a non-
zero number and when received MUST be ignored.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. Protocol Operation</span>
This section describes the operation of a router supporting
autoconfiguration mode.
<span class="h4"><a class="selflink" id="section-3.4.1" href="#section-3.4.1">3.4.1</a>. Startup Mode</span>
When a router starts operation in autoconfiguration mode, both the S
and A flags MUST be set in the Router-Fingerprint TLV included in
both hellos and LSP #0. During this mode, only LSP #0 is generated
and IS or IP/IPv6 reachability TLVs MUST NOT be included in LSP #0.
A router remains in startup 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
startup mode once the minimum time has elapsed and full LSP database
synchronization is achieved with all neighbors in the UP state.
When a router exits startup mode, it clears the S flag in Router-
Fingerprint TLVs that it sends in hellos and LSP #0. The router MAY
now advertise the IS neighbor and IP/IPv6 prefix reachability in its
LSPs and MAY generate LSPs with a non-zero number.
The purpose of startup mode is to minimize the occurrence of System
ID changes for a router once it has become fully operational. Any
System ID change during startup mode will have minimal impact on a
running network because, while in startup mode, the router is not yet
being used for forwarding traffic.
<span class="grey">Liu, et al. Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
<span class="h4"><a class="selflink" id="section-3.4.2" href="#section-3.4.2">3.4.2</a>. Adjacency Formation</span>
Routers operating in autoconfiguration mode MUST NOT form adjacencies
with routers that are NOT operating in autoconfiguration mode. The
presence of the Router-Fingerprint TLV with the A flag set indicates
the router is operating in autoconfiguration mode.
NOTE: The use of the special area address of all 0s makes it unlikely
that a router that is not operating in autoconfiguration mode will be
in the same area as a router operating in autoconfiguration mode.
However, the check for the Router-Fingerprint TLV with the A flag set
provides additional protection.
<span class="h4"><a class="selflink" id="section-3.4.3" href="#section-3.4.3">3.4.3</a>. IS-IS System ID Duplication Detection</span>
The System ID of each node MUST be unique. As described in
<a href="#section-3.4.5">Section 3.4.5</a>, the System ID is generated based on entropies (e.g.,
Media Access Control (MAC) address) that 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. A duplicate system ID may occur between neighbors or
between routers in the same area that are not neighbors.
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
Router-Fingerprint in the received Router-Fingerprint TLV does NOT
match the locally generated Router-Fingerprint.
A duplicate system ID with a non-neighbor is detected when an LSP #0
is received, the System ID of the originator is identical to the
local System ID, and the Router-Fingerprint in the Router-Fingerprint
TLV does NOT match the locally generated Router-Fingerprint.
<span class="h4"><a class="selflink" id="section-3.4.4" href="#section-3.4.4">3.4.4</a>. Duplicate System ID Resolution Procedures</span>
When a 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, whenever possible, to restart a router that is
in startup mode.
The contents of the Router-Fingerprint TLVs for the two routers with
duplicate system IDs are compared.
<span class="grey">Liu, et al. Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
If one TLV has the S flag set (the router is in startup mode) and one
TLV has the S flag clear (the router is NOT in startup mode), the
router in startup mode MUST generate a new System ID and restart the
protocol.
If both TLVs have the S flag set (both routers are in startup mode)
or both TLVs have the S flag clear (neither router is in startup
mode), then the router with the numerically smaller Router-
Fingerprint MUST generate a new System ID and restart the protocol.
Fingerprint comparison is performed octet by octet starting from the
first received octet until a difference is detected. If the
fingerprints have different lengths and all octets up to the shortest
length are identical, then the fingerprint with smaller length is
considered smaller on the whole.
If the fingerprints are identical in both content and length (and the
state of the S flag is identical), and the duplication is detected in
hellos, then both routers MUST generate a new System ID and restart
the protocol.
If fingerprints are identical in both content and length, and the
duplication is detected in LSP #0, then the procedures defined in
<a href="#section-3.4.6">Section 3.4.6</a> MUST be followed.
<span class="h4"><a class="selflink" id="section-3.4.5" href="#section-3.4.5">3.4.5</a>. System ID and Router-Fingerprint Generation Considerations</span>
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 that can
provide an extremely high probability of uniqueness (some examples
listed below). These resources can be used as seeds to derive
identifiers:
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)
<span class="grey">Liu, et al. Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
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 regenerate the System ID when
duplication happens.
This document also does not specify a method to generate the Router-
Fingerprint.
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 IS-IS autoconfiguration. In this case, this
document suggests using the MAC address as the System ID and
generating a pseudorandom number based on another seed (such as the
memory address of a certain variable in the program) as the Router-
Fingerprint. The pseudorandom number might not have a very high
probability of uniqueness in this solution but should be sufficient
in home network scenarios.
The considerations surrounding System ID stability described in
<a href="#section-3.2">Section 3.2</a> also need to be applied.
<span class="h4"><a class="selflink" id="section-3.4.6" href="#section-3.4.6">3.4.6</a>. Duplication of Both System ID and Router-Fingerprint</span>
As described above, the resources for generating a System ID /
Router-Fingerprint might be very constrained during the initial
stages. Hence, the duplication of both System ID and Router-
Fingerprint need to be considered. In such a case, it is possible
that a router will receive an LSP with a System ID and Router-
Fingerprint identical to the local values, but the LSP is NOT
identical to the locally generated copy, i.e., the sequence number is
newer or the sequence number is the same, but the LSP has a valid
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
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 a higher sequence number and flood the new LSP
version. This will cause other routers in the network to update
their LSP Database (LSPDB) and synchronization will be achieved.
<span class="grey">Liu, et al. Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
In the pathological case, the generation of a new version of an LSP
by one of the "twins" will cause the other twin to generate the same
LSP with a higher sequence number -- and oscillation will continue
without achieving LSPDB synchronization.
Note that a comparison of the S flag in the Router-Fingerprint TLV
cannot be performed, as in the benign case it is expected that the S
flag will be clear. Also note that the conditions for detecting a
duplicate system ID will NOT be satisfied because both the System ID
and the Router-Fingerprint will be identical.
The following procedure is defined:
DD-state is a boolean that indicates if a
DD-LSP #0 has been received.
DD-count is the count of the number of occurrences
of reception of a DD-LSP.
DD-timer is a timer associated with reception of
DD-LSPs; the recommended value is 60 seconds.
DD-max is the maximum number of DD-LSPs allowed
to be received in DD-timer interval;
the 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 DD-state is TRUE:
DD-count is incremented.
If DD-count is >= DD-max:
The local system MUST generate a new System ID
and Router-Fingerprint and restart the protocol.
DD-state is (re)initialized to FALSE and
DD-timer is canceled.
If DD-timer expires:
DD-state is set to FALSE.
Note that to minimize the likelihood of duplication of both System ID
and Router-Fingerprint reoccurring, routers SHOULD have more
entropies available. One simple way to achieve this is to add the
LSP sequence number of the next LSP it will send to the Router-
Fingerprint.
<span class="grey">Liu, et al. Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. Additional IS-IS TLVs Usage Guidelines</span>
This section describes the behavior of selected TLVs when used by a
router supporting IS-IS autoconfiguration.
<span class="h4"><a class="selflink" id="section-3.5.1" href="#section-3.5.1">3.5.1</a>. Authentication TLV</span>
It is RECOMMENDED that IS-IS routers supporting this specification
offer an option to explicitly configure a single password for HMAC-
MD5 authentication as specified in [<a href="./rfc5304" title=""IS-IS Cryptographic Authentication"">RFC5304</a>].
<span class="h4"><a class="selflink" id="section-3.5.2" href="#section-3.5.2">3.5.2</a>. Metric Used in Reachability TLVs</span>
It is RECOMMENDED that IS-IS autoconfiguration routers use a high
metric value (e.g., 100000) as default in order to allow manually
configured adjacencies to be preferred over autoconfigured.
<span class="h4"><a class="selflink" id="section-3.5.3" href="#section-3.5.3">3.5.3</a>. Dynamic Name TLV</span>
IS-IS autoconfiguration routers MAY advertise their Dynamic Name TLV
(TLV 137 [<a href="./rfc5301" title=""Dynamic Hostname Exchange Mechanism for IS-IS"">RFC5301</a>]). The hostname 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 hostname, the System ID SHOULD be
appended as a suffix in the names.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Security Considerations</span>
In the absence of cryptographic authentication, it is possible for an
attacker to inject a PDU falsely indicating there is a duplicate
system ID. This may trigger automatic restart of the protocol using
the duplicate-id resolution procedures defined in this document.
Note that the use of authentication is incompatible with
autoconfiguration 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.
<span class="grey">Liu, et al. Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. IANA Considerations</span>
This document details a new IS-IS TLV reflected in the "IS-IS TLV
Codepoints" registry:
Value Name IIH LSP SNP Purge
---- ------------ --- --- --- -----
15 Router-Fingerprint Y Y N Y
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. References</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Normative References</span>
[<a id="ref-ISO_IEC10589">ISO_IEC10589</a>]
International Organization for Standardization,
"Information technology -- Telecommunications and
information exchange between systems -- Intermediate
System to Intermediate System intra-domain routeing
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.
[<a id="ref-RFC1195">RFC1195</a>] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
dual environments", <a href="./rfc1195">RFC 1195</a>, DOI 10.17487/RFC1195,
December 1990, <<a href="http://www.rfc-editor.org/info/rfc1195">http://www.rfc-editor.org/info/rfc1195</a>>.
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC5301">RFC5301</a>] McPherson, D. and N. Shen, "Dynamic Hostname Exchange
Mechanism for IS-IS", <a href="./rfc5301">RFC 5301</a>, DOI 10.17487/RFC5301,
October 2008, <<a href="http://www.rfc-editor.org/info/rfc5301">http://www.rfc-editor.org/info/rfc5301</a>>.
[<a id="ref-RFC5304">RFC5304</a>] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", <a href="./rfc5304">RFC 5304</a>, DOI 10.17487/RFC5304, October
2008, <<a href="http://www.rfc-editor.org/info/rfc5304">http://www.rfc-editor.org/info/rfc5304</a>>.
[<a id="ref-RFC5305">RFC5305</a>] Li, T. and H. Smit, "IS-IS Extensions for Traffic
Engineering", <a href="./rfc5305">RFC 5305</a>, DOI 10.17487/RFC5305, October
2008, <<a href="http://www.rfc-editor.org/info/rfc5305">http://www.rfc-editor.org/info/rfc5305</a>>.
[<a id="ref-RFC5308">RFC5308</a>] Hopps, C., "Routing IPv6 with IS-IS", <a href="./rfc5308">RFC 5308</a>,
DOI 10.17487/RFC5308, October 2008,
<<a href="http://www.rfc-editor.org/info/rfc5308">http://www.rfc-editor.org/info/rfc5308</a>>.
<span class="grey">Liu, et al. Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
[<a id="ref-RFC8174">RFC8174</a>] Leiba, B., "Ambiguity of Uppercase vs Lowercase in <a href="./rfc2119">RFC</a>
<a href="./rfc2119">2119</a> Key Words", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc8174">RFC 8174</a>, DOI 10.17487/RFC8174,
May 2017, <<a href="http://www.rfc-editor.org/info/rfc8174">http://www.rfc-editor.org/info/rfc8174</a>>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Informative References</span>
[<a id="ref-RFC7503">RFC7503</a>] Lindem, A. and J. Arkko, "OSPFv3 Autoconfiguration",
<a href="./rfc7503">RFC 7503</a>, DOI 10.17487/RFC7503, April 2015,
<<a href="http://www.rfc-editor.org/info/rfc7503">http://www.rfc-editor.org/info/rfc7503</a>>.
Acknowledgements
This document was heavily inspired by [<a href="./rfc7503" title=""OSPFv3 Autoconfiguration"">RFC7503</a>].
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.
<span class="grey">Liu, et al. Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc8196">RFC 8196</a> IS-IS Autoconfiguration July 2017</span>
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
Les Ginsberg
Cisco Systems
821 Alder Drive
Milpitas CA 95035
United States of America
Email: ginsberg@cisco.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
Liu, et al. Standards Track [Page 15]
</pre>
|
