idnits 2.17.1 draft-ietf-ipngwg-ipv6-tunnel-02.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-20) 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 37 longer pages, the longest (page 2) being 60 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.) ** There are 384 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 32 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 13 has weird spacing: '... Drafts are ...' == Line 14 has weird spacing: '...cuments of t...' == Line 15 has weird spacing: '... groups may ...' == Line 19 has weird spacing: '... Drafts may ...' == Line 20 has weird spacing: '...iate to use ...' == (379 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 (June 1996) is 10171 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 section? 'RFC-1883' on line 1298 looks like a reference -- Missing reference section? 'RFC-1885' on line 1305 looks like a reference -- Missing reference section? 'IPv6ND' on line 1309 looks like a reference -- Missing reference section? 'TBD' on line 1346 looks like a reference -- Missing reference section? 'IPv6PMTU' on line 1318 looks like a reference -- Missing reference section? 'RFC-1700' on line 1321 looks like a reference -- Missing reference section? 'RFC-1884' on line 1302 looks like a reference -- Missing reference section? 'ADDRCONF' on line 1315 looks like a reference -- Missing reference section? 'IPv4TUN' on line 1407 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Conta (Cascade Communications Corp.) 2 INTERNET-DRAFT S. Deering (Xerox PARC) 3 June 1996 5 Generic Packet Tunneling in IPv6 7 Specification 9 draft-ietf-ipngwg-ipv6-tunnel-02.txt 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are draft documents valid for a maximum of six 19 months. Internet Drafts may be updated, replaced, or obsoleted by 20 other documents at any time. It is not appropriate to use Internet 21 Drafts as reference material or to cite them other than as a "working 22 draft" or "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 26 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 30 Distribution of this memo is unlimited. 32 Abstract 34 This document defines the model and generic mechanisms for IPv6 35 encapsulation of Internet packets, such as IPv6 and IPv4. The model 36 and mechanisms can be applied to other protocol packets as well, such 37 as AppleTalk, IPX, CLNP, or others. 39 Table of Contents 41 Status of this Memo...........................................1 42 Table of Contents.............................................2 43 1. Introduction..................................................4 44 2. Terminology...................................................4 45 3. Generic IPv6 Tunneling........................................6 46 3.1 IPv6 Encapsulation.......................................7 47 3.2 IPv6 Packet Processing in Tunnels........................8 48 3.3 IPv6 Decapsulation.......................................8 49 3.4 IPv6 Tunnel Protocol Engine..............................9 50 4. Recursive Encapsulation......................................13 51 4.1 Limiting Recursive Encapsulation.......................13 52 4.1.1 Tunnel Encapsulation Limit.......................14 53 4.1.2 Loopback Recursive Encapsulation.................15 54 4.1.3 Routing Loop Recursive Encapsulation.............16 55 5. Tunnel IPv6 Header...........................................16 56 5.1 Tunnel IPv6 Extension Headers...........................18 57 6. IPv6 Tunnel State Variables..................................19 58 6.1 IPv6 Tunnel Entry-Point Node............................20 59 6.2 IPv6 Tunnel Exit-Point Node.............................20 60 6.3 IPv6 Tunnel Hop Limit...................................20 61 6.4 IPv6 Tunnel Packet Priority.............................21 62 6.5 IPv6 Tunnel Flow Label..................................21 63 6.6 IPv6 Tunnel Encapsulation Limit.........................21 64 6.7 IPv6 Tunnel MTU.........................................22 65 7. IPv6 Tunnel Packet Size Issues...............................22 66 7.1 IPv6 Tunnel Packet Fragmentation........................22 67 7.2 IPv4 Tunnel Packet Fragmentation........................23 68 8. IPv6 Tunnel Error Reporting and Processing...................23 69 8.1 Tunnel ICMP Messages....................................27 70 8.2 ICMP Messages for IPv6 Original Packets.................29 71 8.3 ICMP Messages for IPv4 Original Packets.................30 72 8.4 ICMP Messages for Recursive Tunnel Packets..............31 73 9. Open Issues..................................................31 74 10. References..................................................32 75 11. Acknowledgments.............................................32 76 12. Security Considerations.....................................33 77 Authors' Addresses..............................................33 78 Appendix A.Risk Factors in Recursive Encapsulation..............33 79 Appendix B.Changes from previous version........................36 81 Fig.1.................................................6 82 Fig.2.................................................7 83 Fig.3.................................................8 84 Fig.4.................................................9 85 Fig.5................................................10 86 Fig.6................................................13 87 Fig.7................................................24 88 Fig.8................................................26/27 89 1. Introduction 91 This document specifies a method and generic mechanisms by which a 92 packet is encapsulated and carried as payload within an IPv6 packet. 93 The resulting packet is called an IPv6 tunnel packet. The forwarding 94 path between the source and destination of the tunnel packet is 95 called an IPv6 tunnel. The technique is called IPv6 tunneling. 97 A typical scenario for IPv6 tunneling is the case in which an 98 intermediate node exerts explicit routing control by specifying 99 particular forwarding paths for selected packets. This control is 100 achieved by prepending to each of the selected original packets IPv6 101 headers that identify the forwarding path. 103 In addition to the description of generic IPv6 tunneling mechanisms, 104 which is the focus of this document, specific mechanisms for 105 tunneling IPv6 and IPv4 packets are also described herein. 107 2. Terminology 109 original packet 111 a packet that undergoes encapsulation. 113 original header 115 the header of an original packet. 117 tunnel 119 a forwarding path between two nodes on which packets payloads 120 are original packets. 122 tunnel end-node 124 a node where a tunnel begins or ends. 126 tunnel header 128 the header prepended to the original packet during 129 encapsulation. It specifies the tunnel end-points as source and 130 destination. 132 tunnel packet 134 a packet that encapsulates an original packet. 136 tunnel entry-point 138 the tunnel end-node where an original packet is encapsulated. 140 tunnel exit-point 142 the tunnel end-node where a tunnel packet is decapsulated. 144 IPv6 tunnel 146 a tunnel configured as a virtual link between two IPv6 nodes, on 147 which the encapsulating protocol is IPv6. 149 free-exit tunnel 151 a tunnel for which no specific exit-point was configured. 153 fixed-exit tunnel 155 a tunnel for which a specific exit-point was configured. 157 tunnel MTU 159 the Path MTU between the tunnel entry-point and the tunnel 160 exit-point nodes; it includes the tunnel headers. 162 tunnel hop limit 164 the maximum number of hops that a tunnel packet can travel from 165 the tunnel entry-point to the tunnel exit-point. 167 inner tunnel 169 a tunnel that is a hop (virtual link) of another tunnel. 171 outer tunnel 173 a tunnel containing one or more inner tunnels. 175 recursive tunnel packet 177 a tunnel packet that has as payload a tunnel packet. 179 recursive tunnel header 181 the tunnel header of a recursive tunnel packet. 183 recursive encapsulation 184 encapsulation of an encapsulated packet. 186 tunnel encapsulation limit 188 the maximum number of encapsulations of a packet. 190 3. IPv6 Tunneling 192 IPv6 tunneling is a technique for establishing a "virtual link" 193 between two IPv6 nodes for transmitting data packets as payloads of 194 IPv6 packets (see Fig.1). From the point of view of the two nodes, 195 this "virtual link", called IPv6 tunnel, appears as a link on which 196 IPv6 acts like a link-layer protocol The two IPv6 nodes play specific 197 roles. One node encapsulates original packets received from other 198 nodes or from itself and forwards the resulting tunnel packets 199 through the tunnel. The other node decapsulates the received tunnel 200 packets and forwards the resulting original packets towards their 201 destination, possibly itself. The encapsulator node is called the 202 tunnel entry-point node, and it is the source of the tunnel packets. 203 The decapsulator node is called the tunnel exit-point, and it is the 204 destination of the tunnel packets. 206 Tunnel from node B to node C 207 <----------------------> 208 Tunnel Tunnel 209 Entry-Point Exit-Point 210 Node Node 211 +-+ +-+ +-+ +-+ 212 |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D| 213 +-+ +-+ +-+ +-+ 214 Original Original 215 Packet Packet 216 Source Destination 217 Node Node 219 Fig.1 Tunnel 221 An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow 222 takes place in one direction between the IPv6 tunnel entry-point and 223 exit-point nodes (see Fig.1). 225 Bi-directional tunneling is achieved by merging two unidirectional 226 mechanisms, that is, configuring two tunnels, each in opposite 227 direction to the other - the entry-point node of one tunnel is the 228 exit-point node of the other tunnel (see Fig.2). 230 Tunnel from Node B to Node C 231 <------------------------> 232 Tunnel Tunnel 233 Original Entry-Point Exit-Point Original 234 Packet Node Node Packet 235 Source Destination 236 Node Node 237 +-+ +-+ +-+ +-+ 238 | |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| | 239 |A| |B| |C| |D| 240 | |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| | 241 +-+ +-+ +-+ +-+ 242 Original Original 243 Packet Packet 244 Destination Tunnel Tunnel Source 245 Node Exit-Point Entry-Point Node 246 Node Node 247 <-------------------------> 248 Tunnel from Node C to Node B 250 Fig.2 Bi-directional Tunneling Mechanism 252 3.1 IPv6 Encapsulation 254 IPv6 encapsulation consists of prepending to the original packet an 255 IPv6 header and, optionally, a set of IPv6 extension headers (see 256 Fig.3), which are collectively called tunnel IPv6 headers. The 257 encapsulation takes place in an IPv6 tunnel entry-point node, as the 258 result of an original packet being forwarded onto the virtual link 259 represented by the tunnel. The original packet is processed during 260 forwarding according to the forwarding rules of the protocol of that 261 packet. For instance if the original packet is an: 263 (a) IPv6 packet, the IPv6 original header hop limit is decremented 264 by one. 266 (b) IPv4 packet, the IPv4 original header time to live field (TTL) 267 is decremented by one. 269 At encapsulation, the source field of the tunnel IPv6 header is 270 filled with the IPv6 address of the tunnel entry-point node, and the 271 destination field with the IPv6 address of the tunnel exit-point. 272 Subsequently, the tunnel packet resulting from encapsulation is sent 273 towards the tunnel exit-point node. 275 Tunnel extension headers should appear in the order recommended by 276 the specifications that define the extension headers, such as [RFC- 277 1883]. 279 A source of original packets and a tunnel entry-point that 280 encapsulates those packets can be the same node. 282 +----------------------------------//-----+ 283 | Original | | 284 | | Original Packet Payload | 285 | Headers | | 286 +----------------------------------//-----+ 287 < Original Packet > 288 | 289 v 290 < Original Packet > 291 +---------+ - - - - - +-------------------------//--------------+ 292 | IPv6 | IPv6 | | 293 | | Extension | Original Packet | 294 | Header | Headers | | 295 +---------+ - - - - - +-------------------------//--------------+ 296 < Tunnel IPv6 Packet > 298 Fig.3 Encapsulating a Packet 300 3.2 Packet Processing in Tunnels 302 The intermediate nodes in the tunnel process the IPv6 tunnel packets 303 according to the IPv6 protocol. For example, a tunnel Hop by Hop 304 Options extension header is processed by each receiving node in the 305 tunnel; a tunnel Routing extension header identifies the intermediate 306 processing nodes, and controls at a finer granularity the forwarding 307 path of the tunnel packet through the tunnel; a tunnel Destination 308 Options extension header is processed at the tunnel exit-point node. 310 3.3 IPv6 Decapsulation 312 Decapsulation is graphically shown in Fig.4: 314 +---------+- - - - - -+----------------------------------//-----+ 315 | IPv6 | IPv6 | | 316 | | Extension | Original Packet | 317 | Headers | Headers | | 318 +---------+- - - - - -+----------------------------------//-----+ 319 < Tunnel IPv6 Packet > 320 | 321 v 322 +----------------------------------//-----+ 323 | Original | | 324 | | Original Packet Payload | 325 | Headers | | 326 +----------------------------------//-----+ 327 < Original Packet > 329 Fig.4 Decapsulating a Packet 331 Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel 332 entry-point node, its IPv6 protocol layer processes the tunnel 333 headers. When processing is complete, control is handed to the next 334 protocol engine, which is identified by the Next Header field value 335 in the last header processed. If this is set to a tunnel protocol 336 value, the tunnel protocol engine discards the tunnel headers and 337 passes the resulting original packet to the Internet or lower layer 338 protocol identified by that value for further processing. For 339 example, in the case the Next Header field has the IPv6 Tunnel 340 Protocol value, the resulting original packet is passed to the IPv6 341 protocol layer. 343 The tunnel exit-point node, which decapsulates the tunnel packets, 344 and the destination node, which receives the resulting original 345 packets can be the same node. 347 3.4 IPv6 Tunnel Protocol Engine 349 Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a 350 node is graphically shown below in Fig.5: 352 +-----------------------+ +-----------------------------------+ 353 | Upper-Layer Protocols | | IPv6 Tunnel Upper-Layer | 354 | | | | 355 | | | ---<-------------------<------- | 356 | | | | ---->---|------>--------- | | 357 | | | | | | | | | | 358 +-----------------------+ +-----------------------+ | | | 359 | | | | | | | | | v ^ | 360 v ^ v ^ v ^ v ^ Tunnel | | | | 361 | | | | | | | | Packets| | | | 362 +---------------------------------------------+ | | | | 363 | | | | | / / | | | | D E | 364 | v ^ IPv6 | --<-3--/-/--<---- | | | | E N | 365 | | | Layer ---->-4-/-/--->-- | | | | | C C | 366 | v ^ / / | | | | | | A A | 367 | | | 2 1 | | | | | | P P | 368 | v ^ -----<---5---/-/-<---- v ^ v ^ | | S S | 369 | | | | -->---6---/-/-->-- | | | | | | | U U | 370 | v ^ | | / / 6 5 4 3 8 7 | | L L | 371 | | | | | / / | | | | | | | | A A | 372 | v ^ v ^ / / v ^ | | | | | | T T | 373 +---------------------------------------------+ | E E | 374 | | | | | | | | | | | | | | | | 375 v ^ v ^ v ^ v ^ v ^ v ^ Original| | | | 376 | | | | | | | | | | | | Packets | v ^ | 377 +-----------------------+ +-----------------------+ | | | 378 | | | | | | | | | | | | 379 | | | | ---|----|-------<-------- | | 380 | | | --->--------------->------>---- | 381 | | | | 382 | Link-Layer Protocols | | IPv6 Tunnel Link-Layer | 383 +-----------------------+ +-----------------------------------+ 385 Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node 387 The "tunnel-layer" protocol engine acts as both an "upper-layer" and 388 a "link-layer", each with a specific input and output as follows: 390 (u.i) "tunnel upper-layer input" - consists of tunnel IPv6 packets 391 that are going to be decapsulated. The tunnel packets are 392 incoming through the IPv6 layer from: 394 (u.i.1) a link-layer - (path #1, Fig.5) 396 These are tunnel packets destined to this node and will 397 undergo decapsulation. 399 (u.i.2) a tunnel link-layer - (path #7, Fig.5) 401 These are tunnel packets that underwent one or more 402 decapsulations on this node, that is, the packets had 403 one or more recursive tunnel headers and one recursive 404 tunnel header was just discarded. This node is the 405 exit-point of both an outer tunnel and one or more of 406 its inner tunnels. 408 For both above cases the resulting original packets are passed 409 back to the IPv6 layer as "tunnel link-layer" output for 410 further processing (see b.2). 412 (u.o) "tunnel upper-layer output" - consists of tunnel IPv6 packets 413 that are passed through the IPv6 layer down to: 415 (u.o.1) a link-layer - (path #2, Fig.5) 417 These packets underwent encapsulation and are sent 418 towards the tunnel exit-point 420 (u.o.2) a tunnel link-layer - (path #8, Fig.5) 422 These tunnel packets are going to be recursively 423 encapsulated. This node is the entry-point node of both 424 an outer tunnel and one or more of its inner tunnel. 426 Implementation Note: 428 The tunnel upper-layer input and output can be implemented similar 429 to the input and output of the other upper-layer protocols. 431 The tunnel link-layer input and output are as follows: 433 (l.i) "tunnel link-layer input" - consists of original IPv6 packets 434 that are going to be encapsulated. 436 The original packets are incoming through the IPv6 layer from: 438 (l.i.1) an upper-layer - (path #4, Fig.5) 440 These are original packets originating on this node 441 that undergo encapsulation. The original packet source 442 and tunnel entry-point are the same node. 444 (l.i.2) a link-layer - (path #6, Fig.5) 446 These are original packets incoming from a different 447 node that undergo encapsulation on this tunnel entry- 448 point node. 450 (l.i.3) a tunnel upper-layer - (path #8, Fig.5) 452 These packets are tunnel packets that undergo 453 recursive encapsulation. This node is both the entry- 454 point node of an outer tunnel and one or more of its 455 inner tunnels. 457 The resulting tunnel packets are passed as tunnel upper-layer 458 output packets through the IPv6 layer (see u.o) down to: 460 (l.o) "tunnel link-layer output" - consists of original IPv6 packets 461 resulting from decapsulation. These packets are passed through 462 the IPv6 layer to: 464 (l.o.1) an upper-layer - (path #3, Fig.5) 466 These original packets are destined to this node. 468 (l.o.2) a link-layer - (path #5, Fig.5) 470 These original packets are destined to another node; 471 they are transmitted on a link towards their 472 destination. 474 (l.o.3) a tunnel upper-layer - (path #7, Fig.5) 476 These packets undergo another decapsulation; they were 477 recursive tunnel packets. This node is both the exit- 478 point node of an outer tunnel and one or more inner 479 tunnels. 481 Implementation Note: 483 The tunnel link-layer input and output can be implemented similar 484 to the input and output of other link-layer protocols, for 485 instance, associating an interface or pseudo-interface with the 486 IPv6 tunnel. 488 The selection of the "IPv6 tunnel link" over other links results 489 from the packet forwarding decision taken based on the content of 490 the node's routing table. 492 4. Recursive Encapsulation 494 Recursive IPv6 encapsulation is the encapsulation of a tunnel packet. 495 It takes place when a hop of an IPv6 tunnel is a tunnel. The tunnel 496 containing a tunnel is called an outer tunnel. The tunnel contained 497 in the outer tunnel is called an inner tunnel - see Fig.6. 499 Outer Tunnel 500 <-------------------------------------> 501 <--links--><-virtual link-><--links---> 502 Inner Tunnel 504 Outer Tunnel Outer Tunnel 505 Entry-Point Exit-Point 506 Node Node 507 +-+ +-+ +-+ +-+ +-+ +-+ 508 | | | | | | | | | | | | 509 | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| | 510 | | | | | | | | | | | | 511 +-+ +-+ +-+ +-+ +-+ +-+ 512 Original Inner Tunnel Inner Tunnel Original 513 Packet Entry-Point Exit-Point Packet 514 Source Node Node Destination 515 Node Node 517 Fig.6. Recursive Encapsulation 519 The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv6 520 packets encapsulated by the "outer IPv6 tunnel" entry-point node. The 521 "inner tunnel entry-point node" treats the receiving tunnel packets 522 as original packets and performs encapsulation. The resulting 523 packets are "tunnel packets" for the "inner IPv6 tunnel", and 524 "recursive tunnel packets" for the "outer IPv6 tunnel". 526 4.1 Limiting Recursive Encapsulation 528 A tunnel IPv6 packet size is limited to the maximum IPv6 datagram 529 size [RFC 1883]. Each encapsulation adds to the size of a tunnel 530 packet the size of the tunnel IPv6 headers. Consequently, the number 531 of recursive tunnel headers, and therefore, the number of recursive 532 encapsulations, and furthermore, the number of "inner IPv6 tunnels" 533 that an "outer IPv6 tunnel" can have are limited by the maximum 534 packet size. 536 The increase in the size of a tunnel IPv6 packet due to repeated 537 recursive encapsulations may require fragmentation [RFC-1883] - see 538 section 7. Furthermore, each fragmentation, due to recursive 539 encapsulation, of an already fragmented tunnel packet results in a 540 doubling of the number of fragments. Moreover, it is probable that 541 once this fragmentation begins, each new recursive encapsulation 542 results in yet additional fragmentation. Therefore limiting 543 recursive encapsulation is recommended. 545 The proposed mechanism for limiting excessive recursive encapsulation 546 is a "tunnel encapsulation limit", which is carried in an IPv6 547 Destination Option header. 549 4.1.1 Tunnel Encapsulation Limit 551 The "Tunnel Encapsulation Limit" destination option header is built 552 only by tunnel entry-point nodes, it is discarded only by tunnel 553 exit-point nodes, and it is used to carry optional information [RFC- 554 1883] that need be examined only by tunnel entry-point nodes. 556 The "Tunnel Encapsulation Limit" destination option header is defined 557 as follows: 559 Option Type Opt Data Len Opt Data Len 560 0 1 2 3 4 5 6 7 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |0 0 0 0 0 1 0 0| 1 | Tun Encap Lim | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Option Type value 4 567 - the highest-order two bits - set to 00 - 568 indicate "skip over this option if the option is 569 not recognized". 571 - the third-highest-order bit - set to 0 - 572 indicates that the option data in this option does 573 not change en route to the packet's destination 574 [RFC-1883]. 576 Opt Data Len value 1 - the data portion of the Option is one 577 byte long. 579 Opt Data Value the Tunnel Encapsulation Limit value - 8-bit 580 unsigned integer. 582 To avoid excessive recursive encapsulation, an IPv6 tunnel entry- 583 point node may prepend to a packet undergoing encapsulation a "Tunnel 584 Encapsulation Limit - Destination Options" tunnel header with the 585 "Opt Data Value" field set to: 587 (a) a pre-configured value - if the packet has no previous 588 "Tunnel Encapsulation Limit" header - see section 6.6. 590 (b) a value resulting from a pre-existent value - if the packet 591 has a previous "Tunnel Encapsulation Limit" header. The 592 value from the previous header is copied into the newly 593 prepended "Tunnel Encapsulation Limit" header and then 594 decremented by one. 596 This is an exception to the rule of processing destination 597 extension headers in that, although the entry-point node is 598 not a destination node, the IPv6 tunneling protocol engine 599 looks ahead during the encapsulation of a packet in the 600 extant tunnel headers for the "Tunnel Encapsulation Limit" 601 destination option header. 603 If the Tunnel Encapsulation Limit is decremented to zero, 604 the packet undergoing encapsulation is discarded. When the 605 packet is discarded, a Parameter Problem ICMP message 606 [RFC-1885] is returned to the packet originator, which is 607 the previous tunnel entry-point. The message points to the 608 Opt Data Value field within the Tunnel Encapsulation Limit 609 destination header of the packet. The field pointed to has 610 a value of one. 612 Two cases of recursive encapsulation that should be avoided are 613 described below: 615 4.1.2 Loopback Recursive Encapsulation 617 A particular case of recursive encapsulation which must be avoided is 618 the loopback recursive encapsulation. Loopback recursive 619 encapsulation takes place when a tunnel IPv6 entry-point node 620 encapsulates tunnel IPv6 packets originated from itself, and destined 621 to itself. This can generate an infinite processing loop in the 622 entry-point node. 624 To avoid such a case, it is recommended that an implementation have a 625 mechanism that checks and rejects the configuration of a tunnel in 626 which both the entry-point and exit-point node addresses belong to 627 the same node. It is also recommended that the encapsulating engine 628 checks for and rejects the encapsulation of a packet that has the 629 pair of tunnel entry-point and exit-point addresses identical with 630 the pair of original packet source and final destination addresses. 632 4.1.3 Routing Loop Recursive Encapsulation 634 In the case of a forwarding path with multiple levels of inner 635 tunnels, a routing loop from an inner tunnel to an outer tunnel is 636 particularly dangerous when the loop includes the outer tunnel 637 entry-point node without including the outer tunnel exit-point. The 638 danger is that the outer tunnel entry-point node may recursively 639 encapsulate packets excessively, with the negative effects described 640 in 4.1. Because each encapsulation adds a tunnel header with a new 641 hop limit value, the IPv6 hop limit mechanism cannot control the 642 number of times the packet reaches the outer tunnel entry-point node, 643 and thus cannot control the number of recursive encapsulations. 645 When the path of a packet from source to final destination includes 646 tunnels, the maximum number of hops that the packet can traverse 647 should be controlled by two mechanisms used together to avoid the 648 negative effects of recursive encapsulation in routing loops: 650 (a) the original packet hop limit. 652 It is decremented at each forwarding operation performed on 653 an original packet. This includes each encapsulation of the 654 original packet. It does not include recursive 655 encapsulations of the original packet 657 (b) the tunnel IPv6 packet encapsulation limit. 659 It is decremented at each recursive encapsulation of the 660 packet. 662 For a discussion of the excessive encapsulation risk factors in 663 recursive encapsulation see Appendix A. 665 5. Tunnel IPv6 Header 667 The tunnel entry-point node fills out a tunnel IPv6 main header 668 [RFC-1883] as follows: 670 Version: 672 value 6 674 Priority: 676 Depending on the entry-point node tunnel configuration, the 677 priority can be set to that of either the original packet or 678 a pre-configured value - see section 6.3. 680 Flow label: 682 Depending on the entry-point node tunnel configuration, the 683 flow label can be set to a pre-configured value. The typical 684 value is zero - see section 6.4. 686 Payload Length: 688 The original packet length. 690 If the packet is prepended with tunnel IPv6 extension 691 headers, this value is set to the original packet length 692 plus the length of the encapsulating IPv6 extension headers. 694 Next header: 696 The next header value according to [RFC-1883] from the 697 Assigned Numbers RFC [RFC-1700 or its succesors ]. 699 For example, if the original packet is an IPv6 packet, this 700 is set to: 702 - decimal value 41 (Assigned payload type number for 703 IPv6) - if there are no tunnel extension headers. 705 - value 0 (Assigned payload type number for IPv6 Hop by 706 Hop Options header) - if a hop by hop options header 707 immediately follows the tunnel IPv6 header. 709 - decimal value 60 (Assigned payload type number for 710 IPv6 Destination Options header) - if a Tunnel 711 Encapsulation Limit destination option header 712 immediately follows the tunnel IPv6 header. 714 Hop limit: 716 The tunnel IPv6 header hop limit is set to a pre-configured 717 value - see section 6.3. 719 The default value for hosts is the Neighbor Discovery 720 advertised hop limit [IPv6ND]. The default value for routers 721 is the default IPv6 Hop Limit [TBD] value from the Assigned 722 Numbers RFC. 724 Source Address: 726 An IPv6 address of the outgoing interface of the tunnel 727 entry-point node. This address is configured as tunnel 728 entry-point node address - see section 6.1. 730 Destination Address: 732 An IPv6 address of the tunnel exit-point node. If the tunnel 733 is configured as a free-exit tunnel, then the IPv6 address 734 of the destination from the original IPv6 header - see 735 section 6.2. 737 5.1 Tunnel IPv6 Extension Headers 739 Depending on IPv6 node configuration parameters, a tunnel entry-point 740 node may append to the tunnel IPv6 main header one or more IPv6 741 extension headers, such as hop by hop, routing, or others. 743 To limit the number of recursive encapsulations of a packet, if it 744 was configured to do so - see section 6.6 - a tunnel entry-point 745 appends as the last tunnel extension header a Tunnel Encapsulation 746 Limit destination option header with fields set as follows: 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Next Header |Hdr Ext Len = 0| Opt Type = 4 |Opt Data Len=1 | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 | 0 | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Next Header: 755 Identifies the type of the original packet header. For 756 example, if the original packet is an IPv6 packet, the next 757 header protocol value is set to decimal value 41 (Assigned 758 payload type number for IPv6). 760 Hdr Ext Len: 762 Length of the Tunnel Encapsulation Limit destination option 763 header in 8-octet units, not including the first 8 octets. 764 Set to value 0. 766 Option Type: 768 value 4 - see section 4.1.1. 770 Opt Data Len: 772 value 1 - see section 4.1.1. 774 Tun Encap Lim: 776 8 bit unsigned integer - see section 4.1.1. 778 Option Type: 780 value 1 - PadN option, to align the header following this 781 header. 783 Opt Data Len: 785 value 1 - one octet of option data. 787 Option Data: 789 value 0 - one zero-valued octet. 791 6. IPv6 Tunnel State Variables 793 The IPv6 tunnel state variables, some of which are or may be 794 configured on the tunnel enrty-point node, are: 796 6.1 IPv6 Tunnel Entry-Point Node Address 798 The tunnel entry-point node address is one of the valid IPv6 unicast 799 addresses of the entry-point node - the validation of the address at 800 tunnel configuration time is recommended. 802 The tunnel entry-point node address is copied to the source address 803 field in the tunnel IPv6 header during packet encapsulation. 805 6.2 IPv6 Tunnel Exit-Point Node Address 807 The tunnel exit-point node address is used as IPv6 destination 808 address for the tunnel IPv6 header. The tunnel exit-point node 809 address can be configured with a specific IPv6 address, in which case 810 the tunnel is called a fixed-exit tunnel. Such a tunnel acts like a 811 virtual point to point link between the entry-point node and exit- 812 point node. Alternatively, a tunnel exit-point address can be 813 configured with no specific address, in which case the tunnel is 814 called a free-exit tunnel. Such a tunnel acts like a virtual point to 815 point link between the entry-point node and an exit-point node 816 identified by the destination address from the original packet 817 header. 819 The tunnel exit-point node address is copied to the destination 820 address field in the tunnel IPv6 header during packet encapsulation. 822 The configuration of the tunnel entry-point and exit-point addresses 823 is not subject to IPv6 Autoconfiguration, or IPv6 Neighbor Discovery. 825 6.3 IPv6 Tunnel Hop Limit 827 An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in 828 which the passing of the original packet through the tunnel is like 829 the passing of the original packet over a one hop link, regardless of 830 the number of hops in the IPv6 tunnel. 832 The "single-hop" mechanism should be implemented by having the tunnel 833 entry point node set a tunnel IPv6 header hop limit independently of 834 the hop limit of the original header. 836 The "single-hop" mechanism hides from the original IPv6 packets the 837 number of IPv6 hops of the tunnel. 839 It is recommended that the tunnel hop limit be configured with a 840 value that ensures: 842 (a) tunnel IPv6 packets can reach the tunnel exit-point node 844 (b) quick expiration of the tunnel packet if a routing loop 845 occurs within the IPv6 tunnel. 847 The tunnel hop limit default value for hosts is the IPv6 Neighbor 848 Discovery advertised hop limit [IPv6ND]. The tunnel hop limit default 849 value for routers is the default IPv6 Hop Limit value [TBD] from the 850 Assigned Numbers RFC. 852 The tunnel hop limit is copied into the hop limit field of the tunnel 853 IPv6 header of each packet encapsulated by the tunnel entry-point 854 node. 856 6.4 IPv6 Tunnel Packet Priority 858 The IPv6 Tunnel Packet Priority indicates the value that a tunnel 859 entry-point node sets in the priority field of a tunnel header. The 860 default value is zero. The Packet Priority can also indicate whether 861 the value of the priority field in the tunnel header is copied from 862 the original header, or it is set to the pre-configured value. 864 6.5 IPv6 Tunnel Flow Label 866 The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- 867 point node sets in the flow label of a tunnel header. The default 868 value is zero. 870 6.6 IPv6 Tunnel Encapsulation Limit 872 The Tunnel Encapsulation Limit value can indicate whether the entry- 873 point node is configured to limit the number of encapsulations of 874 tunnel packets originating on that node. The IPv6 Tunnel 875 Encapsulation Limit is the maximum number of encapsulations permitted 876 for packets undergoing encapsulation at that entry-point node. 877 Recommended default value is 5. An entry-point node configured to 878 limit the number of recursive encapsulations prepends a Tunnel 879 Encapsulation Limit destination options header to an original packet 880 undergoing encapsulation - see section 4.1, and 4.1.1. 882 6.7 IPv6 Tunnel MTU 884 The tunnel MTU is set dynamically to the Path MTU of the tunnel: the 885 maximum size of a packet that can be sent through the tunnel without 886 fragmentation [RFC-1883]. The tunnel entry-point node performs Path 887 MTU discovery on the tunnel [IPv6PMTU], [RFC-1885]. 889 Although it should be able to send a tunnel IPv6 packet of any valid 890 size, a tunnel entry-point node attempts to avoid the fragmentation 891 of tunnel packets, by reporting to source nodes of original packets 892 the MTU to be used in sizing original packets sent towards that 893 tunnel entry-point node. 895 7. IPv6 Tunnel Packet Size Issues 897 A tunnel packet resulting from the encapsulation of an IPv6 original 898 packet may require fragmentation. 900 A tunnel IPv6 packet resulting from the encapsulation of an original 901 packet is considered an IPv6 packet originating from the tunnel 902 entry-point node. Therefore, like any source of an IPv6 packet, a 903 tunnel entry-point node must support fragmentation of tunnel IPv6 904 packets. 906 A tunnel intermediate node that forwards a tunnel packet to another 907 node in the tunnel follows the general IPv6 rule that it must not 908 fragment a packet undergoing forwarding. 910 7.1 IPv6 Tunnel Packet Fragmentation 912 Tunnel packets that exceed the tunnel MTU are candidates for 913 fragmentation. The fragmentation of tunnel packets containing IPv6 914 original packets is performed as follows: 916 (a) if the original IPv6 packet size is larger than 576 octets, 917 the entry-point node discards the packet and it returns an 918 ICMPv6 "Packet Too Big" message to the source node of the 919 original packet indicating the MTU size to be used by that 920 node in sizing original packets sent towards the tunnel 921 entry-point. The MTU is the original packet size minus the 922 size of the tunnel headers - see section 8.2. 924 (b) if the original IPv6 packet is equal or smaller than 576 925 octets, the tunnel entry-point node encapsulates the 926 original packet, and subsequently fragments the resulting 927 IPv6 tunnel packet into IPv6 fragments that do not exceed 928 the tunnel MTU. 930 7.2 IPv4 Tunnel Packet Fragmentation 932 Tunnel packets that exceed the tunnel MTU are candidates for 933 fragmentation. The conditions that determine IPv4 fragmentation of 934 tunnel packets are as follows: 936 (a) if in the original IPv4 packet header the Don't Fragment - 937 DF - bit flag is SET, the entry-point node discards the 938 packet and returns an ICMP message. The ICMP message has 939 the type = "unreachable", the code = "datagram too big", 940 and the recommended MTU size field set to the size of the 941 original packet minus the size of the tunnel headers - see 942 section 8.3. 944 (b) if in the original packet header the Don't Fragment - DF - 945 bit flag is CLEAR, the tunnel entry-point node encapsulates 946 the original packet, and subsequently fragments the 947 resulting IPv6 tunnel packet into IPv6 fragments that do 948 not exceed the tunnel MTU. 950 8. IPv6 Tunnel Error Processing and Reporting 952 IPv6 Tunneling follows the general rule that an error detected during 953 the processing of an IPv6 packet is reported through an ICMP message 954 to the source of the packet. 956 On a forwarding path that includes IPv6 tunnels, an error detected by 957 a node that is not in any tunnel is directly reported to the source 958 of the original IPv6 packet. 960 An error detected by a node inside a tunnel is reported to the source 961 of the tunnel packet, that is, the tunnel entry-point node. The ICMP 962 message sent to the tunnel entry-point node has as ICMP payload the 963 tunnel IPv6 packet that has the original packet as its payload. 965 The cause of a packet error encountered inside a tunnel can be a 966 problem with: 968 (a) the tunnel header, or 970 (b) the tunnel packet. 972 Both tunnel header and tunnel packet problems are reported to the 973 tunnel entry-point node. 975 If a tunnel packet problem is a consequence of a problem with the 976 original packet, which is the payload of the tunnel packet, then the 977 problem is also reported to the source of the original packet. 979 To report a problem detected inside the tunnel to the source of an 980 original packet, the tunnel entry point node must relay the ICMP 981 message received from inside the tunnel to the source of that 982 original IPv6 packet. 984 An example of the processing that can take place in the error 985 reporting mechanism of a node is illustrated in Fig.7, and Fig.8: 987 Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives an 988 ICMP packet from inside the tunnel, marked Tunnel ICMPv6 Message in 989 Fig.7. The tunnel entry-point node IPv6 layer passes the received 990 ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP 991 type and code [RFC-1885] generates an internal "error code". 993 Fig.7 path #1 - The internal error code, is passed with the "ICMPv6 994 message payload" to the upper-layer protocol - in this case the IPv6 995 tunnel upper-layer error input. 997 Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input 998 decapsulates the tunnel IPv6 packet, which is the ICMPv6 message 999 payload, obtaining the original packet, and thus the original headers 1000 and dispatches the "internal error code", the source address from the 1001 original packet header, and the original packet, down to the error 1002 report block of the protocol identified by the Next Header field in 1003 the tunnel header immediately preceding the original packet in the 1004 ICMP message payload. 1006 +-------+ +-------+ +-----------------------+ 1007 | Upper | | Upper | | Upper | 1008 | Layer | | Layer | | Layer | 1009 | Proto.| | Proto | | IPv6 Tunnel | 1010 | Error | | Error | | Error | 1011 | Input | | Input | | Input | 1012 | | | | | Decapsulate | 1013 | | | | | -->--ICMPv6--#2->-- | 1014 | | | | | | Payload | | 1015 +-------+ +-------+ +--|-----------------|--+ 1016 | | | | 1017 ^ ^ ^ v 1018 | | | | 1019 --------------------#1-- -----Orig.Packet?--- - - - - - - - - - 1020 #1 #3 Int.Error Code, #5 | 1021 Int.Error Code,^ v Source Address, v v 1022 ICMPv6 Payload | IPv6 | Orig. Packet | IPv4 | 1023 +--------------+ +--------------+ +--------------+ + - - - - + 1024 | | | | | | 1025 | ICMP v6 | | ICMP v6 | | ICMP v4 | | | 1026 | Input | | Error Report | | Error Report | 1027 | - - - - +----+ - - - - | + - - - - + + - - - - + 1028 | | | | 1029 | IPv6 Layer | | IPv4 Layer | | | 1030 | | | | 1031 +----------------------------------+ +--------------+ + - - - - + 1032 | | | 1033 ^ V V 1034 #0 #4 #6 1035 | | | 1036 Tunnel ICMPv6 ICMPv4 1037 ICMPv6 Message Message 1038 Message | | 1039 | | | 1041 Fig.7. Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine) 1043 From here the processing depends on the protocol of the original 1044 packet: 1046 (a) - for an IPv6 original packet 1048 Fig.7 path #3 and Fig.8 (c.1)- for an IPv6 original packet, the 1049 ICMPv6 error report builds an ICMP message of a type and code 1050 according to the "internal error code", containing the "original 1051 packet" as ICMP payload. 1053 Fig.7 path #4 and Fig.8 (d.1)- The ICMP message has the tunnel 1054 entry-point node address as source address, and the original packet 1055 source node address as destination address. The tunnel entry-point 1056 node sends the ICMP message to the source node of the original 1057 packet. 1059 (b) - for an IPv4 original packet 1061 Fig.7 path #5 and Fig.8 (c.2) - for an IPv4 original packet, the 1062 ICMPv4 error report builds an ICMP message of a type and code 1063 derived from the the "internal error code", containing the 1064 "original packet" as ICMP payload. 1066 Fig.7 path #6 and Fig.8 (d.2) - The ICMP message has the tunnel 1067 entry-point node IPv4 address as source address, and the original 1068 packet IPv4 source node address as destination address. The tunnel 1069 entry-point node sends the ICMP message to the source node of the 1070 original packet. 1072 A graphical description of the header processing taking place is the 1073 following: 1075 < Tunnel Packet > 1076 +--------+- - - - - -+--------+------------------------------//------+ 1077 | IPv6 | IPv6 | ICMP | Tunnel | 1078 (a)| | Extension | | IPv6 | 1079 | Header | Headers | Header | Packet in error | 1080 +--------+- - - - - -+--------+------------------------------//------+ 1081 < Tunnel Headers > < Tunnel ICMP Message > 1082 < ICMPv6 Message Payload > 1083 | 1084 v 1085 < Tunnel ICMP Message > 1086 < Tunnel IPv6 Packet in Error > 1087 +--------+ +---------+ +----------+--------//------+ 1088 | ICMP | | Tunnel | | Original | Original | 1089 (b) | | + | IPv6 | + | | Packet | 1090 | Header | | Headers | | Headers | Payload | 1091 +--------+ +---------+ +----------+--------//------+ 1092 | 1093 ----------------- | 1094 | | 1095 --------------|--------------- 1096 | | 1097 V V 1098 +---------+ +--------+ +-------------------//------+ 1099 | New | | ICMP | | | 1100 (c.1) | IPv6 | + | | + | Orig. Packet in Error | 1101 | Headers | | Header | | | 1102 +---------+ +--------+ +-------------------//------+ 1103 | 1104 v 1105 +---------+--------+-------------------//------+ 1106 | New | ICMP | Original | 1107 (d.1) | IPv6 | | | 1108 | Headers | Header | Packet in Error | 1109 +---------+--------+-------------------//------+ 1110 < New ICMP Message > 1112 or for an IPv4 original packet 1114 +---------+ +--------+ +-------------------//------+ 1115 | New | | ICMP | | | 1116 (c.2) | IPv4 | + | | + | Orig. Packet in Error | 1117 | Header | | Header | | | 1118 +---------+ +--------+ +-------------------//------+ 1119 | 1120 v 1121 +---------+--------+-------------------//------+ 1122 | New | ICMP | Original | 1123 (d.2) | IPv4 | | | 1124 | Header | Header | Packet in Error | 1125 +---------+--------+-------------------//------+ 1126 < New ICMP Message > 1128 Fig.8. ICMP Error Reporting and Processing 1130 8.1 Tunnel ICMP Messages 1132 The tunnel ICMP messages that are reported to the source of the 1133 original packet are: 1135 hop limit exceeded 1137 The tunnel has a misconfigured hop limit, or contains a 1138 routing loop, and packets do not reach the tunnel exit- 1139 point node. This problem is reported to the tunnel entry- 1140 point node, where the tunnel hop limit can be reconfigured 1141 to a higher value. The problem is further reported to the 1142 source of the original packet as described in section 8.2, 1143 or 8.3. 1145 unreachable node 1147 One of the nodes in the tunnel is not or is no longer 1148 reachable. This problem is reported to the tunnel entry- 1149 point node, which should be reconfigured with a valid and 1150 active path between the entry and exit-point of the tunnel. 1151 The problem is further reported to the source of the 1152 original packet as described in section 8.2, or 8.3. 1154 parameter problem 1156 A Parameter Problem ICMP message pointing to a valid Tunnel 1157 Encapsulation Limit Destination header with a Tun Encap Lim 1158 field value set to one is an indication that the tunnel 1159 packet exceeded the maximum number of encapsulations 1160 allowed. The problem is further reported to the source of 1161 the original packet as described in section 8.2, or 8.3. 1163 The above three problems detected inside the tunnel, which are a 1164 tunnel configuration and a tunnel topology problem, are reported to 1165 the source of the original IPv6 packet, as a tunnel generic 1166 "unreachable" problem caused by a "link problem" - see section 8.2 1167 and 8.3. 1169 packet too big 1171 The tunnel packet exceeds the tunnel Path MTU. 1173 This type of ICMP message is used as follows: 1175 - by a receiving tunnel entry-point node to set or adjust 1176 the tunnel MTU 1178 - by a sending tunnel entry-point node to indicate to the 1179 source of an original packet the MTU size that should be 1180 used in sending IPv6 packets towards the tunnel entry-point 1181 node. 1183 8.2 ICMP Messages for IPv6 Original Packets 1185 The tunnel entry-point node builds the ICMP and IPv6 headers of the 1186 ICMP message that is sent to the source of the original packet as 1187 follows: 1189 IPv6 Fields: 1191 Source Address 1193 A valid unicast IPv6 address of the outgoing interface. 1195 Destination Address 1197 Copied from the Source Address field of the Original 1198 IPv6 header. 1200 ICMP Fields: 1202 For any of the following tunnel ICMP error messages: 1204 hop limit exceeded 1206 unreachable node 1208 parameter problem 1210 pointing to a valid Tunnel Encapsulation Limit destination 1211 header with the Tun Encap Lim field set to a value one: 1213 Type 1 - unreachable node 1215 Code 3 - address unreachable 1217 For tunnel ICMP error message "packet too big": 1219 Type 2 - packet too big 1221 Code 0 1223 MTU The MTU field from the tunnel ICMP message minus 1224 the length of the tunnel headers. 1226 According to the general rules described in 7.1, an ICMP "packet too 1227 big" message is sent to the source of the original packet only if the 1228 original packet size is larger than 576 octets. 1230 8.3 ICMP Messages for IPv4 Original Packets 1232 The tunnel entry-point node builds the ICMP and IPv4 header of the 1233 ICMP message that is sent to the source of the original packet as 1234 follows: 1236 IPv4 Fields: 1238 Source Address 1240 A valid unicast IPv4 address of the outgoing interface. 1242 Destination Address 1244 Copied from the Source Address field of the Original 1245 IPv4 header. 1247 ICMP Fields: 1249 For any of the following tunnel ICMP error messages: 1251 hop limit exceeded 1253 unreachable node 1255 parameter problem 1257 pointing to a valid Tunnel Enacpsulation Limit destination 1258 header with the Tun Encap Lim field set to a value one: 1260 Type 3 - destination unreachable 1262 Code 1 - host unreachable 1264 For a tunnel ICMP error message "packet too big": 1266 Type 3 - destination unreachable 1268 Code 4 - datagram too big 1270 MTU The MTU field from the tunnel ICMP message minus 1271 the length of the tunnel headers. 1273 According to the general rules described in section 7.2, an ICMP 1274 "datagram too big" message is sent to the original IPv4 packet source 1275 node if the the original IPv4 header has the DF - don't fragment - 1276 bit flag SET. 1278 8.4 ICMP Messages for Recursive Tunnel Packets 1280 In case of an error uncovered with a recursive tunnel packet, the 1281 inner tunnel entry-point, which receives the ICMP error message from 1282 the inner tunnel reporting node, relays the ICMP message to the outer 1283 tunnel entry-point following the mechanisms described in sections 1284 8.,8.1, 8.2, and 8.3. Further, the outer tunnel entry-point relays 1285 the ICMP message to the source of the original packet, following the 1286 same mechanisms. 1288 9. Open Issues 1290 (a) Tunnel default hop limit value 1292 At this time, there is no definition for an IPv6 hop limit 1293 default value. The Assigned Numbers [RFC-1700] IPv4 TTL default 1294 value could be used instead. 1296 10.References 1298 [RFC-1883] 1299 S. Deering, R. Hinden, "Internet Protocol Version 6 1300 Specification" 1302 [RFC-1884] 1303 S. Deering, R. Hinden, "IP Version 6 Addressing Architecture". 1305 [RFC-1885] 1306 A. Conta, and S. Deering "Internet Control Message Protocol for 1307 the Internet Protocol Version 6 (IPv6)" 1309 [IPv6ND] 1310 T. Narten, E. Nordmark, "IPv6 Neighbor Discovery Specification" 1312 [IPv6PMTU] 1313 J. McCann and S. Deering, "IPv6 Path MTU Discovery" 1315 [ADDRCONF] 1316 T. Narten, and S. Thomson, "IPv6 Address Autoconfiguration" 1318 [IPv6PMTU] 1319 S. Deering, and J. McCann, "IPv6 Path MTU Discovery" 1321 [RFC-1700] 1322 J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994 1324 11.Acknowledgments 1326 This document is partially derived from several discussions about 1327 IPv6 tunneling on the IPng Working Group Mailing List and from 1328 feedback from the IPng Working Group to an IPv6 presentation that 1329 focused on IPv6 tunneling at the 33rd IETF, in Stockholm, in July 1330 1995. 1332 Additionally, the following documents that focused on tunneling or 1333 encapsulation were helpful references: RFC 1933 (R. Gilligan, E. 1334 Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P. Tsuchiya), 1335 RFC 1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W. 1336 Simpson), as well as the IP encapsulation draft of the Mobile IP 1337 working Group (C. Perkins). 1339 Important contributions were made by Brian Carpenter and Erik 1340 Nordmark, both of whom gave numerous and valuable reviewing comments 1341 and suggestions for the improvement of this document. Also many 1342 thanks to Judith Grossman, who provided a sample of her many years of 1343 editorial and writing experience as well as a good amount of probing 1344 technical questions. 1346 [TBD] 1348 12.Security Considerations 1350 Security considerations are not discussed in this memo. 1352 Authors' Addresses: 1354 Alex Conta Stephen Deering 1355 Cascade Communications Corp. Xerox Palo Alto Research Center 1356 5 Carlisle Rd 3333 Coyote Hill Road 1357 Westford, MA 03062 Palo Alto, CA 94304 1358 +1-508-952-1534 +1-415-812-4839 1360 email: conta@casc.com email: deering@parc.xerox.com 1362 Appendix A 1364 A.1 Risk Factors in Recursive Encapsulation 1366 The cases which present a high risk of excessive recursive 1367 encapsulation are those in which a tunnel entry-point node cannot 1368 discern between a valid and an invalid recursive encapsulation. 1369 Routing loops that cause tunnel packets to reach nodes that were 1370 already reached before are certainly the major cause of the problem. 1371 But since routing loops exist, and happen, it is important to 1372 understand and describe, the cases in which the risk for excessive 1373 recursive encapsulation is higher. 1375 There are two significant elements that determine the risk factor of 1376 routing loop excessive recursive encapsulation: 1378 (a) the type of tunnel, 1380 (b) the type of route to the tunnel exit-point, which 1381 determines the packet forwarding through the tunnel, that 1382 is, over the tunnel virtual-link. 1384 A.1.1 Risk Factor in Recursive Encapsulation - type of tunnel. 1386 The type of tunnels which were identified as a high risk factor for 1387 excessive recursive encapsulation in routing loops are: 1389 "inner tunnels with identical exit-points". 1391 These tunnels can be: 1393 "fixed-end inner tunnels with different entry-points", 1395 or: 1397 "free-end inner tunnels with different entry-points" 1399 Note that free-end inner tunnels fall always into the category of 1400 identical exit-point tunnels. 1402 Since the source and destination of an original packet is the main 1403 information used to decide whether to forward a packet through a 1404 tunnel or not, an excessive recursive encapsulation can be avoided in 1405 case of a single tunnel (non-inner), by checking that the packet to 1406 be encapsulated is not originated on the entry-point node. This 1407 mechanism is suggested in [IPv4TUN]. 1409 However, this type of protection does not seem to work well in case 1410 of inner tunnels with different entry-points, and identical exit- 1411 points. 1413 Inner tunnels with different entry-points and identical exit-points 1414 introduce ambiguity in deciding whether to encapsulate a packet, when 1415 a packet encapsulated in an inner tunnel reaches the entry-point node 1416 of an outer tunnel by means of a routing loop. Because the source of 1417 the tunnel packet is the inner tunnel entry-point node which is 1418 different than the entry-point node of the outer tunnel, the source 1419 address checking (mentioned above) fails to detect an invalid 1420 encapsulation, and as a consequence the tunnel packet gets 1421 encapsulated at the outer tunnel each time it reaches it through the 1422 routing loop. 1424 A.1.2 Risk Factor in Recursive Encapsulation - type of route. 1426 The type of route to a tunnel exit-point node has been also 1427 identified as a high risk factor of excessive recursive encapsulation 1428 in routing loops. 1430 One type of route to a tunnel exit-point node is a route to a 1431 specified destination node, that is, the destination is a valid 1432 specified IPv6 address (route to node). Such a route can be selected 1433 based on the longest match of an original packet destination address 1434 with the destination address stored in the tunnel entry-point node 1435 routing table entry for that route. The packet forwarded on such a 1436 route is first encapsulated and then forwarded towards the tunnel 1437 exit-point node. 1439 Another type of route to a tunnel exit-point node is a route to a 1440 specified prefix-net, that is, the destination is a valid specified 1441 IPv6 prefix (route to net). Such a route can be selected based on the 1442 longest path match of an original packet destination address with the 1443 prefix destination stored in the tunnel entry-point node routing 1444 table entry for that route. The packet forwarded on such a route is 1445 first encapsulated and then forwarded towards the tunnel exit-point 1446 node. 1448 And finally another type of route to a tunnel exit-point is a default 1449 route, or a route to an unspecified destination. This route is 1450 selected when no-other match for the destination of the original 1451 packet has been found in the routing table. A tunnel that is the 1452 first hop of a default route is a "default tunnel". 1454 If the route to a tunnel exit-point is a route to node, the risk 1455 factor for excessive recursive encapsulation is minimum. 1457 If the route to a tunnel exit-point is a route to net, the risk 1458 factor for excessive recursive encapsulation is medium. There is a 1459 range of destination addresses that will match the prefix the route 1460 is associated with. If one or more inner tunnels with different 1461 tunnel entry-points have exit-point node addresses that match the 1462 route to net of an outer tunnel exit-point, then an excessive 1463 recursive encapsulation may occur if a tunnel packet gets diverted 1464 from inside such an inner tunnel to the entry-point of the outer 1465 tunnel that has a route to its exit-point that matches the exit-point 1466 of an inner tunnel. 1468 If the route to a tunnel exit-point is a default route, the risk 1469 factor for excessive recursive encapsulation is maximum. Packets are 1470 forwarded through a default tunnel for lack of a better route. In 1471 many situations, forwarding through a default tunnel can happen for a 1472 wide range of destination addresses which at the maximum extent is 1473 the entire Internet minus the node's link. As consequence, it is 1474 likely that in a routing loop case, if a tunnel packet gets diverted 1475 from an inner tunnel to an outer tunnel entry-point in which the 1476 tunnel is a default tunnel, the packet will be once more 1477 encapsulated, because the default routing mechanism will not be able 1478 to discern differently, based on the destination. 1480 Appendix B Changes: 1482 B.1 From draft 00 to draft 01 1484 - add new sections: 1486 3.4 IPv6 Tunnels and Address Formats 1487 3.5 IPv6 Tunnels and IPv6 Autoconfiguration 1488 3.6 IPv6 Tunnels and IPv6 Neighbor Discovery 1489 4.1.4 Risk Factors in Recursive Encapsulation 1490 Appendix A..Inner tunnels 1491 Appendix B..Default tunnels 1493 - separate fragmentation from section 6.7 into a new 1494 section: 1496 7. IPv6 Tunnel Packet Fragmentation 1497 7.1 IPv6 Packet Fragmentation 1498 7.2 IPv4 Packet Fragmentation 1500 - include comments from Erik Nordmark 1502 - some of the comments are part of the modifications 1503 mentioned above. 1505 - Section 5: flow label 1506 "tipical" corrected to "typical". 1508 - Section 6.2: 1509 changed from multi-point to point-to-point 1511 - section 8, 8.1, 8.3 1512 replace "original packet originator" with 1513 "source of original packet". 1515 B.2 From draft 01 to draft 02 1517 - deleted - Appendix A 1518 - Appendix B 1520 - moved section 4.1.4 to new Appendix A. 1522 - added new section 3.2 "IPv6 Packet Processing in Tunnels". 1524 - added new section 8.4 "ICMP Messages for Recursive Tunnel Packets". 1526 - improved, reduced, or extended text in 1527 (this includes comments from Erik Nordmark) 1529 1. Introduction 1530 2. Terminology 1531 3. Generic IPv6 Tunneling 1532 3.1 IPv6 Encapsulation 1533 3.2 IPv6 Packet Processing in Tunnels... 1534 3.3 IPv6 Decapsulation... 1535 3.4 IPv6 Tunnel Protocol Engine... 1536 4. Recursive Encapsulation... 1537 4.1 Limiting Recursive Encapsulation... 1538 4.1.1 Tunnel Encapsulation Limit... 1539 4.1.2 Loopback Recursive Encapsulation... 1540 4.1.3 Routing Loop Recursive Encapsulation... 1541 7. IPv6 Tunnel Packet Fragmentation... 1542 7.1 IPv6 Packet Fragmentation... 1543 7.2 IPv4 Packet Fragmentation... 1544 8. IPv6 Tunnel Error Reporting and Processing... 1545 8.1 Tunnel ICMP Messages... 1546 8.2 ICMP Messages for IPv6 Original Packets... 1547 8.3 ICMP Messages for IPv4 Original Packets... 1549 - changed sections title: 1551 7. IPv6 Tunnel Packet Fragmentation 1552 to: 1554 7. IPv6 Tunnel Packet Size Issues 1556 7.1 IPv6 Packet Fragmentation 1557 to: 1558 7.1 IPv6 Tunnel Packet Fragmentation 1560 7.2 IPv4 Packet Fragmentation 1561 to: 1562 7.2 IPv4 Tunnel Packet Fragmentation