idnits 2.17.1 draft-smith-skinny-ipv6-in-ipv6-tunnelling-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 26, 2017) is 2466 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.voyer-6man-extension-header-insertion' is defined on line 690, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-intarea-tunnels-07 == Outdated reference: A later version (-10) exists of draft-voyer-6man-extension-header-insertion-00 -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2423 (Obsoleted by RFC 3801) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force M. Smith 3 Internet-Draft July 26, 2017 4 Intended status: Standards Track 5 Expires: January 27, 2018 7 Skinny IPv6 in IPv6 Tunnelling 8 draft-smith-skinny-ipv6-in-ipv6-tunnelling-00 10 Abstract 12 This memo proposes a method of tunnelling IPv6 packets inside IPv6 13 packets with a reduced tunnelling overhead. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 27, 2018. 32 Copyright Notice 34 Copyright (c) 2017 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. Skinny IPv6-in-IPv6 Virtual Link Characteristics . . . . . . 4 52 4. Addressing Tunnel Endpoints . . . . . . . . . . . . . . . . . 4 53 5. Proxied Inner IPv6 Packet Header Fields . . . . . . . . . . . 6 54 6. Non-Proxied Inner IPv6 Packet Header Fields . . . . . . . . . 6 55 7. Hop Limit Handling . . . . . . . . . . . . . . . . . . . . . 7 56 8. Skinny IPv6-in-IPv6 Tunnel Extension Header . . . . . . . . . 8 57 8.1. Extension Header rather than Destination Option . . . . . 8 58 8.2. Extension Header Format . . . . . . . . . . . . . . . . . 8 59 8.3. Extension Header Fields . . . . . . . . . . . . . . . . . 9 60 9. Encapsulation Procedure . . . . . . . . . . . . . . . . . . . 9 61 9.1. Skinny IPv6-in-IPv6 EH Construction . . . . . . . . . . . 10 62 9.2. Outer IPv6 Packet Construction . . . . . . . . . . . . . 11 63 10. Decapsulation Procedure . . . . . . . . . . . . . . . . . . . 12 64 11. Reduction in Overhead . . . . . . . . . . . . . . . . . . . . 14 65 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 66 13. Security Considerations . . . . . . . . . . . . . . . . . . . 14 67 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 68 15. Change Log [RFC Editor please remove] . . . . . . . . . . . . 14 69 16. Informative References . . . . . . . . . . . . . . . . . . . 15 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 72 1. Introduction 74 There have been some recent proposals to insert additional 75 information via Extension Headers (EHs) into IPv6 packets that are 76 currently "in-flight", with in-flight meaning that they have left the 77 source host that originated the packet and are on their way across 78 the network towards the packet's destination host [I-D.voyer-6man-ext 79 ension-header-insertion][I-D.francois-dots-ipv6-signal-option]. 81 The fundamental drawback of inserting EHs into existing packets is 82 that while the inserted EH is present, the IPv6 header's Source 83 Address field's semantics are incorrect, as the device with the 84 recorded source address is not the source of the inserted EH. 86 If the inserted EH causes the packet to trigger a mechanism that 87 relies on IPv6 header Source Address semantics, such as Path MTU 88 Discovery [RFC1981], the triggered mechanism may fail. This is 89 because the mechanism's messages will be sent to the source address 90 indicated, rather than the device that inserted the EH. The device 91 inserting the EH is not identified in the packet so that messages can 92 be sent to it if necessary. 94 Troubleshooting is also impacted, in particular when packets are 95 received over long Autonomous System paths across the Internet. If 96 an inserted EH is received and causes failures, it isn't possible to 97 identify which AS inserted the EH from the received packet. 98 Significant time will need to be spent contacting each AS that may 99 have inserted the EH, to then inform them that they aren't removing 100 the EHs they're inserting. 102 The alternative to inserting EHs is to add EHs using IPv6-in-IPv6 103 tunnelling e.g., via [RFC2423]. A new IPv6 packet is created with 104 the new EH, with the original packet then being the new IPv6 packet's 105 payload. As the source of the added EH is now identified in the 106 outer IPv6 packet header, mechanisms such as PMTUD will work 107 correctly if addition of the EH triggers the mechanism. 109 The drawback of conventional IPv6-in-IPv6 tunnelling is the overhead 110 of adding another IPv6 header to the original IPv6 packet, a minimum 111 of an additional 40 octets. It is likely that insertion of EHs into 112 existing in-flight packets was motivated by trying to avoid this 113 tunnelling encapsulation overhead. 115 From the perspective of the original and inner IPv6 packet, IPv6-in- 116 IPv6 tunnelling is treating the outer or underlying IPv6 network as 117 though it was a link-layer. The inner IPv6 packet is treated by the 118 outer IPv6 packet as a link-layer opaque payload 119 [I-D.ietf-intarea-tunnels]. 121 A property unique to IPv6-in-IPv6 tunnelling, unlike other link-layer 122 encapsulations of IPv6 packets, is that all fixed header fields of 123 the outer IPv6 "link-layer" packet have the same semantics as all 124 fixed header fields of the inner and being carried IPv6 packet. 126 If opaque treatment of the inner IPv6 packet by the outer IPv6 packet 127 is compromised, matching inner and outer IPv6 packet field semantics 128 provides the opportunity to reduce the IPv6-in-IPv6 tunnelling 129 overhead. This can be achieved by partially or fully using a number 130 of the outer IPv6 packet's fields as proxies for the inner packet's 131 fields while the inner packet is in-flight over the outer IPv6 "link- 132 layer". These inner IPv6 packet's fields are removed during link- 133 layer encapsulation and then restored during link-layer 134 decapsulation, using the values of the fields from the outer IPv6 135 packet. 137 This memo describes this method of IPv6-in-IPv6 tunnelling, giving it 138 the name "Skinny IPv6-in-IPv6 Tunnelling". It preserves source 139 address semantics for both the inner and outer packet source 140 addresses, allowing mechanisms such as PMTUD to function, while also 141 reducing tunnelling overhead. 143 In essence, this memo is a specification for a method of using IPv6 144 as a link-layer, adding to others in that set such as [RFC2423]. 146 A number of the techniques and concepts have been taken from or 147 inspired by the previous draft [I-D.smith-enhance-vne-with-ipv6]. 149 2. Terminology 151 Terminology used in this memo is from "IP Tunnels in the Internet 152 Architecture" [I-D.ietf-intarea-tunnels]. 154 3. Skinny IPv6-in-IPv6 Virtual Link Characteristics 156 A virtual link created using this method has the following 157 characteristics: 159 o Limited to carrying IPv6 packets as link-layer payload. As many 160 IPv4 packet fields have similar if not the same semantics as IPv6 161 packet fields, a similar method could be used for carrying IPv4 in 162 IPv6, however this is out of scope for this memo. 164 o Point-to-multipoint transmission via IPv6 multicast. A link node 165 (tunnel endpoint) can send a single packet, have it duplicated by 166 the link (the underlying IPv6 network) and then have the 167 duplicates arrive at multiple destination link nodes. The set of 168 destination link nodes or tunnel endpoints are identified by an 169 IPv6 multicast address. 171 o Can be used to create a single link-layer instance (e.g., a single 172 point-to-point connection between two routers, hosts, or a host 173 and a router, or a single multi-access link interconnecting a set 174 of routers), or as one of a set of component links used to create 175 a link-layer instance (i.e., a multi-link link-layer topology, 176 where links are bridged together.). In this latter case, a link- 177 layer loop prevention mechanism may be needed. 179 4. Addressing Tunnel Endpoints 181 Initially suggested in [I-D.smith-enhance-vne-with-ipv6], Skinny 182 IPv6-in-IPv6 tunnelling uses individual /64s to identify individual 183 tunnel endpoints, rather than using individual IPv6 addresses (i.e., 184 /128s). 186 For Skinny IPv6-in-IPv6 unicast tunnelling to a tunnel endpoint, this 187 allows the lower 64 bits of the outer packet's source and destination 188 addresses (the Interface Identifier or IID parts) to carry the 189 corresponding lower 64 bits of the inner packet's source and 190 destination addresses. These two sets of 64 bits are removed from 191 the inner IPv6 packet's addresses, effectively lowering the 192 tunnelling overhead by 16 octets. 194 Multicast Skinny IPv6-in-IPv6 tunnel endpoints cannot be identified 195 by /64s, as IPv6 multicast groups cannot be uniquely created at the 196 /64 boundary. When multicast tunnelling towards a multicast group of 197 tunnel endpoints, only the inner packet source address lower 64 bits 198 are carried in the outer packet's source address lower 64 bits, and 199 removed from the inner source address. The inner packet's full 128 200 bit destination address is carried in the Skinny IPv6-in-IPv6 tunnel 201 header. The removal of the inner packet's source address lower 64 202 bits reduces the tunnelling overhead by 8 octets. 204 An emergent benefit of this technique of carrying inner packet IIDs 205 in the outer packet's addresses between tunnel endpoints is that 206 inner packet address entropy useful for load balancing is exposed to 207 the network carrying the outer packets. 209 Skinny IPv6-in-IPv6 tunnel endpoints are expected to be represented 210 as virtual interfaces in routers or hosts, and therefore will have at 211 least a Link-Local unicast /128 address per the [RFC4291] interface 212 address requirements, and perhaps other individual IPv6 addresses. 214 The use of /64s to identify tunnel endpoints means that for other 215 non-Skinny IPv6-in-IPv6 traffic originated by or sent to the tunnel 216 endpoint, any of the individual IPv6 addresses within the /64 are 217 valid as local source or destination addresses for this traffic. 218 Examples of other types of traffic originated by or sent to tunnel 219 endpoints could be ICMPv6, TCP, or UDP. 221 When receiving non-Skinny IPv6-in-IPv6 packets, a tunnel endpoint is 222 to consider all destination addresses within its assigned /64 valid 223 and local, passing the received packets' payload to the appropriate 224 upper layer protocol if supported, or dropping if not and possibly 225 emitting an appropriate ICMPv6 message. 227 When originating non-Skinny IPv6-in-IPv6 packets from a source 228 address within the assigned /64, a common individual address within 229 the /64 should be used for all packets, to avoid confusing a receiver 230 that does not expect a single device to be assigned an entire /64. 231 Alternatively, per connection or per protocol common individual 232 source address could be used if useful. Consistent and expected 233 source address usage by the sender is the requirement at the receiver 234 that needs to be met. 236 If the tunnel endpoint exists on a router (more specifically, is a 237 forwarding interface), then the source address for tunnel endpoint 238 originated packets could be the Subnet-Router anycast address 239 [RFC4291], the endpoint's /64 plus an IID of all zeros. 241 Alternatively, if the tunnel endpoint exists on a host (more 242 specifically, is a non-forwarding interface), then the source address 243 should not be the Subnet-Router anycast address. Some other address 244 within the /64, such as a statically configured address, or an 245 address generated by the SLAAC procedure [RFC4862][RFC7217][RFC8064] 246 should be used. Non-Subnet Router anycast source addresses could 247 also be used by tunnel endpoints on routers. 249 In any of these cases, source and destination address selection will 250 occur per the standard IPv6 default address selection procedure 251 [RFC6724], unless a specific source and/or destination address is 252 provided. 254 5. Proxied Inner IPv6 Packet Header Fields 256 While the inner IPv6 packet is being tunnelled, the following inner 257 packet header fields are proxied by the fields in the outer IPv6 258 packet header [RFC2460]: 260 o Version 262 o Traffic Class 264 o Flow Label 266 o Source Address lower 64 bits for both unicast and multicast tunnel 267 destination endpoints 269 o Destination Address lower 64 bits for unicast tunnel destination 270 endpoints 272 6. Non-Proxied Inner IPv6 Packet Header Fields 274 While the inner IPv6 packet is being tunnelled, values of the 275 following inner packet header fields [RFC2460] are carried in fields 276 in the Skinny IPv6-in-IPv6 Extension Header. This allows them to be 277 restored upon decapsulation, as the outer packet's header field 278 values cannot or may not be used. 280 o Payload Length 282 o Hop Limit 284 o Source Address upper 64 bits 285 o Destination Address upper 64 bits 287 o Destination Address lower 64 bits for multicast tunnel destination 288 endpoints 290 7. Hop Limit Handling 292 Conventional link-layers commonly do not have a hop count or hop 293 limit field in their frames to mitigate the effects of link-layer 294 forwarding loops. A separate mechanism or method must be used to 295 prevent forwarding loops occurring. 297 When IPv6 is being used as a link-layer, the packet's Hop Limit field 298 and processing acts as a link-layer forwarding loop mitigation 299 mechanism. 301 It could be useful to have the number of hops the outer packet took 302 included in the inner packet's recorded Hop Limit after the inner 303 packet has traversed the tunnel. This would expose the outer IPv6 304 packet hops that occurred during tunnelling to the inner IPv6 305 packet's network. This may be useful for troubleshooting, or 306 mitigating forwarding loops sooner. 308 Alternatively, the number of hops the outer IPv6 packet took could be 309 hidden from the inner IPv6 packet's network, by restoring the Hop 310 Limit value from the Hop Limit field value in the Skinny IPv6-in-IPv6 311 Extension Header. Restoring the inner packet's pre-Skinny Ipv6-in- 312 IPv6 Hop Limit value is critical when the Neighbor Discovery protocol 313 [RFC4861] is used across the Skinny IPv6-in-IPv6 virtual link. This 314 is necessary as to ensure these ND packets have not come from an off- 315 link source, their Hop Limit is set to 255 upon transmission and the 316 recipient will only accept ND packets that arrive with a Hop Limit 317 value of 255. 319 Whether to use the outer packet's Hop Limit value or to use the inner 320 Skinny IPv6-in-IPv6 EH preserved Hop Limit value during inner IPv6 321 packet header reconstruction is indicated by the value of the Skinny 322 IPv6-in-IPv6 EH preserved Hop Limit field value when it arrives at 323 the destination tunnel endpoint. If the value is 0, the outer IPv6 324 packet header's current Hop Limit value is used during 325 reconstruction, where as if the value is non-zero (e.g., 255 for ND 326 packets), then that value is used during inner IPv6 packet 327 reconstruction. 329 8. Skinny IPv6-in-IPv6 Tunnel Extension Header 331 While the original IPv6 packet is being tunnelled, the Skinny IPv6 332 Extension Header carries the particles of the original inner IPv6 333 packet's header that are or may not be being proxied in the outer 334 IPv6 packet header. 336 8.1. Extension Header rather than Destination Option 338 [RFC6564] requires justification for the creation of a new Extension 339 Header rather than the creation of a new Destinations Options Header 340 option. 342 The creation of a Skinny IPv6-in-IPv6 Extension Header is requested 343 for the following reasons: 345 o Simplified header processing, which will be beneficial at high 346 packet per second rates. The receiving device will only need to 347 look up a single Next Header value in either the outer IPv6 header 348 or the previous Extension Header to determine that a Skinny IPv6- 349 in-IPv6 EH follows. This is in comparison to a two stage lookup 350 to process a Destination Option in a Destination Option EH. 352 o Consistent with other IPv6-in-IPv6 tunnelling encapsulations that 353 use Extension Headers such as conventional IPv6-in-IPv6 [RFC2423] 354 and GRE [RFC7676]. 356 8.2. Extension Header Format 358 (ASCII art to come!) 360 o Next Header - 8 bits. 362 o Hdr Ext Len - 8 bits. 364 o Reserved - 24 bits. 366 o Inner Payload Length - 16 bits. 368 o Inner Hop Limit - 8 bits. 370 o Inner SA 64 bit Prefix - 64 bits / 8 octets. 372 o Inner DA 64 bit Prefix - 64 bits / 8 octets. 374 o Inner DA 64 bit IID - 64 bits / 8 octets. 376 8.3. Extension Header Fields 378 o Next Header - 8 bits field, specifying the header type of the 379 header that immediately followed the inner IPv6 packet's original 380 IPv6 fixed header. May be another extension header value, or an 381 upper layer protocol value such as UDP or TCP. 383 o Hdr Ext Len - 8 bit field, specifying the length of this Skinny 384 IPv6-in-IPv6 extension header in units of 8 octets, minus the 385 first unit of 8 octets. The valid values are 2 or 3. 387 o Reserved - 24 bits field reserved for future use, to 8 octet align 388 the extension header. Set to zero upon transmission, ignored upon 389 receipt. A possible future use of one or more of these octets is 390 as a flag field. 392 o Inner Payload Length - 16 bits Payload Length field value from the 393 inner IPv6 packet before Skinny IPv6-in-IPv6 encapsulation 394 occurred. 396 o Inner Hop Limit - 8 bits Hop Limit field value from inner IPv6 397 packet before Skinny IPv6-in-IPv6 encapsulation occurred, or zero. 399 o Inner SA 64 bit Prefix - upper 64 bits / 8 octets of the inner 400 IPv6 packet's source address, prior to Skinny IPv6-in-IPv6 401 encapsulation. 403 o Inner DA 64 bit Prefix - upper 64 bits / 8 octets of the inner 404 IPv6 packet's destination address, prior to Skinny IPv6-in-IPv6 405 encapsulation. 407 o Inner DA 64 bit IID - optional lower 64 bits / 8 octets of the 408 inner IPv6 packet's destination address when the outer Skinny 409 IPv6-in-IPv6 packet's destination is a multicast group of tunnel 410 endpoints. 412 9. Encapsulation Procedure 414 The following steps describe the encapsulation procedure performed by 415 the ingress Skinny IPv6-in-IPv6 tunnel endpoint upon a IPv6 packet 416 that is being tunnelled. Note that it is a functional description, 417 meaning that implementations may perform different and more 418 performance oriented steps that achieve the same functional outcome. 420 After receiving the packet to be Skinny IPv6-in-IPv6 tunnelled from 421 the upper IPv6 network layer: 423 9.1. Skinny IPv6-in-IPv6 EH Construction 425 1. Create a new instance of the Skinny IPv6-in-IPv6 Extension 426 Header. If the destination tunnel endpoint is a multicast 427 destination, the new EH instance will need to provide the 428 optional Inner DA 64 bit IID field. 430 2. Set the new EH's Next Header value to the Next Header value in 431 the original IPv6 packet header's Next Header field value. 433 3. If the destination Skinny-IPv6-in-IPv6 tunnel endpoint is an 434 individual /64, set the new EH's Hdr Ext Len field value to 2. 435 If the destination Skinny-IPv6-in-IPv6 tunnel endpoint is a 436 multicast address, set the new EH's Hdr Ext Len field value to 437 3. 439 4. Set the new EH's Reserved field bits all to zeros. 441 5. Set the new EH's Inner Payload Length field to the original IPv6 442 packet header's Payload Length field value. 444 6. If the tunnel endpoint is configured to use the outer IPv6 445 packet header's Hop Limit value after tunnelling when 446 reconstructing the inner IPv6 packet during decapsulation, set 447 the new EH's Inner Hop Limit field value to zero. 449 7. If the tunnel endpoint is not configured to use the original 450 IPv6 packet header's Hop Limit value after tunnelling, the 451 default configuration, set the new EH's Inner Hop Limit field 452 value to the original inner IPv6 packet's Hop Limit value (note 453 that this will be after the Hop Limit has been decremented if 454 the IPv6 packet is being forwarded per [RFC2460]). 456 8. Set the new EH's Inner SA 64 bit Prefix field to the high order 457 8 octets of the original IPv6 packet header's source address 458 high order 8 octets. 460 9. Set the new EH's Inner DA 64 bit Prefix field to the high order 461 8 octets of the original IPv6 packet header's destination 462 address high order 8 octets. 464 10. If the destination Skinny-IPv6-in-IPv6 tunnel endpoint is a 465 multicast address, set the new EH's Inner DA 64 bit IID field to 466 the low order 8 octets of the original IPv6 packet header's 467 destination address low order 8 octets. 469 9.2. Outer IPv6 Packet Construction 471 1. Create a new instance of an IPv6 packet header, and set its 472 Version field value to 6. 474 2. Set the new IPv6 packet header's Traffic Class field value to 475 the original IPv6 packet header's Traffic Class field value. 477 3. Set the new IPv6 packet header's Flow Label field value to the 478 original IPv6 packet header's Flow Label field value. 480 4. If the tunnel endpoint is configured to use the outer IPv6 481 packet header's Hop Limit value after tunnelling when 482 reconstructing the inner IPv6 packet during decapsulation, set 483 the new IPv6 packet header's Hop Limit to the original inner 484 IPv6 packet header's Hop Limit field value. 486 5. If the tunnel endpoint is not configured to use the original 487 IPv6 packet header's Hop Limit value after tunnelling, the 488 default configuration, set the new IPv6 packet header's Hop 489 Limit field value to the device's current Hop Limit default 490 value when originating packets. 492 6. Set the new IPv6 packet header's Source Address high order 8 493 octets/64 bits to the tunnel endpoint's /64 value. 495 7. Set the new IPv6 packet header's Source Address low order 8 496 octets/64 bits to the original IPv6 packet's Source Address low 497 order 8 octets. 499 8. Set the new IPv6 packet header's Destination Address high order 500 8 octets/64 bits to the destination tunnel endpoint's /64 value, 501 or for a multicast tunnel destination, the high order 8 octets 502 of the destination multicast address. 504 9. Set the new IPv6 packet header's Destination Address low order 8 505 octets/64 bits to the original IPv6 packet's Destination Address 506 lower order 8 octets, or for a multicast tunnel destination, the 507 low order 8 octets of the destination multicast address. 509 10. Append any additional tunnel endpoint specific EHs to the new 510 IPv6 packet header. 512 11. Set the new IPv6 packet header's Next Header field value to the 513 first of the tunnel endpoint specific EHs selector value. 515 12. Append the Skinny IPv6-in-IPv6 EH to the end of the existing set 516 of EHs. 518 13. Append the original IPv6 packet's set of EHs after the Skinny 519 IPv6-in-IPv6 EH, if any exist. 521 14. Append the original IPv6 packet's payload. 523 15. Set the new IPv6 packet header's Payload Length value based on 524 the tunnel endpoint specific EHs, the Skinny IPv6-in-IPv6 EH and 525 the original IPv6 packet's payload. 527 16. Discard the original IPv6 packet, as it has now been fully 528 Skinny IPv6-in-IPv6 encapsulated. 530 17. Send the new IPv6 Skinny IPv6-in-IPv6 packet. 532 10. Decapsulation Procedure 534 The following steps describe the decapsulation procedure performed by 535 the egress Skinny IPv6-in-IPv6 tunnel endpoint upon a IPv6 packet 536 that has been tunnelled. Note that it is a functional description, 537 meaning that implementations may perform different and more 538 performance oriented steps that achieve the same functional outcome. 539 (An obvious optimisation is to utilise the received packet header 540 when reconstructing the original Skinny IPv6-in-IPv6 tunnelled 541 packet's header, avoiding a number of copy operations among other 542 things.) 544 After receiving the Skinny IPv6-in-IPv6 packet from the network: 546 1. Perform any Extension Header processing for the EHs that reside 547 after the received fixed IPv6 header and before the Skinny IPv6- 548 in-IPv6 Extension Header. 550 2. Create a new instance of an IPv6 packet header, and set its 551 Version field value to 6. This is the IPv6 packet header that 552 is being used to reconstruct the original inner IPv6 packet. 554 3. From the received Skinny IPv6-in-IPv6 outer packet header, copy 555 the Traffic Class field value into the new IPv6 header's Traffic 556 Class field. 558 4. From the received Skinny IPv6-in-IPv6 outer packet header, copy 559 the Flow Label field value into the new IPv6 header's Flow Label 560 field. 562 5. From the Skinny IPv6-in-IPv6 Extension Header, copy the Inner 563 Payload Length field value into the new IPv6 header's Payload 564 Length field. 566 6. From the Skinny IPv6-in-IPv6 Extension Header, copy the Next 567 Header field value into the new IPv6 header's Next Header field. 569 7. If the Skinny IPv6-in-IPv6 Extension Header's Inner Hop Limit 570 field value is 0, copy the received Skinny IPv6-in-IPv6 outer 571 packet header's Hop Limit field value into the new IPv6 header's 572 Hop Limit field. 574 8. If the Skinny IPv6-in-IPv6 Extension Header's Inner Hop Limit 575 field value is not 0, copy the Skinny IPv6-in-IPv6 Extension 576 Header's Inner Hop Limit field value into the new IPv6 header's 577 Hop Limit field. 579 9. From the Skinny IPv6-in-IPv6 Extension Header, copy the SA 64 580 bit Prefix into the high order 64 bits of the new IPv6 header's 581 Source Address field. 583 10. From the received Skinny IPv6-in-IPv6 outer packet header, copy 584 the low order 64 bits of the Source Address into the low order 585 64 bits of the the new IPv6 header's Source Address field. 587 11. From the Skinny IPv6-in-IPv6 Extension Header, copy the DA 64 588 bit Prefix into the high order 64 bits of the new IPv6 header's 589 Destination Address field. 591 12. If the Skinny IPv6-in-IPv6 Extension Header's Hdr Ext Len field 592 value is 2, copy the low order 64 bits of the Destination 593 Address from the received Skinny IPv6-in-IPv6 outer packet 594 header into the low order 64 bits of the new IPv6 header's 595 Destination Address field. 597 13. If the Skinny IPv6-in-IPv6 Extension Header's Hdr Ext Len field 598 value is 3, copy the Skinny IPv6-in-IPv6 Extension Header's 599 Inner DA 64 bit IID field value into the low order 64 bits of 600 the new IPv6 header's Destination Address field. 602 14. If the Skinny IPv6-in-IPv6 Extension Header's Hdr Ext Len field 603 value is not 2 or 3, discard the new IPv6 packet header and the 604 received Skinny IPv6-in-IPv6 packet; if required, record them as 605 discarded (e.g., in a tunnel interface discarded packet 606 counter); and abort the decapsulation procedure. 608 15. Append any Extension Headers that followed the Skinny IPv6-in- 609 IPv6 Extension Header to the new IPv6 header. 611 16. Append the Skinny IPv6-in-IPv6's packet's payload to the new 612 IPv6 packet, after the appended Extension Headers. 614 17. Discard the received Skinny IPv6-in-IPv6 packet. 616 18. Submit the new IPv6 packet to the device's upper IPv6 layer for 617 further processing (such as forwarding or local processing based 618 on the destination address). 620 11. Reduction in Overhead 622 Conventional IPv6 tunnelling described in [RFC2423] adds at least 623 another 40 octets to the original packet being tunnelled, as that is 624 the size of the fixed IPv6 header. 626 Using the method described in this memo, for packets destined to a 627 single (unicast) tunnel endpoint, this 40 octet overhead is reduced 628 to 24 octets, a saving of 16 octets. This is a 40 percent saving. 630 Using the method described in this memo, for packets destined to 631 multiple tunnel endpoint identified by an IPv6 multicast address, 632 this 40 octet overhead is reduced to 32 octets, a saving of 8 octets. 633 This is a 20 percent saving. 635 12. IANA Considerations 637 IANA are requested to allocate an IPv6 Next Header value for use by 638 the Skinny IPv6-in-IPv6 Extension header, per [RFC5237]. 640 13. Security Considerations 642 There are no security considerations specific to Skinny IPv6-in-IPv6 643 tunnelling. General tunnelling security considerations apply 644 [RFC6169]. 646 14. Acknowledgements 648 Review and comments were provided by YOUR NAME HERE! 650 This memo was prepared using the xml2rfc tool. 652 15. Change Log [RFC Editor please remove] 654 draft-smith-skinny-ipv6-in-ipv6-tunnelling-00, initial version, 655 2017-07-13 657 draft-smith-skinny-ipv6-in-ipv6-tunnelling-01, first revision, 658 2017-07-13 660 o Forgot Abstract in 00. Facepalm! 661 draft-smith-skinny-ipv6-in-ipv6-tunnelling-02, second revision, 662 2017-07-13 664 o Typo in Abstract. Facepalm again! 666 draft-smith-skinny-ipv6-in-ipv6-tunnelling-01, third revision, 2017- 667 0x-xx 669 o Revert revision back to 00, as IETF ID submission tool complains. 670 Previous were private revisions, waiting for IETF ID tool to 671 become available again (two weeks pre-IETF99 meeting) 673 16. Informative References 675 [I-D.francois-dots-ipv6-signal-option] 676 Francois, J., Lahmadi, A., and M. Davids, "IPv6 DOTS 677 Signal Option", draft-francois-dots-ipv6-signal-option-02 678 (work in progress), May 2017. 680 [I-D.ietf-intarea-tunnels] 681 Touch, J. and M. Townsley, "IP Tunnels in the Internet 682 Architecture", draft-ietf-intarea-tunnels-07 (work in 683 progress), June 2017. 685 [I-D.smith-enhance-vne-with-ipv6] 686 Smith, M., "Enhancing Virtual Network Encapsulation with 687 IPv6", draft-smith-enhance-vne-with-ipv6-07 (work in 688 progress), October 2015. 690 [I-D.voyer-6man-extension-header-insertion] 691 daniel.voyer@bell.ca, d., daniel.bernier@bell.ca, d., 692 Leddy, J., Filsfils, C., Previdi, S., Salsano, S., 693 Cianfrani, A., Lebrun, D., Bonaventure, O., Jonnalagadda, 694 P., Sharif, M., Elmalky, H., Abdelsalam, A., Raszuk, R., 695 Ayyangar, A., Steinberg, D., and W. Henderickx, "Insertion 696 of IPv6 Segment Routing Headers in a Controlled Domain", 697 draft-voyer-6man-extension-header-insertion-00 (work in 698 progress), March 2017. 700 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 701 for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August 702 1996, . 704 [RFC2423] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME 705 Sub-type Registration", RFC 2423, DOI 10.17487/RFC2423, 706 September 1998, . 708 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 709 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 710 December 1998, . 712 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 713 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 714 2006, . 716 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 717 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 718 DOI 10.17487/RFC4861, September 2007, 719 . 721 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 722 Address Autoconfiguration", RFC 4862, 723 DOI 10.17487/RFC4862, September 2007, 724 . 726 [RFC5237] Arkko, J. and S. Bradner, "IANA Allocation Guidelines for 727 the Protocol Field", BCP 37, RFC 5237, 728 DOI 10.17487/RFC5237, February 2008, 729 . 731 [RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security 732 Concerns with IP Tunneling", RFC 6169, 733 DOI 10.17487/RFC6169, April 2011, 734 . 736 [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and 737 M. Bhatia, "A Uniform Format for IPv6 Extension Headers", 738 RFC 6564, DOI 10.17487/RFC6564, April 2012, 739 . 741 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 742 "Default Address Selection for Internet Protocol Version 6 743 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 744 . 746 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 747 Interface Identifiers with IPv6 Stateless Address 748 Autoconfiguration (SLAAC)", RFC 7217, 749 DOI 10.17487/RFC7217, April 2014, 750 . 752 [RFC7676] Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support 753 for Generic Routing Encapsulation (GRE)", RFC 7676, 754 DOI 10.17487/RFC7676, October 2015, 755 . 757 [RFC8064] Gont, F., Cooper, A., Thaler, D., and W. Liu, 758 "Recommendation on Stable IPv6 Interface Identifiers", 759 RFC 8064, DOI 10.17487/RFC8064, February 2017, 760 . 762 Author's Address 764 Mark Smith 765 PO BOX 521 766 HEIDELBERG, VIC 3084 767 AU 769 Email: markzzzsmith@gmail.com