idnits 2.17.1 draft-ietf-ipngwg-ipv6-tunnel-06.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-25) 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 32 longer pages, the longest (page 9) being 71 lines == It seems as if not all pages are separated by form feeds - found 33 form feeds but 36 pages 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 408 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 20 instances of too long lines in the document, the longest one being 41 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '... Drafts are ...' == Line 15 has weird spacing: '...cuments of t...' == Line 16 has weird spacing: '... groups may ...' == Line 20 has weird spacing: '... Drafts may ...' == Line 21 has weird spacing: '...iate to use ...' == (403 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 (December 1996) is 9993 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 1242, but not defined ** Obsolete undefined reference: RFC 1825 (Obsoleted by RFC 2401) == Missing Reference: 'RFC1826' is mentioned on line 1242, but not defined ** Obsolete undefined reference: RFC 1826 (Obsoleted by RFC 2402) == Missing Reference: 'RFC1827' is mentioned on line 1242, but not defined ** Obsolete undefined reference: RFC 1827 (Obsoleted by RFC 2406) == Missing Reference: 'RFC1883' is mentioned on line 1236, but not defined ** Obsolete undefined reference: RFC 1883 (Obsoleted by RFC 2460) == Unused Reference: 'RFC-1825' is defined on line 1295, but no explicit reference was found in the text == Unused Reference: 'RFC-1826' is defined on line 1298, but no explicit reference was found in the text == Unused Reference: 'RFC-1827' is defined on line 1300, but no explicit reference was found in the text == Unused Reference: 'RFC-1700' is defined on line 1304, 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 (~~), 17 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 December 1996 6 Generic Packet Tunneling in IPv6 8 Specification 10 draft-ietf-ipngwg-ipv6-tunnel-06.txt 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working 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.......................14 54 4.1.2 Loopback Encapsulation...........................15 55 4.1.3 Routing Loop Nested Encapsulation................16 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.............................20 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.........................................22 66 7. IPv6 Tunnel Packet Size Issues...............................22 67 7.1 IPv6 Tunnel Packet Fragmentation........................23 68 7.2 IPv4 Tunnel Packet Fragmentation........................23 69 8. IPv6 Tunnel Error Reporting and Processing...................24 70 8.1 Tunnel ICMP Messages....................................28 71 8.2 ICMP Messages for IPv6 Original Packets.................29 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 127 encapsulation. It specifies the tunnel end-points as source and 128 destination. 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 162 tunnel 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 182 the tunnel header of a nested tunnel packet. 184 nested encapsulation 186 encapsulation of an encapsulated packet. 188 recursive encapsulation 190 encapsulation of a packet that reenters a tunnel before exiting 191 it. 193 tunnel encapsulation limit 195 the maximum number of nested encapsulations of a packet. 197 3. IPv6 Tunneling 199 IPv6 tunneling is a technique for establishing a "virtual link" 200 between two IPv6 nodes for transmitting data packets as payloads of 201 IPv6 packets (see Fig.1). From the point of view of the two nodes, 202 this "virtual link", called an IPv6 tunnel, appears as a point to 203 point link on which IPv6 acts like a link-layer protocol. The two 204 IPv6 nodes play specific roles. One node encapsulates original 205 packets received from other nodes or from itself and forwards the 206 resulting tunnel packets through the tunnel. The other node 207 decapsulates the received tunnel packets and forwards the resulting 208 original packets towards their destinations, possibly itself. The 209 encapsulator node is called the tunnel entry-point node, and it is 210 the source of the tunnel packets. The decapsulator node is called the 211 tunnel exit-point, and it is the destination of the tunnel packets. 213 Note: 215 This document refers in particular to tunnels between two nodes 216 identified by unicast addresses - such tunnels look like "virtual 217 point to point links". The mechanisms described herein apply also to 218 tunnels in which the exit-point nodes are identified by other types 219 of addresses, such as anycast or multicast. These tunnels may look 220 like "virtual point to multipoint links". At the time of writing this 221 document, IPv6 anycast addresses are a subject of ongoing 222 specification and experimental work. 224 Tunnel from node B to node C 225 <----------------------> 226 Tunnel Tunnel 227 Entry-Point Exit-Point 228 Node Node 229 +-+ +-+ +-+ +-+ 230 |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D| 231 +-+ +-+ +-+ +-+ 232 Original Original 233 Packet Packet 234 Source Destination 235 Node Node 237 Fig.1 Tunnel 239 An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow 240 takes place in one direction between the IPv6 tunnel entry-point and 241 exit-point nodes (see Fig.1). 243 Bi-directional tunneling is achieved by merging two unidirectional 244 mechanisms, that is, configuring two tunnels, each in opposite 245 direction to the other - the entry-point node of one tunnel is the 246 exit-point node of the other tunnel (see Fig.2). 248 Tunnel from Node B to Node C 249 <------------------------> 250 Tunnel Tunnel 251 Original Entry-Point Exit-Point Original 252 Packet Node Node Packet 253 Source Destination 254 Node Node 255 +-+ +-+ +-+ +-+ 256 | |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| | 257 |A| |B| |C| |D| 258 | |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| | 259 +-+ +-+ +-+ +-+ 260 Original Original 261 Packet Packet 262 Destination Tunnel Tunnel Source 263 Node Exit-Point Entry-Point Node 264 Node Node 265 <-------------------------> 266 Tunnel from Node C to Node B 268 Fig.2 Bi-directional Tunneling Mechanism 269 3.1 IPv6 Encapsulation 271 IPv6 encapsulation consists of prepending to the original packet an 272 IPv6 header and, optionally, a set of IPv6 extension headers (see 273 Fig.3), which are collectively called tunnel IPv6 headers. The 274 encapsulation takes place in an IPv6 tunnel entry-point node, as the 275 result of an original packet being forwarded onto the virtual link 276 represented by the tunnel. The original packet is processed during 277 forwarding according to the forwarding rules of the protocol of that 278 packet. For instance if the original packet is an: 280 (a) IPv6 packet, the IPv6 original header hop limit is decremented 281 by one. 283 (b) IPv4 packet, the IPv4 original header time to live field (TTL) 284 is decremented by one. 286 At encapsulation, the source field of the tunnel IPv6 header is 287 filled with an IPv6 address of the tunnel entry-point node, and the 288 destination field with an IPv6 address of the tunnel exit-point. 289 Subsequently, the tunnel packet resulting from encapsulation is sent 290 towards the tunnel exit-point node. 292 Tunnel extension headers should appear in the order recommended by 293 the specifications that define the extension headers, such as [RFC- 294 1883]. 296 A source of original packets and a tunnel entry-point that 297 encapsulates those packets can be the same node. 299 +----------------------------------//-----+ 300 | Original | | 301 | | Original Packet Payload | 302 | Header | | 303 +----------------------------------//-----+ 304 < Original Packet > 305 | 306 v 307 < Original Packet > 308 +---------+ - - - - - +-------------------------//--------------+ 309 | IPv6 | IPv6 | | 310 | | Extension | Original Packet | 311 | Header | Headers | | 312 +---------+ - - - - - +-------------------------//--------------+ 313 < Tunnel IPv6 Packet > 315 Fig.3 Encapsulating a Packet 316 3.2 Packet Processing in Tunnels 318 The intermediate nodes in the tunnel process the IPv6 tunnel packets 319 according to the IPv6 protocol. For example, a tunnel Hop by Hop 320 Options extension header is processed by each receiving node in the 321 tunnel; a tunnel Routing extension header identifies the intermediate 322 processing nodes, and controls at a finer granularity the forwarding 323 path of the tunnel packet through the tunnel; a tunnel Destination 324 Options extension header is processed at the tunnel exit-point node. 326 3.3 IPv6 Decapsulation 328 Decapsulation is graphically shown in Fig.4: 330 +---------+- - - - - -+----------------------------------//-----+ 331 | IPv6 | IPv6 | | 332 | | Extension | Original Packet | 333 | Header | Headers | | 334 +---------+- - - - - -+----------------------------------//-----+ 335 < Tunnel IPv6 Packet > 336 | 337 v 339 | | | | ---->---|------>--------- | | 340 | | | | | | | | | | 341 +-----------------------+ +-----------------------+ | | | 342 | | | | | | | | | v ^ | 343 v ^ v ^ v ^ v ^ Tunnel | | | | 344 | | | | | | | | Packets| | | | 345 +---------------------------------------------+ | | | | 346 | | | | | / / | | | | D E | 347 | v ^ IPv6 | --<-3--/-/--<---- | | | | E N | 348 | | | Layer ---->-4-/-/--->-- | | | | | C C | 349 | v ^ / / | | | | | | A A | 350 | | | 2 1 | | | | | | P P | 351 | v ^ -----<---5---/-/-<---- v ^ v ^ | | S S | 352 | | | | -->---6---/-/-->-- | | | | | | | U U | 353 | v ^ | | / / 6 5 4 3 8 7 | | L L | 354 | | | | | / / | | | | | | | | A A | 355 | v ^ v ^ / / v ^ | | | | | | T T | 356 +---------------------------------------------+ | E E | 357 | | | | | | | | | | | | | | | | 358 v ^ v ^ v ^ v ^ v ^ v ^ Original| | | | 359 | | | | | | | | | | | | Packets | v ^ | 360 +-----------------------+ +-----------------------+ | | | 361 | | | | | | | | | | | | 362 | | | | ---|----|-------<-------- | | 363 | | | --->--------------->------>---- | 364 | | | | 365 | Link-Layer Protocols | | IPv6 Tunnel Link-Layer | 366 +-----------------------+ +-----------------------------------+ 368 Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node 369 Note: 371 In Fig.5, the Upper-Layer Protocols box represents transport 372 protocols such as TCP, UDP, control protocols such as ICMP, routing 373 protocols such as OSPF, and internet or lower-layer protocol being 374 "tunneled" over IPv6, such as IPv4, IPX, etc. The Link-Layer 375 Protocols box represents Ethernet, Token Ring, FDDI, PPP, X.25, Frame 376 Relay, ATM, etc..., as well as internet layer "tunnels" such as IPv4 377 tunnels. 379 The IPv6 tunnel protocol engine acts as both an "upper-layer" and a 380 "link-layer", each with a specific input and output as follows: 382 (u.i) "tunnel upper-layer input" - consists of tunnel IPv6 packets 383 that are going to be decapsulated. The tunnel packets are 384 incoming through the IPv6 layer from: 386 (u.i.1) a link-layer - (path #1, Fig.5) 388 These are tunnel packets destined to this node and will 389 undergo decapsulation. 391 (u.i.2) a tunnel link-layer - (path #7, Fig.5) 393 These are tunnel packets that underwent one or more 394 decapsulations on this node, that is, the packets had 395 one or more nested tunnel headers and one nested tunnel 396 header was just discarded. This node is the exit-point 397 of both an outer tunnel and one or more of its inner 398 tunnels. 400 For both above cases the resulting original packets are passed 401 back to the IPv6 layer as "tunnel link-layer" output for 402 further processing (see b.2). 404 (u.o) "tunnel upper-layer output" - consists of tunnel IPv6 packets 405 that are passed through the IPv6 layer down to: 407 (u.o.1) a link-layer - (path #2, Fig.5) 409 These packets underwent encapsulation and are sent 410 towards the tunnel exit-point 412 (u.o.2) a tunnel link-layer - (path #8, Fig.5) 413 These tunnel packets undergo nested encapsulation. This 414 node is the entry-point node of both an outer tunnel 415 and one or more of its inner tunnel. 417 Implementation Note: 419 The tunnel upper-layer input and output can be implemented similar 420 to the input and output of the other upper-layer protocols. 422 The tunnel link-layer input and output are as follows: 424 (l.i) "tunnel link-layer input" - consists of original IPv6 packets 425 that are going to be encapsulated. 427 The original packets are incoming through the IPv6 layer from: 429 (l.i.1) an upper-layer - (path #4, Fig.5) 431 These are original packets originating on this node 432 that undergo encapsulation. The original packet source 433 and tunnel entry-point are the same node. 435 (l.i.2) a link-layer - (path #6, Fig.5) 437 These are original packets incoming from a different 438 node that undergo encapsulation on this tunnel entry- 439 point node. 441 (l.i.3) a tunnel upper-layer - (path #8, Fig.5) 443 These packets are tunnel packets that undergo nested 444 encapsulation. This node is both the entry-point node 445 of an outer tunnel and one or more of its inner 446 tunnels. 448 The resulting tunnel packets are passed as tunnel upper-layer 449 output packets through the IPv6 layer (see u.o) down to: 451 (l.o) "tunnel link-layer output" - consists of original IPv6 packets 452 resulting from decapsulation. These packets are passed through 453 the IPv6 layer to: 455 (l.o.1) an upper-layer - (path #3, Fig.5) 457 These original packets are destined to this node. 459 (l.o.2) a link-layer - (path #5, Fig.5) 461 These original packets are destined to another node; 462 they are transmitted on a link towards their 463 destination. 465 (l.o.3) a tunnel upper-layer - (path #7, Fig.5) 467 These packets undergo another decapsulation; they were 468 nested tunnel packets. This node is both the exit- 469 point node of an outer tunnel and one or more inner 470 tunnels. 472 Implementation Note: 474 The tunnel link-layer input and output can be implemented similar 475 to the input and output of other link-layer protocols, for 476 instance, associating an interface or pseudo-interface with the 477 IPv6 tunnel. 479 The selection of the "IPv6 tunnel link" over other links results 480 from the packet forwarding decision taken based on the content of 481 the node's routing table. 483 4. Nested Encapsulation 485 Nested IPv6 encapsulation is the encapsulation of a tunnel packet. 486 It takes place when a hop of an IPv6 tunnel is a tunnel. The tunnel 487 containing a tunnel is called an outer tunnel. The tunnel contained 488 in the outer tunnel is called an inner tunnel - see Fig.6. Inner 489 tunnels and their outer tunnels are nested tunnels. 491 The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv6 492 packets encapsulated by the "outer IPv6 tunnel" entry-point node. The 493 "inner tunnel entry-point node" treats the receiving tunnel packets 494 as original packets and performs encapsulation. The resulting 495 packets are "tunnel packets" for the "inner IPv6 tunnel", and "nested 496 tunnel packets" for the "outer IPv6 tunnel". 498 Outer Tunnel 499 <-------------------------------------> 500 <--links--><-virtual link-><--links---> 501 Inner Tunnel 503 Outer Tunnel Outer Tunnel 504 Entry-Point Exit-Point 505 Node Node 506 +-+ +-+ +-+ +-+ +-+ +-+ 507 | | | | | | | | | | | | 508 | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| | 509 | | | | | | | | | | | | 510 +-+ +-+ +-+ +-+ +-+ +-+ 511 Original Inner Tunnel Inner Tunnel Original 512 Packet Entry-Point Exit-Point Packet 513 Source Node Node Destination 514 Node Node 516 Fig.6. Nested Encapsulation 518 4.1 Limiting Nested Encapsulation 520 A tunnel IPv6 packet size is limited to the maximum IPv6 datagram 521 size [RFC 1883]. Each encapsulation adds to the size of a tunnel 522 packet the size of the tunnel IPv6 headers. Consequently, the number 523 of tunnel headers, and therefore, the number of nested 524 encapsulations, and furthermore, the number of "inner IPv6 tunnels" 525 that an "outer IPv6 tunnel" can have are limited by the maximum 526 packet size. 528 The increase in the size of a tunnel IPv6 packet due to nested 529 encapsulations may require fragmentation [RFC-1883] - see section 7. 530 Furthermore, each fragmentation, due to nested encapsulation, of an 531 already fragmented tunnel packet results in a doubling of the number 532 of fragments. Moreover, it is probable that once this fragmentation 533 begins, each new nested encapsulation results in yet additional 534 fragmentation. Therefore limiting nested encapsulation is 535 recommended. 537 The proposed mechanism for limiting excessive nested encapsulation is 538 a "tunnel encapsulation limit", which is carried in an IPv6 539 Destination Option header. 541 4.1.1 Tunnel Encapsulation Limit 543 The "Tunnel Encapsulation Limit" destination option is provided only 544 by tunnel entry-point nodes, it is discarded only by tunnel exit- 545 point nodes, and it is used to carry optional information [RFC-1883] 546 that need be examined only by tunnel entry-point nodes. 548 The "Tunnel Encapsulation Limit" destination option is defined as 549 follows: 551 Option Type Opt Data Len Opt Data Len 552 0 1 2 3 4 5 6 7 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 |0 0 0 0 0 1 0 0| 1 | Tun Encap Lim | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 Option Type value 4 559 - the highest-order two bits - set to 00 - 560 indicate "skip over this option if the option is 561 not recognized". 563 - the third-highest-order bit - set to 0 - 564 indicates that the option data in this option does 565 not change en route to the packet's destination 566 [RFC-1883]. 568 Opt Data Len value 1 - the data portion of the Option is one 569 byte long. 571 Opt Data Value the Tunnel Encapsulation Limit value - 8-bit 572 unsigned integer. 574 To avoid excessive nested encapsulation, an IPv6 tunnel entry-point 575 node may prepend to a packet undergoing encapsulation a "Tunnel 576 Encapsulation Limit - Destination Option". The "OptData Value" field 577 of the option is set to: 579 (a) a pre-configured value - if the packet being encapsulated 580 has no IPv6 destination options header or no "Tunnel 581 Encapsulation Limit" option in such a header - see section 582 6.6. 584 (b) a value resulting from a value stored in the IPv6 585 destination options header - if such a header exist and if 586 it contains a "Tunnel Encapsulation Limit" option. The 587 "OptData Value" of the extant option is copied into the 588 newly prepended "Tunnel Encapsulation Limit" option and 589 then decremented by one. 591 This is an exception to the rule of processing a 592 destination options extension header in that, although the 593 entry-point node is not a destination node, during 594 encapsulation, the IPv6 tunneling protocol engine looks 595 ahead, for an IPv6 destination header with a "Tunnel 596 Encapsulation Limit" option immediately following the 597 current IPv6 main header. 599 If the Tunnel Encapsulation Limit is decremented to zero, 600 the packet undergoing encapsulation is discarded. When the 601 packet is discarded, a Parameter Problem ICMP message 602 [RFC-1885] is returned to the packet originator, which is 603 the previous tunnel entry-point. The message points to the 604 Opt Data Value field within the Tunnel Encapsulation Limit 605 destination header of the packet. The field pointed to has 606 a value of one. 608 Two cases of encapsulation that should be avoided are described 609 below: 611 4.1.2 Loopback Encapsulation 613 A particular case of encapsulation which must be avoided is the 614 loopback encapsulation. Loopback encapsulation takes place when a 615 tunnel IPv6 entry-point node encapsulates tunnel IPv6 packets 616 originated from itself, and destined to itself. This can generate an 617 infinite processing loop in the entry-point node. 619 To avoid such a case, it is recommended that an implementation have a 620 mechanism that checks and rejects the configuration of a tunnel in 621 which both the entry-point and exit-point node addresses belong to 622 the same node. It is also recommended that the encapsulating engine 623 check for and reject the encapsulation of a packet that has the pair 624 of tunnel entry-point and exit-point addresses identical with the 625 pair of original packet source and final destination addresses. 627 4.1.3 Routing-Loop Nested Encapsulation 629 In the case of a forwarding path with multiple level nested tunnels, 630 a routing-loop from an inner tunnel to an outer tunnel is 631 particularly dangerous when packets from the inner tunnels reenter an 632 outer tunnel from which they have not yet exited. In such a case, the 633 nested encapsulation becomes a recursive encapsulation with the 634 negative effects described in 4.1. Because each nested encapsulation 635 adds a tunnel header with a new hop limit value, the IPv6 hop limit 636 mechanism cannot control the number of times the packet reaches the 637 outer tunnel entry-point node, and thus cannot control the number of 638 recursive encapsulations. 640 When the path of a packet from source to final destination includes 641 tunnels, the maximum number of hops that the packet can traverse 642 should be controlled by two mechanisms used together to avoid the 643 negative effects of recursive encapsulation in routing loops: 645 (a) the original packet hop limit. 647 It is decremented at each forwarding operation performed on 648 an original packet. This includes each encapsulation of the 649 original packet. It does not include nested encapsulations 650 of the original packet 652 (b) the tunnel IPv6 packet encapsulation limit. 654 It is decremented at each nested encapsulation of the 655 packet. 657 For a discussion of the excessive encapsulation risk factors in 658 nested encapsulation see Appendix A. 660 5. Tunnel IPv6 Header 662 The tunnel entry-point node fills out a tunnel IPv6 main header 663 [RFC-1883] as follows: 665 Version: 667 value 6 668 Priority: 670 Depending on the entry-point node tunnel configuration, the 671 priority can be set to that of either the original packet or 672 a pre-configured value - see section 6.3. 674 Flow label: 676 Depending on the entry-point node tunnel configuration, the 677 flow label can be set to a pre-configured value. The typical 678 value is zero - see section 6.4. 680 Payload Length: 682 The original packet length, plus the length of the 683 encapsulating (prepended) IPv6 extension headers, if any. 685 Next header: 687 The next header value according to [RFC-1883] from the 688 Assigned Numbers RFC [RFC-1700 or its succesors ]. 690 For example, if the original packet is an IPv6 packet, this 691 is set to: 693 - decimal value 41 (Assigned payload type number for 694 IPv6) - if there are no tunnel extension headers. 696 - value 0 (Assigned payload type number for IPv6 Hop by 697 Hop Options header) - if a hop by hop options header 698 immediately follows the tunnel IPv6 header. 700 - decimal value 60 (Assigned payload type number for 701 IPv6 Destination Options header) - if a Tunnel 702 Encapsulation Limit destination option header 703 immediately follows the tunnel IPv6 header. 705 Hop limit: 707 The tunnel IPv6 header hop limit is set to a pre-configured 708 value - see section 6.3. 710 The default value for hosts is the Neighbor Discovery 711 advertised hop limit [RFC-1970]. The default value for 712 routers is the default IPv6 Hop Limit value from the 713 Assigned Numbers RFC (64 at the time of writing this 714 document). 716 Source Address: 718 An IPv6 address of the outgoing interface of the tunnel 719 entry-point node. This address is configured as the tunnel 720 entry-point node address - see section 6.1. 722 Destination Address: 724 An IPv6 address of the tunnel exit-point node. If the tunnel 725 is configured as a free-exit tunnel, then the IPv6 address 726 of the destination from the original IPv6 header - see 727 section 6.2. 729 5.1 Tunnel IPv6 Extension Headers 731 Depending on IPv6 node configuration parameters, a tunnel entry-point 732 node may append to the tunnel IPv6 main header one or more IPv6 733 extension headers, such as hop by hop, routing, or others. 735 To limit the number of nested encapsulations of a packet, if it was 736 configured to do so - see section 6.6 - a tunnel entry-point appends 737 as the last tunnel extension header a Tunnel Encapsulation Limit 738 destination option header with fields set as follows: 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Next Header |Hdr Ext Len = 0| Opt Type = 4 |Opt Data Len=1 | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 | 0 | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 Next Header: 748 Identifies the type of the original packet header. For 749 example, if the original packet is an IPv6 packet, the next 750 header protocol value is set to decimal value 41 (Assigned 751 payload type number for IPv6). 753 Hdr Ext Len: 755 Length of the Tunnel Encapsulation Limit destination option 756 header in 8-octet units, not including the first 8 octets. 757 Set to value 0, if no other options are present in this 758 destination options header. 760 Option Type: 762 value 4 - see section 4.1.1. 764 Opt Data Len: 766 value 1 - see section 4.1.1. 768 Tun Encap Lim: 770 8 bit unsigned integer - see section 4.1.1. 772 Option Type: 774 value 1 - PadN option, to align the header following this 775 header. 777 Opt Data Len: 779 value 1 - one octet of option data. 781 Option Data: 783 value 0 - one zero-valued octet. 785 6. IPv6 Tunnel State Variables 787 The IPv6 tunnel state variables, some of which are or may be 788 configured on the tunnel entry-point node, are: 790 6.1 IPv6 Tunnel Entry-Point Node Address 792 The tunnel entry-point node address is one of the valid IPv6 unicast 793 addresses of the entry-point node - the validation of the address at 794 tunnel configuration time is recommended. 796 The tunnel entry-point node address is copied to the source address 797 field in the tunnel IPv6 header during packet encapsulation. 799 6.2 IPv6 Tunnel Exit-Point Node Address 801 The tunnel exit-point node address is used as IPv6 value for hosts is the IPv6 Neighbor 802 Discovery advertised hop limit [RFC-1970]. The tunnel hop limit 803 default value for routers is the default IPv6 Hop Limit value from 804 the Assigned Numbers RFC (64 at the time of writing this document). 806 The tunnel hop limit is copied into the hop limit field of the tunnel 807 IPv6 header of each packet encapsulated by the tunnel entry-point 808 node. 810 6.4 IPv6 Tunnel Packet Priority 812 The IPv6 Tunnel Packet Priority indicates the value that a tunnel 813 entry-point node sets in the priority field of a tunnel header. The 814 default value is zero. The configured Packet Priority can also 815 indicate whether the value of the priority field in the tunnel header 816 is copied from the original header, or it is set to the pre- 817 configured value. 819 6.5 IPv6 Tunnel Flow Label 821 The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- 822 point node sets in the flow label of a tunnel header. The default 823 value is zero. 825 6.6 IPv6 Tunnel Encapsulation Limit 827 The Tunnel Encapsulation Limit value can indicate whether the entry- 828 point node is configured to limit the number of encapsulations of 829 tunnel packets originating on that node. The IPv6 Tunnel 830 Encapsulation Limit is the maximum number of encapsulations permitted 831 for packets undergoing encapsulation at that entry-point node. 832 Recommended default value is 5. An entry-point node configured to 833 limit the number of nested encapsulations prepends a Tunnel 834 Encapsulation Limit destination options header to an original packet 835 undergoing encapsulation - see section 4.1, and 4.1.1. 837 6.7 IPv6 Tunnel MTU 839 The tunnel MTU is set dynamically to the Path MTU between the tunnel 840 entry-point and the tunnel exit-point nodes minus the size of the 841 tunnel headers: the maximum size of a tunnel packet payload that can 842 be sent through the tunnel without fragmentation [RFC-1883]. The 843 tunnel entry-point node performs Path MTU discovery on the path 844 between the tunnel entry-point and exit-point nodes [RFC-1981], 845 [RFC-1885]. The tunnel MTU of a nested tunnel is the tunnel MTU of 846 the outer tunnel minus the size of the tunnel headers. 848 Although it should be able to send a tunnel IPv6 packet of any valid 849 size, a tunnel entry-point node attempts to avoid the fragmentation 850 of tunnel packets, by reporting to source nodes of original packets 851 the MTU to be used in sizing original packets sent towards that 852 tunnel entry-point node. 854 7. IPv6 Tunnel Packet Size Issues 856 Prepending a tunnel header increases the size of a packet, therefore 857 a tunnel packet resulting from the encapsulation of an IPv6 original 858 packet may require fragmentation. 860 A tunnel IPv6 packet resulting from the encapsulation of an original 861 packet is considered an IPv6 packet originating from the tunnel 862 entry-point node. Therefore, like any source of an IPv6 packet, a 863 tunnel entry-point node must support fragmentation of tunnel IPv6 864 packets. 866 A tunnel intermediate node that forwards a tunnel packet to another 867 node in the tunnel follows the general IPv6 rule that it must not 868 fragment a packet undergoing forwarding. 870 A tunnel exit-point node receiving tunnel packets at the end of the 871 tunnel for decapsulation applies the strict left-to-right processing 872 rules for extension headers. In the case of fragmentation headers, 873 the fragments are reassembled into a tunnel packet before determining 874 that an embedded IP packet is present. 876 Note: 878 A particular problem arises when the destination of a fragmented 879 tunnel packet is an exit-point node identified by an anycast address. 880 The problem, which is similar to that of original fragmented IPv6 881 packets destined to nodes identified by an anycast address, consists 882 in the requirement that all the fragments of a packet must arrive to 883 the same destination node, for that node to be able to perform a 884 successful reassembly. 886 7.1 IPv6 Tunnel Packet Fragmentation 888 Tunnel packets that exceed the tunnel MTU are candidates for 889 fragmentation. The fragmentation of tunnel packets containing IPv6 890 original packets is performed as follows: 892 (a) if the original IPv6 packet size is larger than 576 octets, 893 the entry-point node discards the packet and it returns an 894 ICMPv6 "Packet Too Big" message to the source node of the 895 original packet with the recommended MTU size field set to 896 the maximum between 576, and the tunnel MTU, i.e. max(576, 897 tunnel MTU). Note that the tunnel MTU is the Path MTU 898 between the tunnel entry-point and the tunnel exit-point 899 nodes minus the size of the tunnel headers. Also see 900 section 6.7, and 8.2. 902 (b) if the original IPv6 packet is equal or smaller than 576 903 octets, the tunnel entry-point node encapsulates the 904 original packet, and subsequently fragments the resulting 905 IPv6 tunnel packet into IPv6 fragments that do not exceed 906 the tunnel MTU. 908 7.2 IPv4 Tunnel Packet Fragmentation 910 Tunnel packets that exceed the tunnel MTU are candidates for 911 fragmentation. The fragmentation of tunnel packets containing IPv4 912 original packets is performed as follows: 914 (a) if in the original IPv4 packet header the Don't Fragment - 915 DF - bit flag is SET, the entry-point node discards the 916 packet and returns an ICMP message. The ICMP message has 917 the type = "unreachable", the code = "datagram too big", 918 and the recommended MTU size field set to the size of the 919 tunnel MTU - see section 6.7, and 8.3. 921 (b) if in the original packet header the Don't Fragment - DF - 922 bit flag is CLEAR, the tunnel entry-point node encapsulates 923 the original packet, and subsequently fragments the 924 resulting IPv6 tunnel packet into IPv6 fragments that do 925 not exceed the tunnel MTU. 927 8. IPv6 Tunnel Error Processing and Reporting 929 IPv6 Tunneling follows the general rule that an error detected during 930 the processing of an IPv6 packet is reported through an ICMP message 931 to the source of the packet. 933 On a forwarding path that includes IPv6 tunnels, an error detected by 934 a node that is not in any tunnel is directly reported to the source 935 of the original IPv6 packet. 937 An error detected by a node inside a tunnel is reported to the source 938 of the tunnel packet, that is, the tunnel entry-point node. The ICMP 939 message sent to the tunnel entry-point node has as ICMP payload the 940 tunnel IPv6 packet that has the original packet as its payload. 942 The cause of a packet error encountered inside a tunnel can be a 943 problem with: 945 (a) the tunnel header, or 947 (b) the tunnel packet. 949 Both tunnel header and tunnel packet problems are reported to the 950 tunnel entry-point node. 952 If a tunnel packet problem is a consequence of a problem with the 953 original packet, which is the payload of the tunnel packet, then the 954 problem is also reported to the source of the original packet. 956 To report a problem detected inside the tunnel to the source of an 957 original packet, the tunnel entry point node must relay the ICMP 958 message received from inside the tunnel to the source of that 959 original IPv6 packet. 961 An example of the processing that can take place in the error 962 reporting mechanism of a node is illustrated in Fig.7, and Fig.8: 964 Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives an 965 ICMP packet from inside the tunnel, marked Tunnel ICMPv6 Message in 966 Fig.7. The tunnel entry-point node IPv6 layer passes the received 967 ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP 968 type and code [RFC-1885] generates an internal "error code". 970 Fig.7 path #1 - The internal error code, is passed with the "ICMPv6 971 message payload" to the upper-layer protocol - in this case the IPv6 972 tunnel upper-layer error input. 974 +-------+ +-------+ +-----------------------+ 975 | Upper | | Upper | | Upper | 976 | Layer | | Layer | | Layer | 977 | Proto.| | Proto | | IPv6 Tunnel | 978 | Error | | Error | | Error | 979 | Input | | Input | | Input | 980 | | | | | Decapsulate | 981 | | | | | -->--ICMPv6--#2->-- | 982 | | | | | | Payload | | 983 +-------+ +-------+ +--|-----------------|--+ 984 | | | | 985 ^ ^ ^ v 986 | | | | 987 --------------------#1-- -----Orig.Packet?--- - - - - - - - - - 988 #1 #3 Int.Error Code, #5 | 989 Int.Error Code,^ v Source Address, v v 990 ICMPv6 Payload | IPv6 | Orig. Packet | IPv4 | 991 +--------------+ +--------------+ +--------------+ + - - - - + 992 | | | | | | 993 | ICMP v6 | | ICMP v6 | | ICMP v4 | | | 994 | Input | | Error Report | | Error Report | 995 | - - - - +----+ - - - - | + - - - - + + - - - - + 996 | | | | 997 | IPv6 Layer | | IPv4 Layer | | | 998 | | | | 999 +----------------------------------+ +--------------+ + - - - - + 1000 | | | 1001 ^ V V 1002 #0 #4 #6 1003 | | | 1004 Tunnel ICMPv6 ICMPv6 ICMPv4 1005 Message Message Message 1006 | | | 1008 Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine) 1010 Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input 1011 decapsulates the tunnel IPv6 packet, which is the ICMPv6 message 1012 payload, obtaining the original packet, and thus the original headers 1013 and dispatches the "internal error code", the source address from the 1014 original packet header, and the original packet, down to the error 1015 report block of the protocol identified by the Next Header field in 1016 the tunnel header immediately preceding the original packet in the 1017 ICMP message payload. 1019 From here the processing depends on the protocol of the original 1020 packet: 1022 (a) - for an IPv6 original packet 1024 Fig.7 path #3 and Fig.8 (c.1)- for an IPv6 original packet, the 1025 ICMPv6 error report builds an ICMP message of a type and code 1026 according to the "internal error code", containing the "original 1027 packet" as ICMP payload. 1029 Fig.7 path #4 and Fig.8 (d.1)- The ICMP message has the tunnel 1030 entry-point node address as source address, and the original | Headers | | Headers | Payload | 1031 +--------+ +---------+ +----------+--------//------+ 1032 | 1033 ----------------- | 1034 | | 1035 --------------|--------------- 1036 | | 1037 V V 1038 +---------+ +--------+ +-------------------//------+ 1039 | New | | ICMP | | | 1040 (c.1) | IPv6 | + | | + | Orig. Packet in Error | 1041 | Headers | | Header | | | 1042 +---------+ +--------+ +-------------------//------+ 1043 | 1044 v 1045 +---------+--------+-------------------//------+ 1046 | New | ICMP | Original | 1047 (d.1) | IPv6 | | | 1048 | Headers | Header | Packet in Error | 1049 +---------+--------+-------------------//------+ 1050 < New ICMP Message > 1052 or for an IPv4 original packet 1054 +---------+ +--------+ +-------------------//------+ 1055 | New | | ICMP | | | 1056 (c.2) | IPv4 | + | | + | Orig. Packet in Error | 1057 | Header | | Header | | | 1058 +---------+ +--------+ +-------------------//------+ 1059 | 1060 v 1061 +---------+--------+-------------------//------+ 1062 | New | ICMP | Original | 1063 (d.2) | IPv4 | | | 1064 | Header | Header | Packet in Error | 1065 +---------+--------+-------------------//------+ 1066 < New ICMP Message > 1068 Fig.8 ICMP Error Reporting and Processing 1069 8.1 Tunnel ICMP Messages 1071 The tunnel ICMP messages that are reported to the source of the 1072 original packet are: 1074 hop limit exceeded 1076 The tunnel has a misconfigured hop limit, or contains a 1077 routing loop, and packets do not reach the tunnel exit- 1078 point node. This problem is reported to the tunnel entry- 1079 point node, where the tunnel hop limit can be reconfigured 1080 to a higher value. The problem is further reported to the 1081 source of the original packet as described in section 8.2, 1082 or 8.3. 1084 unreachable node 1086 One of the nodes in the tunnel is not or is no longer 1087 reachable. This problem is reported to the tunnel entry- 1088 point node, which should be reconfigured with a valid and 1089 active path between the entry and exit-point of the tunnel. 1090 The problem is further reported to the source of the 1091 original packet as described in section 8.2, or 8.3. 1093 parameter problem 1095 A Parameter Problem ICMP message pointing to a valid Tunnel 1096 Encapsulation Limit Destination header with a Tun Encap Lim 1097 field value set to one is an indication that the tunnel 1098 packet exceeded the maximum number of encapsulations 1099 allowed. The problem is further reported to the source of 1100 the original packet as described in section 8.2, or 8.3. 1102 The above three problems detected inside the tunnel, which are a 1103 tunnel configuration and a tunnel topology problem, are reported to 1104 the source of the original IPv6 packet, as a tunnel generic 1105 "unreachable" problem caused by a "link problem" - see section 8.2 1106 and 8.3. 1108 packet too big 1110 The tunnel packet exceeds the tunnel Path MTU. 1112 The information carried by this type of ICMP message is 1113 used as follows: 1115 - by a receiving tunnel entry-point node to set or adjust 1116 the tunnel MTU 1118 - by a sending tunnel entry-point node to indicate to the 1119 source of an original packet the MTU size that should be 1120 used in sending IPv6 packets towards the tunnel entry-point 1121 node. 1123 8.2 ICMP Messages for IPv6 Original Packets 1125 The tunnel entry-point node builds the ICMP and IPv6 headers of the 1126 ICMP message that is sent to the source of the original packet as 1127 follows: 1129 IPv6 Fields: 1131 Source Address 1133 A valid unicast IPv6 address of the outgoing interface. 1135 Destination Address 1137 Copied from the Source Address field of the Original 1138 IPv6 header. 1140 ICMP Fields: 1142 For any of the following tunnel ICMP error messages: 1144 "hop limit exceeded" 1146 "unreachable node" 1148 "parameter problem" - pointing to a valid Tunnel Encapsulation 1149 Limit destination header with the Tun Encap Lim field set to a 1150 value one: 1152 Type 1 - unreachable node 1154 Code 3 - address unreachable 1156 For tunnel ICMP error message "packet too big": 1158 Type 2 - packet too big 1160 Code 0 1162 MTU The MTU field from the tunnel ICMP message minus 1163 the length of the tunnel headers. 1165 According to the general rules described in 7.1, an ICMP "packet too 1166 big" message is sent to the source of the original packet only if the 1167 original packet size is larger than 576 octets. 1169 8.3 ICMP Messages for IPv4 Original Packets 1171 The tunnel entry-point node builds the ICMP and IPv4 header of the 1172 ICMP message that is sent to the source of the original packet as 1173 follows: 1175 IPv4 Fields: 1177 Source Address 1179 A valid unicast IPv4 address of the outgoing interface. 1181 Destination Address 1183 Copied from the Source Address field of the Original 1184 IPv4 header. 1186 ICMP Fields: 1188 For any of the following tunnel ICMP error messages: 1190 "hop limit exceeded" 1192 "unreachable node" 1194 "parameter problem" - pointing to a valid Tunnel Enacpsulation 1195 Limit destination header with the Tun Encap Lim field set to a 1196 value one: 1198 Type 3 - destination unreachable 1200 Code 1 - host unreachable 1201 For a tunnel ICMP error message "packet too big": 1203 Type 3 - destination unreachable 1205 Code 4 - datagram too big 1207 MTU The MTU field from the tunnel ICMP message minus 1208 the length of the tunnel headers. 1210 According to the general rules described in section 7.2, an ICMP 1211 "datagram too big" message is sent to the original IPv4 packet source 1212 node if the the original IPv4 header has the DF - don't fragment - 1213 bit flag SET. 1215 8.4 ICMP Messages for Nested Tunnels Packets 1217 In case of an error uncovered with a nested tunnels packet, the inner 1218 tunnel entry-point, which receives the ICMP error message from the 1219 inner tunnel reporting node, relays the ICMP message to the outer 1220 tunnel entry-point following the mechanisms described in sections 1221 8.,8.1, 8.2, and 8.3. Further, the outer tunnel entry-point relays 1222 the ICMP message to the source of the original packet, following the 1223 same mechanisms. 1225 9. Security Considerations 1227 An IPv6 tunnel can be secured, by securing the IPv6 path between the 1228 tunnel entry-point and exit-point node. The security architecture, 1229 mechanisms, and services are described in [RFC1825], [RFC1826], and 1230 [RFC1827]. A secure IPv6 tunnel may act as a gateway-to-gateway 1231 secure path as described in [RFC1825]. 1233 For a secure IPv6 tunnel, in addition to the mechanisms described 1234 earlier in this document, the entry-point node of the tunnel performs 1235 security algorithms on the packet and prepends as part of the tunnel 1236 headers one or more security headers in conformance with [RFC1883], 1237 [RFC1825], and [RFC1826], or [RFC1827]. 1239 The exit-point node of a secure IPv6 tunnel performs security 1240 algorithms and processes the tunnel security header[s] as part of the 1241 tunnel headers processing described earlier, and in conformance with 1242 [RFC1825], and [RFC1826], or [RFC1827]. The exit-point node discards 1243 the tunnel security header[s] with the rest of the tunnel headers 1244 after tunnel headers processing completion. 1246 The degree of integrity, authentication, and confidentiality and the 1247 security processing performed on a tunnel packet at the entry-point 1248 and exit-point node of a secure IPv6 tunnel depend on the type of 1249 security header - authentication (AH) or encryption (ESP) - and 1250 parameters configured in the Security Association for the tunnel. 1251 There is no dependency or interaction between the security level and 1252 mechanisms applied to the tunnel packets and the security applied to 1253 the original packets which are the payloads of the tunnel packets. In 1254 case of nested tunnels, each inner tunnel may have its own set of 1255 security services, independently from those of the outer tunnels, or 1256 of those between the source and destination of the original packet. 1258 10. Acknowledgments 1260 This document is partially derived from several discussions about 1261 IPv6 tunneling on the IPng Working Group Mailing List and from 1262 feedback from the IPng Working Group to an IPv6 presentation that 1263 focused on IPv6 tunneling at the 33rd IETF, in Stockholm, in July 1264 1995. 1266 Additionally, the following documents that focused on tunneling or 1267 encapsulation were helpful references: RFC 1933 (R. Gilligan, E. 1268 Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P. Tsuchiya), 1269 RFC 1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W. 1270 Simpson), as well as RFC 2003 (C. Perkins). 1272 Brian Carpenter, Richard Draves, Bob Hinden, Thomas Narten, Erik 1273 Nordmark (in alphabetical order) gave valuable reviewing comments and 1274 suggestions for the improvement of this document. Scott Bradner, Ross 1275 Callon, Dimitry Haskin, Paul Traina, and James Watt (in alphabetical 1276 order) shared their view or experience on matters of concern in this 1277 document. Judith Grossman provided a sample of her many years of 1278 editorial and writing experience as well as a good amount of probing 1279 technical questions. 1281 11. References 1283 [RFC-1883] S. Deering, R. Hinden, "Internet Protocol Version 6 1284 Specification" 1286 [RFC-1885] A. Conta, and S. Deering "Internet Control Message 1287 Protocol for the Internet Protocol Version 6 (IPv6)" 1289 [RFC-1970] T. Narten, E. Nordmark, W.Simpson "Neighbor Discovery for 1290 IP Version 6 (IPv6)" 1292 [RFC-1981] J. McCann, S. Deering, J. Mogul "Path MTU Discovery for IP 1293 Version 6 (IPv6)" 1295 [RFC-1825] R. Atkinson, "Security Architecture for the Internet 1296 Protocol" 1298 [RFC-1826] R. Atkinson, "IP Authentication Header" 1300 [RFC-1827] R. Atkinson, "IP Encapsulation Security Payload (ESP)" 1302 [RFC-1853] W. Simpson, "IP in IP Tunneling" 1304 [RFC-1700] J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994 1306 Authors' Addresses: 1308 Alex Conta Stephen Deering 1309 Lucent Technologies Inc. Cisco Systems 1310 1300 Massaschussets Ave 170 West Tasman Dr 1311 Boxborough, MA 01719 San Jose, CA 95132-1706 1312 +1-508-263-3600/ext 535 +1-408-527-8213 1314 email: aconta@lucent.com email: deering@cisco.com 1315 Appendix A 1317 A.1 Risk Factors in Nested Encapsulation 1319 Nested encapsulations of a packet become a recursive encapsulation if 1320 the packet reenters an outer tunnel before exiting it. The cases 1321 which present a high risk of recursive encapsulation are those in 1322 which a tunnel entry-point node cannot determine whether a packet 1323 that undergoes encapsulation reenters the tunnel before exiting it. 1324 Routing loops that cause tunnel packets to reenter a tunnel before 1325 exiting it are certainly the major cause of the problem. But since 1326 routing loops exist, and happen, it is important to understand and 1327 describe, the cases in which the risk for recursive encapsulation is 1328 higher. 1330 There are two significant elements that determine the risk factor of 1331 routing loop recursive encapsulation: 1333 (a) the type of tunnel, 1335 (b) the type of route to the tunnel exit-point, which 1336 determines the packet forwarding through the tunnel, that 1337 is, over the tunnel virtual-link. 1339 A.1.1 Risk Factor in Nested Encapsulation - type of tunnel. 1341 The type of tunnels which were identified as a high risk factor for 1342 recursive encapsulation in routing loops are: 1344 "inner tunnels with identical exit-points". 1346 These tunnels can be: 1348 "fixed-end inner tunnels with different entry-points", 1350 or: 1352 "free-end inner tunnels with different entry-points" 1354 Note that free-end inner tunnels fall always into the category of 1355 identical exit-point tunnels. 1357 Since the source and destination of an original packet is the main 1358 information used to decide whether to forward a packet through a 1359 tunnel or not, a recursive encapsulation can be avoided in case of a 1360 single tunnel (non-inner), by checking that the packet to be 1361 encapsulated is not originated on the entry-point node. This 1362 mechanism is suggested in [RFC-1853]. 1364 However, this type of protection does not seem to work well in case 1365 of inner tunnels with different entry-points, and identical exit- 1366 points. 1368 Inner tunnels with different entry-points and identical exit-points 1369 introduce ambiguity in deciding whether to encapsulate a packet, when 1370 a packet encapsulated in an inner tunnel reaches the entry-point node 1371 of an outer tunnel by means of a routing loop. Because the source of 1372 the tunnel packet is the inner tunnel entry-point node which is 1373 different than the entry-point node of the outer tunnel, the source 1374 address checking (mentioned above) fails to detect an invalid 1375 encapsulation, and as a consequence the tunnel packet gets 1376 encapsulated at the outer tunnel each time it reaches it through the 1377 routing loop. 1379 A.1.2 Risk Factor in Nested Encapsulation - type of route. 1381 The type of route to a tunnel exit-point node has been also 1382 identified as a high risk factor of recursive encapsulation in 1383 routing loops. 1385 One type of route to a tunnel exit-point node is a route to a 1386 specified destination node, that is, the destination is a valid 1387 specified IPv6 address (route to node). Such a route can be selected 1388 based on the longest match of an original packet destination address 1389 with the destination address stored in the tunnel entry-point node 1390 routing table entry for that route. The packet forwarded on such a 1391 route is first encapsulated and then forwarded towards the tunnel 1392 exit-point node. 1394 Another type of route to a tunnel exit-point node is a route to a 1395 specified prefix-net, that is, the destination is a valid specified 1396 IPv6 prefix (route to net). Such a route can be selected based on the 1397 longest path match of an original packet destination address with the 1398 prefix destination stored in the tunnel entry-point node routing 1399 table entry for that route. The packet forwarded on such a route is 1400 first encapsulated and then forwarded towards the tunnel exit-point 1401 node. 1403 And finally another type of route to a tunnel exit-point is a default 1404 route, or a route to an unspecified destination. This route is 1405 selected when no-other match for the destination of the original 1406 packet has been found in the routing table. A tunnel that is the 1407 first hop of a default route is a "default tunnel". 1409 If the route to a tunnel exit-point is a route to node, the risk 1410 factor for recursive encapsulation is minimum. 1412 If the route to a tunnel exit-point is a route to net, the risk 1413 factor for recursive encapsulation is medium. There is a range of 1414 destination addresses that will match the prefix the route is 1415 associated with. If one or more inner tunnels with different tunnel 1416 entry-points have exit-point node addresses that match the route to 1417 net of an outer tunnel exit-point, then a recursive encapsulation may 1418 occur if a tunnel packet gets diverted from inside such an inner 1419 tunnel to the entry-point of the outer tunnel that has a route to its 1420 exit-point that matches the exit-point of an inner tunnel. 1422 If the route to a tunnel exit-point is a default route, the risk 1423 factor for recursive encapsulation is maximum. Packets are forwarded 1424 through a default tunnel for lack of a better route. In many 1425 situations, forwarding through a default tunnel can happen for a wide 1426 range of destination addresses which at the maximum extent is the 1427 entire Internet minus the node's link. As consequence, it is likely 1428 that in a routing loop case, if a tunnel packet gets diverted from an 1429 inner tunnel to an outer tunnel entry-point in which the tunnel is a 1430 default tunnel, the packet will be once more encapsulated, because 1431 the default routing mechanism will not be able to discern 1432 differently, based on the destination.