idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-17.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 (17 January 2022) is 829 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man R. Bonica 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track Y. Kamite 5 Expires: 21 July 2022 NTT Communications Corporation 6 L. Jalil 7 Verizon 8 Y. Zhou 9 ByteDance 10 G. Chen 11 Baidu 12 17 January 2022 14 The IPv6 Tunnel Payload Forwarding (TPF) Option 15 draft-bonica-6man-vpn-dest-opt-17 17 Abstract 19 This document explains how IPv6 options can be used in IPv6 tunnels. 20 It also defines the IPv6 Tunnel Payload Forwarding (TPF) option. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 21 July 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 57 3. The IPv6 Tunnel Payload Forwarding (TPF) Option . . . . . . . 4 58 4. TPF Information Determines Next-Protocol Engine Behavior . . 5 59 5. TPF Information Semantics . . . . . . . . . . . . . . . . . . 5 60 6. Virtual Private Networking (VPN) Applications . . . . . . . . 6 61 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 63 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 64 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 65 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 67 11.2. Informative References . . . . . . . . . . . . . . . . . 8 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 70 1. Introduction 72 This document explains how IPv6 options [RFC8200] can be used in IPv6 73 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) 74 option. 76 An IPv6 tunnel [RFC2473] connects two nodes, called the entry-point 77 and the exit-point. The entry-point receives a packet and 78 encapsulates it in a Tunnel IPv6 Header. Figure 1 depicts the 79 encapsulation. 81 +----------------------------------//-----+ 82 | Original | | 83 | | Original Packet Payload | 84 | Header | | 85 +----------------------------------//-----+ 86 < Original Packet > 87 | 88 v 89 < Original Packet > 91 +---------+ - - - - - +-------------------------//--------------+ 92 | IPv6 | IPv6 | | 93 | | Extension | Original Packet | 94 | Header | Headers | | 95 +---------+ - - - - - +-------------------------//--------------+ 96 < Tunnel IPv6 Packet > 98 Figure 1: IPv6 Tunnel Encapsulation 100 The original packet can be any layer-2 or layer-3 packet (e.g., 101 Ethernet, IPv4, IPv6). The Tunnel Header is an IPv6 header followed 102 by zero or more extension headers. The resulting packet is a Tunnel 103 IPv6 Packet. 105 The entry-point sends the Tunnel IPv6 Packet to the exit-point which 106 then executes the following procedure: 108 * Process the Tunnel IPv6 Header. 110 * Remove the Tunnel IPv6 Header, exposing the original packet. 112 * Submit the original packet to the next-protocol engine. 114 The exit-point node processes the Tunnel IPv6 Header in strict left- 115 to-right order. It processes the IPv6 header first and then 116 processes extension headers in the order that they appear in the 117 packet. The IPv6 header, and each extension header, includes a Next 118 Header field. The last Next Header field processed identifies the 119 next-protocol engine. 121 Entry-point nodes can send optional information to the next-protocol 122 engine on the exit-point node. For example, the entry-point can 123 indicate: 125 * The interface through which the next-protocol engine should send 126 the packet. 128 * The routing table that the next-protocol engine should use to 129 process the packet. 131 To send this information, the entry-point node includes an IPv6 132 Destination Option header in the Tunnel IPv6 Header. The IPv6 133 Destination Options header includes an IPv6 TPF option and the IPv6 134 TPF option includes TPF information. The next-protocol engine on the 135 exit-point node uses TPF information when it forwards the original 136 packet. 138 2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 142 "OPTIONAL" in this document are to be interpreted as described in BCP 143 14 [RFC2119] [RFC8174] when, and only when, they appear in all 144 capitals, as shown here. 146 3. The IPv6 Tunnel Payload Forwarding (TPF) Option 148 The TPF Option contains the following fields: 150 * Option Type: 8-bit selector. TPF option. Value TBD by IANA. 151 (Suggested value: 0x41). See Note below. 153 * Opt Data Len - 8-bit unsigned integer. Length of the option, in 154 octets, excluding the Option Type and Option Length fields. This 155 field MUST be set to 4. 157 * Option Data - 32-bits. Tunnel Payload Forwarding (TPF) 158 Information. 160 The TPF option MAY appear in a Destination Options header that 161 precedes an upper-layer header. It MUST NOT appear in a Hop-by-hop 162 Options header or in a Destination Options header that precedes a 163 Routing header. 165 NOTE : The highest-order two bits of the Option Type (i.e., the "act" 166 bits) are 01. These bits specify the action taken by a destination 167 node that does not recognize the option. The required action is to 168 discard the packet. The third highest-order bit of the Option Type 169 (i.e., the "chg" bit) is 0. This indicates that Option Data cannot 170 be modified along the path between the packet's source and its 171 destination. 173 4. TPF Information Determines Next-Protocol Engine Behavior 175 An exit-point node supports one or more next-protocol engines (e.g., 176 Ethernet, IPv4, IPv6). Each next-protocol engine supports a default 177 forwarding procedure and zero or more special forwarding procedures. 179 When an exit-point node submits a packet to a next-protocol engine 180 without TPF information, the next-protocol engine executes its 181 default forwarding procedure. For example, assume that the exit- 182 point node receives the following Tunnel IPv6 Packet: 184 * The Tunnel IPv6 Packet does not contain TPF information. 186 * The original packet is IPv4. 188 In this case, the exit-point node processes and removes the Tunnel 189 IPv6 Header. It then submits the original packet, without any TPF 190 information, to the IPv4 protocol engine. 192 The IPv4 protocol engine executes its default forwarding procedure. 193 It searches its Forwarding Information Base (FIB) for and entry that 194 matches the original packet's destination address. If the search 195 returns a FIB entry, the protocol engine forwards the packet through 196 an interface that the FIB entry identifies. 198 When an exit-point node submits a packet to a next-protocol engine 199 with TPF information, the next-protocol engine executes a special 200 forwarding procedure. For example, assume that the exit-point node 201 receives the following Tunnel IPv6 packet: 203 * The Tunnel IPv6 Packet contains TPF information that identifies an 204 interface. 206 * The original packet is IPv4. 208 In this case, the exit-point node processes and removes the Tunnel 209 IPv6 Header. It then submits the original packet, along with TPF 210 information, to the IPv4 protocol engine. 212 The IPv4 protocol engine executes a special forwarding procedure. It 213 forwards the packet through the interface identified by TPF 214 information, without searching the FIB. 216 5. TPF Information Semantics 218 TPF information is opaque. While it must be understood by the entry- 219 point node and the exit-point node, it does not need to be understood 220 by any other node. 222 6. Virtual Private Networking (VPN) Applications 224 The IPv6 TPF option is useful in deployments where IPv6 tunnels 225 carry: 227 * Layer 3 Virtual Private Network (L3VPN) [RFC4364] traffic. 229 * Ethernet Virtual Private Network (EVPN) [RFC7432] traffic. 231 When an IPv6 tunnel carries L3VPN traffic, VPN context information 232 can be encoded in an IPv6 TPF option. Therefore, the MPLS service 233 label that is normally present in an L3VPN packet can be eliminated. 235 When an IPv6 tunnel carries EVPN traffic, VPN context information can 236 be encoded in an IPv6 TPF option. Therefore, the UDP and VXLAN 237 headers that might otherwise be present can be eliminated. 239 7. Security Considerations 241 TPF information MUST NOT be accepted from untrusted sources. The 242 following are acceptable methods of risk mitigation: 244 * Authenticate the IPv6 TPF option using the IPv6 Authentication 245 Header (AH) [RFC4302] or the IPv6 Encapsulating Security Payload 246 (ESP) Header [RFC4303]. 248 * Maintain a secure TPF domain. 250 All nodes at the edge of a secure TPF domain discard packets that 251 satisfy the following criteria: 253 * Contain an IPv6 TPF option. 255 * Contain an IPv6 Destination Address that represents an interface 256 inside of the secure TPF domain. 258 8. IANA Considerations 260 IANA is requested to allocate a code point from the Destination 261 Options and Hop-by-hop Options registry 262 (https://www.iana.org/assignments/ipv6-parameters/ 263 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called 264 "Tunnel Payload Forwarding Option". The "act" bits are 01 and the 265 "chg" bit is 0. The suggested value is 0x41. 267 9. Acknowledgements 269 Thanks to Dr. Vanessa Ameen, Brian Carpenter, Adrian Farrel, Ishaan 270 Gandhi, Tom Herbert, John Leddy, Srihari Sangli and Tony Li for their 271 comments. 273 10. Contributors 275 Chris Lenart 277 Verizon 279 22001 Loudoun County Parkway 281 Ashburn, Virginia 20147 USA 283 Email: chris.lenart@verizon.com 285 Greg Presbury 287 Hughes Network Systems 289 11717 Exploration Lane 291 Germantown, Maryland 20876 USA 293 Email: greg.presbury@hughes.com 295 11. References 297 11.1. Normative References 299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 300 Requirement Levels", BCP 14, RFC 2119, 301 DOI 10.17487/RFC2119, March 1997, 302 . 304 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 305 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 306 December 1998, . 308 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 309 DOI 10.17487/RFC4302, December 2005, 310 . 312 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 313 RFC 4303, DOI 10.17487/RFC4303, December 2005, 314 . 316 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 317 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 318 May 2017, . 320 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 321 (IPv6) Specification", STD 86, RFC 8200, 322 DOI 10.17487/RFC8200, July 2017, 323 . 325 11.2. Informative References 327 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 328 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 329 2006, . 331 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 332 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 333 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 334 2015, . 336 Authors' Addresses 338 Ron Bonica 339 Juniper Networks 340 2251 Corporate Park Drive 341 Herndon, Virginia 20171 342 United States of America 344 Email: rbonica@juniper.net 346 Yuji Kamite 347 NTT Communications Corporation 348 3-4-1 Shibaura, Minato-ku, 349 108-8118 350 Japan 352 Email: y.kamite@ntt.com 353 Luay Jalil 354 Verizon 355 Richardson, Texas 356 United States of America 358 Email: luay.jalil@one.verizon.com 360 Yifeng Zhou 361 ByteDance 362 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian District 363 Beijing 364 100000 365 P.R. China 367 Email: yifeng.zhou@bytedance.com 369 Gang Chen 370 Baidu 371 No.10 Xibeiwang East Road Haidian District 372 Beijing 373 100193 374 P.R. China 376 Email: phdgang@gmail.com