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