idnits 2.17.1 draft-ietf-ipngwg-ipv6-tunnel-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 35 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 382 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 29 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 15 has weird spacing: '... uments of th...' == Line 16 has weird spacing: '...tribute work-...' == Line 19 has weird spacing: '... Drafts are ...' == Line 20 has weird spacing: '...ed, or obsol...' == Line 21 has weird spacing: '... other docum...' == (377 more instances...) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 1996) is 10017 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1825' is mentioned on line 1354, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Missing Reference: 'RFC1826' is mentioned on line 1354, but not defined ** Obsolete undefined reference: RFC 1826 (Obsoleted by RFC 2402) == Missing Reference: 'RFC1827' is mentioned on line 1354, but not defined ** Obsolete undefined reference: RFC 1827 (Obsoleted by RFC 2406) == Missing Reference: 'RFC1883' is mentioned on line 1348, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Unused Reference: 'RFC-1825' is defined on line 1406, but no explicit reference was found in the text == Unused Reference: 'RFC-1826' is defined on line 1409, but no explicit reference was found in the text == Unused Reference: 'RFC-1827' is defined on line 1411, but no explicit reference was found in the text == Unused Reference: 'RFC-1700' is defined on line 1415, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1885 (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1970 (Obsoleted by RFC 2461) ** Obsolete normative reference: RFC 1981 (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 1825 (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1853 ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 23 errors (**), 0 flaws (~~), 16 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPng Working Group A. Conta (Lucent Technologies Inc.) 3 INTERNET-DRAFT S. Deering (Cisco Systems) 4 November 1996 6 Generic Packet Tunneling in IPv6 8 Specification 10 draft-ietf-ipngwg-ipv6-tunnel-05.txt 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working doc- 15 uments of the Internet Engineering Task Force (IETF), its Areas, and 16 its Working Groups. Note that other groups may also distribute work- 17 ing documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 27 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Distribution of this memo is unlimited. 33 Abstract 35 This document defines the model and generic mechanisms for IPv6 36 encapsulation of Internet packets, such as IPv6 and IPv4. The model 37 and mechanisms can be applied to other protocol packets as well, such 38 as AppleTalk, IPX, CLNP, or others. 40 Table of Contents 42 Status of this Memo...........................................1 43 Table of Contents.............................................2 44 1. Introduction..................................................3 45 2. Terminology...................................................3 46 3. Generic IPv6 Tunneling........................................5 47 3.1 IPv6 Encapsulation.......................................7 48 3.2 IPv6 Packet Processing in Tunnels........................8 49 3.3 IPv6 Decapsulation.......................................8 50 3.4 IPv6 Tunnel Protocol Engine..............................9 51 4. Nested Encapsulation.........................................12 52 4.1 Limiting Nested Encapsulation..........................13 53 4.1.1 Tunnel Encapsulation Limit.......................13 54 4.1.2 Loopback Encapsulation...........................15 55 4.1.3 Routing Loop Nested Encapsulation................15 56 5. Tunnel IPv6 Header...........................................16 57 5.1 Tunnel IPv6 Extension Headers...........................18 58 6. IPv6 Tunnel State Variables..................................19 59 6.1 IPv6 Tunnel Entry-Point Node............................19 60 6.2 IPv6 Tunnel Exit-Point Node.............................19 61 6.3 IPv6 Tunnel Hop Limit...................................20 62 6.4 IPv6 Tunnel Packet Priority.............................21 63 6.5 IPv6 Tunnel Flow Label..................................21 64 6.6 IPv6 Tunnel Encapsulation Limit.........................21 65 6.7 IPv6 Tunnel MTU.........................................21 66 7. IPv6 Tunnel Packet Size Issues...............................22 67 7.1 IPv6 Tunnel Packet Fragmentation........................22 68 7.2 IPv4 Tunnel Packet Fragmentation........................23 69 8. IPv6 Tunnel Error Reporting and Processing...................23 70 8.1 Tunnel ICMP Messages....................................27 71 8.2 ICMP Messages for IPv6 Original Packets.................28 72 8.3 ICMP Messages for IPv4 Original Packets.................30 73 8.4 ICMP Messages for Nested Tunnel Packets.................31 74 9. Security Considerations......................................31 75 10. Acknowledgments.............................................32 76 11. References..................................................32 77 Authors' Addresses..............................................33 78 Appendix A.Risk Factors in Recursive Encapsulation..............34 79 Fig.1.................................................6 80 Fig.2.................................................6 81 Fig.3.................................................7 82 Fig.4.................................................8 83 Fig.5.................................................9 84 Fig.6................................................13 85 Fig.7................................................25 86 Fig.8................................................26/27 87 1. Introduction 89 This document specifies a method and generic mechanisms by which a 90 packet is encapsulated and carried as payload within an IPv6 packet. 91 The resulting packet is called an IPv6 tunnel packet. The forwarding 92 path between the source and destination of the tunnel packet is 93 called an IPv6 tunnel. The technique is called IPv6 tunneling. 95 A typical scenario for IPv6 tunneling is the case in which an 96 intermediate node exerts explicit routing control by specifying 97 particular forwarding paths for selected packets. This control is 98 achieved by prepending to each of the selected original packets IPv6 99 headers that identify the forwarding path. 101 In addition to the description of generic IPv6 tunneling mechanisms, 102 which is the focus of this document, specific mechanisms for 103 tunneling IPv6 and IPv4 packets are also described herein. 105 2. Terminology 107 original packet 109 a packet that undergoes encapsulation. 111 original header 113 the header of an original packet. 115 tunnel 117 a forwarding path between two nodes on which packets payloads 118 are original packets. 120 tunnel end-node 122 a node where a tunnel begins or ends. 124 tunnel header 126 the header prepended to the original packet during encapsula- 127 tion. It specifies the tunnel end-points as source and destina- 128 tion. 130 tunnel packet 132 a packet that encapsulates an original packet. 134 tunnel entry-point 136 the tunnel end-node where an original packet is encapsulated. 138 tunnel exit-point 140 the tunnel end-node where a tunnel packet is decapsulated. 142 IPv6 tunnel 144 a tunnel configured as a virtual link between two IPv6 nodes, on 145 which the encapsulating protocol is IPv6. 147 fixed-exit tunnel 149 a tunnel for which a specific exit-point was configured. 151 free-exit tunnel 153 a tunnel for which no specific exit-point was configured; the 154 exit point is extracted from the destination of each packet 155 encapsulated and sent into the tunnel. 157 tunnel MTU 159 the maximum size of a tunnel packet payload without requiring 160 fragmentation, that is, the Path MTU between the tunnel entry- 161 point and the tunnel exit-point nodes minus the size of the tun- 162 nel headers. 164 tunnel hop limit 166 the maximum number of hops that a tunnel packet can travel from 167 the tunnel entry-point to the tunnel exit-point. 169 inner tunnel 171 a tunnel that is a hop (virtual link) of another tunnel. 173 outer tunnel 175 a tunnel containing one or more inner tunnels. 177 nested tunnel packet 179 a tunnel packet that has as payload a tunnel packet. 181 nested tunnel header 183 the tunnel header of a nested tunnel packet. 185 nested encapsulation 187 encapsulation of an encapsulated packet. 189 recursive encapsulation 191 encapsulation of a packet that reenters a tunnel before exiting 192 it. 194 tunnel encapsulation limit 196 the maximum number of nested encapsulations of a packet. 198 3. IPv6 Tunneling 200 IPv6 tunneling is a technique for establishing a "virtual link" 201 between two IPv6 nodes for transmitting data packets as payloads of 202 IPv6 packets (see Fig.1). From the point of view of the two nodes, 203 this "virtual link", called an IPv6 tunnel, appears as a point to 204 point link on which IPv6 acts like a link-layer protocol. The two 205 IPv6 nodes play specific roles. One node encapsulates original pack- 206 ets received from other nodes or from itself and forwards the result- 207 ing tunnel packets through the tunnel. The other node decapsulates 208 the received tunnel packets and forwards the resulting original pack- 209 ets towards their destinations, possibly itself. The encapsulator 210 node is called the tunnel entry-point node, and it is the source of 211 the tunnel packets. The decapsulator node is called the tunnel exit- 212 point, and it is the destination of the tunnel packets. 214 Note: 216 This document refers in particular to tunnels between two nodes iden- 217 tified by unicast addresses - such tunnels look like "virtual point 218 to point links". Some of the mechanisms described herein apply also 219 to tunnels in which the entry and exit-point nodes are identified by 220 other types of addresses, such as anycast or multicast. These tun- 221 nels look like "virtual point to multipoint links". At the time of 222 writing this document, such addresses, in particular anycast 223 addresses are a subject of ongoing specification and experimental 224 work. Therefore it is not in the scope of this document to describe 225 in detail mechanisms of tunnels between nodes identified by anycast 226 or multicast addresses. 228 Tunnel from node B to node C 229 <----------------------> 230 Tunnel Tunnel 231 Entry-Point Exit-Point 232 Node Node 233 +-+ +-+ +-+ +-+ 234 |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D| 235 +-+ +-+ +-+ +-+ 236 Original Original 237 Packet Packet 238 Source Destination 239 Node Node 241 Fig.1 Tunnel 243 An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow 244 takes place in one direction between the IPv6 tunnel entry-point and 245 exit-point nodes (see Fig.1). 247 Bi-directional tunneling is achieved by merging two unidirectional 248 mechanisms, that is, configuring two tunnels, each in opposite direc- 249 tion to the other - the entry-point node of one tunnel is the exit- 250 point node of the other tunnel (see Fig.2). 252 Tunnel from Node B to Node C 253 <------------------------> 254 Tunnel Tunnel 255 Original Entry-Point Exit-Point Original 256 Packet Node Node Packet 257 Source Destination 258 Node Node 259 +-+ +-+ +-+ +-+ 260 | |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| | 261 |A| |B| |C| |D| 262 | |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| | 263 +-+ +-+ +-+ +-+ 264 Original Original 265 Packet Packet 266 Destination Tunnel Tunnel Source 267 Node Exit-Point Entry-Point Node 268 Node Node 269 <-------------------------> 270 Tunnel from Node C to Node B 272 Fig.2 Bi-directional Tunneling Mechanism 273 3.1 IPv6 Encapsulation 275 IPv6 encapsulation consists of prepending to the original packet an 276 IPv6 header and, optionally, a set of IPv6 extension headers (see 277 Fig.3), which are collectively called tunnel IPv6 headers. The encap- 278 sulation takes place in an IPv6 tunnel entry-point node, as the 279 result of an original packet being forwarded onto the virtual link 280 represented by the tunnel. The original packet is processed during 281 forwarding according to the forwarding rules of the protocol of that 282 packet. For instance if the original packet is an: 284 (a) IPv6 packet, the IPv6 original header hop limit is decremented 285 by one. 287 (b) IPv4 packet, the IPv4 original header time to live field (TTL) 288 is decremented by one. 290 At encapsulation, the source field of the tunnel IPv6 header is 291 filled with an IPv6 address of the tunnel entry-point node, and the 292 destination field with an IPv6 address of the tunnel exit-point. 293 Subsequently, the tunnel packet resulting from encapsulation is sent 294 towards the tunnel exit-point node. 296 Tunnel extension headers should appear in the order recommended by 297 the specifications that define the extension headers, such as 298 [RFC-1883]. 300 A source of original packets and a tunnel entry-point that encapsu- 301 lates those packets can be the same node. 303 +----------------------------------//-----+ 304 | Original | | 305 | | Original Packet Payload | 306 | Header | | 307 +----------------------------------//-----+ 308 < Original Packet > 309 | 310 v 311 < Original Packet > 312 +---------+ - - - - - +-------------------------//--------------+ 313 | IPv6 | IPv6 | | 314 | | Extension | Original Packet | 315 | Header | Headers | | 316 +---------+ - - - - - +-------------------------//--------------+ 317 < Tunnel IPv6 Packet > 319 Fig.3 Encapsulating a Packet 320 3.2 Packet Processing in Tunnels 322 The intermediate nodes in the tunnel process the IPv6 tunnel packets 323 according to the IPv6 protocol. For example, a tunnel Hop by Hop 324 Options extension header is processed by each receiving node in the 325 tunnel; a tunnel Routing extension header identifies the intermediate 326 processing nodes, and controls at a finer granularity the forwarding 327 path of the tunnel packet through the tunnel; a tunnel Destination 328 Options extension header is processed at the tunnel exit-point node. 330 3.3 IPv6 Decapsulation 332 Decapsulation is graphically shown in Fig.4: 334 +---------+- - - - - -+----------------------------------//-----+ 335 | IPv6 | IPv6 | | 336 | | Extension | Original Packet | 337 | Header | Headers | | 338 +---------+- - - - - -+----------------------------------//-----+ 339 < Tunnel IPv6 Packet > 340 | 341 v 342 +----------------------------------//-----+ 343 | Original | | 344 | | Original Packet Payload | 345 | Headers | | 346 +----------------------------------//-----+ 347 < Original Packet > 349 Fig.4 Decapsulating a Packet 351 Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel 352 exit-point node, its IPv6 protocol layer processes the tunnel 353 headers. The strict left-to-right processing rules for extension 354 headers is applied. When processing is complete, control is handed to 355 the next protocol engine, which is identified by the Next Header 356 field value in the last header processed. If this is set to a tunnel 357 protocol value, the tunnel protocol engine discards the tunnel head- 358 ers and passes the resulting original packet to the Internet or lower 359 layer protocol identified by that value for further processing. For 360 example, in the case the Next Header field has the IPv6 Tunnel Proto- 361 col value, the resulting original packet is passed to the IPv6 proto- 362 col layer. 364 The tunnel exit-point node, which decapsulates the tunnel packets, 365 and the destination node, which receives the resulting original pack- 366 ets can be the same node. 368 3.4 IPv6 Tunnel Protocol Engine 370 Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a 371 node is graphically shown in Fig.5: 373 +-----------------------+ +-----------------------------------+ 374 | Upper-Layer Protocols | | IPv6 Tunnel Upper-Layer | 375 | | | | 376 | | | ---<-------------------<------- | 377 | | | | ---->---|------>--------- | | 378 | | | | | | | | | | 379 +-----------------------+ +-----------------------+ | | | 380 | | | | | | | | | v ^ | 381 v ^ v ^ v ^ v ^ Tunnel | | | | 382 | | | | | | | | Packets| | | | 383 +---------------------------------------------+ | | | | 384 | | | | | / / | | | | D E | 385 | v ^ IPv6 | --<-3--/-/--<---- | | | | E N | 386 | | | Layer ---->-4-/-/--->-- | | | | | C C | 387 | v ^ / / | | | | | | A A | 388 | | | 2 1 | | | | | | P P | 389 | v ^ -----<---5---/-/-<---- v ^ v ^ | | S S | 390 | | | | -->---6---/-/-->-- | | | | | | | U U | 391 | v ^ | | / / 6 5 4 3 8 7 | | L L | 392 | | | | | / / | | | | | | | | A A | 393 | v ^ v ^ / / v ^ | | | | | | T T | 394 +---------------------------------------------+ | E E | 395 | | | | | | | | | | | | | | | | 396 v ^ v ^ v ^ v ^ v ^ v ^ Original| | | | 397 | | | | | | | | | | | | Packets | v ^ | 398 +-----------------------+ +-----------------------+ | | | 399 | | | | | | | | | | | | 400 | | | | ---|----|-------<-------- | | 401 | | | --->--------------->------>---- | 402 | | | | 403 | Link-Layer Protocols | | IPv6 Tunnel Link-Layer | 404 +-----------------------+ +-----------------------------------+ 406 Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node 407 Note: 409 In Fig.5, the Upper-Layer Protocols box represents transport proto- 410 cols such as TCP, UDP, control protocols such as ICMP, routing proto- 411 cols such as OSPF, and internet or lower-layer protocol being "tun- 412 neled" over IPv6, such as IPv4, IPX, etc. The Link-Layer Protocols 413 box represents Ethernet, Token Ring, FDDI, PPP, X.25, Frame Relay, 414 ATM, etc..., as well as internet layer "tunnels" such as IPv4 tun- 415 nels. 417 The IPv6 tunnel protocol engine acts as both an "upper-layer" and a 418 "link-layer", each with a specific input and output as follows: 420 (u.i) "tunnel upper-layer input" - consists of tunnel IPv6 packets 421 that are going to be decapsulated. The tunnel packets are 422 incoming through the IPv6 layer from: 424 (u.i.1) a link-layer - (path #1, Fig.5) 426 These are tunnel packets destined to this node and 427 will undergo decapsulation. 429 (u.i.2) a tunnel link-layer - (path #7, Fig.5) 431 These are tunnel packets that underwent one or more 432 decapsulations on this node, that is, the packets had 433 one or more nested tunnel headers and one nested tun- 434 nel header was just discarded. This node is the exit- 435 point of both an outer tunnel and one or more of its 436 inner tunnels. 438 For both above cases the resulting original packets are passed 439 back to the IPv6 layer as "tunnel link-layer" output for fur- 440 ther processing (see b.2). 442 (u.o) "tunnel upper-layer output" - consists of tunnel IPv6 packets 443 that are passed through the IPv6 layer down to: 445 (u.o.1) a link-layer - (path #2, Fig.5) 447 These packets underwent encapsulation and are sent 448 towards the tunnel exit-point 450 (u.o.2) a tunnel link-layer - (path #8, Fig.5) 451 These tunnel packets undergo nested encapsulation. 452 This node is the entry-point node of both an outer 453 tunnel and one or more of its inner tunnel. 455 Implementation Note: 457 The tunnel upper-layer input and output can be implemented similar 458 to the input and output of the other upper-layer protocols. 460 The tunnel link-layer input and output are as follows: 462 (l.i) "tunnel link-layer input" - consists of original IPv6 packets 463 that are going to be encapsulated. 465 The original packets are incoming through the IPv6 layer from: 467 (l.i.1) an upper-layer - (path #4, Fig.5) 469 These are original packets originating on this node 470 that undergo encapsulation. The original packet source 471 and tunnel entry-point are the same node. 473 (l.i.2) a link-layer - (path #6, Fig.5) 475 These are original packets incoming from a different 476 node that undergo encapsulation on this tunnel entry- 477 point node. 479 (l.i.3) a tunnel upper-layer - (path #8, Fig.5) 481 These packets are tunnel packets that undergo nested 482 encapsulation. This node is both the entry-point node 483 of an outer tunnel and one or more of its inner tun- 484 nels. 486 The resulting tunnel packets are passed as tunnel upper-layer 487 output packets through the IPv6 layer (see u.o) down to: 489 (l.o) "tunnel link-layer output" - consists of original IPv6 packets 490 resulting from decapsulation. These packets are passed through 491 the IPv6 layer to: 493 (l.o.1) an upper-layer - (path #3, Fig.5) 495 These original packets are destined to this node. 497 (l.o.2) a link-layer - (path #5, Fig.5) 499 These original packets are destined to another node; 500 they are transmitted on a link towards their destina- 501 tion. 503 (l.o.3) a tunnel upper-layer - (path #7, Fig.5) 505 These packets undergo another decapsulation; they were 506 nested tunnel packets. This node is both the exit- 507 point node of an outer tunnel and one or more inner 508 tunnels. 510 Implementation Note: 512 The tunnel link-layer input and output can be implemented similar 513 to the input and output of other link-layer protocols, for 514 instance, associating an interface or pseudo-interface with the 515 IPv6 tunnel. 517 The selection of the "IPv6 tunnel link" over other links results 518 from the packet forwarding decision taken based on the content of 519 the node's routing table. 521 4. Nested Encapsulation 523 Nested IPv6 encapsulation is the encapsulation of a tunnel packet. 524 It takes place when a hop of an IPv6 tunnel is a tunnel. The tunnel 525 containing a tunnel is called an outer tunnel. The tunnel contained 526 in the outer tunnel is called an inner tunnel - see Fig.6. Inner tun- 527 nels and their outer tunnels are nested tunnels. 529 The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv6 530 packets encapsulated by the "outer IPv6 tunnel" entry-point node. The 531 "inner tunnel entry-point node" treats the receiving tunnel packets 532 as original packets and performs encapsulation. The resulting pack- 533 ets are "tunnel packets" for the "inner IPv6 tunnel", and "nested 534 tunnel packets" for the "outer IPv6 tunnel". 536 Outer Tunnel 537 <-------------------------------------> 538 <--links--><-virtual link-><--links---> 539 Inner Tunnel 541 Outer Tunnel Outer Tunnel 542 Entry-Point Exit-Point 543 Node Node 544 +-+ +-+ +-+ +-+ +-+ +-+ 545 | | | | | | | | | | | | 546 | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| | 547 | | | | | | | | | | | | 548 +-+ +-+ +-+ +-+ +-+ +-+ 549 Original Inner Tunnel Inner Tunnel Original 550 Packet Entry-Point Exit-Point Packet 551 Source Node Node Destination 552 Node Node 554 Fig.6. Nested Encapsulation 556 4.1 Limiting Nested Encapsulation 558 A tunnel IPv6 packet size is limited to the maximum IPv6 datagram 559 size [RFC 1883]. Each encapsulation adds to the size of a tunnel 560 packet the size of the tunnel IPv6 headers. Consequently, the number 561 of tunnel headers, and therefore, the number of nested encapsula- 562 tions, and furthermore, the number of "inner IPv6 tunnels" that an 563 "outer IPv6 tunnel" can have are limited by the maximum packet size. 565 The increase in the size of a tunnel IPv6 packet due to nested encap- 566 sulations may require fragmentation [RFC-1883] - see section 7. Fur- 567 thermore, each fragmentation, due to nested encapsulation, of an 568 already fragmented tunnel packet results in a doubling of the number 569 of fragments. Moreover, it is probable that once this fragmentation 570 begins, each new nested encapsulation results in yet additional frag- 571 mentation. Therefore limiting nested encapsulation is recommended. 573 The proposed mechanism for limiting excessive nested encapsulation is 574 a "tunnel encapsulation limit", which is carried in an IPv6 Destina- 575 tion Option header. 577 4.1.1 Tunnel Encapsulation Limit 579 The "Tunnel Encapsulation Limit" destination option is provided only 580 by tunnel entry-point nodes, it is discarded only by tunnel exit- 581 point nodes, and it is used to carry optional information [RFC-1883] 582 that need be examined only by tunnel entry-point nodes. 584 The "Tunnel Encapsulation Limit" destination option is defined as 585 follows: 587 Option Type Opt Data Len Opt Data Len 588 0 1 2 3 4 5 6 7 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 |0 0 0 0 0 1 0 0| 1 | Tun Encap Lim | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Option Type value 4 595 - the highest-order two bits - set to 00 - indi- 596 cate "skip over this option if the option is not 597 recognized". 599 - the third-highest-order bit - set to 0 - 600 indicates that the option data in this option 601 does not change en route to the packet's des- 602 tination [RFC-1883]. 604 Opt Data Len value 1 - the data portion of the Option is one 605 byte long. 607 Opt Data Value the Tunnel Encapsulation Limit value - 8-bit 608 unsigned integer. 610 To avoid excessive nested encapsulation, an IPv6 tunnel entry-point 611 node may prepend to a packet undergoing encapsulation a "Tunnel 612 Encapsulation Limit - Destination Option". The "OptData Value" field 613 of the option is set to: 615 (a) a pre-configured value - if the packet being encapsulated has 616 no IPv6 destination options header or no "Tunnel Encapsulation 617 Limit" option in such a header - see section 6.6. 619 (b) a value resulting from a value stored in the IPv6 destination 620 options header - if such a header exist and if it contains a 621 "Tunnel Encapsulation Limit" option. The "OptData Value" of 622 the extant option is copied into the newly prepended "Tunnel 623 Encapsulation Limit" option and then decremented by one. 625 This is an exception to the rule of processing a destination 626 options extension header in that, although the entry-point 627 node is not a destination node, during encapsulation, the IPv6 628 tunneling protocol engine looks ahead, for an IPv6 destination 629 header with a "Tunnel Encapsulation Limit" option immediately 630 following the current IPv6 main header. 632 If the Tunnel Encapsulation Limit is decremented to zero, the 633 packet undergoing encapsulation is discarded. When the packet 634 is discarded, a Parameter Problem ICMP message [RFC-1885] is 635 returned to the packet originator, which is the previous tun- 636 nel entry-point. The message points to the Opt Data Value 637 field within the Tunnel Encapsulation Limit destination header 638 of the packet. The field pointed to has a value of one. 640 Two cases of encapsulation that should be avoided are described 641 below: 643 4.1.2 Loopback Encapsulation 645 A particular case of encapsulation which must be avoided is the loop- 646 back encapsulation. Loopback encapsulation takes place when a tunnel 647 IPv6 entry-point node encapsulates tunnel IPv6 packets originated 648 from itself, and destined to itself. This can generate an infinite 649 processing loop in the entry-point node. 651 To avoid such a case, it is recommended that an implementation have a 652 mechanism that checks and rejects the configuration of a tunnel in 653 which both the entry-point and exit-point node addresses belong to 654 the same node. It is also recommended that the encapsulating engine 655 check for and reject the encapsulation of a packet that has the pair 656 of tunnel entry-point and exit-point addresses identical with the 657 pair of original packet source and final destination addresses. 659 4.1.3 Routing-Loop Nested Encapsulation 661 In the case of a forwarding path with multiple level nested tunnels, 662 a routing-loop from an inner tunnel to an outer tunnel is particu- 663 larly dangerous when packets from the inner tunnels reenter an outer 664 tunnel from which they have not yet exited. In such a case, the 665 nested encapsulation becomes a recursive encapsulation with the nega- 666 tive effects described in 4.1. Because each nested encapsulation 667 adds a tunnel header with a new hop limit value, the IPv6 hop limit 668 mechanism cannot control the number of times the packet reaches the 669 outer tunnel entry-point node, and thus cannot control the number of 670 recursive encapsulations. 672 When the path of a packet from source to final destination includes 673 tunnels, the maximum number of hops that the packet can traverse 674 should be controlled by two mechanisms used together to avoid the 675 negative effects of recursive encapsulation in routing loops: 677 (a) the original packet hop limit. 679 It is decremented at each forwarding operation performed on an 680 original packet. This includes each encapsulation of the orig- 681 inal packet. It does not include nested encapsulations of the 682 original packet 684 (b) the tunnel IPv6 packet encapsulation limit. 686 It is decremented at each nested encapsulation of the packet. 688 For a discussion of the excessive encapsulation risk factors in 689 nested encapsulation see Appendix A. 691 5. Tunnel IPv6 Header 693 The tunnel entry-point node fills out a tunnel IPv6 main header 694 [RFC-1883] as follows: 696 Version: 698 value 6 700 Priority: 702 Depending on the entry-point node tunnel configuration, the 703 priority can be set to that of either the original packet or 704 a pre-configured value - see section 6.3. 706 Flow label: 708 Depending on the entry-point node tunnel configuration, the 709 flow label can be set to a pre-configured value. The typical 710 value is zero - see section 6.4. 712 Payload Length: 714 The original packet length, plus the length of the encapsu- 715 lating (prepended) IPv6 extension headers, if any. 717 Next header: 719 The next header value according to [RFC-1883] from the 720 Assigned Numbers RFC [RFC-1700 or its succesors ]. 722 For example, if the original packet is an IPv6 packet, this 723 is set to: 725 - decimal value 41 (Assigned payload type number for 726 IPv6) - if there are no tunnel extension headers. 728 - value 0 (Assigned payload type number for IPv6 Hop by 729 Hop Options header) - if a hop by hop options header 730 immediately follows the tunnel IPv6 header. 732 - decimal value 60 (Assigned payload type number for IPv6 733 Destination Options header) - if a Tunnel Encapsulation 734 Limit destination option header immediately follows the 735 tunnel IPv6 header. 737 Hop limit: 739 The tunnel IPv6 header hop limit is set to a pre-configured 740 value - see section 6.3. 742 The default value for hosts is the Neighbor Discovery adver- 743 tised hop limit [RFC-1970]. The default value for routers is 744 the default IPv6 Hop Limit value from the Assigned Numbers 745 RFC (64 at the time of writing this document). 747 Source Address: 749 An IPv6 address of the outgoing interface of the tunnel 750 entry-point node. This address is configured as the tunnel 751 entry-point node address - see section 6.1. 753 Destination Address: 755 An IPv6 address of the tunnel exit-point node. If the tunnel 756 is configured as a free-exit tunnel, then the IPv6 address 757 of the destination from the original IPv6 header - see 758 section 6.2. 760 5.1 Tunnel IPv6 Extension Headers 762 Depending on IPv6 node configuration parameters, a tunnel entry-point 763 node may append to the tunnel IPv6 main header one or more IPv6 764 extension headers, such as hop by hop, routing, or others. 766 To limit the number of nested encapsulations of a packet, if it was 767 configured to do so - see section 6.6 - a tunnel entry-point appends 768 as the last tunnel extension header a Tunnel Encapsulation Limit 769 destination option header with fields set as follows: 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Next Header |Hdr Ext Len = 0| Opt Type = 4 |Opt Data Len=1 | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 | 0 | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 Next Header: 779 Identifies the type of the original packet header. For exam- 780 ple, if the original packet is an IPv6 packet, the next 781 header protocol value is set to decimal value 41 (Assigned 782 payload type number for IPv6). 784 Hdr Ext Len: 786 Length of the Tunnel Encapsulation Limit destination option 787 header in 8-octet units, not including the first 8 octets. 788 Set to value 0, if no other options are present in this des- 789 tination options header. 791 Option Type: 793 value 4 - see section 4.1.1. 795 Opt Data Len: 797 value 1 - see section 4.1.1. 799 Tun Encap Lim: 801 8 bit unsigned integer - see section 4.1.1. 803 Option Type: 805 value 1 - PadN option, to align the header following this 806 header. 808 Opt Data Len: 810 value 1 - one octet of option data. 812 Option Data: 814 value 0 - one zero-valued octet. 816 6. IPv6 Tunnel State Variables 818 The IPv6 tunnel state variables, some of which are or may be config- 819 ured on the tunnel entry-point node, are: 821 6.1 IPv6 Tunnel Entry-Point Node Address 823 The tunnel entry-point node address is one of the valid IPv6 unicast 824 addresses of the entry-point node - the validation of the address at 825 tunnel configuration time is recommended. 827 The tunnel entry-point node address is copied to the source address 828 field in the tunnel IPv6 header during packet encapsulation. 830 6.2 IPv6 Tunnel Exit-Point Node Address 832 The tunnel exit-point node address is used as IPv6 destination 833 address for the tunnel IPv6 header. The tunnel exit-point node 834 address can be configured with a specific IPv6 address, in which case 835 the tunnel is called a fixed-exit tunnel. Such a tunnel acts like a 836 virtual point to point link between the entry-point node and exit- 837 point node. Alternatively, a tunnel exit-point address can be con- 838 figured with no specific address, in which case the tunnel is called 839 a free-exit tunnel. Such a tunnel acts like a virtual point to point 840 link between the entry-point node and an exit-point node identified 841 by the destination address from the original packet header. 843 The tunnel exit-point node address is copied to the destination 844 address field in the tunnel IPv6 header during packet encapsulation. 846 The configuration of the tunnel entry-point and exit-point addresses 847 is not subject to IPv6 Autoconfiguration, or IPv6 Neighbor Discovery. 849 Note: 851 This document refers to tunnels in which the exit-point node is iden- 852 tified by a unicast address. Although some of the mechanisms 853 described herein apply also to tunnels in which the entry and exit- 854 point nodes are identified by other types of addresses, such as any- 855 cast or multicast, specific mechanisms for such tunnels may need fur- 856 ther specification. 858 6.3 IPv6 Tunnel Hop Limit 860 An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in 861 which the passing of the original packet through the tunnel is like 862 the passing of the original packet over a one hop link, regardless of 863 the number of hops in the IPv6 tunnel. 865 The "single-hop" mechanism should be implemented by having the tunnel 866 entry point node set a tunnel IPv6 header hop limit independently of 867 the hop limit of the original header. 869 The "single-hop" mechanism hides from the original IPv6 packets the 870 number of IPv6 hops of the tunnel. 872 It is recommended that the tunnel hop limit be configured with a 873 value that ensures: 875 (a) that tunnel IPv6 packets can reach the tunnel exit-point node 877 (b) a quick expiration of the tunnel packet if a routing loop 878 occurs within the IPv6 tunnel. 880 The tunnel hop limit default value for hosts is the IPv6 Neighbor 881 Discovery advertised hop limit [RFC-1970]. The tunnel hop limit 882 default value for routers is the default IPv6 Hop Limit value from 883 the Assigned Numbers RFC (64 at the time of writing this document). 885 The tunnel hop limit is copied into the hop limit field of the tunnel 886 IPv6 header of each packet encapsulated by the tunnel entry-point 887 node. 889 6.4 IPv6 Tunnel Packet Priority 891 The IPv6 Tunnel Packet Priority indicates the value that a tunnel 892 entry-point node sets in the priority field of a tunnel header. The 893 default value is zero. The configured Packet Priority can also indi- 894 cate whether the value of the priority field in the tunnel header is 895 copied from the original header, or it is set to the pre-configured 896 value. 898 6.5 IPv6 Tunnel Flow Label 900 The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- 901 point node sets in the flow label of a tunnel header. The default 902 value is zero. 904 6.6 IPv6 Tunnel Encapsulation Limit 906 The Tunnel Encapsulation Limit value can indicate whether the entry- 907 point node is configured to limit the number of encapsulations of 908 tunnel packets originating on that node. The IPv6 Tunnel Encapsula- 909 tion Limit is the maximum number of encapsulations permitted for 910 packets undergoing encapsulation at that entry-point node. Recom- 911 mended default value is 5. An entry-point node configured to limit 912 the number of nested encapsulations prepends a Tunnel Encapsulation 913 Limit destination options header to an original packet undergoing 914 encapsulation - see section 4.1, and 4.1.1. 916 6.7 IPv6 Tunnel MTU 918 The tunnel MTU is set dynamically to the Path MTU between the tunnel 919 entry-point and the tunnel exit-point nodes minus the size of the 920 tunnel headers: the maximum size of a tunnel packet payload that can 921 be sent through the tunnel without fragmentation [RFC-1883]. The tun- 922 nel entry-point node performs Path MTU discovery on the path between 923 the tunnel entry-point and exit-point nodes [RFC-1981], [RFC-1885]. 924 The tunnel MTU of a nested tunnel is the tunnel MTU of the outer tun- 925 nel minus the size of the tunnel headers. 927 Although it should be able to send a tunnel IPv6 packet of any valid 928 size, a tunnel entry-point node attempts to avoid the fragmentation 929 of tunnel packets, by reporting to source nodes of original packets 930 the MTU to be used in sizing original packets sent towards that tun- 931 nel entry-point node. 933 7. IPv6 Tunnel Packet Size Issues 935 Prepending a tunnel header increases the size of a packet, therefore 936 a tunnel packet resulting from the encapsulation of an IPv6 original 937 packet may require fragmentation. 939 A tunnel IPv6 packet resulting from the encapsulation of an original 940 packet is considered an IPv6 packet originating from the tunnel 941 entry-point node. Therefore, like any source of an IPv6 packet, a 942 tunnel entry-point node must support fragmentation of tunnel IPv6 943 packets. 945 A tunnel intermediate node that forwards a tunnel packet to another 946 node in the tunnel follows the general IPv6 rule that it must not 947 fragment a packet undergoing forwarding. 949 A tunnel exit-point node receiving tunnel packets at the end of the 950 tunnel for decapsulation applies the strict left-to-right processing 951 rules for extension headers. In the case of fragmentation headers, 952 the fragments are reassembled into a tunnel packet before determining 953 that an embedded IP packet is present. 955 Note: 957 A particular problem arises when the destination of a fragmented tun- 958 nel packet is an exit-point node identified by an anycast address. 959 The problem is similar to that of original fragmented IPv6 packets 960 destined to nodes identified by an anycast address. As in that case, 961 a mechanism must be used to make sure that all the fragments of a 962 packet arrive to one node, for that node to be able to perform a suc- 963 cessful reassembly. 965 7.1 IPv6 Tunnel Packet Fragmentation 967 Tunnel packets that exceed the tunnel MTU are candidates for fragmen- 968 tation. The fragmentation of tunnel packets containing IPv6 original 969 packets is performed as follows: 971 (a) if the original IPv6 packet size is larger than 576 octets, 972 the entry-point node discards the packet and it returns an 973 ICMPv6 "Packet Too Big" message to the source node of the 974 original packet with the recommended MTU size field set to the 975 maximum between 576, and the tunnel MTU, i.e. max(576, tunnel 976 MTU). Note that the tunnel MTU is the Path MTU between the 977 tunnel entry-point and the tunnel exit-point nodes minus the 978 size of the tunnel headers. Also see section 6.7, and 8.2. 980 (b) if the original IPv6 packet is equal or smaller than 576 981 octets, the tunnel entry-point node encapsulates the original 982 packet, and subsequently fragments the resulting IPv6 tunnel 983 packet into IPv6 fragments that do not exceed the tunnel MTU. 985 7.2 IPv4 Tunnel Packet Fragmentation 987 Tunnel packets that exceed the tunnel MTU are candidates for 988 fragmentation. The fragmentation of tunnel packets containing IPv4 989 original packets is performed as follows: 991 (a) if in the original IPv4 packet header the Don't Fragment - DF 992 - bit flag is SET, the entry-point node discards the packet 993 and returns an ICMP message. The ICMP message has the type = 994 "unreachable", the code = "datagram too big", and the recom- 995 mended MTU size field set to the size of the tunnel MTU - see 996 section 6.7, and 8.3. 998 (b) if in the original packet header the Don't Fragment - DF - bit 999 flag is CLEAR, the tunnel entry-point node encapsulates the 1000 original packet, and subsequently fragments the resulting IPv6 1001 tunnel packet into IPv6 fragments that do not exceed the tun- 1002 nel MTU. 1004 8. IPv6 Tunnel Error Processing and Reporting 1006 IPv6 Tunneling follows the general rule that an error detected during 1007 the processing of an IPv6 packet is reported through an ICMP message 1008 to the source of the packet. 1010 On a forwarding path that includes IPv6 tunnels, an error detected by 1011 a node that is not in any tunnel is directly reported to the source 1012 of the original IPv6 packet. 1014 An error detected by a node inside a tunnel is reported to the source 1015 of the tunnel packet, that is, the tunnel entry-point node. The ICMP 1016 message sent to the tunnel entry-point node has as ICMP payload the 1017 tunnel IPv6 packet that has the original packet as its payload. 1019 The cause of a packet error encountered inside a tunnel can be a 1020 problem with: 1022 (a) the tunnel header, or 1024 (b) the tunnel packet. 1026 Both tunnel header and tunnel packet problems are reported to the 1027 tunnel entry-point node. 1029 If a tunnel packet problem is a consequence of a problem with the 1030 original packet, which is the payload of the tunnel packet, then the 1031 problem is also reported to the source of the original packet. 1033 To report a problem detected inside the tunnel to the source of an 1034 original packet, the tunnel entry point node must relay the ICMP mes- 1035 sage received from inside the tunnel to the source of that original 1036 IPv6 packet. 1038 An example of the processing that can take place in the error report- 1039 ing mechanism of a node is illustrated in Fig.7, and Fig.8: 1041 Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives an 1042 ICMP packet from inside the tunnel, marked Tunnel ICMPv6 Message in 1043 Fig.7. The tunnel entry-point node IPv6 layer passes the received 1044 ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP 1045 type and code [RFC-1885] generates an internal "error code". 1047 Fig.7 path #1 - The internal error code, is passed with the "ICMPv6 1048 message payload" to the upper-layer protocol - in this case the IPv6 1049 tunnel upper-layer error input. 1051 Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input decapsu- 1052 lates the tunnel IPv6 packet, which is the ICMPv6 message payload, 1053 obtaining the original packet, and thus the original headers and dis- 1054 patches the "internal error code", the source address from the origi- 1055 nal packet header, and the original packet, down to the error report 1056 block of the protocol identified by the Next Header field in the tun- 1057 nel header immediately preceding the original packet in the ICMP 1058 message payload. 1060 +-------+ +-------+ +-----------------------+ 1061 | Upper | | Upper | | Upper | 1062 | Layer | | Layer | | Layer | 1063 | Proto.| | Proto | | IPv6 Tunnel | 1064 | Error | | Error | | Error | 1065 | Input | | Input | | Input | 1066 | | | | | Decapsulate | 1067 | | | | | -->--ICMPv6--#2->-- | 1068 | | | | | | Payload | | 1069 +-------+ +-------+ +--|-----------------|--+ 1070 | | | | 1071 ^ ^ ^ v 1072 | | | | 1073 --------------------#1-- -----Orig.Packet?--- - - - - - - - - - 1074 #1 #3 Int.Error Code, #5 | 1075 Int.Error Code,^ v Source Address, v v 1076 ICMPv6 Payload | IPv6 | Orig. Packet | IPv4 | 1077 +--------------+ +--------------+ +--------------+ + - - - - + 1078 | | | | | | 1079 | ICMP v6 | | ICMP v6 | | ICMP v4 | | | 1080 | Input | | Error Report | | Error Report | 1081 | - - - - +----+ - - - - | + - - - - + + - - - - + 1082 | | | | 1083 | IPv6 Layer | | IPv4 Layer | | | 1084 | | | | 1085 +----------------------------------+ +--------------+ + - - - - + 1086 | | | 1087 ^ V V 1088 #0 #4 #6 1089 | | | 1090 Tunnel ICMPv6 ICMPv6 ICMPv4 1091 Message Message Message 1092 | | | 1094 Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine) 1096 From here the processing depends on the protocol of the original 1097 packet: 1099 (a) - for an IPv6 original packet 1101 Fig.7 path #3 and Fig.8 (c.1)- for an IPv6 original packet, the ICMPv6 1102 error report builds an ICMP message of a type and code according to 1103 the "internal error code", containing the "original packet" as ICMP 1104 payload. 1106 Fig.7 path #4 and Fig.8 (d.1)- The ICMP message has the tunnel entry- 1107 point node address as source address, and the original packet source 1108 node address as destination address. The tunnel entry-point node sends 1109 the ICMP message to the source node of the original packet. 1111 (b) - for an IPv4 original packet 1113 Fig.7 path #5 and Fig.8 (c.2) - for an IPv4 original packet, the 1114 ICMPv4 error report builds an ICMP message of a type and code derived 1115 from the the "internal error code", containing the "original packet" 1116 as ICMP payload. 1118 Fig.7 path #6 and Fig.8 (d.2) - The ICMP message has the tunnel entry- 1119 point node IPv4 address as source address, and the original packet 1120 IPv4 source node address as destination address. The tunnel entry- 1121 point node sends the ICMP message to the source node of the original 1122 packet. 1124 A graphical description of the header processing taking place is the 1125 following: 1127 < Tunnel Packet > 1128 +--------+- - - - - -+--------+------------------------------//------+ 1129 | IPv6 | IPv6 | ICMP | Tunnel | 1130 (a)| | Extension | | IPv6 | 1131 | Header | Headers | Header | Packet in error | 1132 +--------+- - - - - -+--------+------------------------------//------+ 1133 < Tunnel Headers > < Tunnel ICMP Message > 1134 < ICMPv6 Message Payload > 1135 | 1136 v 1137 < Tunnel ICMP Message > 1138 < Tunnel IPv6 Packet in Error > 1139 +--------+ +---------+ +----------+--------//------+ 1140 | ICMP | | Tunnel | | Original | Original | 1141 (b) | | + | IPv6 | + | | Packet | 1142 | Header | | Headers | | Headers | Payload | 1143 +--------+ +---------+ +----------+--------//------+ 1144 | 1145 ----------------- | 1146 | | 1147 --------------|--------------- 1148 | | 1149 V V 1150 +---------+ +--------+ +-------------------//------+ 1151 | New | | ICMP | | | 1152 (c.1) | IPv6 | + | | + | Orig. Packet in Error | 1153 | Headers | | Header | | | 1154 +---------+ +--------+ +-------------------//------+ 1155 | 1156 v 1157 +---------+--------+-------------------//------+ 1158 | New | ICMP | Original | 1159 (d.1) | IPv6 | | | 1160 | Headers | Header | Packet in Error | 1161 +---------+--------+-------------------//------+ 1162 < New ICMP Message > 1164 or for an IPv4 original packet 1166 +---------+ +--------+ +-------------------//------+ 1167 | New | | ICMP | | | 1168 (c.2) | IPv4 | + | | + | Orig. Packet in Error | 1169 | Header | | Header | | | 1170 +---------+ +--------+ +-------------------//------+ 1171 | 1172 v 1173 +---------+--------+-------------------//------+ 1174 | New | ICMP | Original | 1175 (d.2) | IPv4 | | | 1176 | Header | Header | Packet in Error | 1177 +---------+--------+-------------------//------+ 1178 < New ICMP Message > 1180 Fig.8 ICMP Error Reporting and Processing 1182 8.1 Tunnel ICMP Messages 1184 The tunnel ICMP messages that are reported to the source of the orig- 1185 inal packet are: 1187 hop limit exceeded 1189 The tunnel has a misconfigured hop limit, or contains a rout- 1190 ing loop, and packets do not reach the tunnel exit-point node. 1191 This problem is reported to the tunnel entry-point node, where 1192 the tunnel hop limit can be reconfigured to a higher value. 1194 The problem is further reported to the source of the original 1195 packet as described in section 8.2, or 8.3. 1197 unreachable node 1199 One of the nodes in the tunnel is not or is no longer reach- 1200 able. This problem is reported to the tunnel entry-point node, 1201 which should be reconfigured with a valid and active path 1202 between the entry and exit-point of the tunnel. The problem is 1203 further reported to the source of the original packet as 1204 described in section 8.2, or 8.3. 1206 parameter problem 1208 A Parameter Problem ICMP message pointing to a valid Tunnel 1209 Encapsulation Limit Destination header with a Tun Encap Lim 1210 field value set to one is an indication that the tunnel packet 1211 exceeded the maximum number of encapsulations allowed. The 1212 problem is further reported to the source of the original 1213 packet as described in section 8.2, or 8.3. 1215 The above three problems detected inside the tunnel, which are a tun- 1216 nel configuration and a tunnel topology problem, are reported to the 1217 source of the original IPv6 packet, as a tunnel generic "unreachable" 1218 problem caused by a "link problem" - see section 8.2 and 8.3. 1220 packet too big 1222 The tunnel packet exceeds the tunnel Path MTU. 1224 The information carried by this type of ICMP message is used 1225 as follows: 1227 - by a receiving tunnel entry-point node to set or adjust the 1228 tunnel MTU 1230 - by a sending tunnel entry-point node to indicate to the 1231 source of an original packet the MTU size that should be used 1232 in sending IPv6 packets towards the tunnel entry-point node. 1234 8.2 ICMP Messages for IPv6 Original Packets 1236 The tunnel entry-point node builds the ICMP and IPv6 headers of the 1237 ICMP message that is sent to the source of the original packet as 1238 follows: 1240 IPv6 Fields: 1242 Source Address 1244 A valid unicast IPv6 address of the outgoing interface. 1246 Destination Address 1248 Copied from the Source Address field of the Original 1249 IPv6 header. 1251 ICMP Fields: 1253 For any of the following tunnel ICMP error messages: 1255 "hop limit exceeded" 1257 "unreachable node" 1259 "parameter problem" - pointing to a valid Tunnel Encapsulation 1260 Limit destination header with the Tun Encap Lim field set to a 1261 value one: 1263 Type 1 - unreachable node 1265 Code 3 - address unreachable 1267 For tunnel ICMP error message "packet too big": 1269 Type 2 - packet too big 1271 Code 0 1273 MTU The MTU field from the tunnel ICMP message minus 1274 the length of the tunnel headers. 1276 According to the general rules described in 7.1, an ICMP "packet too 1277 big" message is sent to the source of the original packet only if the 1278 original packet size is larger than 576 octets. 1280 8.3 ICMP Messages for IPv4 Original Packets 1282 The tunnel entry-point node builds the ICMP and IPv4 header of the 1283 ICMP message that is sent to the source of the original packet as 1284 follows: 1286 IPv4 Fields: 1288 Source Address 1290 A valid unicast IPv4 address of the outgoing interface. 1292 Destination Address 1294 Copied from the Source Address field of the Original 1295 IPv4 header. 1297 ICMP Fields: 1299 For any of the following tunnel ICMP error messages: 1301 "hop limit exceeded" 1303 "unreachable node" 1305 "parameter problem" - pointing to a valid Tunnel Enacpsulation 1306 Limit destination header with the Tun Encap Lim field set to a 1307 value one: 1309 Type 3 - destination unreachable 1311 Code 1 - host unreachable 1313 For a tunnel ICMP error message "packet too big": 1315 Type 3 - destination unreachable 1317 Code 4 - datagram too big 1319 MTU The MTU field from the tunnel ICMP message minus 1320 the length of the tunnel headers. 1322 According to the general rules described in section 7.2, an ICMP 1323 "datagram too big" message is sent to the original IPv4 packet source 1324 node if the the original IPv4 header has the DF - don't fragment - 1325 bit flag SET. 1327 8.4 ICMP Messages for Nested Tunnels Packets 1329 In case of an error uncovered with a nested tunnels packet, the inner 1330 tunnel entry-point, which receives the ICMP error message from the 1331 inner tunnel reporting node, relays the ICMP message to the outer 1332 tunnel entry-point following the mechanisms described in sections 1333 8.,8.1, 8.2, and 8.3. Further, the outer tunnel entry-point relays 1334 the ICMP message to the source of the original packet, following the 1335 same mechanisms. 1337 9. Security Considerations 1339 An IPv6 tunnel can be secured, by securing the IPv6 path between the 1340 tunnel entry-point and exit-point node. The security architecture, 1341 mechanisms, and services are described in [RFC1825], [RFC1826], and 1342 [RFC1827]. A secure IPv6 tunnel may act as a gateway-to-gateway 1343 secure path as described in [RFC1825]. 1345 For a secure IPv6 tunnel, in addition to the mechanisms described 1346 earlier in this document, the entry-point node of the tunnel performs 1347 security algorithms on the packet and prepends as part of the tunnel 1348 headers a security header in conformance with [RFC1883], [RFC1825], 1349 and [RFC1826], or [RFC1827]. 1351 The exit-point node of a secure IPv6 tunnel performs security algo- 1352 rithms and processes the tunnel security header as part of the tunnel 1353 headers processing described earlier, and in conformance with 1354 [RFC1825], and [RFC1826], or [RFC1827]. The tunnel security header 1355 is discarded with the rest of the tunnel headers after tunnel headers 1356 processing completion. 1358 The degree of integrity, authentication, and confidentiality and the 1359 security processing performed on a tunnel packet at the entry-point 1360 and exit-point node of a secure IPv6 tunnel depend on the type of 1361 security header - authentication (AH) or encryption (ESP) - and 1362 parameters configured in the Security Association for the tunnel. 1363 There is no dependency or interaction between the security applied to 1364 the tunnel packets and the security applied to the original packets 1365 which are the payloads of the tunnel packets. In case of nested tun- 1366 nels, each inner tunnel may have its own set of security services, 1367 independently from the outer tunnels security services, or of the 1368 path between the source and destination of the original packet. 1370 10. Acknowledgments 1372 This document is partially derived from several discussions about 1373 IPv6 tunneling on the IPng Working Group Mailing List and from feed- 1374 back from the IPng Working Group to an IPv6 presentation that focused 1375 on IPv6 tunneling at the 33rd IETF, in Stockholm, in July 1995. 1377 Additionally, the following documents that focused on tunneling or 1378 encapsulation were helpful references: RFC 1933 (R. Gilligan, E. 1379 Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P. Tsuchiya), 1380 RFC 1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W. 1381 Simpson), as well as RFC 2003 (C. Perkins). 1383 Brian Carpenter, Richard Draves, Bob Hinden, Thomas Narten, Erik 1384 Nordmark, and (in alphabetical order) gave valuable reviewing com- 1385 ments and suggestions for the improvement of this document. Scott 1386 Bradner, Ross Callon, Dimitry Haskin, Paul Traina, and James Watt (in 1387 alphabetical order) shared their view or experience on matters of 1388 concern in this document. Judith Grossman provided a sample of her 1389 many years of editorial and writing experience as well as a good 1390 amount of probing technical questions. 1392 11. References 1394 [RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 Speci- 1395 fication" 1397 [RFC-1885] A. Conta, and S. Deering "Internet Control Message Proto- 1398 col for the Internet Protocol Version 6 (IPv6)" 1400 [RFC-1970] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for 1401 IP Version 6 (IPv6)" 1403 [RFC-1981] J. McCann, S. Deering, J. Mogul "Path MTU Discovery for IP 1404 Version 6 (IPv6)" 1406 [RFC-1825] R. Atkinson, "Security Architecture for the Internet Pro- 1407 tocol" 1409 [RFC-1826] R. Atkinson, "IP Authentication Header" 1411 [RFC-1827] R. Atkinson, "IP Encapsulation Security Payload (ESP)" 1413 [RFC-1853] W. Simpson, "IP in IP Tunneling" 1415 [RFC-1700] J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994 1417 Authors' Addresses: 1419 Alex Conta Stephen Deering 1420 Lucent Technologies Inc. Cisco Systems 1421 1300 Massaschussets Ave 170 West Tasman Dr 1422 Boxborough, MA 01719 San Jose, CA 95132-1706 1423 +1-508-263-3600/ext 535 +1-408-527-8213 1425 email: aconta@lucent.com email: deering@cisco.com 1426 Appendix A 1428 A.1 Risk Factors in Nested Encapsulation 1430 Nested encapsulations of a packet become a recursive encapsulation if 1431 the packet reenters an outer tunnel before exiting it. The cases 1432 which present a high risk of recursive encapsulation are those in 1433 which a tunnel entry-point node cannot determine whether a packet 1434 that undergoes encapsulation reenters the tunnel before exiting it. 1435 Routing loops that cause tunnel packets to reenter a tunnel before 1436 exiting it are certainly the major cause of the problem. But since 1437 routing loops exist, and happen, it is important to understand and 1438 describe, the cases in which the risk for recursive encapsulation is 1439 higher. 1441 There are two significant elements that determine the risk factor of 1442 routing loop recursive encapsulation: 1444 (a) the type of tunnel, 1446 (b) the type of route to the tunnel exit-point, which determines 1447 the packet forwarding through the tunnel, that is, over the 1448 tunnel virtual-link. 1450 A.1.1 Risk Factor in Nested Encapsulation - type of tunnel. 1452 The type of tunnels which were identified as a high risk factor for 1453 recursive encapsulation in routing loops are: 1455 "inner tunnels with identical exit-points". 1457 These tunnels can be: 1459 "fixed-end inner tunnels with different entry-points", 1461 or: 1463 "free-end inner tunnels with different entry-points" 1465 Note that free-end inner tunnels fall always into the category of 1466 identical exit-point tunnels. 1468 Since the source and destination of an original packet is the main 1469 information used to decide whether to forward a packet through a tun- 1470 nel or not, a recursive encapsulation can be avoided in case of a 1471 single tunnel (non-inner), by checking that the packet to be encapsu- 1472 lated is not originated on the entry-point node. This mechanism is 1473 suggested in [RFC-1853]. 1475 However, this type of protection does not seem to work well in case 1476 of inner tunnels with different entry-points, and identical exit- 1477 points. 1479 Inner tunnels with different entry-points and identical exit-points 1480 introduce ambiguity in deciding whether to encapsulate a packet, when 1481 a packet encapsulated in an inner tunnel reaches the entry-point node 1482 of an outer tunnel by means of a routing loop. Because the source of 1483 the tunnel packet is the inner tunnel entry-point node which is dif- 1484 ferent than the entry-point node of the outer tunnel, the source 1485 address checking (mentioned above) fails to detect an invalid encap- 1486 sulation, and as a consequence the tunnel packet gets encapsulated at 1487 the outer tunnel each time it reaches it through the routing loop. 1489 A.1.2 Risk Factor in Nested Encapsulation - type of route. 1491 The type of route to a tunnel exit-point node has been also identi- 1492 fied as a high risk factor of recursive encapsulation in routing 1493 loops. 1495 One type of route to a tunnel exit-point node is a route to a speci- 1496 fied destination node, that is, the destination is a valid specified 1497 IPv6 address (route to node). Such a route can be selected based on 1498 the longest match of an original packet destination address with the 1499 destination address stored in the tunnel entry-point node routing 1500 table entry for that route. The packet forwarded on such a route is 1501 first encapsulated and then forwarded towards the tunnel exit-point 1502 node. 1504 Another type of route to a tunnel exit-point node is a route to a 1505 specified prefix-net, that is, the destination is a valid specified 1506 IPv6 prefix (route to net). Such a route can be selected based on the 1507 longest path match of an original packet destination address with the 1508 prefix destination stored in the tunnel entry-point node routing 1509 table entry for that route. The packet forwarded on such a route is 1510 first encapsulated and then forwarded towards the tunnel exit-point 1511 node. 1513 And finally another type of route to a tunnel exit-point is a default 1514 route, or a route to an unspecified destination. This route is 1515 selected when no-other match for the destination of the original 1516 packet has been found in the routing table. A tunnel that is the 1517 first hop of a default route is a "default tunnel". 1519 If the route to a tunnel exit-point is a route to node, the risk fac- 1520 tor for recursive encapsulation is minimum. 1522 If the route to a tunnel exit-point is a route to net, the risk fac- 1523 tor for recursive encapsulation is medium. There is a range of desti- 1524 nation addresses that will match the prefix the route is associated 1525 with. If one or more inner tunnels with different tunnel entry-points 1526 have exit-point node addresses that match the route to net of an 1527 outer tunnel exit-point, then a recursive encapsulation may occur if 1528 a tunnel packet gets diverted from inside such an inner tunnel to the 1529 entry-point of the outer tunnel that has a route to its exit-point 1530 that matches the exit-point of an inner tunnel. 1532 If the route to a tunnel exit-point is a default route, the risk fac- 1533 tor for recursive encapsulation is maximum. Packets are forwarded 1534 through a default tunnel for lack of a better route. In many situa- 1535 tions, forwarding through a default tunnel can happen for a wide 1536 range of destination addresses which at the maximum extent is the 1537 entire Internet minus the node's link. As consequence, it is likely 1538 that in a routing loop case, if a tunnel packet gets diverted from an 1539 inner tunnel to an outer tunnel entry-point in which the tunnel is a 1540 default tunnel, the packet will be once more encapsulated, because 1541 the default routing mechanism will not be able to discern differ- 1542 ently, based on the destination.