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>Network Working Group F. Templin
Request for Comments: 5214 Boeing Phantom Works
Obsoletes: <a href="./rfc4214">4214</a> T. Gleeson
Category: Informational Cisco Systems K.K.
D. Thaler
Microsoft Corporation
March 2008
<span class="h1">Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)</span>
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
IESG Note
The IESG thinks that this work is related to IETF work done in WG
softwires, but this does not prevent publishing.
Abstract
The Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) connects
dual-stack (IPv6/IPv4) nodes over IPv4 networks. ISATAP views the
IPv4 network as a link layer for IPv6 and supports an automatic
tunneling abstraction similar to the Non-Broadcast Multiple Access
(NBMA) model.
<span class="grey">Templin, et al. Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
Table of Contents
<a href="#section-1">1</a>. Introduction ....................................................<a href="#page-2">2</a>
<a href="#section-2">2</a>. Requirements ....................................................<a href="#page-3">3</a>
<a href="#section-3">3</a>. Terminology .....................................................<a href="#page-3">3</a>
<a href="#section-4">4</a>. Domain of Applicability .........................................<a href="#page-4">4</a>
<a href="#section-5">5</a>. Node Requirements ...............................................<a href="#page-4">4</a>
<a href="#section-6">6</a>. Addressing Requirements .........................................<a href="#page-4">4</a>
<a href="#section-6.1">6.1</a>. ISATAP Interface Identifiers ...............................<a href="#page-4">4</a>
<a href="#section-6.2">6.2</a>. ISATAP Interface Address Configuration .....................<a href="#page-5">5</a>
<a href="#section-6.3">6.3</a>. Multicast/Anycast ..........................................<a href="#page-5">5</a>
<a href="#section-7">7</a>. Automatic Tunneling .............................................<a href="#page-5">5</a>
<a href="#section-7.1">7.1</a>. Encapsulation ..............................................<a href="#page-5">5</a>
<a href="#section-7.2">7.2</a>. Handling ICMPv4 Errors .....................................<a href="#page-5">5</a>
<a href="#section-7.3">7.3</a>. Decapsulation ..............................................<a href="#page-6">6</a>
<a href="#section-7.4">7.4</a>. Link-Local Addresses .......................................<a href="#page-6">6</a>
<a href="#section-7.5">7.5</a>. Neighbor Discovery over Tunnels ............................<a href="#page-6">6</a>
<a href="#section-8">8</a>. Neighbor Discovery for ISATAP Interfaces ........................<a href="#page-6">6</a>
<a href="#section-8.1">8.1</a>. Conceptual Model of a Host .................................<a href="#page-7">7</a>
<a href="#section-8.2">8.2</a>. Router and Prefix Discovery - Router Specification .........<a href="#page-7">7</a>
<a href="#section-8.3">8.3</a>. Router and Prefix Discovery - Host Specification ...........<a href="#page-7">7</a>
<a href="#section-8.3.1">8.3.1</a>. Host Variables ......................................<a href="#page-7">7</a>
<a href="#section-8.3.2">8.3.2</a>. Potential Router List Initialization ................<a href="#page-7">7</a>
<a href="#section-8.3.3">8.3.3</a>. Processing Received Router Advertisements ...........<a href="#page-8">8</a>
<a href="#section-8.3.4">8.3.4</a>. Sending Router Solicitations ........................<a href="#page-8">8</a>
<a href="#section-8.4">8.4</a>. Neighbor Unreachability Detection ..........................<a href="#page-9">9</a>
<a href="#section-9">9</a>. Site Administration Considerations ..............................<a href="#page-9">9</a>
<a href="#section-10">10</a>. Security Considerations ........................................<a href="#page-9">9</a>
<a href="#section-11">11</a>. IANA Considerations ...........................................<a href="#page-10">10</a>
<a href="#section-12">12</a>. Acknowledgments ...............................................<a href="#page-10">10</a>
<a href="#section-13">13</a>. References ....................................................<a href="#page-11">11</a>
<a href="#section-13.1">13.1</a>. Normative References .....................................<a href="#page-11">11</a>
<a href="#section-13.2">13.2</a>. Informative References ...................................<a href="#page-12">12</a>
<a href="#appendix-A">Appendix A</a>. Modified EUI-64 Addresses in the IANA Ethernet
Address Block ...........................................<a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
This document specifies a simple mechanism called the Intra-Site
Automatic Tunnel Addressing Protocol (ISATAP) that connects
dual-stack (IPv6/IPv4) nodes over IPv4 networks. Dual-stack nodes
use ISATAP to automatically tunnel IPv6 packets in IPv4, i.e., ISATAP
views the IPv4 network as a link layer for IPv6.
ISATAP enables automatic tunneling whether global or private IPv4
addresses are used, and it presents a Non-Broadcast Multiple Access
(NBMA) abstraction similar to [<a href="./rfc2491" title=""IPv6 over Non-Broadcast Multiple Access (NBMA) networks"">RFC2491</a>],[<a href="./rfc2492" title=""IPv6 over ATM Networks"">RFC2492</a>],[<a href="./rfc2529" title=""Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"">RFC2529</a>], and
[<a href="./rfc3056" title=""Connection of IPv6 Domains via IPv4 Clouds"">RFC3056</a>].
<span class="grey">Templin, et al. Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
The main objectives of this document are to: 1) describe the domain
of applicability, 2) specify addressing requirements, 3) specify
automatic tunneling using ISATAP, 4) specify the operation of IPv6
Neighbor Discovery over ISATAP interfaces, and 5) discuss Site
Administration, Security, and IANA considerations.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Requirements</span>
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
This document also uses internal conceptual variables to describe
protocol behavior and external variables that an implementation must
allow system administrators to change. The specific variable names,
how their values change, and how their settings influence protocol
behavior are provided in order to demonstrate protocol behavior. An
implementation is not required to have them in the exact form
described here, as long as its external behavior is consistent with
that described in this document.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Terminology</span>
The terminology of [<a href="./rfc2460" title=""Internet Protocol, Version 6 (IPv6) Specification"">RFC2460</a>] and [<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>] applies to this document.
The following additional terms are defined:
ISATAP node/host/router:
A dual-stack (IPv6/IPv4) node/host/router that implements the
specifications in this document.
ISATAP interface:
An ISATAP node's Non-Broadcast Multi-Access (NBMA) IPv6 interface,
used for automatic tunneling of IPv6 packets in IPv4.
ISATAP interface identifier:
An IPv6 interface identifier with an embedded IPv4 address
constructed as specified in <a href="#section-6.1">Section 6.1</a>.
ISATAP address:
An IPv6 unicast address that matches an on-link prefix on an
ISATAP interface of the node, and that includes an ISATAP
interface identifier.
locator:
An IPv4 address-to-interface mapping; i.e., a node's IPv4 address
and its associated interface.
<span class="grey">Templin, et al. Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
locator set:
A set of locators associated with an ISATAP interface. Each
locator in the set belongs to the same site.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Domain of Applicability</span>
The domain of applicability for this technical specification is
automatic tunneling of IPv6 packets in IPv4 for ISATAP nodes within
sites that observe the security considerations found in this
document, including host-to-router, router-to-host, and host-to-host
automatic tunneling in certain enterprise networks and 3GPP/3GPP2
wireless operator networks. (Other scenarios with a sufficient trust
basis ensured by the mechanisms specified in this document also fall
within this domain of applicability.)
Extensions to the above domain of applicability (e.g., by combining
the mechanisms in this document with those in other technical
specifications) are out of the scope of this document.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Node Requirements</span>
ISATAP nodes observe the common functionality requirements for IPv6
nodes found in [<a href="./rfc4294" title=""IPv6 Node Requirements"">RFC4294</a>] and the requirements for dual IP layer
operation found in <a href="./rfc4213#section-2">Section 2 of [RFC4213]</a>. They also implement the
additional features specified in this document.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Addressing Requirements</span>
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. ISATAP Interface Identifiers</span>
ISATAP interface identifiers are constructed in Modified EUI-64
format per <a href="./rfc4291#section-2.5.1">Section 2.5.1 of [RFC4291]</a> by concatenating the 24-bit
IANA OUI (00-00-5E), the 8-bit hexadecimal value 0xFE, and a 32-bit
IPv4 address in network byte order as follows:
|0 1|1 3|3 6|
|0 5|6 1|2 3|
+----------------+----------------+--------------------------------+
|000000ug00000000|0101111011111110|mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm|
+----------------+----------------+--------------------------------+
When the IPv4 address is known to be globally unique, the "u" bit
(universal/local) is set to 1; otherwise, the "u" bit is set to 0.
"g" is the individual/group bit, and "m" represents the bits of the
IPv4 address.
<span class="grey">Templin, et al. Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
Per <a href="./rfc4291#section-2.5.1">Section 2.5.1 of [RFC4291]</a>, ISATAP nodes are not required to
validate that interface identifiers created with modified EUI-64
tokens with the "u" bit set to universal are unique.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. ISATAP Interface Address Configuration</span>
Each ISATAP interface configures a set of locators consisting of IPv4
address-to-interface mappings from a single site; i.e., an ISATAP
interface's locator set MUST NOT span multiple sites.
When an IPv4 address is removed from an interface, the corresponding
locator SHOULD be removed from its associated locator set(s). When a
new IPv4 address is assigned to an interface, the corresponding
locator MAY be added to the appropriate locator set(s).
ISATAP interfaces form ISATAP interface identifiers from IPv4
addresses in their locator set and use them to create link-local
ISATAP addresses (<a href="./rfc4862#section-5.3">Section 5.3 of [RFC4862]</a>).
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. Multicast/Anycast</span>
It is not possible to assume the general availability of wide-area
IPv4 multicast, so (unlike 6over4 [<a href="./rfc2529" title=""Transmission of IPv6 over IPv4 Domains without Explicit Tunnels"">RFC2529</a>]) ISATAP must assume that
its underlying IPv4 carrier network only has unicast capability.
Support for IPv6 multicast over ISATAP interfaces is not described in
this document.
Similarly, support for Reserved IPv6 Subnet Anycast Addresses is not
described in this document.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Automatic Tunneling</span>
ISATAP interfaces use the basic tunneling mechanisms specified in
<a href="./rfc4213#section-3">Section 3 of [RFC4213]</a>. The following sub-sections describe
additional specifications.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Encapsulation</span>
ISATAP addresses are mapped to a link-layer address by a static
computation; i.e., the last four octets are treated as an IPv4
address.
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Handling ICMPv4 Errors</span>
ISATAP interfaces SHOULD process Address Resolution Protocol (ARP)
failures and persistent ICMPv4 errors as link-specific information
indicating that a path to a neighbor may have failed (<a href="./rfc4861#section-7.3.3">Section 7.3.3
of [RFC4861]</a>).
<span class="grey">Templin, et al. Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Decapsulation</span>
The specification in <a href="./rfc4213#section-3.6">Section 3.6 of [RFC4213]</a> is used. Additionally,
when an ISATAP node receives an IPv4 protocol 41 datagram that does
not belong to a configured tunnel interface, it determines whether
the packet's IPv4 destination address and arrival interface match a
locator configured in an ISATAP interface's locator set.
If an ISATAP interface that configures a matching locator is found,
the decapsulator MUST verify that the packet's IPv4 source address is
correct for the encapsulated IPv6 source address. The IPv4 source
address is correct if:
o the IPv6 source address is an ISATAP address that embeds the
IPv4 source address in its interface identifier, or
o the IPv4 source address is a member of the Potential Router
List (see <a href="#section-8.1">Section 8.1</a>).
Packets for which the IPv4 source address is incorrect for this
ISATAP interface are checked to determine whether they belong to
another tunnel interface.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Link-Local Addresses</span>
ISATAP interfaces use link-local addresses constructed as specified
in <a href="#section-6">Section 6</a> of this document.
<span class="h3"><a class="selflink" id="section-7.5" href="#section-7.5">7.5</a>. Neighbor Discovery over Tunnels</span>
ISATAP interfaces use the specifications for neighbor discovery found
in the following section of this document.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Neighbor Discovery for ISATAP Interfaces</span>
ISATAP interfaces use the neighbor discovery mechanisms specified in
[<a href="./rfc4861" title=""Neighbor Discovery for IP version 6 (IPv6)"">RFC4861</a>]. The following sub-sections describe specifications that
are also implemented.
<span class="grey">Templin, et al. Informational [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Conceptual Model of a Host</span>
To the list of Conceptual Data Structures (<a href="./rfc4861#section-5.1">Section 5.1 of [RFC4861]</a>),
ISATAP interfaces add the following:
Potential Router List (PRL)
A set of entries about potential routers; used to support router
and prefix discovery. Each entry ("PRL(i)") has an associated
timer ("TIMER(i)"), and an IPv4 address ("V4ADDR(i)") that
represents a router's advertising ISATAP interface.
<span class="h3"><a class="selflink" id="section-8.2" href="#section-8.2">8.2</a>. Router and Prefix Discovery - Router Specification</span>
Advertising ISATAP interfaces send Solicited Router Advertisement
messages as specified in <a href="./rfc4861#section-6.2.6">Section 6.2.6 of [RFC4861]</a> except that the
messages are sent directly to the soliciting node; i.e., they might
not be received by other nodes on the link.
<span class="h3"><a class="selflink" id="section-8.3" href="#section-8.3">8.3</a>. Router and Prefix Discovery - Host Specification</span>
The Host Specification in <a href="./rfc4861#section-6.3">Section 6.3 of [RFC4861]</a> is used. The
following sub-sections describe specifications added by ISATAP
interfaces.
<span class="h4"><a class="selflink" id="section-8.3.1" href="#section-8.3.1">8.3.1</a>. Host Variables</span>
To the list of host variables (<a href="./rfc4861#section-6.3.2">Section 6.3.2 of [RFC4861]</a>), ISATAP
interfaces add the following:
PrlRefreshInterval
Time in seconds between successive refreshments of the PRL after
initialization. The designated value of all ones (0xffffffff)
represents infinity.
Default: 3600 seconds
MinRouterSolicitInterval
Minimum time in seconds between successive solicitations of the
same advertising ISATAP interface. The designated value of all
ones (0xffffffff) represents infinity.
<span class="h4"><a class="selflink" id="section-8.3.2" href="#section-8.3.2">8.3.2</a>. Potential Router List Initialization</span>
ISATAP nodes initialize an ISATAP interface's PRL with IPv4 addresses
acquired via manual configuration, a DNS Fully Qualified Domain Name
(FQDN) [<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>], a DHCPv4 [<a href="./rfc2131" title=""Dynamic Host Configuration Protocol"">RFC2131</a>] vendor-specific option, or an
unspecified alternate method. Domain names are acquired via manual
<span class="grey">Templin, et al. Informational [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
configuration, receipt of a DHCPv4 Domain Name option [<a href="./rfc2132" title=""DHCP Options and BOOTP Vendor Extensions"">RFC2132</a>], or
an unspecified alternate method. FQDNs are resolved into IPv4
addresses through a static host file lookup, querying the DNS
service, querying a site-specific name service, or with an
unspecified alternate method.
After initializing an ISATAP interface's PRL, the node sets a timer
for the interface to PrlRefreshInterval seconds and re-initializes
the interface's PRL as specified above when the timer expires. When
an FQDN is used, and when it is resolved via a service that includes
Times to Live (TTLs) with the IPv4 addresses returned (e.g., DNS 'A'
resource records [<a href="./rfc1035" title=""Domain names - implementation and specification"">RFC1035</a>]), the timer SHOULD be set to the minimum
of PrlRefreshInterval and the minimum TTL returned. (Zero-valued
TTLs are interpreted to mean that the PRL is re-initialized before
each Router Solicitation event; see <a href="#section-8.3.4">Section 8.3.4</a>.)
<span class="h4"><a class="selflink" id="section-8.3.3" href="#section-8.3.3">8.3.3</a>. Processing Received Router Advertisements</span>
To the list of checks for validating Router Advertisement messages
(<a href="./rfc4861#section-6.1.2">Section 6.1.2 of [RFC4861]</a>), ISATAP interfaces add the following:
o IP Source Address is a link-local ISATAP address that embeds
V4ADDR(i) for some PRL(i).
Valid Router Advertisements received on an ISATAP interface are
processed as specified in <a href="./rfc4861#section-6.3.4">Section 6.3.4 of [RFC4861]</a>.
<span class="h4"><a class="selflink" id="section-8.3.4" href="#section-8.3.4">8.3.4</a>. Sending Router Solicitations</span>
To the list of events after which Router Solicitation messages may be
sent (<a href="./rfc4861#section-6.3.7">Section 6.3.7 of [RFC4861]</a>), ISATAP interfaces add the
following:
o TIMER(i) for some PRL(i) expires.
Since unsolicited Router Advertisements may be incomplete and/or
absent, ISATAP nodes MAY schedule periodic Router Solicitation events
for certain PRL(i)s by setting the corresponding TIMER(i).
When periodic Router Solicitation events are scheduled, the node
SHOULD set TIMER(i) so that the next event will refresh remaining
lifetimes stored for PRL(i) before they expire, including the Router
Lifetime, Valid Lifetimes received in Prefix Information Options, and
Route Lifetimes received in Route Information Options [<a href="./rfc4191" title=""Default Router Preferences and More-Specific Routes"">RFC4191</a>].
TIMER(i) MUST be set to no less than MinRouterSolicitInterval seconds
where MinRouterSolicitInterval is configurable for the node, or for a
specific PRL(i), with a conservative default value (e.g., 2 minutes).
<span class="grey">Templin, et al. Informational [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
When TIMER(i) expires, the node sends Router Solicitation messages as
specified in <a href="./rfc4861#section-6.3.7">Section 6.3.7 of [RFC4861]</a> except that the messages are
sent directly to PRL(i); i.e., they might not be received by other
routers. While the node continues to require periodic Router
Solicitation events for PRL(i), and while PRL(i) continues to act as
a router, the node resets TIMER(i) after each expiration event as
described above.
<span class="h3"><a class="selflink" id="section-8.4" href="#section-8.4">8.4</a>. Neighbor Unreachability Detection</span>
ISATAP hosts SHOULD perform Neighbor Unreachability Detection
(<a href="./rfc4861#section-7.3">Section 7.3 of [RFC4861]</a>). ISATAP routers MAY perform Neighbor
Unreachability Detection, but this might not scale in all
environments.
After address resolution, ISATAP hosts SHOULD perform an initial
reachability confirmation by sending Neighbor Solicitation messages
and receiving a Neighbor Advertisement message. ISATAP routers MAY
perform this initial reachability confirmation, but this might not
scale in all environments.
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Site Administration Considerations</span>
Site administrators maintain a Potential Router List (PRL) of IPv4
addresses representing advertising ISATAP interfaces of routers.
The PRL is commonly maintained as an FQDN for the ISATAP service in
the site's name service (see <a href="#section-8.3.2">Section 8.3.2</a>). There are no mandatory
rules for the selection of the FQDN, but site administrators are
encouraged to use the convention "isatap.domainname" (e.g.,
isatap.example.com).
When the site's name service includes TTLs with the IPv4 addresses
returned, site administrators SHOULD configure the TTLs with
conservative values to minimize control traffic.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Security Considerations</span>
Implementers should be aware that, in addition to possible attacks
against IPv6, security attacks against IPv4 must also be considered.
Use of IP security at both IPv4 and IPv6 levels should nevertheless
be avoided, for efficiency reasons. For example, if IPv6 is running
encrypted, encryption of IPv4 would be redundant unless traffic
analysis is felt to be a threat. If IPv6 is running authenticated,
then authentication of IPv4 will add little. Conversely, IPv4
security will not protect IPv6 traffic once it leaves the ISATAP
domain. Therefore, implementing IPv6 security is required even if
IPv4 security is available.
<span class="grey">Templin, et al. Informational [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
The threats associated with IPv6 Neighbor Discovery are described in
[<a href="./rfc3756" title=""IPv6 Neighbor Discovery (ND) Trust Models and Threats"">RFC3756</a>].
There is a possible spoofing attack in which spurious ip-protocol-41
packets are injected into an ISATAP link from outside. Since an
ISATAP link spans an entire IPv4 site, restricting access to the link
can be achieved by restricting access to the site; i.e., by having
site border routers implement IPv4 ingress filtering and ip-
protocol-41 filtering.
Another possible spoofing attack involves spurious ip-protocol-41
packets injected from within an ISATAP link by a node pretending to
be a router. The Potential Router List (PRL) provides a list of IPv4
addresses representing advertising ISATAP interfaces of routers that
hosts use in filtering decisions. Site administrators should ensure
that the PRL is kept up to date, and that the resolution mechanism
(see <a href="#section-9">Section 9</a>) cannot be subverted.
The use of temporary addresses [<a href="./rfc4941" title=""Privacy Extensions for Stateless Address Autoconfiguration in IPv6"">RFC4941</a>] and Cryptographically
Generated Addresses [<a href="./rfc3972" title=""Cryptographically Generated Addresses (CGA)"">RFC3972</a>] on ISATAP interfaces is outside the
scope of this specification.
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. IANA Considerations</span>
The IANA has specified the format for Modified EUI-64 address
construction (Appendix A of [<a href="./rfc4291" title=""IP Version 6 Addressing Architecture"">RFC4291</a>]) in the IANA Ethernet Address
Block. The text in the Appendix of this document has been offered as
an example specification. The current version of the IANA registry
for Ether Types can be accessed at:
<a href="http://www.iana.org/assignments/ethernet-numbers">http://www.iana.org/assignments/ethernet-numbers</a>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Acknowledgments</span>
The ideas in this document are not original, and the authors
acknowledge the original architects. Portions of this work were
sponsored through SRI International and Nokia and Boeing internal
projects and government contracts. Government sponsors include
Monica Farah Stapleton and Russell Langan (U.S. Army CECOM ASEO) and
Dr. Allen Moshfegh (U.S. Office of Naval Research). SRI
International sponsors include Dr. Mike Frankel, J. Peter
Marcotullio, Lou Rodriguez, and Dr. Ambatipudi Sastry.
The following are acknowledged for providing peer review input: Jim
Bound, Rich Draves, Cyndi Jung, Ambatipudi Sastry, Aaron Schrader,
Ole Troan, and Vlad Yasevich.
<span class="grey">Templin, et al. Informational [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
The following are acknowledged for their significant contributions:
Marcelo Albuquerque, Brian Carpenter, Alain Durand, Hannu Flinck,
Jason Goldschmidt, Christian Huitema, Nathan Lutchansky, Karen
Nielsen, Mohan Parthasarathy, Chirayu Patel, Art Shelest, Markku
Savela, Pekka Savola, Margaret Wasserman, Brian Zill, and members of
the IETF IPv6 and V6OPS working groups. Mohit Talwar contributed to
earlier versions of this document.
The authors acknowledge the work done by Brian Carpenter and Cyndi
Jung in <a href="./rfc2529">RFC 2529</a> that introduced the concept of intra-site automatic
tunneling. This concept was later called: "Virtual Ethernet" and
researched by Quang Nguyen under the guidance of Dr. Lixia Zhang.
<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>. References</span>
<span class="h3"><a class="selflink" id="section-13.1" href="#section-13.1">13.1</a>. Normative References</span>
[<a id="ref-RFC1035">RFC1035</a>] Mockapetris, P., "Domain names - implementation and
specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987.
[<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>, March 1997.
[<a id="ref-RFC2131">RFC2131</a>] Droms, R., "Dynamic Host Configuration Protocol", <a href="./rfc2131">RFC</a>
<a href="./rfc2131">2131</a>, March 1997.
[<a id="ref-RFC2132">RFC2132</a>] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", <a href="./rfc2132">RFC 2132</a>, March 1997.
[<a id="ref-RFC2460">RFC2460</a>] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", <a href="./rfc2460">RFC 2460</a>, December 1998.
[<a id="ref-RFC4861">RFC4861</a>] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", <a href="./rfc4861">RFC 4861</a>,
September 2007.
[<a id="ref-RFC4213">RFC4213</a>] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
for IPv6 Hosts and Routers", <a href="./rfc4213">RFC 4213</a>, October 2005.
[<a id="ref-RFC4291">RFC4291</a>] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", <a href="./rfc4291">RFC 4291</a>, February 2006.
[<a id="ref-RFC4862">RFC4862</a>] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", <a href="./rfc4862">RFC 4862</a>, September 2007.
<span class="grey">Templin, et al. Informational [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
<span class="h3"><a class="selflink" id="section-13.2" href="#section-13.2">13.2</a>. Informative References</span>
[<a id="ref-RFC2491">RFC2491</a>] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", <a href="./rfc2491">RFC</a>
<a href="./rfc2491">2491</a>, January 1999.
[<a id="ref-RFC2492">RFC2492</a>] Armitage, G., Schulter, P., and M. Jork, "IPv6 over ATM
Networks", <a href="./rfc2492">RFC 2492</a>, January 1999.
[<a id="ref-RFC2529">RFC2529</a>] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", <a href="./rfc2529">RFC 2529</a>, March 1999.
[<a id="ref-RFC3056">RFC3056</a>] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", <a href="./rfc3056">RFC 3056</a>, February 2001.
[<a id="ref-RFC3756">RFC3756</a>] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
Neighbor Discovery (ND) Trust Models and Threats", <a href="./rfc3756">RFC</a>
<a href="./rfc3756">3756</a>, May 2004.
[<a id="ref-RFC3972">RFC3972</a>] Aura, T., "Cryptographically Generated Addresses (CGA)",
<a href="./rfc3972">RFC 3972</a>, March 2005.
[<a id="ref-RFC4191">RFC4191</a>] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", <a href="./rfc4191">RFC 4191</a>, November 2005.
[<a id="ref-RFC4294">RFC4294</a>] Loughney, J., Ed., "IPv6 Node Requirements", <a href="./rfc4294">RFC 4294</a>,
April 2006.
[<a id="ref-RFC4941">RFC4941</a>] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", <a href="./rfc4941">RFC 4941</a>, September 2007.
<span class="grey">Templin, et al. Informational [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
<span class="h2"><a class="selflink" id="appendix-A" href="#appendix-A">Appendix A</a>. Modified EUI-64 Addresses in the IANA Ethernet Address</span>
Block
Modified EUI-64 addresses (<a href="#section-2.5.1">Section 2.5.1</a> and <a href="./rfc4291#appendix-A">Appendix A of [RFC4291]</a>)
in the IANA Ethernet Address Block are formed by concatenating the
24-bit IANA OUI (00-00-5E) with a 40-bit extension identifier and
inverting the "u" bit; i.e., the "u" bit is set to one (1) to
indicate universal scope and set to zero (0) to indicate local scope.
Modified EUI-64 addresses have the following appearance in memory
(bits transmitted right-to-left within octets, octets transmitted
left-to-right):
0 23 63
| OUI | extension identifier |
000000ug00000000 01011110xxxxxxxx xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
When the first two octets of the extension identifier encode the
hexadecimal value 0xFFFE, the remainder of the extension identifier
encodes a 24-bit vendor-supplied id as follows:
0 23 39 63
| OUI | 0xFFFE | vendor-supplied id |
000000ug00000000 0101111011111111 11111110xxxxxxxx xxxxxxxxxxxxxxxx
When the first octet of the extension identifier encodes the
hexadecimal value 0xFE, the remainder of the extension identifier
encodes a 32-bit IPv4 address as follows:
0 23 31 63
| OUI | 0xFE | IPv4 address |
000000ug00000000 0101111011111110 xxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxx
<span class="grey">Templin, et al. Informational [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
Authors' Addresses
Fred L. Templin
Boeing Phantom Works
P.O. Box 3707 MC 7L-49
Seattle, WA 98124
USA
EMail: fred.l.templin@boeing.com
Tim Gleeson
Cisco Systems K.K.
Shinjuku Mitsui Building
2-1-1 Nishishinjuku, Shinjuku-ku
Tokyo 163-0409
Japan
EMail: tgleeson@cisco.com
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
US
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
<span class="grey">Templin, et al. Informational [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc5214">RFC 5214</a> ISATAP March 2008</span>
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and at <a href="http://www.rfc-editor.org/copyright.html">http://www.rfc-editor.org/copyright.html</a>,
and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Templin, et al. Informational [Page 15]
</pre>
|
