idnits 2.17.1 draft-ietf-ipv6-tunnel-v02-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 474 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 31 instances of too long lines in the document, the longest one being 6 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 14 has weird spacing: '...ject to all ...' == Line 22 has weird spacing: '... and may be...' == Line 23 has weird spacing: '...me. It is i...' == Line 36 has weird spacing: '...nes the model...' == Line 37 has weird spacing: '...ulation of In...' == (469 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 2002) is 7950 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: 'IPSEC-ARCH' is mentioned on line 1397, but not defined == Unused Reference: 'IPSEC-Arch' is defined on line 1456, but no explicit reference was found in the text == Unused Reference: 'Assign-Nr' is defined on line 1467, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-Spec' -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMP-Spec' ** Obsolete normative reference: RFC 2461 (ref. 'ND-Spec') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 1981 (ref. 'PMTU-Spec') (Obsoleted by RFC 8201) ** Obsolete normative reference: RFC 2401 (ref. 'IPSEC-Arch') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'IPSEC-ATH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'IPSEC-ESP') (Obsoleted by RFC 4303, RFC 4305) ** Downref: Normative reference to an Informational RFC: RFC 1853 (ref. 'IP-IN-IP') ** Obsolete normative reference: RFC 1700 (ref. 'Assign-Nr') (Obsoleted by RFC 3232) Summary: 14 errors (**), 0 flaws (~~), 13 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group A. Conta (Transwitch) 3 INTERNET-DRAFT S. Deering (Cisco) 4 July 2002 6 Generic Packet Tunneling in IPv6 8 Specification 10 draft-ietf-ipv6-tunnel-v02-00.txt 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress". 26 The list of current Internet-Drafts can be accessed at: 28 http://www.ietf.org/1id-abstracts.html 30 The list of Internet-Draft Shadow Directories can be accessed at: 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document defines the model and generic mechanisms for IPv6 37 encapsulation of Internet packets, such as IPv6 and IPv4. The model 38 and mechanisms can be applied to other protocol packets as well, such 39 as AppleTalk, IPX, CLNP, or others. 41 Table of Contents 43 1. Introduction..................................................3 44 2. Terminology...................................................3 45 3. IPv6 Tunneling................................................5 46 3.1 IPv6 Encapsulation.......................................7 47 3.2 IPv6 Packet Processing in Tunnels........................8 48 3.3 IPv6 Decapsulation.......................................8 49 3.4 IPv6 Tunnel Protocol Engine..............................9 50 4. Nested Encapsulation.........................................12 51 4.1 Limiting Nested Encapsulation..........................13 52 4.1.1 Tunnel Encapsulation Limit Option................14 53 4.1.2 Loopback Encapsulation...........................16 54 4.1.3 Routing Loop Nested Encapsulation................16 55 5. Tunnel IPv6 Header...........................................17 56 5.1 Tunnel IPv6 Extension Headers...........................19 57 6. IPv6 Tunnel State Variables..................................20 58 6.1 IPv6 Tunnel Entry-Point Node............................20 59 6.2 IPv6 Tunnel Exit-Point Node.............................21 60 6.3 IPv6 Tunnel Hop Limit...................................21 61 6.4 IPv6 Tunnel Packet Traffic Class........................22 62 6.5 IPv6 Tunnel Flow Label..................................22 63 6.6 IPv6 Tunnel Encapsulation Limit.........................22 64 6.7 IPv6 Tunnel MTU.........................................22 65 7. IPv6 Tunnel Packet Size Issues...............................23 66 7.1 IPv6 Tunnel Packet Fragmentation........................24 67 7.2 IPv4 Tunnel Packet Fragmentation........................24 68 8. IPv6 Tunnel Error Reporting and Processing...................25 69 8.1 Tunnel ICMP Messages....................................29 70 8.2 ICMP Messages for IPv6 Original Packets.................30 71 8.3 ICMP Messages for IPv4 Original Packets.................31 72 8.4 ICMP Messages for Nested Tunnel Packets.................32 73 9. Security Considerations......................................32 74 10. Acknowledgments.............................................33 75 11. References..................................................33 76 Authors' Addresses..............................................34 77 Appendix A.Risk Factors in Recursive Encapsulation..............35 78 Appendix B.Changes from previous version........................37 79 1. Introduction 81 This document specifies a method and generic mechanisms by which a 82 packet is encapsulated and carried as payload within an IPv6 packet. 83 The resulting packet is called an IPv6 tunnel packet. The forwarding 84 path between the source and destination of the tunnel packet is 85 called an IPv6 tunnel. The technique is called IPv6 tunneling. 87 A typical scenario for IPv6 tunneling is the case in which an 88 intermediate node exerts explicit routing control by specifying 89 particular forwarding paths for selected packets. This control is 90 achieved by prepending IPv6 headers to each of the selected original 91 packets. These prepended headers identify the forwarding paths. 93 In addition to the description of generic IPv6 tunneling mechanisms, 94 which is the focus of this document, specific mechanisms for 95 tunneling IPv6 and IPv4 packets are also described herein. 97 The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, 98 SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as 99 defined in [REQ-LEV]. 101 2. Terminology 103 original packet 105 a packet that undergoes encapsulation. 107 original header 109 the header of an original packet. 111 tunnel 113 a forwarding path between two nodes on which the payloads of 114 packets are original packets. 116 tunnel end-node 118 a node where a tunnel begins or ends. 120 tunnel header 122 the header prepended to the original packet during 123 encapsulation. It specifies the tunnel end-points as source and 124 destination. 126 tunnel packet 128 a packet that encapsulates an original packet. 130 tunnel entry-point 132 the tunnel end-node where an original packet is encapsulated. 134 tunnel exit-point 136 the tunnel end-node where a tunnel packet is decapsulated. 138 IPv6 tunnel 140 a tunnel configured as a virtual link between two IPv6 nodes, on 141 which the encapsulating protocol is IPv6. 143 tunnel MTU 145 the maximum size of a tunnel packet payload without requiring 146 fragmentation, that is, the Path MTU between the tunnel entry- 147 point and the tunnel exit-point nodes minus the size of the 148 tunnel header. 150 tunnel hop limit 152 the maximum number of hops that a tunnel packet can travel from 153 the tunnel entry-point to the tunnel exit-point. 155 inner tunnel 157 a tunnel that is a hop (virtual link) of another tunnel. 159 outer tunnel 161 a tunnel containing one or more inner tunnels. 163 nested tunnel packet 165 a tunnel packet that has as payload a tunnel packet. 167 nested tunnel header 169 the tunnel header of a nested tunnel packet. 171 nested encapsulation 172 encapsulation of an encapsulated packet. 174 recursive encapsulation 176 encapsulation of a packet that reenters a tunnel before exiting 177 it. 179 tunnel encapsulation limit 181 the maximum number of nested encapsulations of a packet. 183 3. IPv6 Tunneling 185 IPv6 tunneling is a technique for establishing a "virtual link" 186 between two IPv6 nodes for transmitting data packets as payloads of 187 IPv6 packets (see Fig.1). From the point of view of the two nodes, 188 this "virtual link", called an IPv6 tunnel, appears as a point to 189 point link on which IPv6 acts like a link-layer protocol. The two 190 IPv6 nodes play specific roles. One node encapsulates original 191 packets received from other nodes or from itself and forwards the 192 resulting tunnel packets through the tunnel. The other node 193 decapsulates the received tunnel packets and forwards the resulting 194 original packets towards their destinations, possibly itself. The 195 encapsulator node is called the tunnel entry-point node, and it is 196 the source of the tunnel packets. The decapsulator node is called the 197 tunnel exit-point, and it is the destination of the tunnel packets. 199 Note: 201 This document refers in particular to tunnels between two nodes 202 identified by unicast addresses - such tunnels look like "virtual 203 point to point links". The mechanisms described herein apply also to 204 tunnels in which the exit-point nodes are identified by other types 205 of addresses, such as anycast or multicast. These tunnels may look 206 like "virtual point to multipoint links". At the time of writing 207 this document, IPv6 anycast addresses are a subject of ongoing 208 specification and experimental work. 210 Tunnel from node B to node C 211 <----------------------> 212 Tunnel Tunnel 213 Entry-Point Exit-Point 214 Node Node 215 +-+ +-+ +-+ +-+ 216 |A|-->--//-->--|B|=====>=====//=====>=====|C|-->--//-->--|D| 217 +-+ +-+ +-+ +-+ 218 Original Original 219 Packet Packet 220 Source Destination 221 Node Node 223 Fig.1 Tunnel 225 An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow 226 takes place in one direction between the IPv6 tunnel entry-point and 227 exit-point nodes (see Fig.1). 229 Tunnel from Node B to Node C 230 <------------------------> 231 Tunnel Tunnel 232 Original Entry-Point Exit-Point Original 233 Packet Node Node Packet 234 Source Destination 235 Node Node 236 +-+ +-+ +-+ +-+ 237 | |-->--//-->--| |=====>=====//=====>======| |-->--//-->--| | 238 |A| |B| |C| |D| 239 | |--<--//--<--| |=====<=====//=====<======| |--<--//--<--| | 240 +-+ +-+ +-+ +-+ 241 Original Original 242 Packet Packet 243 Destination Tunnel Tunnel Source 244 Node Exit-Point Entry-Point Node 245 Node Node 246 <-------------------------> 247 Tunnel from Node C to Node B 249 Fig.2 Bi-directional Tunneling Mechanism 251 Bi-directional tunneling is achieved by merging two unidirectional 252 mechanisms, that is, configuring two tunnels, each in opposite 253 direction to the other - the entry-point node of one tunnel is the 254 exit-point node of the other tunnel (see Fig.2). 256 3.1 IPv6 Encapsulation 258 IPv6 encapsulation consists of prepending to the original packet an 259 IPv6 header and, optionally, a set of IPv6 extension headers (see 260 Fig.3), which are collectively called tunnel IPv6 headers. The 261 encapsulation takes place in an IPv6 tunnel entry-point node, as the 262 result of an original packet being forwarded onto the virtual link 263 represented by the tunnel. The original packet is processed during 264 forwarding according to the forwarding rules of the protocol of that 265 packet. For instance if the original packet is an: 267 (a) IPv6 packet, the IPv6 original header hop limit is decremented 268 by one. 270 (b) IPv4 packet, the IPv4 original header time to live field (TTL) 271 is decremented by one. 273 At encapsulation, the source field of the tunnel IPv6 header is 274 filled with an IPv6 address of the tunnel entry-point node, and the 275 destination field with an IPv6 address of the tunnel exit-point. 276 Subsequently, the tunnel packet resulting from encapsulation is sent 277 towards the tunnel exit-point node. 279 +----------------------------------//-----+ 280 | Original | | 281 | | Original Packet Payload | 282 | Header | | 283 +----------------------------------//-----+ 284 < Original Packet > 285 | 286 v 287 < Original Packet > 289 +---------+ - - - - - +-------------------------//--------------+ 290 | IPv6 | IPv6 | | 291 | | Extension | Original Packet | 292 | Header | Headers | | 293 +---------+ - - - - - +-------------------------//--------------+ 294 < Tunnel IPv6 Packet > 296 Fig.3 Encapsulating a Packet 298 Tunnel extension headers should appear in the order recommended by 299 the specifications that define the extension headers, such as [IPv6- 300 Spec]. 302 A source of original packets and a tunnel entry-point that 303 encapsulates those packets can be the same node. 305 3.2 Packet Processing in Tunnels 307 The intermediate nodes in the tunnel process the IPv6 tunnel packets 308 according to the IPv6 protocol. For example, a tunnel Hop by Hop 309 Options extension header is processed by each receiving node in the 310 tunnel; a tunnel Routing extension header identifies the intermediate 311 processing nodes, and controls at a finer granularity the forwarding 312 path of the tunnel packet through the tunnel; a tunnel Destination 313 Options extension header is processed at the tunnel exit-point node. 315 3.3 IPv6 Decapsulation 317 Decapsulation is graphically shown in Fig.4: 319 +---------+- - - - - -+----------------------------------//-----+ 320 | IPv6 | IPv6 | | 321 | | Extension | Original Packet | 322 | Header | Headers | | 323 +---------+- - - - - -+----------------------------------//-----+ 324 < Tunnel IPv6 Packet > 325 | 326 v 327 +----------------------------------//-----+ 328 | Original | | 329 | | Original Packet Payload | 330 | Headers | | 331 +----------------------------------//-----+ 332 < Original Packet > 334 Fig.4 Decapsulating a Packet 336 Upon receiving an IPv6 packet destined to an IPv6 address of a tunnel 337 exit-point node, its IPv6 protocol layer processes the tunnel 338 headers. The strict left-to-right processing rules for extension 339 headers is applied. When processing is complete, control is handed to 340 the next protocol engine, which is identified by the Next Header 341 field value in the last header processed. If this is set to a tunnel 342 protocol value, the tunnel protocol engine discards the tunnel 343 headers and passes the resulting original packet to the Internet or 344 lower layer protocol identified by that value for further processing. 345 For example, in the case the Next Header field has the IPv6 Tunnel 346 Protocol value, the resulting original packet is passed to the IPv6 347 protocol layer. 349 The tunnel exit-point node, which decapsulates the tunnel packets, 350 and the destination node, which receives the resulting original 351 packets can be the same node. 353 3.4 IPv6 Tunnel Protocol Engine 355 Packet flow (paths #1-7) through the IPv6 Tunnel Protocol Engine on a 356 node is graphically shown in Fig.5: 358 Note: 360 In Fig.5, the Upper-Layer Protocols box represents transport 361 protocols such as TCP, UDP, control protocols such as ICMP, routing 362 protocols such as OSPF, and internet or lower-layer protocol being 363 "tunneled" over IPv6, such as IPv4, IPX, etc. The Link-Layer 364 Protocols box represents Ethernet, Token Ring, FDDI, PPP, X.25, 365 Frame Relay, ATM, etc..., as well as internet layer "tunnels" such 366 as IPv4 tunnels. 368 The IPv6 tunnel protocol engine acts as both an "upper-layer" and a 369 "link-layer", each with a specific input and output as follows: 371 (u.i) "tunnel upper-layer input" - consists of tunnel IPv6 packets 372 that are going to be decapsulated. The tunnel packets are 373 incoming through the IPv6 layer from: 375 (u.i.1) a link-layer - (path #1, Fig.5) 377 These are tunnel packets destined to this node and will 378 undergo decapsulation. 380 (u.i.2) a tunnel link-layer - (path #7, Fig.5) 382 These are tunnel packets that underwent one or more 383 decapsulations on this node, that is, the packets had 384 one or more nested tunnel headers and one nested tunnel 385 header was just discarded. This node is the exit-point 386 of both an outer tunnel and one or more of its inner 387 tunnels. 389 For both above cases the resulting original packets are passed 390 back to the IPv6 layer as "tunnel link-layer" output for 391 further processing (see b.2). 393 +-----------------------+ +-----------------------------------+ 394 | Upper-Layer Protocols | | IPv6 Tunnel Upper-Layer | 395 | | | | 396 | | | ---<-------------------<------- | 397 | | | | ---->---|------>--------- | | 398 | | | | | | | | | | 399 +-----------------------+ +-----------------------+ | | | 400 | | | | | | | | | v ^ | 401 v ^ v ^ v ^ v ^ Tunnel | | | | 402 | | | | | | | | Packets| | | | 403 +---------------------------------------------+ | | | | 404 | | | | | / / | | | | D E | 405 | v ^ IPv6 | --<-3--/-/--<---- | | | | E N | 406 | | | Layer ---->-4-/-/--->-- | | | | | C C | 407 | v ^ / / | | | | | | A A | 408 | | | 2 1 | | | | | | P P | 409 | v ^ -----<---5---/-/-<---- v ^ v ^ | | S S | 410 | | | | -->---6---/-/-->-- | | | | | | | U U | 411 | v ^ | | / / 6 5 4 3 8 7 | | L L | 412 | | | | | / / | | | | | | | | A A | 413 | v ^ v ^ / / v ^ | | | | | | T T | 414 +---------------------------------------------+ | E E | 415 | | | | | | | | | | | | | | | | 416 v ^ v ^ v ^ v ^ v ^ v ^ Original| | | | 417 | | | | | | | | | | | | Packets | v ^ | 418 +-----------------------+ +-----------------------+ | | | 419 | | | | | | | | | | | | 420 | | | | ---|----|-------<-------- | | 421 | | | --->--------------->------>---- | 422 | | | | 423 | Link-Layer Protocols | | IPv6 Tunnel Link-Layer | 424 +-----------------------+ +-----------------------------------+ 426 Fig.5 Packet Flow in the IPv6 Tunneling Protocol Engine on a Node 428 (u.o) "tunnel upper-layer output" - consists of tunnel IPv6 packets that 429 are passed through the IPv6 layer down to: 431 (u.o.1) a link-layer - (path #2, Fig.5) 433 These packets underwent encapsulation and are sent towards 434 the tunnel exit-point 436 (u.o.2) a tunnel link-layer - (path #8, Fig.5) 438 These tunnel packets undergo nested encapsulation. This 439 node is the entry-point node of both an outer tunnel and 440 one or more of its inner tunnel. 442 Implementation Note: 444 The tunnel upper-layer input and output can be implemented similar to 445 the input and output of the other upper-layer protocols. 447 The tunnel link-layer input and output are as follows: 449 (l.i) "tunnel link-layer input" - consists of original IPv6 packets 450 that are going to be encapsulated. 452 The original packets are incoming through the IPv6 layer from: 454 (l.i.1) an upper-layer - (path #4, Fig.5) 456 These are original packets originating on this node 457 that undergo encapsulation. The original packet source 458 and tunnel entry-point are the same node. 460 (l.i.2) a link-layer - (path #6, Fig.5) 462 These are original packets incoming from a different 463 node that undergo encapsulation on this tunnel entry- 464 point node. 466 (l.i.3) a tunnel upper-layer - (path #8, Fig.5) 468 These packets are tunnel packets that undergo nested 469 encapsulation. This node is the entry-point node of 470 both an outer tunnel and one or more of its inner 471 tunnels. 473 The resulting tunnel packets are passed as tunnel upper-layer 474 output packets through the IPv6 layer (see u.o) down to: 476 (l.o) "tunnel link-layer output" - consists of original IPv6 packets 477 resulting from decapsulation. These packets are passed through 478 the IPv6 layer to: 480 (l.o.1) an upper-layer - (path #3, Fig.5) 482 These original packets are destined to this node. 484 (l.o.2) a link-layer - (path #5, Fig.5) 486 These original packets are destined to another node; 487 they are transmitted on a link towards their 488 destination. 490 (l.o.3) a tunnel upper-layer - (path #7, Fig.5) 492 These packets undergo another decapsulation; they were 493 nested tunnel packets. This node is both the exit- 494 point node of an outer tunnel and one or more inner 495 tunnels. 497 Implementation Note: 499 The tunnel link-layer input and output can be implemented similar 500 to the input and output of other link-layer protocols, for 501 instance, associating an interface or pseudo-interface with the 502 IPv6 tunnel. 504 The selection of the "IPv6 tunnel link" over other links results 505 from the packet forwarding decision taken based on the content of 506 the node's routing table. 508 4. Nested Encapsulation 510 Nested IPv6 encapsulation is the encapsulation of a tunnel packet. 511 It takes place when a hop of an IPv6 tunnel is a tunnel. The tunnel 512 containing a tunnel is called an outer tunnel. The tunnel contained 513 in the outer tunnel is called an inner tunnel - see Fig.6. Inner 514 tunnels and their outer tunnels are nested tunnels. 516 The entry-point node of an "inner IPv6 tunnel" receives tunnel IPv6 517 packets encapsulated by the "outer IPv6 tunnel" entry-point node. The 518 "inner tunnel entry-point node" treats the receiving tunnel packets 519 as original packets and performs encapsulation. The resulting 520 packets are "tunnel packets" for the "inner IPv6 tunnel", and "nested 521 tunnel packets" for the "outer IPv6 tunnel". 523 Outer Tunnel 524 <-------------------------------------> 525 <--links--><-virtual link-><--links---> 526 Inner Tunnel 528 Outer Tunnel Outer Tunnel 529 Entry-Point Exit-Point 530 Node Node 531 +-+ +-+ +-+ +-+ +-+ +-+ 532 | | | | | | | | | | | | 533 | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//->-| | 534 | | | | | | | | | | | | 535 +-+ +-+ +-+ +-+ +-+ +-+ 536 Original Inner Tunnel Inner Tunnel Original 537 Packet Entry-Point Exit-Point Packet 538 Source Node Node Destination 539 Node Node 541 Fig.6. Nested Encapsulation 543 4.1 Limiting Nested Encapsulation 545 A tunnel IPv6 packet is limited to the maximum IPv6 packet size 546 [IPv6-Spec]. Each encapsulation adds to the size of an encapsulated 547 packet the size of the tunnel IPv6 headers. Consequently, the number 548 of tunnel headers, and therefore, the number of nested encapsulations 549 is limited by the maximum packet size. However this limit is so 550 large (more than 1600 encapsulations for an original packet of 551 minimum size) that it is not an effective limit in most cases. 553 The increase in the size of a tunnel IPv6 packet due to nested 554 encapsulations may require fragmentation [IPv6-Spec] at a tunnel 555 entry point - see section 7. Furthermore, each fragmentation, due to 556 nested encapsulation, of an already fragmented tunnel packet results 557 in a doubling of the number of fragments. Moreover, it is probable 558 that once this fragmentation begins, each new nested encapsulation 559 results in yet additional fragmentation. Therefore limiting nested 560 encapsulation is recommended. 562 The proposed mechanism for limiting excessive nested encapsulation is 563 a "Tunnel Encapsulation Limit" option, which is carried in an IPv6 564 Destination Options extension header accompanying an encapsulating 565 IPv6 header. 567 4.1.1 Tunnel Encapsulation Limit Option 569 A tunnel entry-point node may be configured to include a Tunnel 570 Encapsulation Limit option as part of the information prepended to 571 all packets entering a tunnel at that node. The Tunnel Encapsulaton 572 Limit option is carried in a Destination Options extension header 573 [IPv6-Spec] placed between the encapsulating IPv6 header and the IPv6 574 header of the original packet. (Other IPv6 extension headers may 575 also be present preceding or following the Destination Options 576 extension header, depending on configuration information at the 577 tunnel entry-point node.) 579 The Tunnel Encapsulation Limit option specifies how many additional 580 levels of encapsulation are permitted to be prepended to the packet 581 -- or, in other words, how many further levels of nesting the packet 582 is permitted to undergo -- not counting the encapsulation in which 583 the option itself is contained. For example, a Tunnel Encapsulation 584 Limit option containing a limit value of zero means that a packet 585 carrying that option may not enter another tunnel before exiting the 586 current tunnel. 588 The Tunnel Encapsulation Limit option has the following format: 590 Option Type Opt Data Len Opt Data Len 591 0 1 2 3 4 5 6 7 592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 |0 0 0 0 0 1 0 0| 1 | Tun Encap Lim | 594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 Option Type decimal value 4 598 - the highest-order two bits - set to 00 - 599 indicate "skip over this option if the option is 600 not recognized". 602 - the third-highest-order bit - set to 0 - 603 indicates that the option data in this option does 604 not change en route to the packet's destination 605 [IPv6-Spec]. 607 Opt Data Len value 1 - the data portion of the Option is one 608 octet long. 610 Opt Data Value the Tunnel Encapsulation Limit value - 8-bit 611 unsigned integer specifying how many further 612 levels of encapsulation are permitted for the 613 packet carrying this option. 615 Tunnel Encapsulation Limit options are of interest only to tunnel 616 entry points. A tunnel entry-point node is required to execute the 617 following procedure for every packet entering a tunnel at that node: 619 (a) Examine the packet to see if a Tunnel Encapsulation Limit 620 option is present following its IPv6 header. The headers 621 following the IPv6 header must be examined in strict 622 "left-to-right" order, with the examination stopping as 623 soon as any one of the following headers is encountered: 624 (i) a Destination Options extension header containing a 625 Tunnel Encapsulation Limit, (ii) another IPv6 header, (iii) 626 a non-extension header, such as TCP, UDP, or ICMP, or (iv) 627 a header that cannot be parsed because it is encrypted or 628 its type is unknown. (Note that this requirment is an 629 exception to the general IPv6 rule that a Destination 630 Options extension header need only be examined by a 631 packet's destination node. An alternative and "cleaner" 632 approach would have been to use a Hop-by-Hop extension 633 header for this purpose, but that would have imposed an 634 undesirable extra processing burden, and possible 635 consequent extra delay, at every IPv6 node along the path 636 of a tunnel.) 638 (b) If a Tunnel Encapsulation Limit option is found in the 639 packet entering the tunnel and its limit value is zero, the 640 packet is discarded and an ICMP Parameter Problem message 641 [ICMP-Spec] is sent to the source of the packet, which is 642 the previous tunnel entry-point node. The Code field of 643 the Parameter Problem message is set to zero ("erroneous 644 header field encountered") and the Pointer field is set to 645 point to the third octet of the Tunnel Encapsulation Limit 646 option (i.e., the octet containing the limit value of 647 zero). 649 (c) If a Tunnel Encapsulation Limit option is found in the 650 packet entering the tunnel and its limit value is non-zero, 651 an additional Tunnel Encapsulation Limit option must be 652 included as part of the encapsulating headers being added 653 at this entry point. The limit value in the encapsulating 654 option is set to one less than the limit value found in the 655 packet being encapsulated. 657 (d) If a Tunnel Encapsulation Limit option is not found in the 658 packet entering the tunnel and if an encapsulation limit 659 has been configured for this tunnel, a Tunnel Encapsulation 660 Limit option must be included as part of the encapsulating 661 headers being added at this entry point. The limit value 662 in the option is set to the configured limit. 664 (e) If a Tunnel Encapsulation Limit option is not found in the 665 packet entering the tunnel and if no encapsulation limit 666 has been configured for this tunnel, then no Tunnel 667 Encapsulation Limit option is included as part of the 668 encapsulating headers being added at this entry point. 670 A Tunnel Encapsulation Limit option added at a tunnel entry-point 671 node is removed as part of the decapsulation process at that tunnel's 672 exit-point node. 674 Note: 676 The Tunnel Encapsulation Limit option MUST be a member of the 677 "Unfragmentable Part" of the IPv6 headers. Consequently, the 678 Tunnel Encapsulation Limit option is carried by every fragment of a 679 tunnel packet. 681 Two cases of encapsulation that should be avoided are described 682 below: 684 4.1.2 Loopback Encapsulation 686 A particular case of encapsulation which must be avoided is the 687 loopback encapsulation. Loopback encapsulation takes place when a 688 tunnel IPv6 entry-point node encapsulates tunnel IPv6 packets 689 originated from itself, and destined to itself. This can generate an 690 infinite processing loop in the entry-point node. 692 To avoid such a case, it is recommended that an implementation have a 693 mechanism that checks and rejects the configuration of a tunnel in 694 which both the entry-point and exit-point node addresses belong to 695 the same node. It is also recommended that the encapsulating engine 696 check for and reject the encapsulation of a packet that has the pair 697 of tunnel entry-point and exit-point addresses identical with the 698 pair of original packet source and final destination addresses. 700 4.1.3 Routing-Loop Nested Encapsulation 702 In the case of a forwarding path with multiple-level nested tunnels, 703 a routing-loop from an inner tunnel to an outer tunnel is 704 particularly dangerous when packets from the inner tunnels reenter an 705 outer tunnel from which they have not yet exited. In such a case, the 706 nested encapsulation becomes a recursive encapsulation with the 707 negative effects described in 4.1. Because each nested encapsulation 708 adds a tunnel header with a new hop limit value, the IPv6 hop limit 709 mechanism cannot control the number of times the packet reaches the 710 outer tunnel entry-point node, and thus cannot control the number of 711 recursive encapsulations. 713 When the path of a packet from source to final destination includes 714 tunnels, the maximum number of hops that the packet can traverse 715 should be controlled by two mechanisms used together to avoid the 716 negative effects of recursive encapsulation in routing loops: 718 (a) the original packet hop limit. 720 It is decremented at each forwarding operation performed on 721 an original packet. This includes each encapsulation of the 722 original packet. It does not include nested encapsulations 723 of the original packet 725 (b) the tunnel IPv6 packet encapsulation limit. 727 It is decremented at each nested encapsulation of the 728 packet. 730 For a discussion of the excessive encapsulation risk factors in 731 nested encapsulation see Appendix A. 733 5. Tunnel IPv6 Header 735 The tunnel entry-point node fills out a tunnel IPv6 main header 736 [IPv6-Spec] as follows: 738 Version: 740 value 6 742 Traffic Class: 744 Depending on the entry-point node tunnel configuration, the 745 traffic class can be set to that of either the original 746 packet or a pre-configured value - see section 6.4. 748 Flow Label: 750 Depending on the entry-point node tunnel configuration, the 751 flow label can be set to a pre-configured value. The typical 752 value is zero - see section 6.5. 754 Payload Length: 756 The original packet length, plus the length of the 757 encapsulating (prepended) IPv6 extension headers, if any. 759 Next Header: 761 The next header value according to [IPv6-Spec] from the 762 Assigned Numbers RFC [RFC-1700 or its successors]. 764 For example, if the original packet is an IPv6 packet, this 765 is set to: 767 - decimal value 41 (Assigned Next Header number for 768 IPv6) - if there are no tunnel extension headers. 770 - value 0 (Assigned Next Header number for IPv6 Hop by 771 Hop Options extension header) - if a hop by hop options 772 extension header immediately follows the tunnel IPv6 773 header. 775 - decimal value 60 (Assigned Next Header number for 776 IPv6 Destination Options extension header) - if a 777 destination options extension header immediately 778 follows the tunnel IPv6 header. 780 Hop Limit: 782 The tunnel IPv6 header hop limit is set to a pre-configured 783 value - see section 6.3. 785 The default value for hosts is the Neighbor Discovery 786 advertised hop limit [ND-Spec]. The default value for 787 routers is the default IPv6 Hop Limit value from the 788 Assigned Numbers RFC (64 at the time of writing this 789 document). 791 Source Address: 793 An IPv6 address of the outgoing interface of the tunnel 794 entry-point node. This address is configured as the tunnel 795 entry-point node address - see section 6.1. 797 Destination Address: 799 An IPv6 address of the tunnel exit-point node. This address 800 is configured as the tunnel exit-point node address - see 801 section 6.2. 803 5.1 Tunnel IPv6 Extension Headers 805 Depending on IPv6 node configuration parameters, a tunnel entry-point 806 node may append to the tunnel IPv6 main header one or more IPv6 807 extension headers, such as a Hop-by-Hop Options header, a Routing 808 header, or others. 810 To limit the number of nested encapsulations of a packet, if it was 811 configured to do so - see section 6.6 - a tunnel entry-point includes 812 a Destination Options extension header containing a Tunnel 813 Encapsulation Limit option. If that option is the only option present 814 in the Destination Options header, the header has the following 815 format: 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Next Header |Hdr Ext Len = 0| Opt Type = 4 |Opt Data Len=1 | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 | 0 | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 Next Header: 825 Identifies the type of the original packet header. For 826 example, if the original packet is an IPv6 packet, the next 827 header protocol value is set to decimal value 41 (Assigned 828 payload type number for IPv6). 830 Hdr Ext Len: 832 Length of the Destination Options extension header in 8- 833 octet units, not including the first 8 octets. Set to value 834 0, if no other options are present in this destination 835 options header. 837 Option Type: 839 value 4 - see section 4.1.1. 841 Opt Data Len: 843 value 1 - see section 4.1.1. 845 Tun Encap Lim: 847 8 bit unsigned integer - see section 4.1.1. 849 Option Type: 851 value 1 - PadN option, to align the header following this 852 header. 854 Opt Data Len: 856 value 1 - one octet of option data. 858 Option Data: 860 value 0 - one zero-valued octet. 862 6. IPv6 Tunnel State Variables 864 The IPv6 tunnel state variables, some of which are or may be 865 configured on the tunnel entry-point node, are: 867 6.1 IPv6 Tunnel Entry-Point Node Address 869 The tunnel entry-point node address is one of the valid IPv6 unicast 870 addresses of the entry-point node - the validation of the address at 871 tunnel configuration time is recommended. 873 The tunnel entry-point node address is copied to the source address 874 field in the tunnel IPv6 header during packet encapsulation. 876 6.2 IPv6 Tunnel Exit-Point Node Address 878 The tunnel exit-point node address is used as IPv6 destination 879 address for the tunnel IPv6 header. A tunnel acts like a virtual 880 point to point link between the entry-point node and exit-point node. 882 The tunnel exit-point node address is copied to the destination 883 address field in the tunnel IPv6 header during packet encapsulation. 885 The configuration of the tunnel entry-point and exit-point addresses 886 is not subject to IPv6 Autoconfiguration or IPv6 Neighbor Discovery. 888 6.3 IPv6 Tunnel Hop Limit 890 An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in 891 which the passing of the original packet through the tunnel is like 892 the passing of the original packet over a one hop link, regardless of 893 the number of hops in the IPv6 tunnel. 895 The "single-hop" mechanism should be implemented by having the tunnel 896 entry point node set a tunnel IPv6 header hop limit independently of 897 the hop limit of the original header. 899 The "single-hop" mechanism hides from the original IPv6 packets the 900 number of IPv6 hops of the tunnel. 902 It is recommended that the tunnel hop limit be configured with a 903 value that ensures: 905 (a) that tunnel IPv6 packets can reach the tunnel exit-point 906 node 908 (b) a quick expiration of the tunnel packet if a routing loop 909 occurs within the IPv6 tunnel. 911 The tunnel hop limit default value for hosts is the IPv6 Neighbor 912 Discovery advertised hop limit [ND-Spec]. The tunnel hop limit 913 default value for routers is the default IPv6 Hop Limit value from 914 the Assigned Numbers RFC (64 at the time of writing this document). 916 The tunnel hop limit is copied into the hop limit field of the tunnel 917 IPv6 header of each packet encapsulated by the tunnel entry-point 918 node. 920 6.4 IPv6 Tunnel Packet Traffic Class 922 The IPv6 Tunnel Packet Traffic Class indicates the value that a 923 tunnel entry-point node sets in the Traffic Class field of a tunnel 924 header. The default value is zero. The configured Packet Traffic 925 Class can also indicate whether the value of the Traffic Class field 926 in the tunnel header is copied from the original header, or it is set 927 to the pre-configured value. 929 6.5 IPv6 Tunnel Flow Label 931 The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- 932 point node sets in the flow label of a tunnel header. The default 933 value is zero. 935 6.6 IPv6 Tunnel Encapsulation Limit 937 The Tunnel Encapsulation Limit value can indicate whether the entry- 938 point node is configured to limit the number of encapsulations of 939 tunnel packets originating on that node. The IPv6 Tunnel 940 Encapsulation Limit is the maximum number of additional 941 encapsulations permitted for packets undergoing encapsulation at that 942 entry-point node. Recommended default value is 4. An entry-point node 943 configured to limit the number of nested encapsulations prepends a 944 Destination Options extension header containing a Tunnel 945 Encapsulation Limit option to an original packet undergoing 946 encapsulation - see sections 4.1 and 4.1.1. 948 6.7 IPv6 Tunnel MTU 950 The tunnel MTU is set dynamically to the Path MTU between the tunnel 951 entry-point and the tunnel exit-point nodes, minus the size of the 952 tunnel headers: the maximum size of a tunnel packet payload that can 953 be sent through the tunnel without fragmentation [IPv6-Spec]. The 954 tunnel entry-point node performs Path MTU discovery on the path 955 between the tunnel entry-point and exit-point nodes [PMTU-Spec], 956 [ICMP-Spec]. The tunnel MTU of a nested tunnel is the tunnel MTU of 957 the outer tunnel minus the size of the nested tunnel headers. 959 7. IPv6 Tunnel Packet Size Issues 961 Prepending a tunnel header increases the size of a packet, therefore 962 a tunnel packet resulting from the encapsulation of an IPv6 original 963 packet may require fragmentation. 965 A tunnel IPv6 packet resulting from the encapsulation of an original 966 packet is considered an IPv6 packet originating from the tunnel 967 entry-point node. Therefore, like any source of an IPv6 packet, a 968 tunnel entry-point node must support fragmentation of tunnel IPv6 969 packets. 971 Note: 973 The Tunnel Encapsulation Limit option, if present, MUST be a member 974 of the "Unfragmentable Part" of the IPv6 headers. Consequently, the 975 Tunnel Encapsulation Limit option, if present, is carried in every 976 fragment of a tunnel packet. 978 A tunnel intermediate node that forwards a tunnel packet to another 979 node in the tunnel follows the general IPv6 rule that it must not 980 fragment a packet undergoing forwarding. 982 A tunnel exit-point node receiving tunnel packets at the end of the 983 tunnel for decapsulation applies the strict left-to-right processing 984 rules for extension headers. In the case of a fragmented tunnel 985 packet, the fragments are reassembled into a complete tunnel packet 986 before determining that an embedded packet is present. 988 Note: 990 A particular problem arises when the destination of a fragmented 991 tunnel packet is an exit-point node identified by an anycast 992 address. The problem, which is similar to that of original 993 fragmented IPv6 packets destined to nodes identified by an anycast 994 address, is that all the fragments of a packet must arrive at the 995 same destination node for that node to be able to perform a 996 successful reassembly, a requirement that is not necessarily 997 satisfied by packets sent to an anycast address. 999 7.1 IPv6 Tunnel Packet Fragmentation 1001 When an IPv6 original packet enters a tunnel, if the original packet 1002 size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel 1003 entry-point and the tunnel exit-point, minus the size of the tunnel 1004 header(s)), it is handled as follows: 1006 (a) if the original IPv6 packet size is larger than the IPv6 1007 minimum link MTU [IPv6-Spec], the entry-point node discards 1008 the packet and sends an ICMPv6 "Packet Too Big" message to 1009 the source address of the original packet with the 1010 recommended MTU size field set to the tunnel MTU or the 1011 IPv6 minimum link MTU, whichever is larger, i.e. max(tunnel 1012 MTU, IPv6 minimum link MTU). lso see sections 6.7 and 1013 8.2. 1015 (b) if the original IPv6 packet is equal or smaller than the 1016 IPv6 minimum link MTU, the tunnel entry-point node 1017 encapsulates the original packet, and subsequently 1018 fragments the resulting IPv6 tunnel packet into IPv6 1019 fragments that do not exceed the Path MTU to the tunnel 1020 exit-point. 1022 7.2 IPv4 Tunnel Packet Fragmentation 1024 When an IPv4 original packet enters a tunnel, if the original packet 1025 size exceeds the tunnel MTU (i.e., the Path MTU between the tunnel 1026 entry-point and the tunnel exit-point, minus the size of the tunnel 1027 header(s)), it is handled as follows: 1029 (a) if in the original IPv4 packet header the Don't Fragment - 1030 DF - bit flag is SET, the entry-point node discards the 1031 packet and returns an ICMP message. The ICMP message has 1032 the type = "unreachable", the code = "packet too big", and 1033 the recommended MTU size field set to the size of the 1034 tunnel MTU - see sections 6.7 and 8.3. 1036 (b) if in the original packet header the Don't Fragment - DF - 1037 bit flag is CLEAR, the tunnel entry-point node encapsulates 1038 the original packet, and subsequently fragments the 1039 resulting IPv6 tunnel packet into IPv6 fragments that do 1040 not exceed the Path MTU to the tunnel exit-point. 1042 8. IPv6 Tunnel Error Processing and Reporting 1044 IPv6 Tunneling follows the general rule that an error detected during 1045 the processing of an IPv6 packet is reported through an ICMP message 1046 to the source of the packet. 1048 On a forwarding path that includes IPv6 tunnels, an error detected by 1049 a node that is not in any tunnel is directly reported to the source 1050 of the original IPv6 packet. 1052 An error detected by a node inside a tunnel is reported to the source 1053 of the tunnel packet, that is, the tunnel entry-point node. The ICMP 1054 message sent to the tunnel entry-point node has as ICMP payload the 1055 tunnel IPv6 packet that has the original packet as its payload. 1057 The cause of a packet error encountered inside a tunnel can be a 1058 problem with: 1060 (a) the tunnel header, or 1062 (b) the tunnel packet. 1064 Both tunnel header and tunnel packet problems are reported to the 1065 tunnel entry-point node. 1067 If a tunnel packet problem is a consequence of a problem with the 1068 original packet, which is the payload of the tunnel packet, then the 1069 problem is also reported to the source of the original packet. 1071 To report a problem detected inside the tunnel to the source of an 1072 original packet, the tunnel entry point node must relay the ICMP 1073 message received from inside the tunnel to the source of that 1074 original IPv6 packet. 1076 An example of the processing that can take place in the error 1077 reporting mechanism of a node is illustrated in Fig.7, and Fig.8: 1079 Fig.7 path #0 and Fig.8 (a) - The IPv6 tunnel entry-point receives an 1080 ICMP packet from inside the tunnel, marked Tunnel ICMPv6 Message in 1081 Fig.7. The tunnel entry-point node IPv6 layer passes the received 1082 ICMP message to the ICMPv6 Input. The ICMPv6 Input, based on the ICMP 1083 type and code [ICMP-Spec] generates an internal "error code". 1085 Fig.7 path #1 - The internal error code, is passed with the "ICMPv6 1086 message payload" to the upper-layer protocol - in this case the IPv6 1087 tunnel upper-layer error input. 1089 +-------+ +-------+ +-----------------------+ 1090 | Upper | | Upper | | Upper | 1091 | Layer | | Layer | | Layer | 1092 | Proto.| | Proto | | IPv6 Tunnel | 1093 | Error | | Error | | Error | 1094 | Input | | Input | | Input | 1095 | | | | | Decapsulate | 1096 | | | | | -->--ICMPv6--#2->-- | 1097 | | | | | | Payload | | 1098 +-------+ +-------+ +--|-----------------|--+ 1099 | | | | 1100 ^ ^ ^ v 1101 | | | | 1102 --------------------#1-- -----Orig.Packet?--- - - - - - - - - - 1103 #1 #3 Int.Error Code, #5 | 1104 Int.Error Code,^ v Source Address, v v 1105 ICMPv6 Payload | IPv6 | Orig. Packet | IPv4 | 1106 +--------------+ +--------------+ +--------------+ + - - - - + 1107 | | | | | | 1108 | ICMP v6 | | ICMP v6 | | ICMP v4 | | | 1109 | Input | | Error Report | | Error Report | 1110 | - - - - +----+ - - - - | + - - - - + + - - - - + 1111 | | | | 1112 | IPv6 Layer | | IPv4 Layer | | | 1113 | | | | 1114 +----------------------------------+ +--------------+ + - - - - + 1115 | | | 1116 ^ V V 1117 #0 #4 #6 1118 | | | 1119 Tunnel ICMPv6 ICMPv6 ICMPv4 1120 Message Message Message 1121 | | | 1123 Fig.7 Error Reporting Flow in a Node (IPv6 Tunneling Protocol Engine) 1125 Fig.7 path #2 and Fig.8 (b) - The IPv6 tunnel error input 1126 decapsulates the tunnel IPv6 packet, which is the ICMPv6 message 1127 payload, obtaining the original packet, and thus the original headers 1128 and dispatches the "internal error code", the source address from the 1129 original packet header, and the original packet, down to the error 1130 report block of the protocol identified by the Next Header field in 1131 the tunnel header immediately preceding the original packet in the 1132 ICMP message payload. 1134 From here the processing depends on the protocol of the original 1135 packet: 1137 (a) - for an IPv6 original packet 1139 Fig.7 path #3 and Fig.8 (c.1)- for an IPv6 original packet, the 1140 ICMPv6 error report builds an ICMP message of a type and code 1141 according to the "internal error code", containing the "original 1142 packet" as ICMP payload. 1144 Fig.7 path #4 and Fig.8 (d.1)- The ICMP message has the tunnel 1145 entry-point node address as source address, and the original packet 1146 source node address as destination address. The tunnel entry-point 1147 node sends the ICMP message to the source node of the original 1148 packet. 1150 (b) - for an IPv4 original packet 1152 Fig.7 path #5 and Fig.8 (c.2) - for an IPv4 original packet, the 1153 ICMPv4 error report builds an ICMP message of a type and code 1154 derived from the the "internal error code", containing the 1155 "original packet" as ICMP payload. 1157 Fig.7 path #6 and Fig.8 (d.2) - The ICMP message has the tunnel 1158 entry-point node IPv4 address as source address, and the original 1159 packet IPv4 source node address as destination address. The tunnel 1160 entry-point node sends the ICMP message to the source node of the 1161 original packet. 1163 A graphical description of the header processing taking place is the 1164 following: 1166 < Tunnel Packet > 1167 +--------+- - - - - -+--------+------------------------------//------+ 1168 | IPv6 | IPv6 | ICMP | Tunnel | 1169 (a)| | Extension | | IPv6 | 1170 | Header | Headers | Header | Packet in error | 1171 +--------+- - - - - -+--------+------------------------------//------+ 1172 < Tunnel Headers > < Tunnel ICMP Message > 1173 < ICMPv6 Message Payload > 1174 | 1175 v 1177 < Tunnel ICMP Message > 1178 < Tunnel IPv6 Packet in Error > 1179 +--------+ +---------+ +----------+--------//------+ 1180 | ICMP | | Tunnel | | Original | Original | 1181 (b) | | + | IPv6 | + | | Packet | 1182 | Header | | Headers | | Headers | Payload | 1183 +--------+ +---------+ +----------+--------//------+ 1184 | 1185 ----------------- | 1186 | | 1187 --------------|--------------- 1188 | | 1189 V V 1190 +---------+ +--------+ +-------------------//------+ 1191 | New | | ICMP | | | 1192 (c.1) | IPv6 | + | | + | Orig. Packet in Error | 1193 | Headers | | Header | | | 1194 +---------+ +--------+ +-------------------//------+ 1195 | 1196 v 1197 +---------+--------+-------------------//------+ 1198 | New | ICMP | Original | 1199 (d.1) | IPv6 | | | 1200 | Headers | Header | Packet in Error | 1201 +---------+--------+-------------------//------+ 1202 < New ICMP Message > 1204 or for an IPv4 original packet 1206 +---------+ +--------+ +-------------------//------+ 1207 | New | | ICMP | | | 1208 (c.2) | IPv4 | + | | + | Orig. Packet in Error | 1209 | Header | | Header | | | 1210 +---------+ +--------+ +-------------------//------+ 1211 | 1212 v 1213 +---------+--------+-------------------//------+ 1214 | New | ICMP | Original | 1215 (d.2) | IPv4 | | | 1216 | Header | Header | Packet in Error | 1217 +---------+--------+-------------------//------+ 1218 < New ICMP Message > 1220 Fig.8 ICMP Error Reporting and Processing 1222 8.1 Tunnel ICMP Messages 1224 The tunnel ICMP messages that are reported to the source of the 1225 original packet are: 1227 hop limit exceeded 1229 The tunnel has a misconfigured hop limit, or contains a 1230 routing loop, and packets do not reach the tunnel exit- 1231 point node. This problem is reported to the tunnel entry- 1232 point node, where the tunnel hop limit can be reconfigured 1233 to a higher value. The problem is further reported to the 1234 source of the original packet as described in section 8.2, 1235 or 8.3. 1237 unreachable node 1239 One of the nodes in the tunnel is not or is no longer 1240 reachable. This problem is reported to the tunnel entry- 1241 point node, which should be reconfigured with a valid and 1242 active path between the entry and exit-point of the tunnel. 1243 The problem is further reported to the source of the 1244 original packet as described in section 8.2, or 8.3. 1246 parameter problem 1248 A Parameter Problem ICMP message pointing to a valid Tunnel 1249 Encapsulation Limit Destination header with a Tun Encap Lim 1250 field value set to one is an indication that the tunnel 1251 packet exceeded the maximum number of encapsulations 1252 allowed. The problem is further reported to the source of 1253 the original packet as described in section 8.2, or 8.3. 1255 The above three problems detected inside the tunnel, which are a 1256 tunnel configuration and a tunnel topology problem, are reported to 1257 the source of the original IPv6 packet, as a tunnel generic 1258 "unreachable" problem caused by a "link problem" - see section 8.2 1259 and 8.3. 1261 packet too big 1263 The tunnel packet exceeds the tunnel Path MTU. 1265 The information carried by this type of ICMP message is 1266 used as follows: 1268 - by a receiving tunnel entry-point node to set or adjust 1269 the tunnel MTU 1271 - by a sending tunnel entry-point node to indicate to the 1272 source of an original packet the MTU size that should be 1273 used in sending IPv6 packets towards the tunnel entry-point 1274 node. 1276 8.2 ICMP Messages for IPv6 Original Packets 1278 The tunnel entry-point node builds the ICMP and IPv6 headers of the 1279 ICMP message that is sent to the source of the original packet as 1280 follows: 1282 IPv6 Fields: 1284 Source Address 1286 A valid unicast IPv6 address of the outgoing interface. 1288 Destination Address 1290 Copied from the Source Address field of the Original 1291 IPv6 header. 1293 ICMP Fields: 1295 For any of the following tunnel ICMP error messages: 1297 "hop limit exceeded" 1299 "unreachable node" 1301 "parameter problem" - pointing to a valid Tunnel Encapsulation 1302 Limit destination header with the Tun Encap Lim field set to a 1303 value zero: 1305 Type 1 - unreachable node 1307 Code 3 - address unreachable 1309 For tunnel ICMP error message "packet too big": 1311 Type 2 - packet too big 1313 Code 0 1315 MTU The MTU field from the tunnel ICMP message minus 1316 the length of the tunnel headers. 1318 According to the general rules described in 7.1, an ICMP "packet too 1319 big" message is sent to the source of the original packet only if the 1320 original packet size is larger than the minimum link MTU size 1321 required for IPv6 [IPv6-Spec]. 1323 8.3 ICMP Messages for IPv4 Original Packets 1325 The tunnel entry-point node builds the ICMP and IPv4 header of the 1326 ICMP message that is sent to the source of the original packet as 1327 follows: 1329 IPv4 Fields: 1331 Source Address 1333 A valid unicast IPv4 address of the outgoing interface. 1335 Destination Address 1337 Copied from the Source Address field of the Original 1338 IPv4 header. 1340 ICMP Fields: 1342 For any of the following tunnel ICMP error messages: 1344 "hop limit exceeded" 1346 "unreachable node" 1348 "parameter problem" - pointing to a valid Tunnel Enacpsulation 1349 Limit destination header with the Tun Encap Lim field set to a 1350 value zero: 1352 Type 3 - destination unreachable 1354 Code 1 - host unreachable 1356 For a tunnel ICMP error message "packet too big": 1358 Type 3 - destination unreachable 1360 Code 4 - packet too big 1362 MTU The MTU field from the tunnel ICMP message minus 1363 the length of the tunnel headers. 1365 According to the general rules described in section 7.2, an ICMP 1366 "packet too big" message is sent to the original IPv4 packet source 1367 node if the the original IPv4 header has the DF - don't fragment - 1368 bit flag SET. 1370 8.4 ICMP Messages for Nested Tunnel Packets 1372 In case of an error uncovered with a nested tunnel packet, the inner 1373 tunnel entry-point, which receives the ICMP error message from the 1374 inner tunnel reporting node, relays the ICMP message to the outer 1375 tunnel entry-point following the mechanisms described in sections 1376 8.,8.1, 8.2, and 8.3. Further, the outer tunnel entry-point relays 1377 the ICMP message to the source of the original packet, following the 1378 same mechanisms. 1380 9. Security Considerations 1382 An IPv6 tunnel can be secured by securing the IPv6 path between the 1383 tunnel entry-point and exit-point node. The security architecture, 1384 mechanisms, and services are described in [IPSEC-ARCH], [IPSEC-ATH], 1385 and [IPSEC-ESP]. A secure IPv6 tunnel may act as a gateway-to-gateway 1386 secure path as described in [IPSEC-ARCH]. 1388 For a secure IPv6 tunnel, in addition to the mechanisms described 1389 earlier in this document, the entry-point node of the tunnel performs 1390 security algorithms on the packet and prepends as part of the tunnel 1391 headers one or more security headers in conformance with [IPv6-Spec], 1392 [IPSEC-ARCH], and [IPSEC-ATH], or [IPSEC-ESP]. 1394 The exit-point node of a secure IPv6 tunnel performs security 1395 algorithms and processes the tunnel security header[s] as part of the 1396 tunnel headers processing described earlier, and in conformance with 1397 [IPSEC-ARCH], and [IPSEC-ATH], or [IPSEC-ESP]. The exit-point node 1398 discards the tunnel security header[s] with the rest of the tunnel 1399 headers after tunnel headers processing completion. 1401 The degree of integrity, authentication, and confidentiality and the 1402 security processing performed on a tunnel packet at the entry-point 1403 and exit-point node of a secure IPv6 tunnel depend on the type of 1404 security header - authentication (AH) or encryption (ESP) - and 1405 parameters configured in the Security Association for the tunnel. 1406 There is no dependency or interaction between the security level and 1407 mechanisms applied to the tunnel packets and the security applied to 1408 the original packets which are the payloads of the tunnel packets. 1409 In case of nested tunnels, each inner tunnel may have its own set of 1410 security services, independently from those of the outer tunnels, or 1411 of those between the source and destination of the original packet. 1413 10. Acknowledgments 1415 This document is partially derived from several discussions about 1416 IPv6 tunneling on the IPng Working Group Mailing List and from 1417 feedback from the IPng Working Group to an IPv6 presentation that 1418 focused on IPv6 tunneling at the 33rd IETF, in Stockholm, in July 1419 1995. 1421 Additionally, the following documents that focused on tunneling or 1422 encapsulation were helpful references: RFC 1933 (R. Gilligan, E. 1423 Nordmark), RFC 1241 (R. Woodburn, D. Mills), RFC 1326 (P. Tsuchiya), 1424 RFC 1701, RFC 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1853 (W. 1425 Simpson), as well as RFC 2003 (C. Perkins). 1427 Brian Carpenter, Richard Draves, Bob Hinden, Thomas Narten, Erik 1428 Nordmark (in alphabetical order) gave valuable reviewing comments and 1429 suggestions for the improvement of this document. Scott Bradner, Ross 1430 Callon, Dimitry Haskin, Paul Traina, and James Watt (in alphabetical 1431 order) shared their view or experience on matters of concern in this 1432 document. Judith Grossman provided a sample of her many years of 1433 editorial and writing experience as well as a good amount of probing 1434 technical questions. 1436 The Tunnel Encapsulation Limit processing in case of fragmentaion 1437 specification was further improved with input from Vladislav 1438 Yasevich, Brian Zill, Jinmey Tatuya, Tim Hartrick, and Sowmini 1439 Varadhan. 1441 11. References 1443 [IPv6-Spec] Deering, S., and R. Hinden, "Internet Protocol Version 6 1444 (IPv6) Specification", R%FC 2460, December 1998. 1446 [ICMP-Spec] Conta, A., and S. Deering "Internet Control Message 1447 Protocol for the Internet Protocol Version 6 (IPv6)", work in 1448 progress, November 2001. 1450 [ND-Spec] Narten, T., Nordmark, E., and W. Simpson "Neighbor 1451 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 1453 [PMTU-Spec] McCann, J., Deering, S., and J. Mogul "Path MTU Discovery 1454 for IP Version 6 (IPv6)" , RFC-1981, August 1996. 1456 [IPSEC-Arch] Atkinson, R., "Security Architecture for the Internet 1457 Protocol", RFC 2401, November 1998. 1459 [IPSEC-ATH] Atkinson, R. and S. Kent, "IP Authentication Header", RFC 1460 2402, November 1998. 1462 [IPSEC-ESP] R. Atkinson, "IP Encapsulation Security Payload (ESP)", 1463 RFC 2406, November 1998. 1465 [IP-IN-IP] Simpson, W., "IP in IP Tunneling", RFC 1853, October 1995. 1467 [Assign-Nr] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, 1468 RFC 1700, October 1994. See also: "http://www.iana.org/numbers.html". 1470 [REQ-LEV] S. Bradner "Key words for use in RFCs to indicate 1471 Requirement Levels", BCP 14, RFC 2119, March 1997. 1473 Authors' Addresses: 1475 Alex Conta Stephen Deering 1476 Transwitch Corporation Cisco Systems 1477 3 Enterprise Drive 170 West Tasman Dr 1478 Shelton, CT 06484 San Jose, CA 95132-1706 1479 email: aconta@txc.com email: deering@cisco.com 1481 Appendix A 1483 A.1 Risk Factors in Nested Encapsulation 1485 Nested encapsulations of a packet become a recursive encapsulation if 1486 the packet reenters an outer tunnel before exiting it. The cases 1487 which present a high risk of recursive encapsulation are those in 1488 which a tunnel entry-point node cannot determine whether a packet 1489 that undergoes encapsulation reenters the tunnel before exiting it. 1490 Routing loops that cause tunnel packets to reenter a tunnel before 1491 exiting it are certainly the major cause of the problem. But since 1492 routing loops exist, and happen, it is important to understand and 1493 describe, the cases in which the risk for recursive encapsulation is 1494 higher. 1496 There are two significant elements that determine the risk factor of 1497 routing loop recursive encapsulation: 1499 (a) the type of tunnel, 1501 (b) the type of route to the tunnel exit-point, which 1502 determines the packet forwarding through the tunnel, that 1503 is, over the tunnel virtual-link. 1505 A.1.1 Risk Factor in Nested Encapsulation - type of tunnel. 1507 The type of tunnels which were identified as a high risk factor for 1508 recursive encapsulation in routing loops are: 1510 "inner tunnels with identical exit-points". 1512 Since the source and destination of an original packet is the main 1513 information used to decide whether to forward a packet through a 1514 tunnel or not, a recursive encapsulation can be avoided in case of a 1515 single tunnel (non-inner), by checking that the packet to be 1516 encapsulated is not originated on the entry-point node. This 1517 mechanism is suggested in [IP-IN-IP]. 1519 However, this type of protection does not seem to work well in case 1520 of inner tunnels with different entry-points, and identical exit- 1521 points. 1523 Inner tunnels with different entry-points and identical exit-points 1524 introduce ambiguity in deciding whether to encapsulate a packet, when 1525 a packet encapsulated in an inner tunnel reaches the entry-point node 1526 of an outer tunnel by means of a routing loop. Because the source of 1527 the tunnel packet is the inner tunnel entry-point node which is 1528 different than the entry-point node of the outer tunnel, the source 1529 address checking (mentioned above) fails to detect an invalid 1530 encapsulation, and as a consequence the tunnel packet gets 1531 encapsulated at the outer tunnel each time it reaches it through the 1532 routing loop. 1534 A.1.2 Risk Factor in Nested Encapsulation - type of route. 1536 The type of route to a tunnel exit-point node has been also 1537 identified as a high risk factor of recursive encapsulation in 1538 routing loops. 1540 One type of route to a tunnel exit-point node is a route to a 1541 specified destination node, that is, the destination is a valid 1542 specified IPv6 address (route to node). Such a route can be selected 1543 based on the longest match of an original packet destination address 1544 with the destination address stored in the tunnel entry-point node 1545 routing table entry for that route. The packet forwarded on such a 1546 route is first encapsulated and then forwarded towards the tunnel 1547 exit-point node. 1549 Another type of route to a tunnel exit-point node is a route to a 1550 specified prefix-net, that is, the destination is a valid specified 1551 IPv6 prefix (route to net). Such a route can be selected based on the 1552 longest path match of an original packet destination address with the 1553 prefix destination stored in the tunnel entry-point node routing 1554 table entry for that route. The packet forwarded on such a route is 1555 first encapsulated and then forwarded towards the tunnel exit-point 1556 node. 1558 And finally another type of route to a tunnel exit-point is a default 1559 route, or a route to an unspecified destination. This route is 1560 selected when no-other match for the destination of the original 1561 packet has been found in the routing table. A tunnel that is the 1562 first hop of a default route is a "default tunnel". 1564 If the route to a tunnel exit-point is a route to node, the risk 1565 factor for recursive encapsulation is minimum. 1567 If the route to a tunnel exit-point is a route to net, the risk 1568 factor for recursive encapsulation is medium. There is a range of 1569 destination addresses that will match the prefix the route is 1570 associated with. If one or more inner tunnels with different tunnel 1571 entry-points have exit-point node addresses that match the route to 1572 net of an outer tunnel exit-point, then a recursive encapsulation may 1573 occur if a tunnel packet gets diverted from inside such an inner 1574 tunnel to the entry-point of the outer tunnel that has a route to its 1575 exit-point that matches the exit-point of an inner tunnel. 1577 If the route to a tunnel exit-point is a default route, the risk 1578 factor for recursive encapsulation is maximum. Packets are forwarded 1579 through a default tunnel for lack of a better route. In many 1580 situations, forwarding through a default tunnel can happen for a wide 1581 range of destination addresses which at the maximum extent is the 1582 entire Internet minus the node's link. As consequence, it is likely 1583 that in a routing loop case, if a tunnel packet gets diverted from an 1584 inner tunnel to an outer tunnel entry-point in which the tunnel is a 1585 default tunnel, the packet will be once more encapsulated, because 1586 the default routing mechanism will not be able to discern 1587 differently, based on the destination. 1589 B. Change From Previous Version 1591 Text (a one paragraph note) was added at page 16 and 23 to specify that the 1592 Tunnel Encapsulation Limit option must be carried by each tunnel packet 1593 fragment. 1595 2183