File: rfc2473.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (2019 lines) | stat: -rw-r--r-- 77,956 bytes parent folder | download | duplicates (7)
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
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019






Network Working Group                                          A. Conta
Request for Comments: 2473                     Lucent Technologies Inc.
Category: Standards Track                                    S. Deering
                                                          Cisco Systems
                                                          December 1998


                    Generic Packet Tunneling in IPv6
                             Specification

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document defines the model and generic mechanisms for IPv6
   encapsulation of Internet packets, such as IPv6 and IPv4.  The model
   and mechanisms can be applied to other protocol packets as well, such
   as AppleTalk, IPX, CLNP, or others.

Table of Contents

   1. Introduction..................................................2
   2. Terminology...................................................2
   3. IPv6 Tunneling................................................4
       3.1 IPv6 Encapsulation.......................................6
       3.2 IPv6 Packet Processing in Tunnels........................7
       3.3 IPv6 Decapsulation.......................................7
       3.4 IPv6 Tunnel Protocol Engine..............................8
   4. Nested Encapsulation.........................................11
       4.1  Limiting Nested Encapsulation..........................12
           4.1.1  Tunnel Encapsulation Limit Option................13
           4.1.2  Loopback Encapsulation...........................15
           4.1.3  Routing Loop Nested Encapsulation................15
   5. Tunnel IPv6 Header...........................................16
       5.1 Tunnel IPv6 Extension Headers...........................17
   6. IPv6 Tunnel State Variables..................................19
       6.1 IPv6 Tunnel Entry-Point Node............................19
       6.2 IPv6 Tunnel Exit-Point Node.............................19



Conta & Deering             Standards Track                     [Page 1]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


       6.3 IPv6 Tunnel Hop Limit...................................19
       6.4 IPv6 Tunnel Packet Traffic Class........................20
       6.5 IPv6 Tunnel Flow Label..................................20
       6.6 IPv6 Tunnel Encapsulation Limit.........................20
       6.7 IPv6 Tunnel MTU.........................................20
   7. IPv6 Tunnel Packet Size Issues...............................21
       7.1 IPv6 Tunnel Packet Fragmentation........................21
       7.2 IPv4 Tunnel Packet Fragmentation........................22
   8. IPv6 Tunnel Error Reporting and Processing...................22
       8.1 Tunnel ICMP Messages....................................27
       8.2 ICMP Messages for IPv6 Original Packets.................28
       8.3 ICMP Messages for IPv4 Original Packets.................29
       8.4 ICMP Messages for Nested Tunnel Packets.................30
   9. Security Considerations......................................30
   10. Acknowledgments.............................................31
   11. References..................................................31
   Authors' Addresses..............................................32
   Appendix A. Risk Factors in Recursive Encapsulation.............33
   Full Copyright Statement........................................36

1. Introduction

   This document specifies a method and generic mechanisms by which a
   packet is encapsulated and carried as payload within an IPv6 packet.
   The resulting packet is called an IPv6 tunnel packet. The forwarding
   path between the source and destination of the tunnel packet is
   called an IPv6 tunnel. The technique is called IPv6 tunneling.

   A typical scenario for IPv6 tunneling is the case in which an
   intermediate node exerts explicit routing control by specifying
   particular forwarding paths for selected packets.  This control is
   achieved by prepending IPv6 headers to each of the selected original
   packets. These prepended headers identify the forwarding paths.

   In addition to the description of generic IPv6 tunneling mechanisms,
   which is the focus of this document, specific mechanisms for
   tunneling IPv6 and IPv4 packets are also described herein.

   The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
   SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined
   in RFC 2119.

2. Terminology

   original packet

        a packet that undergoes encapsulation.




Conta & Deering             Standards Track                     [Page 2]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   original header

        the header of an original packet.

   tunnel

        a forwarding path between two nodes on which the payloads of
        packets are original packets.

   tunnel end-node

        a node where a tunnel begins or ends.

   tunnel header

        the header prepended to the original packet during
        encapsulation.  It specifies the tunnel end-points as source and
        destination.

   tunnel packet

        a packet that encapsulates an original packet.

   tunnel entry-point

        the tunnel end-node where an original packet is encapsulated.

   tunnel exit-point

        the tunnel end-node where a tunnel packet is decapsulated.

   IPv6 tunnel

        a tunnel configured as a virtual link between two IPv6 nodes, on
        which the encapsulating protocol is IPv6.

   tunnel MTU

        the maximum size of a tunnel packet payload without requiring
        fragmentation, that is, the Path MTU between the tunnel entry-
        point and the tunnel exit-point nodes minus the size of the
        tunnel header.

   tunnel hop limit

        the maximum number of hops that a tunnel packet can travel from
        the tunnel entry-point to the tunnel exit-point.




Conta & Deering             Standards Track                     [Page 3]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   inner tunnel

        a tunnel that is a hop (virtual link) of another tunnel.

   outer tunnel

        a tunnel containing one or more inner tunnels.

   nested tunnel packet

        a tunnel packet that has as payload a tunnel packet.

   nested tunnel header

        the tunnel header of a nested tunnel packet.

   nested encapsulation

        encapsulation of an encapsulated packet.

   recursive encapsulation

        encapsulation of a packet that reenters a tunnel before exiting
        it.

   tunnel encapsulation limit

        the maximum number of nested encapsulations of a packet.

3. IPv6 Tunneling

   IPv6 tunneling is a technique for establishing a "virtual link"
   between two IPv6 nodes for transmitting data packets as payloads of
   IPv6 packets (see Fig.1).  From the point of view of the two nodes,
   this "virtual link", called an IPv6 tunnel, appears as a point to
   point link on which IPv6 acts like a link-layer protocol.  The two
   IPv6 nodes play specific roles.  One node encapsulates original
   packets received from other nodes or from itself and forwards the
   resulting tunnel packets through the tunnel.  The other node
   decapsulates the received tunnel packets and forwards the resulting
   original packets towards their destinations, possibly itself. The
   encapsulator node is called the tunnel entry-point node, and it is
   the source of the tunnel packets. The decapsulator node is called the
   tunnel exit-point, and it is the destination of the tunnel packets.







Conta & Deering             Standards Track                     [Page 4]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   Note:
   This document refers in particular to tunnels between two nodes
   identified by unicast addresses - such tunnels look like "virtual
   point to point links". The mechanisms described herein apply also to
   tunnels in which the exit-point nodes are identified by other types
   of addresses, such as anycast or multicast.  These tunnels may look
   like "virtual point to multipoint links". At the time of writing this
   document, IPv6 anycast addresses are a subject of ongoing
   specification and experimental work.

                   Tunnel from node B to node C
                    <---------------------->
                 Tunnel                     Tunnel
                 Entry-Point                Exit-Point
                 Node                       Node
  +-+            +-+                        +-+            +-+
  |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D|
  +-+            +-+                        +-+            +-+
  Original                                                 Original
  Packet                                                   Packet
  Source                                                   Destination
  Node                                                     Node
                          Fig.1 Tunnel

   An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow
   takes place in one direction between the IPv6 tunnel entry-point and
   exit-point nodes (see Fig.1).

                   Tunnel from Node B to Node C
                    <------------------------>
                 Tunnel                      Tunnel
  Original       Entry-Point                 Exit-Point     Original
  Packet         Node                        Node           Packet
  Source                                                    Destination
  Node                                                      Node
  +-+            +-+                         +-+            +-+
  | |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| |
  |A|            |B|                         |C|            |D|
  | |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| |
  +-+            +-+                         +-+            +-+
  Original                                                  Original
  Packet                                                    Packet
  Destination    Tunnel                      Tunnel         Source
  Node           Exit-Point                  Entry-Point    Node
                 Node                        Node
                   <------------------------->
                  Tunnel from Node C to Node B
              Fig.2 Bi-directional Tunneling Mechanism



Conta & Deering             Standards Track                     [Page 5]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   Bi-directional tunneling is achieved by merging two unidirectional
   mechanisms, that is, configuring two tunnels, each in opposite
   direction to the other - the entry-point node of one tunnel is the
   exit-point node of the other tunnel (see Fig.2).

3.1 IPv6 Encapsulation

   IPv6 encapsulation consists of prepending to the original packet an
   IPv6 header and, optionally, a set of IPv6 extension headers (see
   Fig.3), which are collectively called tunnel IPv6 headers.  The
   encapsulation takes place in an IPv6 tunnel entry-point node, as the
   result of an original packet being forwarded onto the virtual link
   represented by the tunnel. The original packet is processed during
   forwarding according to the forwarding rules of the protocol of that
   packet. For instance if the original packet is an:

    (a)  IPv6 packet, the IPv6 original header hop limit is  decremented
         by one.

    (b)  IPv4 packet, the IPv4 original header time to live field (TTL)
         is decremented by one.

   At encapsulation, the source field of the tunnel IPv6 header is
   filled with an IPv6 address of the tunnel entry-point node, and the
   destination field with an IPv6 address of the tunnel exit-point.
   Subsequently, the tunnel packet resulting from encapsulation is sent
   towards the tunnel exit-point node.

                            +----------------------------------//-----+
                            | Original |                              |
                            |          |   Original Packet Payload    |
                            | Header   |                              |
                            +----------------------------------//-----+
                             <            Original Packet            >
                                              |
                                              v
       <Tunnel IPv6 Headers> <       Original Packet                 >

      +---------+ - - - - - +-------------------------//--------------+
      | IPv6    | IPv6      |                                         |
      |         | Extension |        Original Packet                  |
      | Header  | Headers   |                                         |
      +---------+ - - - - - +-------------------------//--------------+
       <                          Tunnel IPv6 Packet                 >

                       Fig.3 Encapsulating a Packet





Conta & Deering             Standards Track                     [Page 6]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   Tunnel extension headers should appear in the order recommended by
   the specifications that define the extension headers, such as [IPv6-
   Spec].

   A source of original packets and a tunnel entry-point that
   encapsulates those packets can be the same node.

3.2 Packet Processing in Tunnels

   The intermediate nodes in the tunnel process the IPv6 tunnel packets
   according to the IPv6 protocol.  For example, a tunnel Hop by Hop
   Options extension header is processed by each receiving node in the
   tunnel; a tunnel Routing extension header identifies the intermediate
   processing nodes, and controls at a finer granularity the forwarding
   path of the tunnel packet through the tunnel; a tunnel Destination
   Options extension header is processed at the tunnel exit-point node.

3.3 IPv6 Decapsulation

   Decapsulation is graphically shown in Fig.4:

     +---------+- - - - - -+----------------------------------//-----+
     | IPv6    | IPv6      |                                         |
     |         | Extension |        Original Packet                  |
     | Header  | Headers   |                                         |
     +---------+- - - - - -+----------------------------------//-----+
      <                      Tunnel IPv6 Packet                     >
                                      |
                                      v
                           +----------------------------------//-----+
                           | Original |                              |
                           |          |   Original Packet Payload    |
                           | Headers  |                              |
                           +----------------------------------//-----+
                            <            Original Packet            >


                     Fig.4 Decapsulating a Packet

   Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel
   exit-point node, its IPv6 protocol layer processes the tunnel
   headers. The strict left-to-right processing rules for extension
   headers is applied. When processing is complete, control is handed to
   the next protocol engine, which is identified by the Next Header
   field value in the last header processed. If this is set to a tunnel
   protocol value, the tunnel protocol engine discards the tunnel
   headers and passes the resulting original packet to the Internet or
   lower layer protocol identified by that value for further processing.



Conta & Deering             Standards Track                     [Page 7]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   For example, in the case the Next Header field has the IPv6 Tunnel
   Protocol value, the resulting original packet is passed to the IPv6
   protocol layer.

   The tunnel exit-point node, which decapsulates the tunnel packets,
   and the destination node, which receives the resulting original
   packets can be the same node.

3.4 IPv6 Tunnel Protocol Engine

   Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a
   node is graphically shown in Fig.5:

   Note:

   In Fig.5, the Upper-Layer Protocols box represents transport
   protocols such as TCP, UDP, control protocols such as ICMP, routing
   protocols such as OSPF, and internet or lower-layer protocol being
   "tunneled" over IPv6, such as IPv4, IPX, etc.  The Link-Layer
   Protocols box represents Ethernet, Token Ring, FDDI, PPP, X.25, Frame
   Relay, ATM, etc..., as well as internet layer "tunnels" such as IPv4
   tunnels.

   The IPv6 tunnel protocol engine acts as both an "upper-layer" and a
   "link-layer", each with a specific input and output as follows:

   (u.i) "tunnel upper-layer input" - consists of  tunnel  IPv6  packets
         that are going to be decapsulated.  The tunnel packets are
         incoming through the IPv6 layer from:

         (u.i.1) a link-layer - (path #1, Fig.5)

                 These are tunnel packets destined to this node and will
                 undergo decapsulation.

         (u.i.2) a tunnel link-layer - (path #7, Fig.5)

                 These are tunnel packets that underwent one or more
                 decapsulations on this node, that is, the packets had
                 one or more nested tunnel headers and one nested tunnel
                 header was just discarded. This node is the exit-point
                 of both an outer tunnel and one or more of its inner
                 tunnels.

         For both above cases the resulting original packets are passed
         back to the IPv6 layer as "tunnel link-layer" output for
         further processing (see b.2).




Conta & Deering             Standards Track                     [Page 8]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


      +-----------------------+   +-----------------------------------+
      | Upper-Layer Protocols |   | IPv6 Tunnel Upper-Layer           |
      |                       |   |                                   |
      |                       |   | ---<-------------------<-------   |
      |                       |   | | ---->---|------>---------   |   |
      |                       |   | | |       | |             |   |   |
      +-----------------------+   +-----------------------+   |   |   |
         | |             | |        | |       | |         |   v   ^   |
         v ^             v ^        v ^       v ^  Tunnel |   |   |   |
         | |             | |        | |       | |  Packets|   |   |   |
      +---------------------------------------------+     |   |   |   |
      |  | |             | |       / /        | |   |     |   D   E   |
      |  v ^    IPv6     | --<-3--/-/--<----  | |   |     |   E   N   |
      |  | |    Layer    ---->-4-/-/--->-- |  | |   |     |   C   C   |
      |  v ^                    / /      | |  | |   |     |   A   A   |
      |  | |                   2 1       | |  | |   |     |   P   P   |
      |  v ^     -----<---5---/-/-<----  v ^  v ^   |     |   S   S   |
      |  | |     | -->---6---/-/-->-- |  | |  | |   |     |   U   U   |
      |  v ^     | |        / /     6 5  4 3  8 7   |     |   L   L   |
      |  | |     | |       / /      | |  | |  | |   |     |   A   A   |
      |  v ^     v ^      / /       v ^  | |  | |   |     |   T   T   |
      +---------------------------------------------+     |   E   E   |
         | |     | |     | |        | |  | |  | |         |   |   |   |
         v ^     v ^     v ^        v ^  v ^  v ^ Original|   |   |   |
         | |     | |     | |        | |  | |  | | Packets |   v   ^   |
      +-----------------------+   +-----------------------+   |   |   |
      |                       |   | | |  | |  | |             |   |   |
      |                       |   | | ---|----|-------<--------   |   |
      |                       |   | --->--------------->------>----   |
      |                       |   |                                   |
      | Link-Layer Protocols  |   | IPv6 Tunnel Link-Layer            |
      +-----------------------+   +-----------------------------------+

     Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node

   (u.o) "tunnel upper-layer output" - consists of tunnel IPv6 packets
         that are passed through the IPv6 layer down to:

         (u.o.1) a link-layer - (path #2, Fig.5)

                 These packets underwent encapsulation and are sent
                 towards the tunnel exit-point

         (u.o.2) a tunnel link-layer - (path #8, Fig.5)

                 These tunnel packets undergo nested encapsulation.
                 This node is the entry-point node of both an outer
                 tunnel and one or more of its inner tunnel.



Conta & Deering             Standards Track                     [Page 9]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   Implementation Note:

   The tunnel upper-layer input and output can be implemented similar
   to the input and output of the other upper-layer protocols.

   The tunnel link-layer input and output are as follows:

   (l.i) "tunnel link-layer input" - consists of original IPv6  packets
         that are going to be encapsulated.

         The original packets are incoming through the IPv6 layer from:

         (l.i.1) an upper-layer - (path #4, Fig.5)

                 These are original packets originating on this node
                 that undergo encapsulation. The original packet source
                 and tunnel entry-point are the same node.

         (l.i.2) a link-layer - (path #6, Fig.5)

                 These are original packets incoming from a different
                 node that undergo encapsulation on this tunnel entry-
                 point node.

         (l.i.3) a tunnel upper-layer - (path #8, Fig.5)

                 These packets are tunnel packets that undergo nested
                 encapsulation.  This node is the entry-point node of
                 both an outer tunnel and one or more of its inner
                 tunnels.

         The resulting tunnel packets are passed as tunnel  upper-layer
         output packets through the IPv6 layer (see u.o) down to:

   (l.o) "tunnel link-layer output" - consists of original IPv6 packets
   resulting from decapsulation. These packets are passed through the
   IPv6 layer to:

   (l.o.1) an upper-layer - (path #3, Fig.5)

                 These original packets are destined to this node.

         (l.o.2) a link-layer - (path #5, Fig.5)

                 These original packets are destined to another node;
                 they are transmitted on a link towards their
                 destination.




Conta & Deering             Standards Track                    [Page 10]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


         (l.o.3) a tunnel upper-layer - (path #7, Fig.5)

                 These packets undergo another decapsulation; they were
                 nested tunnel packets.  This node is both the exit-
                 point node of an outer tunnel and one or more inner
                 tunnels.

      Implementation Note:

      The tunnel link-layer input and output can be implemented similar
      to the input and output of other link-layer protocols, for
      instance, associating an interface or pseudo-interface with the
      IPv6 tunnel.

      The selection of the "IPv6 tunnel link" over other links results
      from the packet forwarding decision taken based on the content of
      the node's routing table.

4. Nested Encapsulation

   Nested IPv6 encapsulation is the encapsulation of a tunnel packet.
   It takes place when a hop of an IPv6 tunnel is a tunnel. The tunnel
   containing a tunnel is called an outer tunnel. The tunnel contained
   in the outer tunnel is called an inner tunnel - see Fig.6. Inner
   tunnels and their outer tunnels are nested tunnels.

   The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv6
   packets encapsulated by the "outer IPv6 tunnel" entry-point node. The
   "inner tunnel entry-point node" treats the receiving tunnel packets
   as original packets and performs encapsulation.  The resulting
   packets are "tunnel packets" for the "inner IPv6 tunnel", and "nested
   tunnel packets" for the "outer IPv6 tunnel".



















Conta & Deering             Standards Track                    [Page 11]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


                 Outer Tunnel
                 <------------------------------------->
                 <--links--><-virtual link-><--links--->
                              Inner Tunnel

             Outer Tunnel                          Outer Tunnel
             Entry-Point                           Exit-Point
             Node                                  Node
  +-+        +-+        +-+            +-+         +-+        +-+
  | |        | |        | |            | |         | |        | |
  | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| |
  | |        | |        | |            | |         | |        | |
  +-+        +-+        +-+            +-+         +-+        +-+
Original                Inner Tunnel   Inner Tunnel         Original
Packet                  Entry-Point    Exit-Point           Packet
Source                  Node           Node                 Destination
Node                                                        Node

                      Fig.6. Nested Encapsulation

4.1 Limiting Nested Encapsulation

   A tunnel IPv6 packet is limited to the maximum IPv6 packet size
   [IPv6-Spec].  Each encapsulation adds to the size of an encapsulated
   packet the size of the tunnel IPv6 headers. Consequently, the number
   of tunnel headers, and therefore, the number of nested encapsulations
   is limited by the maximum packet size.  However this limit is so
   large (more than 1600 encapsulations for an original packet of
   minimum size) that it is not an effective limit in most cases.

   The increase in the size of a tunnel IPv6 packet due to nested
   encapsulations may require fragmentation [IPv6-Spec] at a tunnel
   entry point - see section 7.  Furthermore, each fragmentation, due to
   nested encapsulation, of an already fragmented tunnel packet results
   in a doubling of the number of fragments.  Moreover, it is probable
   that once this fragmentation begins, each new nested encapsulation
   results in yet additional fragmentation.  Therefore limiting nested
   encapsulation is recommended.

   The proposed mechanism for limiting excessive nested encapsulation is
   a "Tunnel Encapsulation Limit" option, which is carried in an IPv6
   Destination Options extension header accompanying an encapsulating
   IPv6 header.








Conta & Deering             Standards Track                    [Page 12]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


4.1.1 Tunnel Encapsulation Limit Option

   A tunnel entry-point node may be configured to include a Tunnel
   Encapsulation Limit option as part of the information prepended to
   all packets entering a tunnel at that node.  The Tunnel Encapsulaton
   Limit option is carried in a Destination Options extension header
   [IPv6-Spec] placed between the encapsulating IPv6 header and the IPv6
   header of the original packet.  (Other IPv6 extension headers may
   also be present preceding or following the Destination Options
   extension header, depending on configuration information at the
   tunnel entry-point node.)

   The Tunnel Encapsulation Limit option specifies how many additional
   levels of encapsulation are permitted to be prepended to the packet
   -- or, in other words, how many further levels of nesting the packet
   is permitted to undergo -- not counting the encapsulation in which
   the option itself is contained.  For example, a Tunnel Encapsulation
   Limit option containing a limit value of zero means that a packet
   carrying that option may not enter another tunnel before exiting the
   current tunnel.

   The Tunnel Encapsulation Limit option has the following format:

      Option Type     Opt Data Len   Opt Data Len
    0 1 2 3 4 5 6 7
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 1 0 0|       1       | Tun Encap Lim |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      Option Type decimal value 4

                       - the highest-order two bits - set to 00 -
                       indicate "skip over this option if the option is
                       not recognized".

                        - the third-highest-order bit - set to 0 -
                       indicates that the option data in this option
                       does not change en route to the packet's
                       destination [IPv6-Spec].

      Opt Data Len value 1 - the data portion of the Option is one octet
                       long.

      Opt Data Value the Tunnel Encapsulation Limit value - 8-bit
                       unsigned integer specifying how many further
                       levels of encapsulation are permitted for the




Conta & Deering             Standards Track                    [Page 13]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   Tunnel Encapsulation Limit options are of interest only to tunnel
   entry points.  A tunnel entry-point node is required to execute the
   following procedure for every packet entering a tunnel at that node:

        (a)  Examine the packet to see if a Tunnel  Encapsulation  Limit
             option is present following its IPv6 header.  The headers
             following the IPv6 header must be examined in strict
             "left-to-right" order, with the examination stopping as
             soon as any one of the following headers is encountered:
             (i) a Destination Options extension header containing a
             Tunnel Encapsulation Limit, (ii) another IPv6 header, (iii)
             a non-extension header, such as TCP, UDP, or ICMP, or (iv)
             a header that cannot be parsed because it is encrypted or
             its type is unknown.  (Note that this requirment is an
             exception to the general IPv6 rule that a Destination
             Options extension header need only be examined by a
             packet's destination node.  An alternative and "cleaner"
             approach would have been to use a Hop-by-Hop extension
             header for this purpose, but that would have imposed an
             undesirable extra processing burden, and possible
             consequent extra delay, at every IPv6 node along the path
             of a tunnel.)

        (b) If a Tunnel Encapsulation Limit option is found in the
             packet entering the tunnel and its limit value is zero, the
             packet is discarded and an ICMP Parameter Problem message
             [ICMP-Spec] is sent to the source of the packet, which is
             the previous tunnel entry-point node.  The Code field of
             the Parameter Problem message is set to zero ("erroneous
             header field encountered") and the Pointer field is set to
             point to the third octet of the Tunnel Encapsulation Limit
             option (i.e., the octet containing the limit value of
             zero).

        (c) If a Tunnel Encapsulation Limit option is found in the
             packet entering the tunnel and its limit value is non-zero,
             an additional Tunnel Encapsulation Limit option must be
             included as part of the encapsulating headers being added
             at this entry point.  The limit value in the encapsulating
             option is set to one less than the limit value found in the
             packet being encapsulated.

        (d) If a Tunnel Encapsulation Limit option is not found in the
             packet entering the tunnel and if an encapsulation limit
             has been configured for this tunnel, a Tunnel Encapsulation
             Limit option must be included as part of the encapsulating
             headers being added at this entry point.  The limit value
             in the option is set to the configured limit.



Conta & Deering             Standards Track                    [Page 14]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


        (e)  If a Tunnel Encapsulation Limit option is not found in  the
             packet  entering  the  tunnel and if no encapsulation limit
             has  been  configured  for  this  tunnel,  then  no  Tunnel
             Encapsulation  Limit  option  is  included  as  part of the
             encapsulating headers being added at this entry point.

   A Tunnel Encapsulation Limit option added at a tunnel entry-point
   node is removed as part of the decapsulation process at that tunnel's
   exit-point node.

   Two cases of encapsulation that should be avoided are described
   below:

4.1.2 Loopback Encapsulation

   A particular case of encapsulation which must be avoided is the
   loopback encapsulation.  Loopback encapsulation takes place when a
   tunnel IPv6 entry-point node encapsulates tunnel IPv6 packets
   originated from itself, and destined to itself.  This can generate an
   infinite processing loop in the entry-point node.

   To avoid such a case, it is recommended that an implementation have a
   mechanism that checks and rejects the configuration of a tunnel in
   which both the entry-point and exit-point node addresses belong to
   the same node. It is also recommended that the encapsulating engine
   check for and reject the encapsulation of a packet that has the pair
   of tunnel entry-point and exit-point addresses identical with the
   pair of original packet source and final destination addresses.

4.1.3 Routing-Loop Nested Encapsulation

   In the case of a forwarding path with multiple-level nested tunnels,
   a routing-loop from an inner tunnel to an outer tunnel is
   particularly dangerous when packets from the inner tunnels reenter an
   outer tunnel from which they have not yet exited. In such a case, the
   nested encapsulation becomes a recursive encapsulation with the
   negative effects described in 4.1.  Because each nested encapsulation
   adds a tunnel header with a new hop limit value, the IPv6 hop limit
   mechanism cannot control the number of times the packet reaches the
   outer tunnel entry-point node, and thus cannot control the number of
   recursive encapsulations.

   When the path of a packet from source to final destination includes
   tunnels, the maximum number of hops that the packet can traverse
   should be controlled by two mechanisms used together to avoid the
   negative effects of recursive encapsulation in routing loops:





Conta & Deering             Standards Track                    [Page 15]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


        (a)  the original packet hop limit.

             It is decremented at each forwarding operation performed on
             an original packet. This includes each encapsulation of the
             original packet. It does not include nested encapsulations
             of the original packet

        (b)  the tunnel IPv6 packet encapsulation limit.

             It is decremented at each nested encapsulation of the
             packet.

   For a discussion of the excessive encapsulation risk factors in
   nested encapsulation see Appendix A.

5. Tunnel IPv6 Header

   The tunnel entry-point node fills out a tunnel IPv6 main header
   [IPv6-Spec] as follows:

          Version:

            value 6

          Traffic Class:

            Depending on the entry-point node tunnel configuration, the
            traffic class can be set to that of either the original
            packet or a pre-configured value - see section 6.4.

          Flow Label:

            Depending on the entry-point node tunnel configuration, the
            flow label can be set to a pre-configured value. The typical
            value is zero - see section 6.5.

          Payload Length:

            The original packet length, plus the length of the
            encapsulating (prepended) IPv6 extension headers, if any.

          Next Header:

            The next header value according to [IPv6-Spec] from the
            Assigned Numbers RFC [RFC-1700 or its successors].

            For example, if the original packet is an IPv6 packet, this
            is set to:



Conta & Deering             Standards Track                    [Page 16]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


                 - decimal value 41 (Assigned Next Header number for
                 IPv6) - if there are no tunnel extension headers.

                 - value 0 (Assigned Next Header number for IPv6 Hop by
                 Hop Options extension header) - if a hop by hop options
                 extension header immediately follows the tunnel IPv6
                 header.

                 - decimal value 60 (Assigned Next Header number for
                 IPv6 Destination Options extension header) - if a
                 destination options extension header immediately
                 follows the tunnel IPv6 header.

          Hop Limit:

            The tunnel IPv6 header hop limit is set to a pre-configured
            value - see section 6.3.

            The default value for hosts is the Neighbor Discovery
            advertised hop limit [ND-Spec].  The default value for
            routers is the default IPv6 Hop Limit value from the
            Assigned Numbers RFC (64 at the time of writing this
            document).

          Source Address:

            An IPv6 address of the outgoing interface of the tunnel
            entry-point node.  This address is configured as the tunnel
            entry-point node address - see section 6.1.

          Destination Address:

            An IPv6 address of the tunnel exit-point node. This address
            is configured as the tunnel exit-point node address - see
            section 6.2.

5.1 Tunnel IPv6 Extension Headers

   Depending on IPv6 node configuration parameters, a tunnel entry-point
   node may append to the tunnel IPv6 main header one or more IPv6
   extension headers, such as a Hop-by-Hop Options header, a Routing
   header, or others.









Conta & Deering             Standards Track                    [Page 17]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   To limit the number of nested encapsulations of a packet, if it was
   configured to do so - see section 6.6 - a tunnel entry-point includes
   a Destination Options extension header containing a Tunnel
   Encapsulation Limit option. If that option is the only option present
   in the Destination Options header, the header has the following
   format:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Header  |Hdr Ext Len = 0| Opt Type = 4  |Opt Data Len=1 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Next Header:

            Identifies the type of the original packet header.  For
            example, if the original packet is an IPv6 packet, the next
            header protocol value is set to decimal value 41 (Assigned
            payload type number for IPv6).

          Hdr Ext Len:

            Length of the Destination Options extension header in 8-
            octet units, not including the first 8 octets. Set to value
            0, if no other options are present in this destination
            options header.

          Option Type:

            value 4 - see section 4.1.1.

          Opt Data Len:

            value 1 - see section 4.1.1.

          Tun Encap Lim:

            8 bit unsigned integer - see section 4.1.1.

          Option Type:

            value 1 - PadN option, to align the  header  following
            this header.

          Opt Data Len:

            value 1 - one octet of option data.




Conta & Deering             Standards Track                    [Page 18]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


          Option Data:

            value 0 - one zero-valued octet.

6. IPv6 Tunnel State Variables

   The IPv6 tunnel state variables, some of which are or may be
   configured on the tunnel entry-point node, are:

6.1 IPv6 Tunnel Entry-Point Node Address

   The tunnel entry-point node address is one of the valid IPv6 unicast
   addresses of the entry-point node - the validation of the address at
   tunnel configuration time is recommended.

   The tunnel entry-point node address is copied to the source address
   field in the tunnel IPv6 header during packet encapsulation.

6.2 IPv6 Tunnel Exit-Point Node Address

   The tunnel exit-point node address is used as IPv6 destination
   address for the tunnel IPv6 header. A tunnel acts like a virtual
   point to point link between the entry-point node and exit-point node.

   The tunnel exit-point node address is copied to the destination
   address field in the tunnel IPv6 header during packet encapsulation.

   The configuration of the tunnel entry-point and exit-point addresses
   is not subject to IPv6 Autoconfiguration or IPv6 Neighbor Discovery.

6.3 IPv6 Tunnel Hop Limit

   An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in
   which the passing of the original packet through the tunnel is like
   the passing of the original packet over a one hop link, regardless of
   the number of hops in the IPv6 tunnel.

   The "single-hop" mechanism should be implemented by having the tunnel
   entry point node set a tunnel IPv6 header hop limit independently of
   the hop limit of the original header.

   The "single-hop" mechanism hides from the original IPv6 packets the
   number of IPv6 hops of the tunnel.

   It is recommended that the tunnel hop limit be configured with a
   value that ensures:





Conta & Deering             Standards Track                    [Page 19]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


        (a)  that tunnel IPv6 packets can reach  the  tunnel  exit-point
             node

        (b)  a quick expiration of the tunnel packet if a  routing  loop
             occurs within the IPv6 tunnel.

   The tunnel hop limit default value for hosts is the IPv6 Neighbor
   Discovery advertised hop limit [ND-Spec].  The tunnel hop limit
   default value for routers is the default IPv6 Hop Limit value from
   the Assigned Numbers RFC (64 at the time of writing this document).

   The tunnel hop limit is copied into the hop limit field of the tunnel
   IPv6 header of each packet encapsulated by the tunnel entry-point
   node.

6.4 IPv6 Tunnel Packet Traffic Class

   The IPv6 Tunnel Packet Traffic Class indicates the value that a
   tunnel entry-point node sets in the Traffic Class field of a tunnel
   header. The default value is zero.  The configured Packet Traffic
   Class can also indicate whether the value of the Traffic Class field
   in the tunnel header is copied from the original header, or it is set
   to the pre-configured value.

6.5 IPv6 Tunnel Flow Label

   The IPv6 Tunnel Flow Label indicates the value that a tunnel entry-
   point node sets in the flow label of a tunnel header. The default
   value is zero.

6.6 IPv6 Tunnel Encapsulation Limit

   The Tunnel Encapsulation Limit value can indicate whether the entry-
   point node is configured to limit the number of encapsulations of
   tunnel packets originating on that node.  The IPv6 Tunnel
   Encapsulation Limit is the maximum number of additional
   encapsulations permitted for packets undergoing encapsulation at that
   entry-point node. Recommended default value is 4. An entry-point node
   configured to limit the number of nested encapsulations prepends a
   Destination Options extension header containing a Tunnel
   Encapsulation Limit option to an original packet undergoing
   encapsulation - see sections 4.1 and 4.1.1.

6.7 IPv6 Tunnel MTU

   The tunnel MTU is set dynamically to the Path MTU between the tunnel
   entry-point and the tunnel exit-point nodes, minus the size of the
   tunnel headers: the maximum size of a tunnel packet payload that can



Conta & Deering             Standards Track                    [Page 20]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   be sent through the tunnel without fragmentation [IPv6-Spec]. The
   tunnel entry-point node performs Path MTU discovery on the path
   between the tunnel entry-point and exit-point nodes [PMTU-Spec],
   [ICMP-Spec]. The tunnel MTU of a nested tunnel is the tunnel MTU of
   the outer tunnel minus the size of the nested tunnel headers.

7. IPv6 Tunnel Packet Size Issues

   Prepending a tunnel header increases the size of a packet, therefore
   a tunnel packet resulting from the encapsulation of an IPv6 original
   packet may require fragmentation.

   A tunnel IPv6 packet resulting from the encapsulation of an original
   packet is considered an IPv6 packet originating from the tunnel
   entry-point node. Therefore, like any source of an IPv6 packet, a
   tunnel entry-point node must support fragmentation of tunnel IPv6
   packets.

   A tunnel intermediate node that forwards a tunnel packet to another
   node in the tunnel follows the general IPv6 rule that it must not
   fragment a packet undergoing forwarding.

   A tunnel exit-point node receiving tunnel packets at the end of the
   tunnel for decapsulation applies the strict left-to-right processing
   rules for extension headers. In the case of a fragmented tunnel
   packet, the fragments are reassembled into a complete tunnel packet
   before determining that an embedded packet is present.

   Note:

   A particular problem arises when the destination of a fragmented
   tunnel packet is an exit-point node identified by an anycast address.
   The problem, which is similar to that of original fragmented IPv6
   packets destined to nodes identified by an anycast address, is that
   all the fragments of a packet must arrive at the same destination
   node for that node to be able to perform a successful reassembly, a
   requirement that is not necessarily satisfied by packets sent to an
   anycast address.

7.1 IPv6 Tunnel Packet Fragmentation

   When an IPv6 original packet enters a tunnel, if the original packet
   size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
   entry-point and the tunnel exit-point, minus the size of the tunnel
   header(s)), it is handled as follows:






Conta & Deering             Standards Track                    [Page 21]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


        (a)  if the original IPv6 packet size is larger  than  the  IPv6
             minimum link MTU [IPv6-Spec], the entry-point node discards
             the packet and sends an ICMPv6 "Packet Too Big" message to
             the source address of the original packet with the
             recommended MTU size field set to the tunnel MTU or the
             IPv6 minimum link MTU, whichever is larger, i.e. max
             (tunnel MTU, IPv6 minimum link MTU).  Also see sections 6.7
             and 8.2.

        (b)  if the original IPv6 packet is equal or  smaller  than  the
             IPv6 minimum link MTU, the tunnel entry-point node
             encapsulates the original packet, and subsequently
             fragments the resulting IPv6 tunnel packet into IPv6
             fragments that do not exceed the Path MTU to the tunnel
             exit-point.

7.2 IPv4 Tunnel Packet Fragmentation

   When an IPv4 original packet enters a tunnel, if the original packet
   size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel
   entry-point and the tunnel exit-point, minus the size of the tunnel
   header(s)), it is handled as follows:

        (a)  if in the original IPv4 packet header the Don't Fragment  -
             DF - bit flag is SET, the entry-point node discards the
             packet and returns an ICMP message.  The ICMP message has
             the type = "unreachable", the code = "packet too big", and
             the recommended MTU size field set to the size of the
             tunnel MTU - see sections 6.7 and 8.3.

        (b)  if in the original packet header the Don't Fragment - DF  -
             bit flag is CLEAR, the tunnel entry-point node encapsulates
             the original packet, and subsequently fragments the
             resulting IPv6 tunnel packet into IPv6 fragments that do
             not exceed the Path MTU to the tunnel exit-point.

8. IPv6 Tunnel Error Processing and Reporting

   IPv6 Tunneling follows the general rule that an error detected during
   the processing of an IPv6 packet is reported through an ICMP message
   to the source of the packet.

   On a forwarding path that includes IPv6 tunnels, an error detected by
   a node that is not in any tunnel is directly reported to the source
   of the original IPv6 packet.






Conta & Deering             Standards Track                    [Page 22]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   An error detected by a node inside a tunnel is reported to the source
   of the tunnel packet, that is, the tunnel entry-point node.  The ICMP
   message sent to the tunnel entry-point node has as ICMP payload the
   tunnel IPv6 packet that has the original packet as its payload.

   The cause of a packet error encountered inside a tunnel can be a
   problem with:

        (a)  the tunnel header, or

        (b)  the tunnel packet.

   Both tunnel header and tunnel packet problems are reported to the
   tunnel entry-point node.

   If a tunnel packet problem is a consequence of a problem with the
   original packet, which is the payload of the tunnel packet, then the
   problem is also reported to the source of the original packet.

   To report a problem detected inside the tunnel to the source of an
   original packet, the tunnel entry point node must relay the ICMP
   message received from inside the tunnel to the source of that
   original IPv6 packet.

   An example of the processing that can take place in the error
   reporting mechanism of a node is illustrated in Fig.7, and Fig.8:

   Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives an
   ICMP packet from inside the tunnel, marked Tunnel ICMPv6 Message in
   Fig.7. The tunnel entry-point node IPv6 layer passes the received
   ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP
   type and code [ICMP-Spec] generates an internal "error code".

   Fig.7 path #1 - The internal error code, is passed with the "ICMPv6
   message payload" to the upper-layer protocol - in this case the IPv6
   tunnel upper-layer error input.















Conta & Deering             Standards Track                    [Page 23]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


 +-------+   +-------+   +-----------------------+
 | Upper |   | Upper |   | Upper                 |
 | Layer |   | Layer |   | Layer                 |
 | Proto.|   | Proto |   | IPv6 Tunnel           |
 | Error |   | Error |   | Error                 |
 | Input |   | Input |   | Input                 |
 |       |   |       |   |       Decapsulate     |
 |       |   |       |   |  -->--ICMPv6--#2->--  |
 |       |   |       |   |  |    Payload      |  |
 +-------+   +-------+   +--|-----------------|--+
     |           |          |                 |
     ^           ^          ^                 v
     |           |          |                 |
     --------------------#1--    -----Orig.Packet?--- - - - - - - -
              #1                #3  Int.Error Code, #5             |
Int.Error Code,^                 v  Source Address, v              v
ICMPv6 Payload |            IPv6 |  Orig. Packet    | IPv4         |
      +--------------+    +------------+     +------------+    + - - +
      |              |    |            |     |            |
      | ICMP v6      |    | ICMP v6    |     | ICMP v4    |    |     |
      | Input        |    | Err Report |     | Err Report |
      |  -  -  -  -  +----+  -  -  -  -|     +  -  -  -  -+    + - - +
      |                                |     |            |
      |            IPv6 Layer          |     | IPv4 Layer |    |     |
      |                                |     |            |
      +--------------------------------+     +------------+    + - - +
            |                    |                  |
            ^                    V                  V
            #0                   #4                 #6
            |                    |                  |
       Tunnel ICMPv6          ICMPv6             ICMPv4
         Message              Message            Message
            |                    |                  |

   Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine)

   Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input
   decapsulates the tunnel IPv6 packet, which is the ICMPv6 message
   payload, obtaining the original packet, and thus the original headers
   and dispatches the "internal error code", the source address from the
   original packet header, and the original packet, down to the error
   report block of the protocol identified by the Next Header field in
   the tunnel header immediately preceding the original packet in the
   ICMP message payload.

   From here the processing depends on the protocol of the original
   packet:




Conta & Deering             Standards Track                    [Page 24]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


        (a)  - for an IPv6 original packet

     Fig.7 path #3 and Fig.8 (c.1)- for an IPv6 original packet, the
     ICMPv6 error report builds an ICMP message of a type and code
     according to the "internal error code", containing the "original
     packet" as ICMP payload.

     Fig.7 path #4 and Fig.8 (d.1)- The ICMP message has the tunnel
     entry-point node address as source address, and the original packet
     source node address as destination address. The tunnel entry-point
     node sends the ICMP message to the source node of the original
     packet.

        (b)  - for an IPv4 original packet

     Fig.7 path #5 and Fig.8 (c.2) - for an IPv4 original packet, the
     ICMPv4 error report builds an ICMP message of a type and code
     derived from the the "internal error code", containing the
     "original packet" as ICMP payload.

     Fig.7 path #6 and Fig.8 (d.2) - The ICMP message has the tunnel
     entry-point node IPv4 address as source address, and the original
     packet IPv4 source node address as destination address. The tunnel
     entry-point node sends the ICMP message to the source node of the
     original packet.

   A graphical description of the header processing taking place is  the
   following:























Conta & Deering             Standards Track                    [Page 25]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


    <                     Tunnel Packet                                >
   +--------+- - - - - -+--------+------------------------------//------+
   | IPv6   | IPv6      | ICMP   |             Tunnel                   |
(a)|        | Extension |        |             IPv6                     |
   | Header | Headers   | Header |             Packet in error          |
   +--------+- - - - - -+--------+------------------------------//------+
    < Tunnel Headers   > <       Tunnel ICMP Message                   >
                                  <         ICMPv6 Message Payload     >
                                 |
                                 v
        <                    Tunnel ICMP Message                   >
                        <       Tunnel IPv6 Packet in Error        >
       +--------+      +---------+      +----------+--------//------+
       | ICMP   |      | Tunnel  |      | Original | Original       |
(b)    |        |  +   | IPv6    |  +   |          | Packet         |
       | Header |      | Headers |      | Headers  | Payload        |
       +--------+      +---------+      +----------+--------//------+
           |                             <Original Packet in Error >
           -----------------              |
                           |              |
             --------------|---------------
             |             |
             V             V
       +---------+      +--------+      +-------------------//------+
       | New     |      | ICMP   |      |                           |
(c.1)  | IPv6    |  +   |        |  +   | Orig. Packet in Error     |
       | Headers |      | Header |      |                           |
       +---------+      +--------+      +-------------------//------+
                             |
                             v
                 +---------+--------+-------------------//------+
                 | New     | ICMP   |  Original                 |
(d.1)            | IPv6    |        |                           |
                 | Headers | Header |  Packet in Error          |
                 +---------+--------+-------------------//------+
                  <             New ICMP Message               >















Conta & Deering             Standards Track                    [Page 26]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


                  or for an IPv4 original packet

       +---------+      +--------+      +-------------------//------+
       | New     |      | ICMP   |      |                           |
(c.2)  | IPv4    |  +   |        |  +   | Orig. Packet in Error     |
       | Header  |      | Header |      |                           |
       +---------+      +--------+      +-------------------//------+
                             |
                             v
                 +---------+--------+-------------------//------+
                 | New     | ICMP   |  Original                 |
(d.2)            | IPv4    |        |                           |
                 | Header  | Header |  Packet in Error          |
                 +---------+--------+-------------------//------+
                  <             New ICMP Message               >

                Fig.8 ICMP Error Reporting and Processing

8.1 Tunnel ICMP Messages

   The tunnel ICMP messages that are reported to the source of the
   original packet are:

        hop limit exceeded

             The tunnel has a misconfigured hop limit, or contains a
             routing loop, and packets do not reach the tunnel exit-
             point node. This problem is reported to the tunnel entry-
             point node, where the tunnel hop limit can be reconfigured
             to a higher value. The problem is further reported to the
             source of the original packet as described in section 8.2,
             or 8.3.

        unreachable node

             One of the nodes in the tunnel is not or is no longer
             reachable.  This problem is reported to the tunnel entry-
             point node, which should be reconfigured with a valid and
             active path between the entry and exit-point of the tunnel.

             The problem is further reported to the source of the
             original packet as described in section 8.2, or 8.3.

        parameter problem

             A Parameter Problem ICMP message pointing to a valid Tunnel
             Encapsulation Limit Destination header with a Tun Encap Lim
             field value set to one is an indication that the tunnel



Conta & Deering             Standards Track                    [Page 27]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


             packet exceeded the maximum number of encapsulations
             allowed. The problem is further reported to the source of
             the original packet as described in section 8.2, or 8.3.

   The above three problems detected inside the tunnel, which are a
   tunnel configuration and a tunnel topology problem, are reported to
   the source of the original IPv6 packet, as a tunnel generic
   "unreachable" problem caused by a "link problem" - see section 8.2
   and 8.3.

        packet too big

             The tunnel packet exceeds the tunnel Path MTU.

             The information carried by this type of ICMP message is
             used as follows:

             - by a receiving tunnel entry-point node to set or adjust
             the tunnel MTU

             - by a sending tunnel entry-point node to indicate to the
             source of an original packet the MTU size that should be
             used in sending IPv6 packets towards the tunnel entry-point
             node.

8.2 ICMP Messages for IPv6 Original Packets

   The tunnel entry-point node builds the ICMP and IPv6 headers of the
   ICMP message that is sent to the source of the original packet as
   follows:

   IPv6 Fields:

   Source Address

                  A valid unicast IPv6 address of the outgoing
                  interface.

   Destination Address

                  Copied from the Source Address field of the Original
                  IPv6 header.

   ICMP Fields:

   For any of the following tunnel ICMP error messages:

     "hop limit exceeded"



Conta & Deering             Standards Track                    [Page 28]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


     "unreachable node"

     "parameter problem" - pointing to a valid Tunnel Encapsulation
     Limit destination header with the Tun Encap Lim field set to a
     value zero:

     Type           1 - unreachable node

     Code           3 - address unreachable

   For tunnel ICMP error message "packet too big":

     Type           2 - packet too big

     Code           0

     MTU            The MTU field from the tunnel ICMP message minus
                    the length of the tunnel headers.

   According to the general rules described in 7.1, an ICMP "packet too
   big" message is sent to the source of the original packet only if the
   original packet size is larger than the minimum link MTU size
   required for IPv6 [IPv6-Spec].

8.3 ICMP Messages for IPv4 Original Packets

   The tunnel entry-point node builds the ICMP and IPv4 header of the
   ICMP message that is sent to the source of the original packet as
   follows:

   IPv4 Fields:

   Source Address

                  A valid unicast IPv4 address of the outgoing
                  interface.

   Destination Address

                  Copied from the Source Address field of the Original
                  IPv4 header.

   ICMP Fields:

   For any of the following tunnel ICMP error messages:

     "hop limit exceeded"




Conta & Deering             Standards Track                    [Page 29]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


     "unreachable node"

     "parameter problem" - pointing to a valid Tunnel Enacpsulation
     Limit destination header with the Tun Encap Lim field set to a
     value zero:

     Type           3 - destination unreachable

     Code           1 - host unreachable

   For a tunnel ICMP error message "packet too big":

     Type           3 - destination unreachable

     Code           4 - packet too big

     MTU            The MTU field from the tunnel ICMP message minus
                    the length of the tunnel headers.

   According to the general rules described in section 7.2, an ICMP
   "packet too big" message is sent to the original IPv4 packet source
   node if the the original IPv4 header has the DF - don't fragment -
   bit flag SET.

8.4 ICMP Messages for Nested Tunnel Packets

   In case of an error uncovered with a nested tunnel packet, the inner
   tunnel entry-point, which receives the ICMP error message from the
   inner tunnel reporting node, relays the ICMP message to the outer
   tunnel entry-point following the mechanisms described in sections
   8.,8.1, 8.2, and 8.3. Further, the outer tunnel entry-point relays
   the ICMP message to the source of the original packet, following the
   same mechanisms.

9. Security Considerations

   An IPv6 tunnel can be secured by securing the IPv6 path between the
   tunnel entry-point and exit-point node. The security architecture,
   mechanisms, and services are described in [RFC2401], [RFC2402], and
   [RFC2406].  A secure IPv6 tunnel may act as a gateway-to-gateway
   secure path as described in [RFC2401].

   For a secure IPv6 tunnel, in addition to the mechanisms described
   earlier in this document, the entry-point node of the tunnel performs
   security algorithms on the packet and prepends as part of the tunnel
   headers one or more security headers in conformance with [IPv6-Spec],
   [RFC2401], and [RFC2402], or [RFC2406].




Conta & Deering             Standards Track                    [Page 30]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   The exit-point node of a secure IPv6 tunnel performs security
   algorithms and processes the tunnel security header[s] as part of the
   tunnel headers processing described earlier, and in conformance with
   [RFC2401], and [RFC2402], or [RFC2406].  The exit-point node discards
   the tunnel security header[s] with the rest of the tunnel headers
   after tunnel headers processing completion.

   The degree of integrity, authentication, and confidentiality and the
   security processing performed on a tunnel packet at the entry-point
   and exit-point node of a secure IPv6 tunnel depend on the type of
   security header - authentication (AH) or encryption (ESP) - and
   parameters configured in the Security Association for the tunnel.
   There is no dependency or interaction between the security level and
   mechanisms applied to the tunnel packets and the security applied to
   the original packets which are the payloads of the tunnel packets.
   In case of nested tunnels, each inner tunnel may have its own set of
   security services, independently from those of the outer tunnels, or
   of those between the source and destination of the original packet.

10. Acknowledgments

   This document is partially derived from several discussions about
   IPv6 tunneling on the IPng Working Group Mailing List and from
   feedback from the IPng Working Group to an IPv6 presentation that
   focused on IPv6 tunneling at the 33rd IETF, in Stockholm, in July
   1995.

   Additionally, the following documents that focused on tunneling or
   encapsulation were helpful references: RFC 1933 (R. Gilligan, E.
   Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P.  Tsuchiya),
   RFC 1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W.
   Simpson), as well as RFC 2003 (C. Perkins).

   Brian Carpenter, Richard Draves, Bob Hinden, Thomas Narten, Erik
   Nordmark (in alphabetical order) gave valuable reviewing comments and
   suggestions for the improvement of this document. Scott Bradner, Ross
   Callon, Dimitry Haskin, Paul Traina, and James Watt (in alphabetical
   order) shared their view or experience on matters of concern in this
   document.  Judith Grossman provided a sample of her many years of
   editorial and writing experience as well as a good amount of probing
   technical questions.

11. References


   [IPv6-Spec] Deering, S. and R. Hinden, "Internet Protocol
               Version 6 (IPv6) Specification", RFC 2460, December 1998.




Conta & Deering             Standards Track                    [Page 31]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   [ICMP-Spec] Conta, A. and S. Deering "Internet Control Message
               Protocol for the Internet Protocol Version 6 (IPv6)", RFC
               2463, December 1998.

   [ND-Spec]   Narten, T., Nordmark, E., and W. Simpson "Neighbor
               Discovery for IP Version 6 (IPv6)", RFC 2461, December
               1998.

   [PMTU-Spec] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
               for IP Version 6 (IPv6)", RFC 1981, August 1996.

   [RFC2401]   Atkinson, R., "Security Architecture for the Internet
               Protocol", RFC 2401, November 1998.

   [RFC2402]   Atkinson, R., "IP Authentication Header", RFC 2402,
               November 1998.

   [RFC2406]   Atkinson, R., "IP Encapsulation Security Payload (ESP)",
               RFC 2406, November 1998.

   [RFC-1853]  Simpson, W., "IP in IP Tunneling", RFC 1853, October
               1995.

   [Assign-Nr] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
               RFC 1700, October 1994.  See also:
               http://www.iana.org/numbers.html

   [RFC2119]   Bradner, S., "Key words for use in RFCs to indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors' Addresses

   Alex Conta
   Lucent Technologies Inc.
   300 Baker Ave
   Concord, MA 01742-2168
   +1-978-287-2842

   EMail: aconta@lucent.com


   Stephen Deering
   Cisco Systems
   170 West Tasman Dr
   San Jose, CA 95132-1706

   Phone: +1-408-527-8213
   EMail: deering@cisco.com



Conta & Deering             Standards Track                    [Page 32]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


Appendix A

A.1   Risk Factors in Nested Encapsulation

   Nested encapsulations of a packet become a recursive encapsulation if
   the packet reenters an outer tunnel before exiting it. The cases
   which present a high risk of recursive encapsulation are those in
   which a tunnel entry-point node cannot determine whether a packet
   that undergoes encapsulation reenters the tunnel before exiting it.
   Routing loops that cause tunnel packets to reenter a tunnel before
   exiting it are certainly the major cause of the problem.  But since
   routing loops exist, and happen, it is important to understand and
   describe, the cases in which the risk for recursive encapsulation is
   higher.

   There are two significant elements that determine the risk factor of
   routing loop recursive encapsulation:

        (a)  the type of tunnel,

        (b) the type of route to the tunnel exit-point, which
             determines the packet forwarding through the tunnel, that
             is, over the tunnel virtual-link.

A.1.1  Risk Factor in Nested Encapsulation - type of tunnel.

   The type of tunnels which were identified as a high risk factor for
   recursive encapsulation in routing loops are:

              "inner tunnels with identical exit-points".

   Since the source and destination of an original packet is the main
   information used to decide whether to forward a packet through a
   tunnel or not, a recursive encapsulation can be avoided in case of a
   single tunnel (non-inner), by checking that the packet to be
   encapsulated is not originated on the entry-point node.  This
   mechanism is suggested in [RFC-1853].

   However, this type of protection does not seem to work well in case
   of inner tunnels with different entry-points, and identical exit-
   points.

   Inner tunnels with different entry-points and identical exit-points
   introduce ambiguity in deciding whether to encapsulate a packet, when
   a packet encapsulated in an inner tunnel reaches the entry-point node
   of an outer tunnel by means of a routing loop. Because the source of
   the tunnel packet is the inner tunnel entry-point node which is
   different than the entry-point node of the outer tunnel, the source



Conta & Deering             Standards Track                    [Page 33]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   address checking (mentioned above) fails to detect an invalid
   encapsulation, and as a consequence the tunnel packet gets
   encapsulated at the outer tunnel each time it reaches it through the
   routing loop.

A.1.2  Risk Factor in Nested Encapsulation - type of route.

   The type of route to a tunnel exit-point node has been also
   identified as a high risk factor of recursive encapsulation in
   routing loops.

   One type of route to a tunnel exit-point node is a route to a
   specified destination node, that is, the destination is a valid
   specified IPv6 address (route to node). Such a route can be selected
   based on the longest match of an original packet destination address
   with the destination address stored in the tunnel entry-point node
   routing table entry for that route. The packet forwarded on such a
   route is first encapsulated and then forwarded towards the tunnel
   exit-point node.

   Another type of route to a tunnel exit-point node is a route to a
   specified prefix-net, that is, the destination is a valid specified
   IPv6 prefix (route to net). Such a route can be selected based on the
   longest path match of an original packet destination address with the
   prefix destination stored in the tunnel entry-point node routing
   table entry for that route. The packet forwarded on such a route is
   first encapsulated and then forwarded towards the tunnel exit-point
   node.

   And finally another type of route to a tunnel exit-point is a default
   route, or a route to an unspecified destination. This route is
   selected when no-other match for the destination of the original
   packet has been found in the routing table. A tunnel that is the
   first hop of a default route is a "default tunnel".

   If the route to a tunnel exit-point is a route to node, the risk
   factor for recursive encapsulation is minimum.

   If the route to a tunnel exit-point is a route to net, the risk
   factor for recursive encapsulation is medium. There is a range of
   destination addresses that will match the prefix the route is
   associated with.  If one or more inner tunnels with different tunnel
   entry-points have exit-point node addresses that match the route to
   net of an outer tunnel exit-point, then a recursive encapsulation may
   occur if a tunnel packet gets diverted from inside such an inner
   tunnel to the entry-point of the outer tunnel that has a route to its
   exit-point that matches the exit-point of an inner tunnel.




Conta & Deering             Standards Track                    [Page 34]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


   If the route to a tunnel exit-point is a default route, the risk
   factor for recursive encapsulation is maximum. Packets are forwarded
   through a default tunnel for lack of a better route.  In many
   situations, forwarding through a default tunnel can happen for a wide
   range of destination addresses which at the maximum extent is the
   entire Internet minus the node's link. As consequence, it is likely
   that in a routing loop case, if a tunnel packet gets diverted from an
   inner tunnel to an outer tunnel entry-point in which the tunnel is a
   default tunnel, the packet will be once more encapsulated, because
   the default routing mechanism will not be able to discern
   differently, based on the destination.








































Conta & Deering             Standards Track                    [Page 35]

RFC 2473            Generic Packet Tunneling in IPv6       December 1998


Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
























Conta & Deering             Standards Track                    [Page 36]