idnits 2.17.1 draft-ietf-ipngwg-ipv6-tunnel-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 302 instances of weird spacing in the document. Is it really formatted ragged-right, rather than justified? ** There are 35 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 ...' == (297 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 (November 1995) is 10389 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: 'IPv6' is mentioned on line 894, but not defined == Missing Reference: 'TBD' is mentioned on line 1238, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6ICMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6ND' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6PMTU' ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) Summary: 11 errors (**), 0 flaws (~~), 9 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Conta (Digital Equipment Corporation) 3 INTERNET-DRAFT S. Deering (Xerox PARC) 4 November 1995 6 Generic Packet Tunneling in IPv6 8 Specification 10 draft-ietf-ipngwg-ipv6-tunnel-00.txt 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are draft documents valid for a maximum of six 20 months. Internet Drafts may be updated, replaced, or obsoleted by 21 other documents at any time. It is not appropriate to use Internet 22 Drafts as reference material or to cite them other than as a "working 23 draft" or "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 27 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Distribution of this memo is unlimited. 33 Abstract 35 This document defines the model and mechanisms for IPv6 tunneling of 36 various Internet or lower layer protocol packets, such as IPv6, IPv4, 37 AppleTalk, IPX, etc. 39 Table of Contents 41 Status of this Memo.................................1 42 Table of Contents...................................2 43 1. Introduction........................................3 44 2. Terminology.........................................3 45 3. IPv6 Tunneling......................................6 46 3.1 IPv6 Encapsulation.............................8 47 3.2 IPv6 Decapsulation.............................9 48 3.3 IPv6 Tunnel Protocol Engine...................10 49 4. Recursive Encapsulation............................12 50 4.1 Limiting Recursive Encapsulation.............12 51 4.1.1 Tunnel Encapsulation Limit.............13 52 4.1.2 Loopback Recursive Encapsulation.......14 53 4.1.3 Routing Loop Recursive Encapsulation...15 54 5. Tunnel IPv6 Header.................................16 55 5.1 Tunnel IPv6 Extension Headers.................17 56 6. IPv6 Tunnel State Variables........................19 57 6.1 IPv6 Tunnel Entry-Point Node..................19 58 6.2 IPv6 Tunnel Exit-Point Node...................19 59 6.3 IPv6 Tunnel Hop Limit.........................20 60 6.4 IPv6 Tunnel Packet Priority...................20 61 6.5 IPv6 Tunnel Flow Label........................21 62 6.6 IPv6 Tunnel Encapsulation Limit...............21 63 6.7 IPv6 Tunnel MTU...............................21 64 7. IPv6 Tunnel Error Reporting and Processing.........23 65 7.1 Tunnel ICMP Messages..........................25 66 7.2 ICMP Messages for IPv6 Original Packets.......26 67 7.3 ICMP Messages for IPv4 Original Packets.......27 68 8. Open Issues........................................28 69 9. References.........................................28 70 10. Acknowledgements..................................29 71 11. Security Considerations...........................29 72 Authors' Addresses....................................30 74 Fig. 1.................................................7 75 Fig. 2.................................................8 76 Fig. 3.................................................8 77 Fig. 4.................................................9 78 Fig. 5................................................10 79 Fig. 6................................................12 80 Fig. 7................................................23 81 Fig. 8................................................25 82 1. Introduction 84 This document specifies a method and generic mechanisms by which a 85 packet may be encapsulated and carried as payload within an IPv6 86 packet. The technique of encapsulating packets within IPv6 packets, 87 called also tunneling in IPv6, is recommended for use in various 88 cases of communications. 90 Such a case is when a node, that is not the source node of a packet, 91 wishes to exert explicit routing control over the packet - such as 92 causing the packet to be forwarded to a particular destination on the 93 way to the final destination identified in the original header. The 94 control is exerted by prepending to the packet a new IPv6 header, 95 with a new source and destination address (see section 3.1). 97 The tunnel IPv6 packet is forwarded to the tunnel IPv6 header 98 destination which is the IPv6 tunnel exit-point node. The IPv6 tunnel 99 exit-point node removes the IPv6 tunnel header, and forwards the IPv6 100 packet further towards the original IPv6 header destination node (see 101 section 3.2). 103 The sections of this document describe generic mechanisms for IPv6 104 tunneling that apply to tunneling of various Internet or lower layer 105 protocol packets. section 7.2, and 7.3 are an exception; they 106 describe a specific IPv6 tunneling mechanism for IPv6 packets and 107 respectively IPv4 packets. 109 2. Terminology 111 node 113 a device that implements IPv6. 115 upper-layer 117 a protocol layer immediately above IPv6. Examples are transport 118 protocols such as TCP and UDP, control protocols such as ICMP, and 119 internet or lower-layer protocols being "tunneled" over (i.e., 120 encapsulated in) IPv6 such as IPX, AppleTalk, or IPv6 itself. 122 link 124 a communication facility or medium over which nodes can 125 communicate at the link layer, i.e., the layer immediately below 126 IPv6. Examples are Ethernets (simple or bridged); PPP links; 127 X.25, Frame Relay, or ATM networks; and internet (or higher) layer 128 "tunnels", such as tunnels over IPv4 or IPv6 itself. 130 interface 132 a node's attachment to a link. 134 address 136 an IPv6-layer identifier for an interface or a set of interfaces. 138 packet 140 an IPv6 header plus payload. 142 link MTU 144 the maximum transmission unit, i.e., maximum packet size in 145 octets, that can be conveyed in one piece over a link. 147 path MTU 149 the minimum link MTU of all the links in a path between a source 150 node and a destination node. 152 original packet 154 an Internet or lower layer packet that undergoes encapsulation in 155 a tunnel packet. 157 original header 159 the header of an original packet. 161 tunnel 163 a virtual link between two nodes, on which an Internet or lower 164 layer protocol packet travels after the entry-point node 165 encapsulates that packet in a tunnel protocol packet. 167 tunnel header 169 the header prepended to the original packet during encapsulation. 170 It specifies the tunnel end-points as source and destination. 172 tunnel packet 174 an original packet encapsulated by prepending tunnel header(s) to 175 the original header(s). 177 tunnel entry-point 179 the tunnel end-node where an original packet is encapsulated, and 180 where a tunnel packet originates; the source node of a tunnel 181 packet identified in the tunnel header. 183 tunnel exit-point 185 the tunnel end-node where a tunnel packet is decapsulated, and 186 processed further as original packet based on the original header; 187 the destination node of a tunnel packet, identified in the tunnel 188 header. 190 tunnel MTU 192 the Path MTU in the tunnel, i.e. between the tunnel entry-point 193 node and the tunnel exit-point node. 195 tunnel hop limit 197 the maximum number of hops that a tunnel packet is allowed to 198 travel in a tunnel, i.e. between the tunnel entry-point node and 199 the tunnel exit-point node. 201 inner tunnel 203 a tunnel which serves as one (virtual) hop in another tunnel. 205 outer tunnel 207 a tunnel in which one or more hops are themselves tunnels. 209 recursive tunnel IPv6 packet 211 a tunnel IPv6 packet encapsulated within a tunnel IPv6 packet, by 212 prepending IPv6 tunnel header(s) to previously prepended IPv6 213 tunnel header(s). 215 recursive encapsulation 217 encapsulation of a tunnel packet, i.e. encapsulation of an 218 encapsulated packet. 220 tunnel encapsulation limit 222 the maximum number of recursive encapsulations of a packet. 224 3. IPv6 Tunneling 226 Tunneling in IPv6 is a technique which consists in establishing a 227 "virtual link" between two IPv6 nodes and using that "link" for 228 transmitting data packets. The two IPv6 nodes view the IPv6 "virtual 229 link", also called an "IPv6 tunnel", as a "link", on which the IPv6 230 protocol acts like a "link layer" protocol. Consequently the two 231 nodes at the two ends of the IPv6 tunnel exchange an Internet or 232 lower layer protocol packet by encapsulating in and decapsulating 233 from an IPv6 packet, as they would encapsulate in and decapsulate 234 from a link layer protocol packet. 236 The two IPv6 nodes which are at the two ends of the IPv6 tunnel, the 237 IPv6 tunnel entry point node and the IPv6 tunnel exit point node play 238 specific roles: 240 The tunnel entry-point node encapsulates an original packet within an 241 IPv6 packet by prepending an IPv6 header (and optionally a set of 242 IPv6 extension headers) to the original packet and then transmits the 243 resulting tunnel packet towards the tunnel exit-point node. The 244 tunnel headers (IPv6 header and IPv6 extension headers) are used to 245 control the packet's processing (forwarding) through the tunnel (see 246 section 3.1). 248 The tunnel exit-point node decapsulates a tunnel packet and then it 249 processes further the resulting original packet like any original 250 packet (see section 3.2). 252 A tunnel entry point node can be seen as an original packet source - 253 the source of the IPv6 tunnel packet is the tunnel entry point node. 254 An IPv6 tunnel main header and its extension headers, if any, are 255 processed by the IPv6 layer similarly to processing the headers of an 256 original IPv6 packet. Additionally, an IPv6 tunnel packet resulting 257 from encapsulation is an IPv6 packet that may be the object of a 258 subsequent IPv6 encapsulation, similar to any original packet. 260 A tunnel exit point node can be seen as an original packet 261 destination - the destination of the IPv6 tunnel packet is the tunnel 262 exit-point node. The tunnel exit point node processes the IPv6 main 263 header and its extension headers, if any, of an IPv6 tunnel packet 264 destined to it similarly to processing the IPv6 headers of an 265 original packet destined to it. 267 Tunnel from node B to node C 268 <-------------------------------------> 269 Tunnel Tunnel 270 Entry-Point Exit-Point 271 Node Node 272 +-+ +-+ +-+ +-+ 273 |A|->-//->-|B|=========>=====//========>=========|C|->-//-->-|D| 274 +-+ +-+ +-+ +-+ 275 Original Original 276 Packet Packet 277 Source Destination 278 Node Node 280 Fig. 1. Tunnel 282 An IPv6 tunnel is a unidirectional mechanism - tunnel packet flow 283 takes place in one direction between the IPv6 tunnel entry point node 284 and exit point node (see Fig. 1). 286 A bidirectional tunneling mechanism effect can be achieved by merging 287 two unidirectional mechanisms, by defining two tunnels that are each 288 one in opposite direction to the other - the entry point node of one 289 tunnel is the exit point node of the other tunnel (see Fig. 2). 291 A tunnel entry-point node can be the original packet source, and 292 similarly a tunnel exit-point node can be the original packet 293 destination, i.e. the beginning or ending of a tunnel can coincide 294 with the source or destination of an original packet. 296 Tunnel from node B to node C 297 <---------------------------------------> 298 Tunnel Tunnel 299 Original Entry-Point Exit-Point Original 300 Packet Node Node Packet 301 Source Destination 302 Node Node 303 +-+ +-+ +-+ +-+ 304 | |-->-//->--| |=========>=====//========>=========| |-->-//-->-| | 305 |A| |B| |C| |D| 306 | |--<-//-<--| |=========<=====//========<=========| |--<-//--<-| | 307 +-+ +-+ +-+ +-+ 308 Original Original 309 Packet Packet 310 Destination Tunnel Tunnel Source 311 Node Exit-Point Entry-Point Node 312 Node Node 313 <-------------------------------------> 314 Tunnel from node C to node B 316 Fig. 2. Bidirectional tunneling mechanism effect 318 3.1 IPv6 Encapsulation 320 The IPv6 encapsulation of a packet consists in prepending to the 321 original packet, an IPv6 header and optionally a set of IPv6 322 extension headers, called tunnel IPv6 headers, as graphically shown 323 below in Fig. 3: 325 +----------------------------------//-----+ 326 | Original | | 327 | | Original Packet Payload | 328 | Headers | | 329 +----------------------------------//-----+ 330 < Original packet > 331 | 332 v 333 < Original Packet > 334 +---------+ - - - - - +-------------------------//--------------+ 335 | IPv6 | IPv6 | | 336 | | Extension | Original Packet | 337 | Header | Headers | | 338 +---------+ - - - - - +-------------------------//--------------+ 339 < Tunnel IPv6 packet > 341 Fig. 3. Encapsulating a packet 343 The IPv6 encapsulation takes place in an IPv6 tunnel entry-point 344 node, when transmitting an original packet through the tunnel that 345 begins at that entry-point node. If the transmitting of the original 346 packet through the tunnel is the result of a forwarding operation, 347 the original packet header is processed before encapsulation 348 according to the forwarding rules. For instance if the original 349 packet is an: 351 (a) IPv6 packet, and it is tunneled as result of an IPv6 forwarding 352 operation, the IPv6 original packet hop limit is decremented by 353 one during forwarding. 355 (b) IPv4 packet, and it is tunneled as result of an IPv4 forwarding 356 operation through an IPv6 tunnel, the IPv4 original packet time 357 to live field (TTL) is decremented by one during forwarding. 359 3.2 IPv6 Decapsulation 361 The decapsulation is graphically shown below in Fig. 4: 363 +---------+- - - - - -+----------------------------------//-----+ 364 | IPv6 | IPv6 | | 365 | | Extension | Original Packet | 366 | Headers | Headers | | 367 +---------+- - - - - -+----------------------------------//-----+ 368 < Tunnel IPv6 packet > 369 | 370 v 371 +----------------------------------//-----+ 372 | Original | | 373 | | Original Packet Payload | 374 | Headers | | 375 +----------------------------------//-----+ 376 < Original packet > 378 Fig. 4. Decapsulating a packet from the tunnel IPv6 headers 380 The IPv6 protocol layer of a tunnel exit-point node receiving an IPv6 381 packet destined to one of the node's IPv6 addresses processes the 382 packet according to the IPv6 protocol. A Next Header field value set 383 to a Tunnel Protocol Value (value 41 for IPv6) in the IPv6 header, or 384 the last IPv6 extension header of the packet identifies the packet as 385 a tunnel packet. Upon the completion of the IPv6 protocol layer 386 processing of a tunnel packet, control is given to the Tunnel 387 Protocol layer. The Tunnel Protocol layer discards the tunnel headers 388 and passes the resulting original packet to the Internet or lower 389 layer protocol for further processing - for Next Header value 41, the 390 resulting original packet is passed to the IPv6 protocol layer. 392 3.3 IPv6 Tunnel Protocol Engine 394 The packet flow through the IPv6 Tunnel Protocol Engine is 395 graphically shown below in Fig. 5: 397 +-----------------------+ +-----------------------------------+ 398 | Upper Layer Protocols | | IPv6 Tunnel Upper-Layer | 399 | | | | 400 | | | ---<-------------------<------- | 401 | | | | ---->---|------>--------- | | 402 | | | | | | | | | | 403 +-----------------------+ +-----------------------+ | | | 404 | | | | | | | | | v ^ | 405 v ^ v ^ v ^ v ^ Tunnel | | | | 406 | | | | | | | | packets| | | | 407 +---------------------------------------------+ | | | | 408 | | | | | / / | | | | D E | 409 | v ^ IPv6 | --<-3--/-/--<---- | | | | E N | 410 | | | Layer ---->-4-/-/--->-- | | | | | C C | 411 | v ^ / / | | | | | | A A | 412 | | | 2 1 | | | | | | P P | 413 | v ^ -----<---5---/-/-<---- v ^ v ^ | | S S | 414 | | | | -->---6---/-/-->-- | | | | | | | U U | 415 | v ^ | | / / 6 5 4 3 8 7 | | L L | 416 | | | | | / / | | | | | | | | A A | 417 | v ^ v ^ / / v ^ | | | | | | T T | 418 +---------------------------------------------+ | E E | 419 | | | | | | | | | | | | | | | | 420 v ^ v ^ v ^ v ^ v ^ v ^ Original| | | | 421 | | | | | | | | | | | | packets | v ^ | 422 +-----------------------+ +-----------------------+ | | | 423 | | | | | | | | | | | | 424 | | | | ---|----|-------<-------- | | 425 | | | --->--------------->------>---- | 426 | | | | 427 | Link Layer Protocols | | IPv6 Tunnel Link Layer | 428 +-----------------------+ +-----------------------------------+ 430 Fig. 5. Packet Flow - IPv6 Tunneling Protocol Engine 432 The "tunnel-layer" acts as both an "upper-layer" and a "link layer": 434 (a) The "tunnel upper-layer" has as "input" tunnel IPv6 packets 435 which are going to be decapsulated. The tunnel packets are 436 incoming through the IPv6 layer from a link-layer - (path #1 in 437 Fig. 5) - or from a tunneling link-layer (the exit-point node 438 of an inner tunnel coincides with the exit-point node of an 439 outer tunnel) - (path #7 in Fig. 5). The resulting original 440 packets are passed back to the IPv6 layer as "tunnel link- 441 layer" output for further processing - see (d). 443 (b) The "tunnel upper-layer" has as "output" tunnel IPv6 packets 444 resulting from encapsulation of original packets - see (c) - or 445 packets resulted from previous encapsulations - when this node 446 is an entry-point to an outer tunnel and to an inner tunnel. 447 The "output" tunnel packets are passed through the IPv6 layer 448 down to a link-layer for transmission - (path #2 Fig. 5) - or 449 to a tunnel link-layer for another encapsulation (the entry- 450 point node in an inner tunnel coincides with the entry-point 451 node in an outer tunnel) - (path #8 in Fig. 5). 453 Implementation Note: 455 the "tunnel upper-layer" input and output may be implemented 456 similar to the other upper layer protocols input and output. 458 (c) The "tunnel link-layer" has as "input" original IPv6 packets 459 which are going to be encapsulated. The original packets are 460 incoming through the IPv6 layer from an upper-layer (original 461 packets originated on this node) - (path #4 in Fig. 5) - or 462 from a link layer (original packets originated on a different 463 node) - (path #6 in Fig. 5). The resulting tunnel packets are 464 passed through the IPv6 layer down to a link-layer for 465 transmission - see (b). 467 (d) The "tunnel link-layer" has as "output" original IPv6 packets 468 resulting from decapsulation - see (a) - which are passed 469 through the IPv6 layer up to an upper-layer (the original 470 packet is destined to this node) - (path #3 in Fig. 5) - or 471 down to a link-layer (the original packet is destined to 472 another node, so it is forwarded) - (path #5 in Fig. 5). 474 Implementation Note: 476 the "IPv6 tunnel link layer" input and output may be 477 implemented similar to other link layer protocols input and 478 output, for instance by associating an interface or pseudo- 479 interface with the IPv6 tunnel. 481 The selection of the "IPv6 tunnel link" over other links 482 results from the packet forwarding decision taken based on the 483 content of the node's routing table. 485 4. Recursive Encapsulation 487 Recursive IPv6 encapsulation takes place when portions of an IPv6 488 tunnel are IPv6 tunnels themselves, i.e. a tunnel contains inner 489 tunnels - see Fig. 6. 491 The entry-point node of an "inner IPv6 tunnel" may receive and 492 encapsulate packets that are tunnel IPv6 packets encapsulated at an 493 "outer IPv6 tunnel" entry-point node. These packets are original 494 packets for the "inner IPv6 tunnel" entry-point node, the result of 495 their encapsulation at the "inner IPv6 tunnel entry-point node" is a 496 "tunnel IPv6 packet" for the "inner IPv6 tunnel", and a "recursive 497 tunnel IPv6 packet" for the "outer IPv6 tunnel". 499 Outer Tunnel 500 <-------------------------------------> 501 <--------------> Inner Tunnel 503 Outer Tunnel Outer Tunnel 504 Entry-Point Exit-Point 505 Node Node 506 +-+ +-+ +-+ +-+ +-+ +-+ 507 | | | | | | | | | | | | 508 | |->-//->-| |=>=//=>=| |**>**//**>**| |=>=//=>==| |->-//-->-| | 509 | | | | | | | | | | | | 510 +-+ +-+ +-+ +-+ +-+ +-+ 511 Original Inner Tunnel Inner Tunnel Original 512 Packet Entry-Point Exit-Point Packet 513 Source Node Node Destination 514 Node Node 516 Fig. 6. Recursive Encapsulation 518 4.1 Limiting Recursive Encapsulation 520 There is a practical limit on how many "inner IPv6 tunnels" an "outer 521 IPv6 tunnel" may have which results from the maximum number of 522 possible IPv6 encapsulations of a packet. 524 Each encapsulation adds to the size of a tunnel packet the size of 525 the tunnel IPv6 headers. Consequently, in the case of inner tunnels, 526 the number of recursive encapsulations is practically limited by the 527 number of tunnel IPv6 headers that can be prepended to the original 528 packet before the resulting tunnel packet reaches the maximum IPv6 529 datagram size [IPv6]. 531 The increase in the size of a tunnel IPv6 packet due to repeated 532 recursive encapsulation may require fragmentation at a tunnel entry 533 point node [IPv6] - see section 6.7. 535 Each next recursive encapsulation of a tunnel IPv6 fragment may 536 result in a new fragmentation and thus the addition of one more 537 fragment to the previous existing fragments. Therefore, it is highly 538 probable that once the fragmentation of a tunnel IPv6 packet was 539 triggered, each next recursive encapsulation may result in additional 540 fragmentation, and thus IPv6 fragment multiplication. Therefore, it 541 is recommended to keep recursive encapsulation to a minimum. 543 The proposed mechanism for controlling excessive recursive 544 encapsulation is a "tunnel encapsulation limit" that is carried in an 545 IPv6 Destination Option header. 547 4.1.1 Tunnel Encapsulation Limit 549 The "Tunnel Encapsulation Limit" destination option header is built 550 only by tunnel entry-point nodes, it is discarded only by tunnel 551 exit-point nodes, and it is used to carry optional information [IPv6] 552 that need be examined only by tunnel entry-point nodes. 554 It is defined according to [IPv6] as follows: 556 Option Type Opt Data Len Tun Encap Lim 557 0 1 2 3 4 5 6 7 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |0 0 0 0 0 1 0 0| 1 | u_8int | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 Option Type decimal value 4 - the highest-order two bits - set 563 to 00 - specify "skip over this option if the 564 option is not recognized". The third-highest-order 565 bit - set to 0 - specifies that the option data in 566 this option does not change en-route to the 567 packet's destination [IPv6]. 569 Opt Data Len 1 - the data portion of the Option is one byte 570 long. 572 Tun Encap Lim the Tunnel Encapsulation Limit - 8-bit unsigned 573 integer (u_8int). 575 To avoid excessive recursive encapsulation, an IPv6 tunnel entry- 576 point node may prepend, as part of the IPv6 tunnel headers, a "Tunnel 577 Encapsulation Limit - Destination Extension Header" - with the "Tun 578 Encap Lim - tunnel encapsulation limit" - field set to: 580 (a) a pre-configured value - if the packet has no previous 581 "Tunnel Encapsulation Limit" header - see section 6.6. 583 (b) a value resulting from a pre-existent value - if the packet 584 has a "Tunnel Encapsulation Limit" header, the value is 585 copied into the newly prepended "Tunnel Encapsulation 586 Limit" header and then decremented by one. 588 This is an exception from the rule of processing 589 destination extension headers, in that although the entry- 590 point node is not a destination node, during the 591 encapsulation of a packet, the IPv6 tunneling protocol 592 engine looks ahead in the extant tunnel headers of that 593 packet for the "Tunnel Encapsulation Limit" destination 594 option header. 596 If the Tunnel Encapsulation Limit is decremented to zero, 597 the packet undergoing encapsulation is discarded. Upon 598 dicarding the packet, a Parameter Problem ICMP message 599 [IPv6ICMP] is returned to the packet originator - the 600 Parameter Problem ICMP message points into the Tunnel 601 Encapsulation Limit destination header of the packet, to 602 the Tun Encap Lim field, which has the value one. 604 Two cases of recursive encapsulation that should be avoided are 605 described below: 607 4.1.2 Loopback Recursive Encapsulation 609 A particular case of recursive encapsulation which must be avoided is 610 the loopback recursive encapsulation. Loopback recursive 611 encapsulation takes place when a tunnel IPv6 entry-point node 612 encapsulates tunnel IPv6 packets originated from itself, and destined 613 to itself. This may generate an infinite processing loop in the 614 entry-point node. 616 To avoid such an infinite processing loop in the tunnel entry-point 617 node IPv6 protocol engine, the tunneling engine should not 618 encapsulate packets that have the pair of tunnel entry-point and 619 exit-point addresses the same as the pair of original packet source 620 address and final destination address. To avoid the additional 621 processing in the tunneling protocol engine that the above validation 622 mechanism would require, it is recommended that the validation be 623 done at tunnel configuration time: a node should not permit 624 configuring tunnels where both the entry-point node and exit-point 625 node addresses belong to the entry-point node. 627 4.1.3 Routing Loop Recursive Encapsulation 629 In case of a packet path involving mulitple levels of inner tunnels, 630 a routing loop from an inner tunnel to an outer tunnel is 631 particularly dangerous when the loop is such that a tunnel IPv6 632 packet encapsulated at a certain tunnel entry-point node reaches 633 again that tunnel entry-point node before reaching that tunnel exit- 634 point node. 636 Because there is no relationship between the tunnel IPv6 header hop 637 limit and the original packet hop limit, a tunnel packet reaching its 638 originator - a tunnel entry-point - in a routing loop may expire only 639 after an excessively large number of encapsulations. 641 Additionally, in such a routing loop case, because the prepending of 642 the tunnel IPv6 headers adds to the size of the packets, a tunnel 643 packet may grow to the maximum packet size limit [IPv6], resulting in 644 tunnel packet fragmentation, and fragment multiplication. 646 When the path of a packet from source to final destination includes 647 tunnels, the maximum number of hops that the packet can traverse is 648 controlled by: 650 (a) the original IPv6 packet hop limit, at each forwarding 651 operation performed on the orirginal packet, including at 652 the points where it is encapsulated and decapsulated. 654 (b) the tunnel IPv6 packet encapsulation limit, at each 655 recursive encapsulation of the packet. 657 The two mechanisms mentioned above are used together to avoid the 658 negative effects of routing loops in tunnels. 660 5. Tunnel IPv6 Header 662 The tunnel entry point node fills out a tunnel IPv6 main header 663 [IPv6] as follows: 665 Version: 667 6 669 Priority: 671 Depending on the entry-point node tunnel configuration, the 672 priority may be set to that of the original packet, or to a 673 pre-configured value - see section 6.3. 675 Flow label: 677 Depending on the entry-point node tunnel configuration, the 678 flow label may be set to a pre-configured value. The tipical 679 value is zero - see section 6.4. 681 Payload Length: 683 The original packet length. 685 In case the packet is prepended with tunnel IPv6 extension 686 headers, this value is set to the original packet length 687 plus the length of the encapsulating IPv6 extension headers. 689 Next header: 691 The next header value according to [IPv6] from the Assigned 692 Numbers RFC [RFC-1700]. 694 If the original packet is an IPv6 packet, and there are no 695 intermediate headers, the next header protocol value is set 696 to 41 (Assigned payload type number for IPv6). 698 If a hop by hop option header is immediately following the 699 tunnel IPv6 header, then the next header protocol value in 700 this field is set to 0 (Assigned payload type number for 701 IPv6 Hop by Hop Options header). 703 If a Tunnel Encapsulation Limit destination option header is 704 immediately following the tunnel IPv6 header, then the next 705 header protocol value in this field is set to 60 (Assigned 706 payload type number for IPv6 Destination Options header). 708 Hop limit: 710 The tunnel IPv6 header hop limit is set to a pre-configured 711 value - see Section 6.3. 713 The default value for hosts is the neighbor discovery 714 advertised hop limit [IPv6ND]. The default value for routers 715 is the default IPv6 Hop Limit [TBD] value from the Assigned 716 Numbers RFC. 718 Source Address: 720 IPv6 address of the outgoing interface of the tunnel entry- 721 point node. This address is configured as entry-point node 722 address - see section 6.1. 724 Destination Address: 726 IPv6 address of the tunnel exit-point node. If the tunnel 727 is configured with an unspecified exit-point node address, 728 then the IPv6 address of the destination from the original 729 IPv6 header - see section 6.2. 731 5.1 Tunnel IPv6 Extension Headers 733 Depending on various IPv6 node configuration parameters a tunnel 734 entry-point node may append to the tunnel IPv6 main header, one or 735 more IPv6 extension headers that are not directly related to 736 tunneling, such as hop by hop, routing,...etc, and therefore they are 737 not discussed here. 739 To limit the number of recursive encapsulations of a packet, if it 740 was configured to do so - see section 6.6 - a tunnel entry-point 741 appends after the tunnel IPv6 main header, or after the hop by hop 742 extension header, if any, a Tunnel Encapsulation Limit destination 743 option header with fields set as follows: 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | Next Header |Hdr Ext Len = 0| Opt Type = 4 |Opt Data Len=1 | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | Tun Encap Lim |PadN Opt Type=1|Opt Data Len=1 | 0 | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 Next Header: 753 Identifies the type of header immediately following the 754 Tunnel Encapsulation Limit destination option header [IPv6]. 756 If the original packet is an IPv6 packet, and there are no 757 intermediate headers, the next header protocol value is set 758 to 41 (Assigned payload type number for IPv6). 760 Hdr Ext Len: 762 Length of the Tunnel Encapsulation Limit destination option 763 header in 8-octet units, not including the first 8 octets. 764 Set to value 0. 766 Option Type: 768 4 - see 4.1.1. 770 Opt Data Len: 772 1 - see 4.1.1. 774 Tun Encap Lim: 776 8 bit unsigned integer - see 4.1.1. 778 Option Type: 780 1 - PadN option, to align the header following this header. 782 Opt Data Len: 784 1 - one octet of option data. 786 Option Data: 788 One zero-valued octet. 790 6. IPv6 Tunnel State Variables 792 The IPv6 tunnel state variables, some of which are or may be 793 configured, are: 795 (a) the tunnel entry-point node address - is configured 797 (b) the tunnel exit-point node address - is configured 799 (c) the tunnel hop limit - is configured 801 (d) the tunnel packet priority - is configured 803 (e) the tunnel packet flow label - is configured 805 (f) the tunnel encapsulation limit - may be configured 807 (g) the tunnel MTU 809 6.1 IPv6 Tunnel Entry-Point Node Address 811 The tunnel entry-point node address is one of the valid IPv6 unicast 812 addresses belonging to the entry-point node - it is recommended to 813 validate the address at configuration time. 815 The tunnel entry-point node address is copied to the source address 816 field in the tunnel IPv6 header during packet encapsulation. 818 6.2 IPv6 Tunnel Exit-Point Node Address 820 The tunnel exit-point node address is used as the IPv6 destination 821 address for the tunnel IPv6 header. The tunnel exit-point node 822 address may be configured with a specific IPv6 address, in which case 823 the tunnel acts like a virtual point to point link between the 824 entry-point node and exit-point node, or with the unspecified IPv6 825 address, in which case the tunnel acts like a virtual multi-point 826 link, between the entry-point node and many exit-point nodes, in 827 which case the destination address from each original packet header 828 is used as tunnel IPv6 exit-point node for encapsulating that packet. 830 The tunnel exit-point node address is copied to the destination 831 address field in the tunnel IPv6 header during packet encapsulation. 833 6.3 IPv6 Tunnel Hop Limit 835 An IPv6 tunnel is modeled as a "single-hop virtual link" tunnel, in 836 which regardless of the number of hops in the IPv6 tunnel, the 837 original packet's passing through the tunnel is like the original 838 packet's passing over a one hop link. 840 The "single-hop" mechanism should be implemented by having the tunnel 841 entry point node set a tunnel IPv6 header hop limit independently of 842 the original headers. 844 The "single-hop" mechanism hides to the original IPv6 packets the 845 IPv6 topology of the tunnel. 847 The tunnel hop limit is configured into the tunnel entry-point node 848 with a value that: 850 (a) ensures that tunnel IPv6 packets reach the tunnel exit- 851 point node 853 (b) ensures a quick expiration of the tunnel packet if a 854 routing loop occurs within the IPv6 tunnel. 856 The tunnel hop limit default value for hosts is the neighbor 857 discovery advertised hop limit [IPv6ND]. The tunnel hop limit default 858 value for routers is the default IPv6 Hop Limit [TBD] value from the 859 Assigned Numbers RFC. 861 The tunnel hop limit is copied into the hop limit field of the tunnel 862 IPv6 header of each packet encapsulated by the tunnel entry-point 863 node. 865 6.4 IPv6 Tunnel Packet Priority 867 The IPv6 Tunnel Packet Priority indicates the value that a tunnel 868 entry-point node sets in the priority field of a tunnel header. The 869 default value is zero. The Packet Priority may also indicate whether 870 the value of the priority field in the tunnel header is copied from 871 the original header, or it is set to the configured value. 873 6.5 IPv6 Tunnel Flow Label 875 The IPv6 Tunnel Flow Label indicates the value that a tunnel entry- 876 point node sets in the flow label of a tunnel header. The default 877 value is zero. 879 6.6 IPv6 Tunnel Encapsulation Limit 881 The IPv6 Tunnel Encapsulation Limit may be configured in an entry 882 point node as the maximum number of encapsulations permitted for 883 original packets entering the tunnel at that entry-point node. 884 Recommended default value is 5. 886 An entry-point node configured to limit the number of encapsulations, 887 prepends a Tunnel Encapsulation Limit Destination header to an 888 original packet undergoing encapsulation - see section 5.1. 890 6.7 IPv6 Tunnel MTU 892 The tunnel MTU is set dynamically to the Path MTU of the tunnel - the 893 maximum size of a packet that can be sent through the tunnel without 894 fragmentation - see [IPv6]. The tunnel entry point node performs Path 895 MTU discovery on the tunnel [IPv6PMTU], [IPv6ICMP]. 897 The tunnel's entry-point - the encapsulating node - should be able to 898 send an encapsulated IPv6 packet of any valid size over an IPv6 899 tunnel. 901 If the tunnel entry-point node determines that a packet does not 902 exceed the tunnel MTU after encapsulation, then the tunnel entry- 903 point node encapsulates and sends that packet. 905 If the tunnel entry-point node determines that a packet exceeds the 906 tunnel MTU after encapsulation, then the tunnel entry-point node does 907 one of the following depending on the size of the original packet: 909 (a) if the original packet is larger than 576 octets then the 910 entry-point node returns an ICMP "packet too big" message 911 to the packet originator. The IPv6 node source of the 912 original IPv6 packet resizes - makes packets of smaller 913 size - and retransmits the resulting smaller packets. 915 (b) if the original packet is equal or smaller than 576 octets 916 then the tunnel entry-point node, after encapsulating the 917 original packet, breaks the tunnel packet into fragments 918 that do not exceed the tunnel MTU. 920 The IPv6 packet encapsulation is considered an IPv6 packet 921 originating operation, therefore an IPv6 node that is an IPv6 tunnel 922 entry-point must support fragmentation to encapsulate a packet of any 923 size. 925 A tunnel packet being forwarded follows, like any IPv6 packet, the 926 rule that it must not be fragmented by any IPv6 node other than the 927 originating node - the tunnel entry-point node. 929 7. IPv6 Tunnel Error Processing and Reporting 931 IPv6 Tunneling follows the general rule that errors detected during 932 the processing of IPv6 packets are reported to the packet originator 933 through ICMP messages. 935 For errors detected by nodes that are outside an IPv6 tunnel, on a 936 path that includes IPv6 tunnels, the errors are reported to the 937 original IPv6 packet source node. 939 For errors detected by nodes inside an IPv6 tunnel, ICMP error 940 messages are sent to the tunnel IPv6 packet source node, which is the 941 IPv6 tunnel entry-point node. The ICMP messages sent to the tunnel 942 entry-point node have as ICMP payload the tunnel IPv6 packet that 943 includes the original packet. 945 The cause of an error uncovered inside a tunnel can be: 947 (a) the tunnel header, or 949 (b) the tunnel packet. 951 The tunnel header problems are of concern to the tunnel entry-point 952 node which is the tunnel IPv6 packet originator. 954 The tunnel packet problems that result from bad encapsulation, are of 955 concern also to the tunnel entry-point node. 957 If the tunnel packet problems are a consequence of an original packet 958 problem and if they can be corrected by the original packet 959 originator, then they must be reported to both the tunnel entry-point 960 node and the original packet originator. 962 To report to the original packet originator a problem detected inside 963 the tunnel and reported from inside the tunnel through an ICMP 964 message, the tunnel entry-point node must relay the ICMP message to 965 the original IPv6 packet originator. To relay the ICMP message, the 966 IPv6 tunnel entry-point node builds and sends an ICMP message to the 967 original packet originator, based on the tunnel ICMP message, as it 968 is graphically described below: 970 +-------+ +-------+ +-----------------------+ 971 | Upper | | Upper | | Upper | 972 | Layer | | Layer | | Layer | 973 | Prot. | | Prot. | | IPv6 Tunnel | 974 | Error | | Error | | Error | 975 | Input | | Input | | Input | 976 | | | | | Decapsulate | 977 | | | | | -->--ICMPv6--#2->-- | 978 | | | | | | Payload | | 979 +-------+ +-------+ +--|-----------------|--+ 980 | | | | 981 ^ ^ ^ v 982 | | | | 983 --------------------#1-- -----Orig.Packet?--- - - - - - - - - - 984 error code, | #3 error code, | | 985 ICMPv6 payload ^ v source address, v v 986 | IPv6 | orig. packet | IPv4 | 987 +--------------+ +--------------+ +--------------+ + - - - - + 988 | | | | | | 989 | ICMP v6 | | ICMP v6 | | ICMP v4 | | | 990 | Input | | Error Report | | Error Report | 991 | - - - - +----+ - - - - | + - - - - + + - - - - + 992 | | | | 993 | IPv6 Layer | | IPv4 Layer | | | 994 | | | | 995 +----------------------------------+ +--------------+ + - - - - + 997 Fig. 7. Error Reporting Flow - IPv6 Tunneling Protocol Engine 999 For example, in case of IPv6 original packets, the tunnel entry-point 1000 node IPv6 layer passes the received ICMP message to the ICMPv6 Input. 1001 The ICMPv6 Input, based on the ICMP type and code [IPv6ICMP] 1002 generates an internal "error code" which is passed with the "ICMPv6 1003 message payload" to the upper layer protocol - in this case the IPv6 1004 tunnel upper layer - error input (path #1 in Fig. 7, and (a) in Fig. 1005 8). 1007 The IPv6 tunnel error input decapsulates the tunnel IPv6 packet, 1008 which is the ICMPv6 message payload, obtaining the original packet, 1009 and thus the original headers - path #2 in Fig. 7 and (b) in Fig. 8 - 1010 and dispatches the "error code", the source address from the original 1011 packet header, and the original packet, down to the error report 1012 block of the protocol identified by the Next Header field in the 1013 tunnel header immediately preceding the original packet in the ICMP 1014 message payload - in this example ICMPv6. The ICMPv6 error report 1015 builds an ICMP message of a type and code according to the "error 1016 code", containing the "original packet" as ICMP payload - - path #3 1017 in Fig. 7 and (c) in Fig. 8. The ICMP message has the tunnel entry- 1018 point node address as source address, and the original packet source 1019 node address as destination address - (d) in Fig. 8. The tunnel 1020 entry point node sends the ICMP message to the original packet 1021 originator node. 1023 A graphical description of the header processing taking place is the 1024 following: 1026 < Tunnel packet > 1027 +--------+- - - - - -+--------+------------------------------//------+ 1028 | IPv6 | IPv6 | ICMP | Tunnel | 1029 (a)| | Extension | | IPv6 | 1030 | Header | Headers | Header | Packet in error | 1031 +--------+- - - - - -+--------+------------------------------//------+ 1032 < Tunnel headers > < Tunnel ICMP message > 1033 < ICMPv6 message payload > 1034 | 1035 v 1036 < Tunnel ICMP message > 1037 < Tunnel IPv6 packet in error > 1038 +--------+ +---------+ +----------+--------//------+ 1039 | ICMP | | Tunnel | | Original | Original | 1040 (b) | | <- | IPv6 | <- | IPv6 | IPv6 packet | 1041 | Header | | Headers | | Headers | payload | 1042 +--------+ +---------+ +----------+--------//------+ 1043 | | 1044 ----------------- | | 1045 ----------|--------------- 1046 | | 1047 V V 1048 +---------+ +--------+ +-------------------//------+ 1049 | New | | ICMP | | | 1050 (c) | IPv6 | -> | | -> | Orig. IPv6 packet in error| 1051 | Headers | | Header | | | 1052 +---------+ +--------+ +-------------------//------+ 1054 | 1055 v 1056 +---------+--------+-------------------//------+ 1057 | New | ICMP | Original | 1058 (d) | IPv6 | | IPv6 | 1059 | Headers | Header | packet in error | 1060 +---------+--------+-------------------//------+ 1061 < new ICMP message > 1063 Fig. 8. ICMP Error reporting and processing 1065 7.1 Tunnel ICMP Messages 1067 The tunnel ICMP messages which are reported to the original packet 1068 originator are: 1070 hop limit exceeded 1072 The tunnel is misconfigured, or contains a routing loop, 1073 and packets do not reach the tunnel exit-point node. This 1074 problem is of concern to the tunnel entry point node - the 1075 tunnel hop limit must be reconfigured - and also to the 1076 original IPv6 packet originator. 1078 unreachable node 1080 One of the nodes in the tunnel is not or is no longer 1081 reachable. This is a problem of concern to the tunnel 1082 entry-point node, which should reconfigure the tunnel with 1083 a valid and active path between the entry and exit-point of 1084 the tunnel. 1086 parameter problem 1088 A Parameter Problem ICMP message pointing to a valid Tunnel 1089 Encapsulation Limit Destination header with a Tun Encap Lim 1090 field value set to one is an indication that the tunnel 1091 packet exceeded the maximum number of encapsulations 1092 allowed. 1094 The three above problems detected inside the tunnel, which are a 1095 tunnel configuration and a tunnel topology problem, are reported to 1096 the original IPv6 packet originator, as a tunnel generic 1097 "unreachable" problem caused by a "link problem" - see section 7.2 1098 and 7.3. 1100 packet too big 1102 The tunnel packet exceeds the tunnel Path MTU. The original 1103 packet originator is notified - see section 6.3. If the 1104 original packet is an IPv6 packet, the ICMP message sent to 1105 the packet originator has the same ICMP type/code as the 1106 ICMP message sent from inside the tunnel to the tunnel 1107 entry-point node - see section 7.2, and 7.3. 1109 This ICMP message is used by the tunnel entry point node to 1110 determine the tunnel MTU. 1112 7.2 ICMP Messages for IPv6 Original Packets 1114 The tunnel entry-point node builds the ICMP and IPv6 headers of the 1115 new ICMP message as follows: 1117 IPv6 Fields: 1119 Source Address 1121 A valid unicast IPv6 address of the outgoing interface. 1123 Destination Address 1125 Copied from the Source Address field of the Original 1126 IPv6 header. 1128 ICMP Fields: 1130 For tunnel ICMP error message "hop limit exceeded", or "unreachable 1131 node", or "parameter problem" pointing to a valid Tunnel 1132 Enacpsulation Limit destination header with the Tun Encap Lim field 1133 set to a value one: 1135 Type 1 - unreachable node 1137 Code 3 - address unreachable 1139 For tunnel ICMP error message "packet too big": 1141 Type 2 - packet too big 1143 Code 0 1145 MTU The MTU field from the tunnel ICMP message minus 1146 the length of the tunnel headers. 1148 7.3 ICMP Messages for IPv4 Original Packets 1150 The tunnel entry-point node builds the ICMP and IPv4 header of the 1151 new ICMP message as follows: 1153 IPv4 Fields: 1155 Source Address 1157 A valid unicast IPv4 address of the outgoing interface. 1159 Destination Address 1161 Copied from the Source Address field of the Original 1162 IPv4 header. 1164 ICMP Fields: 1166 For tunnel ICMP error message "hop limit exceeded", or "unreachable 1167 node", or "parameter problem" pointing to a valid Tunnel 1168 Enacpsulation Limit destination header with the Tun Encap Lim field 1169 set to a value one: 1171 Type 3 - destination unreachable 1173 Code 1 - host unreachable 1175 For tunnel ICMP error message "packet too big": 1177 Type 3 - destination unreachable 1179 Code 4 - datagram too big 1181 MTU The MTU field from the tunnel ICMP message minus 1182 the length of the tunnel headers. 1184 8. Open Issues 1186 Open issues are: 1188 (a) Multicast exit point 1190 Does it make sense to have an IPv6 multicast address as tunnel 1191 exit-point node address? 1193 (b) Anycast exit point 1195 Does it make sense to have an IPv6 anycast address as tunnel 1196 exit-point node address? 1198 (c) Tunnel default hop limit value 1200 At this time, there is no definition for an IPv6 hop limit 1201 default value. The Assigned Numbers [RFC-1700] IPv4 TTL default 1202 value could be used instead. 1204 9. References 1206 [IPv6]S. Deering, R. Hinden, "Internet Protocol Version 6 1207 Specification" 1209 [IPv6ICMP] 1210 A. Conta, and S. Deering "Internet Control Message Protocol for 1211 the Internet Protocol Version 6 (IPv6)" 1213 [IPv6ND] 1214 T. Narten, E. Nordmark, "IPv6 Neighbor Discovery Specification" 1216 [IPv6PMTU] 1217 J. McCann and S. Deering, "IPv6 Path MTU Discovery" 1219 [RFC-1700] 1220 J. Reynolds, J. Postel, "Assigned Numbers", 10/20/1994 1222 10.Acknowledgements 1224 The document is partially derived from several ideas about tunneling, 1225 from several discussions about IPv6 in IPv6 tunneling on the IPng 1226 Working Group Mailing List, and from feedback from an IPv6 tunneling 1227 focused IPng Working Group session at the 33th IETF, in Stockholm, 1228 July 1995. 1230 Additionally, several documents focused on tunneling or encapsulation 1231 were used as a reference: "Transition Mechanisms for IPv6 Hosts and 1232 Routers" document by Robert Gilligan and Erik Nordmark, RFC 1241 (R. 1233 Woodburn, and D. Mills), RFC 1326 (P. Tsuchiya), RFC 1701, and RFC 1234 1702 (S. Hanks, D. Farinacci, P. Traina), RFC 1834 (W. Simpson), and 1235 Mobile IP working Group drafts (C. Perkins). 1237 Also an important contribution was made by the reviewers of this 1238 document: [TBD] 1240 11.Security Considerations 1242 Security considerations are not discussed in this memo. 1244 Authors' Addresses: 1246 Alex Conta Stephen Deering 1247 Digital Equipment Corporation Xerox Palo Alto Research Center 1248 110 Spitbrook Rd 3333 Coyote Hill Road 1249 Nashua, NH 03062 Palo Alto, CA 94304 1250 +1-603-881-0744 +1-415-812-4839 1252 email: conta@zk3.dec.com email: deering@parc.xerox.com