idnits 2.17.1 draft-ietf-ipngwg-ipv6-tunnel-01.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-24) 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 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 395 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 53 instances of too long lines in the document, the longest one being 7 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 ...' == (390 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 (February 1996) is 10296 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-1884' on line 1433 looks like a reference -- Missing reference section? 'ADDRCONF' on line 1446 looks like a reference -- Missing reference section? 'RFC-1883' on line 1429 looks like a reference -- Missing reference section? 'RFC-1885' on line 1436 looks like a reference -- Missing reference section? 'IPv4TUN' on line 741 looks like a reference -- Missing reference section? 'RFC-1700' on line 1452 looks like a reference -- Missing reference section? 'IPv6ND' on line 1440 looks like a reference -- Missing reference section? 'TBD' on line 1476 looks like a reference -- Missing reference section? 'IPv6PMTU' on line 1449 looks like a reference -- Missing reference section? 'RFC-1853' on line 1455 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Conta (Digital Equipment Corporation) 3 INTERNET-DRAFT S. Deering (Xerox PARC) 4 February 1996 6 Generic Packet Tunneling in IPv6 8 Specification 10 draft-ietf-ipngwg-ipv6-tunnel-01.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 mechanisms for IPv6 tunneling of 36 various Internet or lower layer protocol packets, such as IPv6, IPv4, 37 AppleTalk, IPX, etc. 39 Table of Contents 41 Status of this Memo...........................................1 42 Table of Contents.............................................2 43 1. Introduction..................................................3 44 2. Terminology...................................................3 45 3. Generic IPv6 Tunneling........................................7 46 3.1 IPv6 Encapsulation.......................................9 47 3.2 IPv6 Decapsulation......................................10 48 3.3 IPv6 Tunnel Protocol Engine.............................11 49 3.4 IPv6 Tunnels and Address Formats........................13 50 3.5 IPv6 Tunnels and IPv6 Autoconfiguration.................13 51 3.6 IPv6 Tunnels and IPv6 Neighbor Discovery................13 52 4. Recursive Encapsulation......................................13 53 4.1 Limiting Recursive Encapsulation.......................14 54 4.1.1 Tunnel Encapsulation Limit.......................14 55 4.1.2 Loopback Recursive Encapsulation.................16 56 4.1.3 Routing Loop Recursive Encapsulation.............16 57 4.1.4 Risk Factors in Recursive Encapsulation..........17 58 5. Generic Tunnel IPv6 Header...................................19 59 5.1 Tunnel IPv6 Extension Headers...........................21 60 6. IPv6 Tunnel State Variables..................................23 61 6.1 IPv6 Tunnel Entry Point Node............................23 62 6.2 IPv6 Tunnel Exit Point Node.............................23 63 6.3 IPv6 Tunnel Hop Limit...................................24 64 6.4 IPv6 Tunnel Packet Priority.............................24 65 6.5 IPv6 Tunnel Flow Label..................................24 66 6.6 IPv6 Tunnel Encapsulation Limit.........................25 67 6.7 IPv6 Tunnel MTU.........................................25 68 7. IPv6 Tunnel Packet Fragmentation.............................25 69 7.1 IPv6 Packet Fragmentation...............................26 70 7.2 IPv4 Packet Fragmentation...............................26 71 8. IPv6 Tunnel Error Reporting and Processing...................27 72 8.1 Tunnel ICMP Messages....................................30 73 8.2 ICMP Messages for IPv6 Original Packets.................31 74 8.3 ICMP Messages for IPv4 Original Packets.................32 75 9. Open Issues..................................................33 76 10. References..................................................34 77 11. Acknowledgements............................................35 78 12. Security Considerations.....................................35 79 Authors' Addresses..............................................35 80 Appendix A..Inner tunnels.......................................35 81 Appendix B..Default tunnels.....................................37 82 Changes from previous version...................................38 84 Fig. 1.................................................8 85 Fig. 2.................................................8 86 Fig. 3.................................................9 87 Fig. 4................................................10 88 Fig. 5................................................11 89 Fig. 6................................................13 90 Fig. 7................................................28 91 Fig. 8................................................29 92 1. Introduction 94 This document specifies a method and generic mechanisms by which a 95 packet may be encapsulated and carried as payload within an IPv6 96 packet. The technique of encapsulating packets within IPv6 packets, 97 called also tunneling in IPv6, is recommended for use in various 98 cases of communications. 100 Such a case is when a node, that is not the source node of a packet, 101 wishes to exert explicit routing control over the packet - such as 102 causing the packet to be forwarded to a particular destination on the 103 way to the final destination identified in the original header. The 104 control is exerted by prepending to the packet a new IPv6 header, 105 with a new source and destination address (see section 3.1). 107 The tunnel IPv6 packet is forwarded to the tunnel IPv6 header 108 destination which is the IPv6 tunnel exit-point node. The IPv6 tunnel 109 exit-point node removes the IPv6 tunnel header, and forwards the IPv6 110 packet further towards the original IPv6 header destination node (see 111 section 3.2). 113 The sections of this document describe generic mechanisms for IPv6 114 tunneling that apply to tunneling of various Internet or lower layer 115 protocol packets. section 7. and 8. describe specific IPv6 tunneling 116 mechanisms for IPv6 packets and respectively IPv4 packets. 118 2. Terminology 120 node 122 a device that implements IPv6. 124 upper-layer 126 a protocol layer immediately above IPv6. Examples are transport 127 protocols such as TCP and UDP, control protocols such as ICMP, and 128 internet or lower-layer protocols being "tunneled" over (i.e., 129 encapsulated in) IPv6 such as IPX, AppleTalk, or IPv6 itself. 131 link 133 a communication facility or medium over which nodes can 134 communicate at the link layer, i.e., the layer immediately below 135 IPv6. Examples are Ethernets (simple or bridged); PPP links; 136 X.25, Frame Relay, or ATM networks; and internet (or higher) layer 137 "tunnels", such as tunnels over IPv4 or IPv6 itself. 139 interface 141 a node's attachment to a link. 143 address 145 an IPv6-layer identifier for an interface or a set of interfaces. 147 packet 149 an IPv6 header plus payload. 151 link MTU 153 the maximum transmission unit, i.e., maximum packet size in 154 octets, that can be conveyed in one piece over a link. 156 path MTU 158 the minimum link MTU of all the links in a path between a source 159 node and a destination node. 161 prefix-net 163 a network of nodes with identical prefix. 165 original packet 167 an Internet or lower layer packet that undergoes encapsulation in 168 a tunnel packet. 170 original header 172 the header of an original packet. 174 tunnel 176 a virtual link between two nodes, on which an Internet or lower 177 layer protocol packet travels after the entry point node 178 encapsulates that packet in a tunnel protocol packet. 180 tunnel header 182 the header prepended to the original packet during encapsulation. 183 It specifies the tunnel end-points as source and destination. 185 tunnel packet 187 an original packet encapsulated by prepending tunnel header(s) to 188 the original header(s). 190 tunnel entry point 192 the tunnel end-node where an original packet is encapsulated, and 193 where a tunnel packet originates; the source node of a tunnel 194 packet identified in the tunnel header. 196 tunnel exit-point 198 the tunnel end-node where a tunnel packet is decapsulated, and 199 processed further as original packet based on the original header; 200 the destination node of a tunnel packet, identified in the tunnel 201 header. 203 free-exit tunnel 205 a tunnel that has an unspecified exit-point address (unspecified 206 IPv6 address). 208 fixed-exit tunnel 210 a tunnel that has a specified exit-point address (not the 211 unspecified IPv6 address). 213 tunnel MTU 215 the Path MTU in the tunnel, i.e. between the tunnel entry point 216 node and the tunnel exit-point node. 218 tunnel hop limit 220 the maximum number of hops that a tunnel packet is allowed to 221 travel in a tunnel, i.e. between the tunnel entry point node and 222 the tunnel exit-point node. 224 inner tunnel 226 a tunnel which serves as one (virtual) hop in another tunnel. 228 outer tunnel 230 a tunnel in which one or more hops are themselves tunnels. 232 recursive tunnel IPv6 packet 233 a tunnel IPv6 packet encapsulated within a tunnel IPv6 packet, by 234 prepending IPv6 tunnel header(s) to previously prepended IPv6 235 tunnel header(s). 237 recursive encapsulation 239 encapsulation of a tunnel packet, i.e. encapsulation of an 240 encapsulated packet. 242 tunnel encapsulation limit 244 the maximum number of recursive encapsulations of a packet. 246 default tunnel 248 a tunnel which is the preferred link (virtual) to the default 249 router. 251 3. IPv6 Tunneling 253 Tunneling in IPv6 is a technique which consists in establishing a 254 "virtual link" between two IPv6 nodes and using that "link" for 255 transmitting data packets. The two IPv6 nodes view the IPv6 "virtual 256 link", also called an "IPv6 tunnel", as a "link", on which the IPv6 257 protocol acts like a "link layer" protocol. Consequently the two 258 nodes at the two ends of the IPv6 tunnel exchange an Internet or 259 lower layer protocol packet by encapsulating in and decapsulating 260 from an IPv6 packet, as they would encapsulate in and decapsulate 261 from a link layer protocol packet. 263 The two IPv6 nodes which are at the two ends of the IPv6 tunnel, the 264 IPv6 tunnel entry point node and the IPv6 tunnel exit point node play 265 specific roles: 267 A tunnel entry point node can be seen as an original packet source - 268 the source of the IPv6 tunnel packet is the tunnel entry point node. 269 An IPv6 tunnel main header and its extension headers, if any, are 270 processed by the IPv6 layer similarly to processing the headers of an 271 original IPv6 packet. Additionally, an IPv6 tunnel packet resulting 272 from encapsulation is an IPv6 packet that may be the object of a 273 subsequent IPv6 encapsulation, similar to any original packet. 275 A tunnel exit point node can be seen as an original packet 276 destination - the destination of the IPv6 tunnel packet is the tunnel 277 exit-point node. The tunnel exit point node processes the IPv6 main 278 header and its extension headers, if any, of an IPv6 tunnel packet 279 destined to it similarly to processing the IPv6 headers of an 280 original packet destined to it. 282 Tunnel from node B to node C 283 <-------------------------------------> 284 Tunnel Tunnel 285 Entry Point Exit Point 286 Node Node 287 +-+ +-+ +-+ +-+ 288 |A|->-//->-|B|=========>=====//========>=========|C|->-//-->-|D| 289 +-+ +-+ +-+ +-+ 290 Original Original 291 Packet Packet 292 Source Destination 293 Node Node 295 Fig. 1. Tunnel 297 An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow 298 takes place in one direction between the IPv6 tunnel entry point node 299 and exit point node (see Fig. 1). 301 Tunnel from node B to node C 302 <---------------------------------------> 303 Tunnel Tunnel 304 Original Entry Point Exit-Point Original 305 Packet Node Node Packet 306 Source Destination 307 Node Node 308 +-+ +-+ +-+ +-+ 309 | |-->-//->--| |=========>=====//========>=========| |-->-//-->-| | 310 |A| |B| |C| |D| 311 | |--<-//-<--| |=========<=====//========<=========| |--<-//--<-| | 312 +-+ +-+ +-+ +-+ 313 Original Original 314 Packet Packet 315 Destination Tunnel Tunnel Source 316 Node Exit-Point Entry Point Node 317 Node Node 318 <-------------------------------------> 319 Tunnel from node C to node B 321 Fig. 2. Bidirectional tunneling mechanism effect 323 A bidirectional tunneling mechanism effect can be achieved by merging 324 two unidirectional mechanisms, by defining two tunnels that are each one 325 in opposite direction to the other - the entry point node of one tunnel 326 is the exit point node of the other tunnel (see Fig. 2). 328 A tunnel entry point node can be the original packet source, and 329 similarly a tunnel exit-point node can be the original packet 330 destination, i.e. the beginning or ending of a tunnel can coincide 331 with the source or destination of an original packet. 333 3.1 IPv6 Encapsulation 335 The IPv6 encapsulation of a packet consists in prepending to the 336 original packet, an IPv6 header and optionally a set of IPv6 337 extension headers, called tunnel IPv6 headers, as graphically shown 338 below in Fig. 3: 340 The IPv6 encapsulation takes place in an IPv6 tunnel entry point 341 node, when transmitting an original packet through the tunnel that 342 begins at that entry point node. The tunnel packet resulted from 343 encapsulation is sent towards the tunnel exit-point node. The tunnel 344 headers are used to control the packet's processing (forwarding) 345 through the tunnel. 347 +----------------------------------//-----+ 348 | Original | | 349 | | Original Packet Payload | 350 | Headers | | 351 +----------------------------------//-----+ 352 < Original packet > 353 | 354 v 355 < Original Packet > 356 +---------+ - - - - - +-------------------------//--------------+ 357 | IPv6 | IPv6 | | 358 | | Extension | Original Packet | 359 | Header | Headers | | 360 +---------+ - - - - - +-------------------------//--------------+ 361 < Tunnel IPv6 packet > 363 Fig. 3. Encapsulating a packet 365 If the transmitting of the original packet through the tunnel is the 366 result of a forwarding operation, the original packet header is 367 processed before encapsulation according to the forwarding rules of 368 the protocol of the original header. For instance if the original 369 packet is an: 371 (a) IPv6 packet, and it is tunneled as result of an IPv6 forwarding 372 operation, the IPv6 original packet hop limit is decremented by 373 one during forwarding. 375 (b) IPv4 packet, and it is tunneled as result of an IPv4 forwarding 376 operation through an IPv6 tunnel, the IPv4 original packet time 377 to live field (TTL) is decremented by one during forwarding. 379 3.2 IPv6 Decapsulation 381 The decapsulation is graphically shown below in Fig. 4: 383 +---------+- - - - - -+----------------------------------//-----+ 384 | IPv6 | IPv6 | | 385 | | Extension | Original Packet | 386 | Headers | Headers | | 387 +---------+- - - - - -+----------------------------------//-----+ 388 < Tunnel IPv6 packet > 389 | 390 v 391 +----------------------------------//-----+ 392 | Original | | 393 | | Original Packet Payload | 394 | Headers | | 395 +----------------------------------//-----+ 396 < Original packet > 398 Fig. 4. Decapsulating a packet from the tunnel IPv6 headers 400 The IPv6 protocol layer of a tunnel exit-point node receiving an IPv6 401 packet destined to one of the node's IPv6 addresses processes the 402 packet according to the IPv6 protocol. A Next Header field value set 403 to a Tunnel Protocol Value (value 41 for IPv6) in the IPv6 header, or 404 the last IPv6 extension header of the packet identifies the packet as 405 a tunnel packet. Upon the completion of the IPv6 protocol layer 406 processing of a tunnel packet, control is given to the Tunnel 407 Protocol layer. The Tunnel Protocol layer discards the tunnel headers 408 and passes the resulting original packet to the Internet or lower 409 layer protocol for further processing - for Next Header value 41, the 410 resulting original packet is passed to the IPv6 protocol layer. 412 3.3 IPv6 Tunnel Protocol Engine 414 The packet flow through the IPv6 Tunnel Protocol Engine is 415 graphically shown below in Fig. 5: 417 +-----------------------+ +-----------------------------------+ 418 | Upper Layer Protocols | | IPv6 Tunnel Upper-Layer | 419 | | | | 420 | | | ---<-------------------<------- | 421 | | | | ---->---|------>--------- | | 422 | | | | | | | | | | 423 +-----------------------+ +-----------------------+ | | | 424 | | | | | | | | | v ^ | 425 v ^ v ^ v ^ v ^ Tunnel | | | | 426 | | | | | | | | packets| | | | 427 +---------------------------------------------+ | | | | 428 | | | | | / / | | | | D E | 429 | v ^ IPv6 | --<-3--/-/--<---- | | | | E N | 430 | | | Layer ---->-4-/-/--->-- | | | | | C C | 431 | v ^ / / | | | | | | A A | 432 | | | 2 1 | | | | | | P P | 433 | v ^ -----<---5---/-/-<---- v ^ v ^ | | S S | 434 | | | | -->---6---/-/-->-- | | | | | | | U U | 435 | v ^ | | / / 6 5 4 3 8 7 | | L L | 436 | | | | | / / | | | | | | | | A A | 437 | v ^ v ^ / / v ^ | | | | | | T T | 438 +---------------------------------------------+ | E E | 439 | | | | | | | | | | | | | | | | 440 v ^ v ^ v ^ v ^ v ^ v ^ Original| | | | 441 | | | | | | | | | | | | packets | v ^ | 442 +-----------------------+ +-----------------------+ | | | 443 | | | | | | | | | | | | 444 | | | | ---|----|-------<-------- | | 445 | | | --->--------------->------>---- | 446 | | | | 447 | Link Layer Protocols | | IPv6 Tunnel Link Layer | 448 +-----------------------+ +-----------------------------------+ 450 Fig. 5. Packet Flow - IPv6 Tunneling Protocol Engine 452 The "tunnel-layer" acts as both an "upper-layer" and a "link layer": 454 (a) The "tunnel upper-layer" has as "input" tunnel IPv6 packets 455 which are going to be decapsulated. The tunnel packets are 456 incoming through the IPv6 layer from a link-layer - (path #1 in 457 Fig. 5) - or from a tunneling link-layer (the exit-point node 458 of an inner tunnel coincides with the exit-point node of an 459 outer tunnel) - (path #7 in Fig. 5). The resulting original 460 packets are passed back to the IPv6 layer as "tunnel link- 461 layer" output for further processing - see (d). 463 (b) The "tunnel upper-layer" has as "output" tunnel IPv6 packets 464 resulting from encapsulation of original packets - see (c) - or 465 packets resulted from previous encapsulations - when this node 466 is an entry point to an outer tunnel and to an inner tunnel. 467 The "output" tunnel packets are passed through the IPv6 layer 468 down to a link-layer for transmission - (path #2 Fig. 5) - or 469 to a tunnel link-layer for another encapsulation (the entry 470 point node in an inner tunnel coincides with the entry point 471 node in an outer tunnel) - (path #8 in Fig. 5). 473 Implementation Note: 475 the "tunnel upper-layer" input and output may be implemented 476 similar to the other upper layer protocols input and output. 478 (c) The "tunnel link-layer" has as "input" original IPv6 packets 479 which are going to be encapsulated. The original packets are 480 incoming through the IPv6 layer from an upper-layer (original 481 packets originated on this node) - (path #4 in Fig. 5) - or 482 from a link layer (original packets originated on a different 483 node) - (path #6 in Fig. 5). The resulting tunnel packets are 484 passed through the IPv6 layer down to a link-layer for 485 transmission - see (b). 487 (d) The "tunnel link-layer" has as "output" original IPv6 packets 488 resulting from decapsulation - see (a) - which are passed 489 through the IPv6 layer up to an upper-layer (the original 490 packet is destined to this node) - (path #3 in Fig. 5) - or 491 down to a link-layer (the original packet is destined to 492 another node, so it is forwarded) - (path #5 in Fig. 5). 494 Implementation Note: 496 the "IPv6 tunnel link layer" input and output may be 497 implemented similar to other link layer protocols input and 498 output, for instance by associating an interface or pseudo- 499 interface with the IPv6 tunnel. 501 The selection of the "IPv6 tunnel link" over other links 502 results from the packet forwarding decision taken based on the 503 content of the node's routing table. 505 3.4 IPv6 Tunnels and Address Formats 507 Although the IPv6 addresses of the two end-nodes of an IPv6 tunnel 508 can be viewed as "virtual link" addresses, they have an IPv6 address 509 format - [RFC-1884]. 511 3.5 IPv6 Tunnels and IPv6 Autoconfiguration 513 Although the IPv6 addresses of the two end-nodes of an IPv6 tunnel 514 can be viewed as "virtual link" addresses of a pseudo-interface, the 515 IPv6 Autoconfiguration [ADDRCONF] mechanisms do not apply for the 516 pseudo-interface. 518 3.6 IPv6 Tunnels and IPv6 Neighbor Discovery 520 Although the IPv6 addresses of the two ends of an IPv6 tunnel can be 521 viewed as "virtual link" addresses, the IPv6 Neighbor Discovery 522 mechanisms do not apply. 524 4. Recursive Encapsulation 526 Recursive IPv6 encapsulation takes place when portions of an IPv6 527 tunnel are IPv6 tunnels themselves, i.e. a tunnel contains inner 528 tunnels - see Fig. 6. 530 Outer Tunnel 531 <-------------------------------------> 532 <--------------> Inner Tunnel 534 Outer Tunnel Outer Tunnel 535 Entry Point Exit Point 536 Node Node 537 +-+ +-+ +-+ +-+ +-+ +-+ 538 | | | | | | | | | | | | 539 | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//-->-| | 540 | | | | | | | | | | | | 541 +-+ +-+ +-+ +-+ +-+ +-+ 542 Original Inner Tunnel Inner Tunnel Original 543 Packet Entry Point Exit Point Packet 544 Source Node Node Destination 545 Node Node 547 Fig. 6. Recursive Encapsulation 549 The entry point node of an "inner IPv6 tunnel" may receive and 550 encapsulate packets that are tunnel IPv6 packets encapsulated at an 551 "outer IPv6 tunnel" entry point node. These packets are original 552 packets for the "inner IPv6 tunnel" entry point node, the result of 553 their encapsulation at the "inner IPv6 tunnel entry point node" is a 554 "tunnel IPv6 packet" for the "inner IPv6 tunnel", and a "recursive 555 tunnel IPv6 packet" for the "outer IPv6 tunnel". 557 4.1 Limiting Recursive Encapsulation 559 There is a practical limit on how many "inner IPv6 tunnels" an "outer 560 IPv6 tunnel" may have which results from the maximum number of 561 possible IPv6 encapsulations of a packet. 563 Each encapsulation adds to the size of a tunnel packet the size of 564 the tunnel IPv6 headers. Consequently, in the case of inner tunnels, 565 the number of recursive encapsulations is practically limited by the 566 number of tunnel IPv6 headers that can be prepended to the original 567 packet before the resulting tunnel packet hits the maximum IPv6 568 datagram size [RFC-1883]. 570 The increase in the size of a tunnel IPv6 packet due to repeated 571 recursive encapsulation may require fragmentation at a tunnel entry 572 point node [RFC-1883] - see section 7. 574 Each next recursive encapsulation of a tunnel IPv6 fragment may 575 result in a new fragmentation and thus the addition of one more 576 fragment to the previous existing fragments. Therefore, it is highly 577 probable that once the fragmentation of a tunnel IPv6 packet was 578 triggered, each next recursive encapsulation may result in additional 579 fragmentation, and thus IPv6 fragment multiplication. Therefore, it 580 is recommended to keep recursive encapsulation to a minimum. 582 The proposed mechanism for controlling excessive recursive encapsulation 583 is a "tunnel encapsulation limit" that is carried in an IPv6 Destination 584 Option header. 586 4.1.1 Tunnel Encapsulation Limit 588 The "Tunnel Encapsulation Limit" destination option header is built 589 only by tunnel entry point nodes, it is discarded only by tunnel 590 exit-point nodes, and it is used to carry optional information [RFC- 591 1883] that need be examined only by tunnel entry point nodes. 593 It is defined according to [RFC-1883] as follows: 595 Option Type Opt Data Len Tun Encap Lim 596 0 1 2 3 4 5 6 7 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 |0 0 0 0 0 1 0 0| 1 | u_8int | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 Option Type decimal value 4 - the highest-order two bits - set 602 to 00 - specify "skip over this option if the 603 option is not recognized". The third-highest-order 604 bit - set to 0 - specifies that the option data in 605 this option does not change en-route to the 606 packet's destination [RFC-1883]. 608 Opt Data Len 1 - the data portion of the Option is one byte 609 long. 611 Tun Encap Lim the Tunnel Encapsulation Limit - 8-bit unsigned 612 integer (u_8int). 614 To avoid excessive recursive encapsulation, an IPv6 tunnel entry 615 point node may prepend, as part of the IPv6 tunnel headers, a "Tunnel 616 Encapsulation Limit - Destination Extension Header" - with the "Tun 617 Encap Lim - tunnel encapsulation limit" - field set to: 619 (a) a pre-configured value - if the packet has no previous 620 "Tunnel Encapsulation Limit" header - see section 6.6. 622 (b) a value resulting from a pre-existent value - if the packet 623 has a "Tunnel Encapsulation Limit" header, the value is 624 copied into the newly prepended "Tunnel Encapsulation 625 Limit" header and then decremented by one. 627 This is an exception from the rule of processing 628 destination extension headers, in that although the entry 629 point node is not a destination node, during the 630 encapsulation of a packet, the IPv6 tunneling protocol 631 engine looks ahead in the extant tunnel headers of that 632 packet for the "Tunnel Encapsulation Limit" destination 633 option header. 635 If the Tunnel Encapsulation Limit is decremented to zero, 636 the packet undergoing encapsulation is discarded. Upon 637 discarding the packet, a Parameter Problem ICMP message 638 [RFC-1885] is returned to the packet originator - the 639 Parameter Problem ICMP message points into the Tunnel 640 Encapsulation Limit destination header of the packet, to 641 the Tun Encap Lim field, which has the value one. 643 Two cases of recursive encapsulation that should be avoided are 644 described below: 646 4.1.2 Loopback Recursive Encapsulation 648 A particular case of recursive encapsulation which must be avoided is 649 the loopback recursive encapsulation. Loopback recursive 650 encapsulation takes place when a tunnel IPv6 entry point node 651 encapsulates tunnel IPv6 packets originated from itself, and destined 652 to itself. This may generate an infinite processing loop in the 653 entry point node. 655 To avoid such an infinite processing loop in the tunnel entry point 656 node IPv6 protocol engine, the tunneling engine should not 657 encapsulate packets that have the pair of tunnel entry point and 658 exit-point addresses the same as the pair of original packet source 659 address and final destination address. To avoid the additional 660 processing in the tunneling protocol engine that the above validation 661 mechanism would require, it is recommended that the validation be 662 done at tunnel configuration time: a node should not permit 663 configuring tunnels that the pair of tunnel entry point and exit- 664 point addresses are identical with the pair of original packet source 665 address and final destination address, and both the entry point node 666 and exit-point node addresses belong to the entry point node. 668 4.1.3 Routing Loop Recursive Encapsulation 670 In case of a packet path involving multiple levels of inner tunnels, 671 a routing loop from an inner tunnel to an outer tunnel is 672 particularly dangerous when the loop is such that a tunnel IPv6 673 packet encapsulated at a certain tunnel entry point node reaches 674 again that tunnel entry point node before reaching that tunnel exit- 675 point node. 677 Because there is no relationship between the tunnel IPv6 header hop 678 limit and the original packet hop limit, a tunnel packet reaching its 679 originator - a tunnel entry point - in a routing loop may expire only 680 after an excessively large number of encapsulations. 682 Additionally, in such a routing loop case, because the prepending of 683 the tunnel IPv6 headers adds to the size of the packets, a tunnel 684 packet may grow to the maximum packet size limit [RFC-1883], 685 resulting in tunnel packet fragmentation, and fragment 686 multiplication. 688 When the path of a packet from source to final destination includes 689 tunnels, the maximum number of hops that the packet can traverse is 690 controlled by two mechanisms that are used together to avoid the 691 negative effects of routing loops in tunnels: 693 (a) the original IPv6 packet hop limit, at each forwarding 694 operation performed on the original packet, including at 695 the points where it is encapsulated and decapsulated. 697 (b) the tunnel IPv6 packet encapsulation limit, at each 698 recursive encapsulation of the packet. 700 4.1.4 Risk Factors in Recursive Encapsulation 702 The cases which present a high risk of excessive recursive 703 encapsulation are those in which a tunnel entry point node cannot 704 discern between a valid and an invalid recursive encapsulation. 705 Routing loops that cause tunnel packets reach nodes that were already 706 reached before are certainly the major cause of the problem. But 707 since routing loops exist, and happen, it is important to understand 708 and describe, the cases in which the risk for excessive recursive 709 encapsulation is higher. 711 There are two significant elements that determine the risk factor of 712 routing loop excessive recursive encapsulation: 714 (a) the type of tunnel, 716 (b) the type of route to the tunnel exit-point, which 717 determines the packet forwarding through the tunnel, i.e. 718 over the tunnel virtual-link. 720 The type of tunnels which were identified as a high risk factor of 721 excessive recursive encapsulation in routing loops are: 723 "inner tunnels with identical exit-points". 725 These tunnels can be: 727 "fixed-end inner tunnels with different entry-points", 729 or: 731 "free-end inner tunnels with different entry-points" 733 Note that free-end inner tunnels fall always into the category of 734 identical exit-point tunnels. 736 Since the source and destination of an original packet is the main 737 information used to decide whether to forward a packet through a 738 tunnel or not, an excessive recursive encapsulation can be avoided in 739 case of a single tunnel (non-inner), by checking that the packet to 740 be encapsulated was not originated by the entry point node. This 741 mechanism is suggested in [IPv4TUN]. 743 However, this type of protection does not seem to work well in case 744 of inner tunnels with different entry-points, and identical exit- 745 points - see Appendix A. 747 Inner tunnels with different entry-points, and identical exit-points 748 introduce ambiguity in deciding whether to encapsulate or not a 749 packet, when a packet encapsulated in an inner tunnel reaches the 750 entry point node of an outer tunnel by means of a routing loop. 751 Because the source of the tunnel packet is the inner tunnel entry 752 point node which is different than the entry point node of the outer 753 tunnel, the source address checking fails to detect an invalid 754 encapsulation, and as consequence the tunnel packet gets encapsulated 755 at the outer tunnel, each time it reaches it through the routing 756 loop. 758 The type of route to a tunnel exit-point node has been also 759 identified as a high risk factor of excessive recursive encapsulation 760 in routing loops. 762 One type of route to a tunnel exit-point node is a route to a 763 specified destination node, i.e. the destination is a valid specified 764 IPv6 address (route to node). Such a route can be selected based on 765 the longest path match of an original packet destination address with 766 the destination address stored in the tunnel entry point node routing 767 table entry for that route. The packet forwarded on such a route is 768 first encapsulated and then forwarded towards the tunnel exit-point 769 node. 771 Another type of route to a tunnel exit-point node is a route to a 772 specified prefix-net, i.e. the destination is a valid specified IPv6 773 prefix (route to net). Such a route can be selected based on the 774 longest path match of an original packet destination address with the 775 prefix destination stored in the tunnel entry point node routing 776 table entry for that route. The packet forwarded on such a route is 777 first encapsulated and then forwarded towards the tunnel exit-point 778 node. 780 And finally another type of route to a tunnel exit-point is a default 781 route, or a route to an unspecified destination, i.e. the destination 782 is the "unspecified" IPv6 address. This route is selected when no- 783 other match for the destination of the original packet has been found 784 in the routing table. A tunnel that is the virtual-link of a default 785 route, i.e. the link to a default router, is a "default tunnel". 787 If the route to a tunnel exit-point is a route to node, the risk 788 factor for excessive recursive encapsulation is minimum. 790 If the route to a tunnel exit-point is a route to net, the risk 791 factor for excessive recursive encapsulation is medium. There is a 792 range of destination addresses that will match the prefix the route 793 is associated with. If one or more inner tunnels with different 794 tunnel entry-points have exit-point node addresses that match the 795 route to net of an outer tunnel exit-point, then an excessive 796 recursive encapsulation may occur if a tunnel packet gets diverted 797 from inside such an inner tunnel to the entry point of the outer 798 tunnel that has a route to its exit-point that matches the exit-point 799 of an inner tunnel. 801 If the route to a tunnel exit-point is a default route, the risk 802 factor for excessive recursive encapsulation is maximum. Packets are 803 forwarded through a default tunnel for lack of a better route. In 804 many situations, forwarding through a default tunnel can happen for a 805 wide range of destination addresses which at the maximum extent is 806 the entire Internet minus the node's link. As consequence, it is 807 likely that in a routing loop case, if a tunnel packet gets diverted 808 from an inner tunnel to an outer tunnel entry point in which the 809 tunnel is a default tunnel, the packet will be once more 810 encapsulated, because the default routing mechanism will not be able 811 to discern differently, based on the destination - see Appendix B. 813 5. Tunnel IPv6 Header 815 The tunnel entry point node fills out a tunnel IPv6 main header 816 [RFC-1883] as follows: 818 Version: 820 6 822 Priority: 824 Depending on the entry point node tunnel configuration, the 825 priority may be set to that of the original packet, or to a 826 pre-configured value - see section 6.3. 828 Flow label: 830 Depending on the entry point node tunnel configuration, the 831 flow label may be set to a pre-configured value. The typical 832 value is zero - see section 6.4. 834 Payload Length: 836 The original packet length. 838 In case the packet is prepended with tunnel IPv6 extension 839 headers, this value is set to the original packet length 840 plus the length of the encapsulating IPv6 extension headers. 842 Next header: 844 The next header value according to [RFC-1883] from the 845 Assigned Numbers RFC [RFC-1700]. 847 For example, if the original packet is an IPv6 packet, and 848 there are no intermediate headers, the next header protocol 849 value is set to 41 (Assigned payload type number for IPv6). 851 If a hop by hop option header is immediately following the 852 tunnel IPv6 header, then the next header protocol value in 853 this field is set to 0 (Assigned payload type number for 854 IPv6 Hop by Hop Options header). 856 If a Tunnel Encapsulation Limit destination option header is 857 immediately following the tunnel IPv6 header, then the next 858 header protocol value in this field is set to 60 (Assigned 859 payload type number for IPv6 Destination Options header). 861 Hop limit: 863 The tunnel IPv6 header hop limit is set to a pre-configured 864 value - see Section 6.3. 866 The default value for hosts is the neighbor discovery 867 advertised hop limit [IPv6ND]. The default value for routers 868 is the default IPv6 Hop Limit [TBD] value from the Assigned 869 Numbers RFC. 871 Source Address: 873 IPv6 address of the outgoing interface of the tunnel entry 874 point node. This address is configured as entry point node 875 address - see section 6.1. 877 Destination Address: 879 IPv6 address of the tunnel exit-point node. If the tunnel 880 is configured with an unspecified exit-point node address, 881 then the IPv6 address of the destination from the original 882 IPv6 header - see section 6.2. 884 5.1 Tunnel IPv6 Extension Headers 886 Depending on various IPv6 node configuration parameters a tunnel 887 entry point node may append to the tunnel IPv6 main header, one or 888 more IPv6 extension headers that are not directly related to 889 tunneling, such as hop by hop, routing,...etc, and therefore they are 890 not discussed here. 892 To limit the number of recursive encapsulations of a packet, if it 893 was configured to do so - see section 6.6 - a tunnel entry point 894 appends after the tunnel IPv6 main header, or after the hop by hop 895 extension header, if any, a Tunnel Encapsulation Limit destination 896 option header with fields set as follows: 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Next Header |Hdr Ext Len = 0| Opt Type = 4 |Opt Data Len=1 | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 | 0 | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 Next Header: 905 Identifies the type of header immediately following the 906 Tunnel Encapsulation Limit destination option header [RFC- 907 1883]. 909 If the original packet is an IPv6 packet, and there are no 910 intermediate headers, the next header protocol value is set 911 to 41 (Assigned payload type number for IPv6). 913 Hdr Ext Len: 915 Length of the Tunnel Encapsulation Limit destination option 916 header in 8-octet units, not including the first 8 octets. 917 Set to value 0. 919 Option Type: 921 4 - see 4.1.1. 923 Opt Data Len: 925 1 - see 4.1.1. 927 Tun Encap Lim: 929 8 bit unsigned integer - see 4.1.1. 931 Option Type: 933 1 - PadN option, to align the header following this header. 935 Opt Data Len: 937 1 - one octet of option data. 939 Option Data: 941 One zero-valued octet. 943 6. IPv6 Tunnel State Variables 945 The IPv6 tunnel state variables, some of which are or may be 946 configured, are: 948 (a) the tunnel entry point node address - is configured 950 (b) the tunnel exit-point node address - is configured 952 (c) the tunnel hop limit - is configured 954 (d) the tunnel packet priority - is configured 956 (e) the tunnel packet flow label - is configured 958 (f) the tunnel encapsulation limit - may be configured 960 (g) the tunnel MTU 962 6.1 IPv6 Tunnel Entry Point Node Address 964 The tunnel entry point node address is one of the valid IPv6 unicast 965 addresses belonging to the entry point node - the validation of the 966 address at tunnel configuration time is recommended. 968 The tunnel entry point node address is copied to the source address 969 field in the tunnel IPv6 header during packet encapsulation. 971 6.2 IPv6 Tunnel Exit-Point Node Address 973 The tunnel exit-point node address is used as the IPv6 destination 974 address for the tunnel IPv6 header. The tunnel exit-point node 975 address may be configured with a specific IPv6 address, in which case 976 the tunnel acts like a virtual point to point link between the entry 977 point node and exit-point node, or with the Unspecified IPv6 address 978 [RFC-1884], in which case the tunnel acts like a virtual point to 979 point link between the entry point node and an exit-point node 980 identified by the destination address from the original packet 981 header. 983 The tunnel exit-point node address is copied to the destination 984 address field in the tunnel IPv6 header during packet encapsulation. 986 6.3 IPv6 Tunnel Hop Limit 988 An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in 989 which regardless of the number of hops in the IPv6 tunnel, the 990 original packet's passing through the tunnel is like the original 991 packet's passing over a one hop link. 993 The "single-hop" mechanism should be implemented by having the tunnel 994 entry point node set a tunnel IPv6 header hop limit independently of 995 the original headers. 997 The "single-hop" mechanism hides to the original IPv6 packets the 998 IPv6 topology of the tunnel. 1000 The tunnel hop limit is configured into the tunnel entry point node 1001 with a value that: 1003 (a) ensures that tunnel IPv6 packets reach the tunnel exit- 1004 point node 1006 (b) ensures a quick expiration of the tunnel packet if a 1007 routing loop occurs within the IPv6 tunnel. 1009 The tunnel hop limit default value for hosts is the neighbor 1010 discovery advertised hop limit [IPv6ND]. The tunnel hop limit default 1011 value for routers is the default IPv6 Hop Limit [TBD] value from the 1012 Assigned Numbers RFC. 1014 The tunnel hop limit is copied into the hop limit field of the tunnel 1015 IPv6 header of each packet encapsulated by the tunnel entry point 1016 node. 1018 6.4 IPv6 Tunnel Packet Priority 1020 The IPv6 Tunnel Packet Priority indicates the value that a tunnel 1021 entry point node sets in the priority field of a tunnel header. The 1022 default value is zero. The Packet Priority may also indicate whether 1023 the value of the priority field in the tunnel header is copied from 1024 the original header, or it is set to the configured value. 1026 6.5 IPv6 Tunnel Flow Label 1028 The IPv6 Tunnel Flow Label indicates the value that a tunnel entry 1029 point node sets in the flow label of a tunnel header. The default 1030 value is zero. 1032 6.6 IPv6 Tunnel Encapsulation Limit 1034 The IPv6 Tunnel Encapsulation Limit may be configured in an entry 1035 point node as the maximum number of encapsulations permitted for 1036 original packets entering the tunnel at that entry point node. 1037 Recommended default value is 5. 1039 An entry point node configured to limit the number of encapsulations, 1040 prepends a Tunnel Encapsulation Limit Destination header to an 1041 original packet undergoing encapsulation - see section 5.1. 1043 6.7 IPv6 Tunnel MTU 1045 The tunnel MTU is set dynamically to the Path MTU of the tunnel - the 1046 maximum size of a packet that can be sent through the tunnel without 1047 fragmentation - see [RFC-1883]. The tunnel entry point node performs 1048 Path MTU discovery on the tunnel [IPv6PMTU], [RFC-1885]. 1050 Although it should be able to send a tunnel IPv6 packet of any valid 1051 size, a tunnel entry point node attempts to avoid the fragmentation 1052 of tunnel packets, by informing source nodes of original packets the 1053 MTU to be used in sizing original packets sent towards that tunnel 1054 entry point node. 1056 7. IPv6 Tunnel Packet Fragmentation 1058 Although the fragmentation of tunnel packets depends on the protocol 1059 of the original packet, the primary condition for fragmentation is 1060 the size of the original packet. 1062 A tunnel IPv6 packet resulting from the encapsulation of an original 1063 packet is considered an IPv6 packet originating from the tunnel entry 1064 point node, therefore like any IPv6 packet source node, a tunnel 1065 entry point node must support fragmentation of tunnel packets. 1067 A node inside the tunnel, that forwards a tunnel packet to another 1068 node in the tunnel, follows the general IPv6 rule that it must not 1069 fragment a packet undergoing forwarding. 1071 Depending on the tunnel packet protocol, the following fragmentation 1072 can take place: 1074 7.1 IPv6 Packet Fragmentation 1076 The fragmentation of tunnel packets containing IPv6 original packets 1077 is performed as follows: 1079 (a) if the original packet size is larger than 576 octets, then 1080 the entry point node returns an ICMPv6 "Packet Too Big" 1081 message to the source node of the original packet 1082 indicating the MTU size to be used by that node in sizing 1083 original packets sent towards the tunnel entry point. The 1084 MTU is the original packet size minus the size of the 1085 tunnel headers - see 8.2, and 8.3. 1087 (b) if the original packet is equal or smaller than 576 octets 1088 then the tunnel entry point node encapsulates the original 1089 packet, and after encapsulation it breaks the resulting 1090 IPv6 tunnel packet into IPv6 fragments that do not exceed 1091 the tunnel MTU. 1093 7.2 IPv4 Packet Fragmentation 1095 Although the fragmentation of tunnel packets depends on the protocol 1096 of the original packet, the primary condition for fragmentation is 1097 the size of the original packet: 1099 (a) if the original packet size is larger than 576 octets, and 1100 the Don't Fragment - DF - bit in the IPv4 header is set 1101 then the entry point node returns an ICMP message with type 1102 = "unreachable", code = "datagram too big", and the MTU 1103 size to be used by the original node in sizing original 1104 packets sent towards the tunnel entry point, which is the 1105 original packet MTU minus the size of the tunnel headers - 1106 see 8.2, and 8.3. 1108 (b) if the original packet is equal or smaller than 576 octets 1109 then the tunnel entry point node encapsulates the original 1110 packet, and after encapsulation it breaks the resulting 1111 IPv6 tunnel packet into IPv6 fragments that do not exceed 1112 the tunnel MTU. 1114 8. IPv6 Tunnel Error Processing and Reporting 1116 IPv6 Tunneling follows the general rule that errors detected during 1117 the processing of IPv6 packets are reported to the packet originator 1118 through ICMP messages. 1120 For errors detected by nodes that are outside an IPv6 tunnel, on a 1121 path that includes IPv6 tunnels, the errors are reported to the 1122 original IPv6 packet source node. 1124 For errors detected by nodes inside an IPv6 tunnel, ICMP error 1125 messages are sent to the tunnel IPv6 packet source node, which is the 1126 IPv6 tunnel entry point node. The ICMP messages sent to the tunnel 1127 entry point node have as ICMP payload the tunnel IPv6 packet that 1128 includes the original packet. 1130 The cause of an error uncovered inside a tunnel can be: 1132 (a) the tunnel header, or 1134 (b) the tunnel packet. 1136 The tunnel header problems are reported to the tunnel entry point 1137 node which is the tunnel IPv6 packet originator. 1139 The tunnel packet problems that result from bad encapsulation, are 1140 reported also to the tunnel entry point node. 1142 If the tunnel packet problems are a consequence of an original packet 1143 problem and if they can be corrected by the source of the original 1144 packet, then they must be reported to both the tunnel entry point 1145 node and the source of the original packet. 1147 To report to the source of original packet a problem detected inside 1148 the tunnel and reported from inside the tunnel through an ICMP 1149 message, the tunnel entry point node must relay the ICMP message to 1150 the source of original IPv6 packet. To relay the ICMP message, the 1151 IPv6 tunnel entry point node builds and sends an ICMP message to the 1152 original packet originator, based on the tunnel ICMP message, as it 1153 is graphically described below: 1155 +-------+ +-------+ +-----------------------+ 1156 | Upper | | Upper | | Upper | 1157 | Layer | | Layer | | Layer | 1158 | Prot. | | Prot. | | IPv6 Tunnel | 1159 | Error | | Error | | Error | 1160 | Input | | Input | | Input | 1161 | | | | | Decapsulate | 1162 | | | | | -->--ICMPv6--#2->-- | 1163 | | | | | | Payload | | 1164 +-------+ +-------+ +--|-----------------|--+ 1165 | | | | 1166 ^ ^ ^ v 1167 | | | | 1168 --------------------#1-- -----Orig.Packet?--- - - - - - - - - - 1169 error code, | #3 error code, | | 1170 ICMPv6 payload ^ v source address, v v 1171 | IPv6 | orig. packet | IPv4 | 1172 +--------------+ +--------------+ +--------------+ + - - - - + 1173 | | | | | | 1174 | ICMP v6 | | ICMP v6 | | ICMP v4 | | | 1175 | Input | | Error Report | | Error Report | 1176 | - - - - +----+ - - - - | + - - - - + + - - - - + 1177 | | | | 1178 | IPv6 Layer | | IPv4 Layer | | | 1179 | | | | 1180 +----------------------------------+ +--------------+ + - - - - + 1182 Fig. 7. Error Reporting Flow - IPv6 Tunneling Protocol Engine 1184 For example, in case of IPv6 original packets, the tunnel entry point 1185 node IPv6 layer passes the received ICMP message to the ICMPv6 Input. 1186 The ICMPv6 Input, based on the ICMP type and code [RFC-1885] 1187 generates an internal "error code" which is passed with the "ICMPv6 1188 message payload" to the upper layer protocol - in this case the IPv6 1189 tunnel upper layer - error input (path #1 in Fig. 7, and (a) in Fig. 1190 8). 1192 The IPv6 tunnel error input decapsulates the tunnel IPv6 packet, 1193 which is the ICMPv6 message payload, obtaining the original packet, 1194 and thus the original headers - path #2 in Fig. 7 and (b) in Fig. 8 - 1195 and dispatches the "error code", the source address from the original 1196 packet header, and the original packet, down to the error report 1197 block of the protocol identified by the Next Header field in the 1198 tunnel header immediately preceding the original packet in the ICMP 1199 message payload - in this example ICMPv6. The ICMPv6 error report 1200 builds an ICMP message of a type and code according to the "error 1201 code", containing the "original packet" as ICMP payload - - path #3 1202 in Fig. 7 and (c) in Fig. 8. The ICMP message has the tunnel entry 1203 point node address as source address, and the original packet source 1204 node address as destination address - (d) in Fig. 8. The tunnel 1205 entry point node sends the ICMP message to the original packet 1206 originator node. 1208 A graphical description of the header processing taking place is the 1209 following: 1211 < Tunnel packet > 1212 +--------+- - - - - -+--------+------------------------------//------+ 1213 | IPv6 | IPv6 | ICMP | Tunnel | 1214 (a)| | Extension | | IPv6 | 1215 | Header | Headers | Header | Packet in error | 1216 +--------+- - - - - -+--------+------------------------------//------+ 1217 < Tunnel headers > < Tunnel ICMP message > 1218 < ICMPv6 message payload > 1219 | 1220 v 1221 < Tunnel ICMP message > 1222 < Tunnel IPv6 packet in error > 1223 +--------+ +---------+ +----------+--------//------+ 1224 | ICMP | | Tunnel | | Original | Original | 1225 (b) | | <- | IPv6 | <- | IPv6 | IPv6 packet | 1226 | Header | | Headers | | Headers | payload | 1227 +--------+ +---------+ +----------+--------//------+ 1228 | | 1229 ----------------- | | 1230 ----------|--------------- 1231 | | 1232 V V 1233 +---------+ +--------+ +-------------------//------+ 1234 | New | | ICMP | | | 1235 (c) | IPv6 | -> | | -> | Orig. IPv6 packet in error| 1236 | Headers | | Header | | | 1237 +---------+ +--------+ +-------------------//------+ 1239 | 1240 v 1241 +---------+--------+-------------------//------+ 1242 | New | ICMP | Original | 1243 (d) | IPv6 | | IPv6 | 1244 | Headers | Header | packet in error | 1245 +---------+--------+-------------------//------+ 1246 < new ICMP message > 1248 Fig. 8. ICMP Error reporting and processing 1250 8.1 Tunnel ICMP Messages 1252 The tunnel ICMP messages which are reported to the original packet 1253 originator are: 1255 hop limit exceeded 1257 The tunnel has a misconfigured hop limit, or contains a 1258 routing loop, and packets do not reach the tunnel exit- 1259 point node. This problem is reported to the tunnel entry 1260 point node - the tunnel hop limit must be reconfigured to a 1261 higher value - and also to the original IPv6 packet 1262 originator. 1264 unreachable node 1266 One of the nodes in the tunnel is not or is no longer 1267 reachable. This problem is reported to the tunnel entry 1268 point node, which should reconfigure the tunnel with a 1269 valid and active path between the entry and exit-point of 1270 the tunnel. 1272 parameter problem 1274 A Parameter Problem ICMP message pointing to a valid Tunnel 1275 Encapsulation Limit Destination header with a Tun Encap Lim 1276 field value set to one is an indication that the tunnel 1277 packet exceeded the maximum number of encapsulations 1278 allowed. 1280 The three above problems detected inside the tunnel, which are a 1281 tunnel configuration and a tunnel topology problem, are reported to 1282 the original IPv6 packet originator, as a tunnel generic 1283 "unreachable" problem caused by a "link problem" - see section 8.2 1284 and 8.3. 1286 packet too big 1288 The tunnel packet exceeds the tunnel Path MTU. 1290 When received, this ICMP message is used by the tunnel 1291 entry point node to determine the tunnel MTU. 1293 When sent, according to the general rules described in 1294 section 7.1, this ICMP message is used by the tunnel entry 1295 point node to indicate to an original packet source node 1296 that original packets sent from that node to the tunnel 1297 entry point node should be resized to the MTU indicated by 1298 the ICMP message. 1300 8.2 ICMP Messages for IPv6 Original Packets 1302 The tunnel entry point node builds the ICMP and IPv6 headers of the 1303 ICMP message that is sent to the original packet source node as 1304 follows: 1306 IPv6 Fields: 1308 Source Address 1310 A valid unicast IPv6 address of the outgoing interface. 1312 Destination Address 1314 Copied from the Source Address field of the Original 1315 IPv6 header. 1317 ICMP Fields: 1319 For any of the following tunnel ICMP error messages: 1321 hop limit exceeded 1323 unreachable node 1325 parameter problem 1327 pointing to a valid Tunnel Encapsulation Limit destination 1328 header with the Tun Encap Lim field set to a value one: 1330 Type 1 - unreachable node 1332 Code 3 - address unreachable 1334 For tunnel ICMP error message "packet too big": 1336 Type 2 - packet too big 1338 Code 0 1340 MTU The MTU field from the tunnel ICMP message minus 1341 the length of the tunnel headers. 1343 According to the general rules described in 6.3, an ICMP "packet too 1344 big" message is sent to the original packet source node only if the 1345 original packet size is larger than 576 octets. 1347 If the original packet size is smaller or equal to 576 octets the 1348 tunnel entry point encapsulates the original IPv6 packet and then 1349 breaks the resulting IPv6 tunnel packet into IPv6 fragments that do 1350 not exceed the tunnel MTU. 1352 8.3 ICMP Messages for IPv4 Original Packets 1354 The tunnel entry point node builds the ICMP and IPv4 header of the 1355 ICMP message that is sent to the original packet source node as 1356 follows: 1358 IPv4 Fields: 1360 Source Address 1362 A valid unicast IPv4 address of the outgoing interface. 1364 Destination Address 1366 Copied from the Source Address field of the Original 1367 IPv4 header. 1369 ICMP Fields: 1371 For any of the following tunnel ICMP error messages: 1373 hop limit exceeded 1375 unreachable node 1377 parameter problem 1379 pointing to a valid Tunnel Enacpsulation Limit destination 1380 header with the Tun Encap Lim field set to a value one: 1382 Type 3 - destination unreachable 1384 Code 1 - host unreachable 1386 For a tunnel ICMP error message "packet too big": 1388 Type 3 - destination unreachable 1390 Code 4 - datagram too big 1392 MTU The MTU field from the tunnel ICMP message minus 1393 the length of the tunnel headers. 1395 According to the general rules described in 7.2, an ICMP "datagram 1396 too big" message is sent to the original IPv4 packet source node only 1397 if the original packet size is larger than 576 octets. 1399 An additionally condition that has to be met for sending the ICMP 1400 message is that the original IPv4 packet header must have the DF - 1401 don't fragment - bit flag set in the IPv6 original header. 1403 If the DF bit is clear, the tunnel entry point encapsulates the 1404 original IPv4 packet and then breaks the resulting IPv6 tunnel packet 1405 into IPv6 fragments that do not exceed the tunnel MTU. 1407 9. Open Issues 1409 Open issues are: 1411 (a) Multicast exit point 1413 Does it make sense to have an IPv6 multicast address as tunnel 1414 exit-point node address? 1416 (b) Anycast exit point 1418 Does it make sense to have an IPv6 anycast address as tunnel 1419 exit-point node address? 1421 (c) Tunnel default hop limit value 1423 At this time, there is no definition for an IPv6 hop limit 1424 default value. The Assigned Numbers [RFC-1700] IPv4 TTL default 1425 value could be used instead. 1427 10.References 1429 [RFC-1883] 1430 S. Deering, R. Hinden, "Internet Protocol Version 6 1431 Specification" 1433 [RFC-1884] 1434 S. Deering, R. Hinden, "IP Version 6 Addressing Architecture". 1436 [RFC-1885] 1437 A. Conta, and S. Deering "Internet Control Message Protocol for 1438 the Internet Protocol Version 6 (IPv6)" 1440 [IPv6ND] 1441 T. Narten, E. Nordmark, "IPv6 Neighbor Discovery Specification" 1443 [IPv6PMTU] 1444 J. McCann and S. Deering, "IPv6 Path MTU Discovery" 1446 [ADDRCONF] 1447 T. Narten, and S. Thomson, "IPv6 Address Autoconfiguration" 1449 [IPv6PMTU] 1450 J. McCann and S. Deering, "IPv6 Path MTU Discovery" 1452 [RFC-1700] 1453 J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994 1455 [RFC-1853] 1456 W. Simpson, "IPv4 Tunneling", 1458 11.Acknowledgements 1460 The document is partially derived from several ideas about tunneling, 1461 from several discussions about IPv6 in IPv6 tunneling on the IPng 1462 Working Group Mailing List, and from feedback from an IPv6 tunneling 1463 focused IPng Working Group session at the 33th IETF, in Stockholm, 1464 July 1995. 1466 Additionally, several documents focused on tunneling or encapsulation 1467 were used as a reference: "Transition Mechanisms for IPv6 Hosts and 1468 Routers" document by Robert Gilligan and Erik Nordmark, RFC 1241 (R. 1469 Woodburn, and D. Mills), RFC 1326 (P. Tsuchiya), RFC 1701, and RFC 1470 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1834 (W. Simpson), and 1471 Mobile IP working Group drafts (C. Perkins). 1473 Also an important contribution was made by the reviewers of this 1474 document: 1476 Brian Carpenter, Erik Nordmark. [TBD] 1478 12.Security Considerations 1480 Security considerations are not discussed in this memo. 1482 Authors' Addresses: 1484 Alex Conta Stephen Deering 1485 Digital Equipment Corporation Xerox Palo Alto Research Center 1486 110 Spitbrook Rd 3333 Coyote Hill Road 1487 Nashua, NH 03062 Palo Alto, CA 94304 1488 +1-603-881-0744 +1-415-812-4839 1490 email: conta@zk3.dec.com email: deering@parc.xerox.com 1492 Appendix A 1494 Fixed-end Inner tunnels with different entry-points and 1495 identical exit-points 1496 node node node node node node node 1498 a.a.1 b.b.1 c.c.1 ... x ... y ... d.d.1 z.z.1 1499 * ** * ** 1501 tunnel I from b.b.1 to z.z.1 1502 tunnel II from c.c.1 to z.z.1 1504 1. node a.a.1: 1506 xmt: aa1/zz1 (source=aa1 destination=zz1) 1507 to bb1 1509 2. node b.b.1: 1511 rcv: aa1/zz1 1513 forwarding: anything that is destined to prefix 'z' => tunnel 'bb1/z 1514 z1' 1515 and send to cc1 1517 xmt: bb1/zz1 | aa1/zz1 1518 to cc1 1520 3. node cc1: 1522 rcv: bb1/zz1 | aa1/zz1 1524 forwarding: anything that is destined to prefix 'z' => tunnel 'cc1/z 1525 z1' 1526 and send to next router on the way to dd1 1528 xmt: cc1/zz1 | bb1/zz1 | aa1/zz1 1529 to next router on the way to dd1 1531 4. before reaching node dd1, routing loop brings packet to bb1 1533 loop:: 1534 node bb1: 1536 rcv: cc1/zz1 | bb1/zz1 | aa1/zz1 1538 forwarding: anything that is destined to prefix 'z' => tunnel 'bb1/ 1539 zz1' 1540 and send to cc1 1542 xmt: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 1543 to cc1 1545 5. node cc1: 1547 rcv: bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 1549 forwarding: anything that is destined to prefix 'z' => tunnel 'cc1/ 1550 zz1' 1552 xmt: cc1/zz1 | bb1/zz1 | cc1/zz1 | bb1/zz1 | aa1/zz1 1553 to next router on the way to dd1 1555 NOTE: check on source address = packet source DOES NOT eliminate the recursi 1556 ve 1557 encapsulation 1559 Appendix B 1561 Default Tunnel - maximum risk for excessive recursive 1562 encapsulation in case of routing loops. 1564 node node node node node node node 1566 a.a.1 b.b.1 c.c.1 d.d.1 e.e.1 f.f.1 z.z.1 1567 * ** ** * 1569 tunnel I from b.b.1 to f.f.1 1570 tunnel II from c.c.1 to e.e.1 1572 1. node aa1: 1574 xmt: aa1/zz1 (source=aa1 destination=zz1) 1576 2. node bb1: 1578 rcv: aa1/zz1 1580 forwarding: 1581 anything that does not go to prefix 'a' or 'c' 1582 => tunnel 'bb1/ff1' and send to cc1 1584 xmt: bb1/ff1 | aa1/zz1 1586 3. node cc1: 1588 rcv: bb1/ff1 | aa1/zz1 1590 forwarding: anything that does not go to prefix 'a', or 'b', or 'd' 1591 => tunnel 'cc1/ee1' and send to next router on 1592 the way to ee1 1594 xmt: cc1/ee1 | bb1/ff1 | aa1/zz1 1595 to next router on the way to ee1 1597 4. before reaching node ee1, routing loop brings packet to bb1 1599 loop:: 1600 node bb1: 1602 rcv: cc1/ee1 | bb1/ff1 | aa1/zz1 1604 forwarding: 1605 anything that does not go to prefix 'a' or 'c' 1606 => tunnel 'bb1/ff1' and send to cc1 1608 xmt: bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 1609 to cc1 1611 5. node cc1: 1613 rcv: bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 1615 forwarding: anything that does not go to prefix 'a', or 'b', or 'd' 1616 => tunnel 'cc1/ee1' 1618 xmt: cc1/ee1 | bb1/ff1 | cc1/ee1 | bb1/ff1 | aa1/zz1 1620 NOTE: check on source address = packet source DOES NOT eliminate the recursi 1621 ve 1622 encapsulation 1624 Changes from previous version. 1626 - add new sections: 1628 3.4 IPv6 Tunnels and Address Formats........................13 1629 3.5 IPv6 Tunnels and IPv6 Autoconfiguration.................13 1630 3.6 IPv6 Tunnels and IPv6 Neighbor Discovery................13 1631 4.1.4 Risk Factors in Recursive Encapsulation..............17 1632 Appendix A..Inner tunnels...................................35 1633 Appendix B..Default tunnels.................................37 1635 - separate fragmentation from section 6.7 into a new 1636 section: 1638 7. IPv6 Tunnel Packet Fragmentation.........................25 1639 7.1 IPv6 Packet Fragmentation...........................25 1640 7.2 IPv4 Packet Fragmentation...........................26 1642 - include comments from Erik Nordmark 1644 - some of the comments are part of the modifications 1645 mentioned above. 1647 - Section 5: flow label 1648 "tipical" corrected to "typical". 1650 - Section 6.2: 1651 changed from multi-point to point-to-point 1653 - section 8.1 1654 replace "original packet originator" with 1655 "source of original packet". 1657 ------- End of Forwarded Message