idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-13.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 (August 30, 2020) is 1307 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: March 3, 2021 NTT Communications Corporation 6 L. Jalil 7 Verizon 8 Y. Zhou 9 ByteDance 10 G. Chen 11 Baidu 12 August 30, 2020 14 The IPv6 Tunnel Payload Forwarding (TPF) Option 15 draft-bonica-6man-vpn-dest-opt-13 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 March 3, 2021. 39 Copyright Notice 41 Copyright (c) 2020 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 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 58 3. The IPv6 Tunnel Payload Forwarding (TPF) Option . . . . . . . 4 59 4. TPF Information Determines Next-Protocol Engine Behavior . . 5 60 5. TPF Information Semantics . . . . . . . . . . . . . . . . . . 5 61 6. Virtual Private Networking (VPN) Applications . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 64 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 65 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 66 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 68 11.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 71 1. Introduction 73 This document explains how IPv6 options [RFC8200] can be used in IPv6 74 tunnels. It also defines the IPv6 Tunnel Payload Forwarding (TPF) 75 option. 77 An IPv6 tunnel [RFC2473] connects two nodes, called the entry-point 78 and the exit-point. The entry-point receives a packet and 79 encapsulates it in a Tunnel IPv6 Header. Figure 1 depicts the 80 encapsulation. 82 +----------------------------------//-----+ 83 | Original | | 84 | | Original Packet Payload | 85 | Header | | 86 +----------------------------------//-----+ 87 < Original Packet > 88 | 89 v 90 < Original Packet > 92 +---------+ - - - - - +-------------------------//--------------+ 93 | IPv6 | IPv6 | | 94 | | Extension | Original Packet | 95 | Header | Headers | | 96 +---------+ - - - - - +-------------------------//--------------+ 97 < Tunnel IPv6 Packet > 99 Figure 1: IPv6 Tunnel Encapsulation 101 The original packet can be any layer-2 or layer-3 packet (e.g., 102 Ethernet, IPv4, IPv6). The Tunnel Header is an IPv6 header followed 103 by zero or more extension headers. The resulting packet is a Tunnel 104 IPv6 Packet. 106 The entry-point sends the Tunnel IPv6 Packet to the exit-point which 107 then executes the following procedure: 109 o Process the Tunnel IPv6 Header. 111 o Remove the Tunnel IPv6 Header, exposing the original packet. 113 o Submit the original packet to the next-protocol engine. 115 The exit-point node processes the Tunnel IPv6 Header in strict left- 116 to-right order. It processes the IPv6 header first and then 117 processes extension headers in the order that they appear in the 118 packet. The IPv6 header, and each extension header, includes a Next 119 Header field. The last Next Header field processed identifies the 120 next-protocol engine. 122 Entry-point nodes can send optional information to the next-protocol 123 engine on the exit-point node. For example, the entry-point can 124 indicate: 126 o The interface through which the next-protocol engine should send 127 the packet. 129 o The routing table that the next-protocol engine should use to 130 process the packet. 132 To send this information, the entry-point node includes an IPv6 133 Destination Option header in the Tunnel IPv6 Header. The IPv6 134 Destination Options header includes an IPv6 TPF option and the IPv6 135 TPF option includes TPF information. The next-protocol engine on the 136 exit-point node uses TPF information when it forwards the original 137 packet. 139 2. Requirements Language 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 143 "OPTIONAL" in this document are to be interpreted as described in BCP 144 14 [RFC2119] [RFC8174] when, and only when, they appear in all 145 capitals, as shown here. 147 3. The IPv6 Tunnel Payload Forwarding (TPF) Option 149 The TPF Option contains the following fields: 151 o Option Type: 8-bit selector. TPF option. Value TBD by IANA. 152 (Suggested value: 33). See Note below. 154 o Opt Data Len - 8-bit unsigned integer. Length of the option, in 155 octets, excluding the Option Type and Option Length fields. This 156 field MUST be set to 4. 158 o Option Data - 32-bits. Tunnel Payload Forwarding (TPF) 159 Information. 161 The TPF option MAY appear in a Destination Options header that 162 precedes an upper-layer header. It MUST NOT appear in a Hop-by-hop 163 Options header or in a Destination Options header that precedes a 164 Routing header. 166 NOTE : The highest-order two bits of the Option Type (i.e., the "act" 167 bits) are 01. These bits specify the action taken by a destination 168 node that does not recognize the option. The required action is to 169 discard the packet. The third highest-order bit of the Option Type 170 (i.e., the "chg" bit) is 0. This indicates that Option Data cannot 171 be modified along the path between the packet's source and its 172 destination. 174 4. TPF Information Determines Next-Protocol Engine Behavior 176 An exit-point node supports one or more next-protocol engines (e.g., 177 Ethernet, IPv4, IPv6). Each next-protocol engine supports a default 178 forwarding procedure and zero or more special forwarding procedures. 180 When an exit-point node submits a packet to a next-protocol engine 181 without TPF information, the next-protocol engine executes its 182 default forwarding procedure. For example, assume that the exit- 183 point node receives the following Tunnel IPv6 Packet: 185 o The Tunnel IPv6 Packet does not contain TPF information. 187 o The original packet is IPv4. 189 In this case, the exit-point node processes and removes the Tunnel 190 IPv6 Header. It then submits the original packet, without any TPF 191 information, to the IPv4 protocol engine. 193 The IPv4 protocol engine executes its default forwarding procedure. 194 It searches its Forwarding Information Base (FIB) for and entry that 195 matches the original packet's destination address. If the search 196 returns a FIB entry, the protocol engine forwards the packet through 197 an interface that the FIB entry identifies. 199 When an exit-point node submits a packet to a next-protocol engine 200 with TPF information, the next-protocol engine executes a special 201 forwarding procedure. For example, assume that the exit-point node 202 receives the following Tunnel IPv6 packet: 204 o The Tunnel IPv6 Packet contains TPF information that identifies an 205 interface. 207 o The original packet is IPv4. 209 In this case, the exit-point node processes and removes the Tunnel 210 IPv6 Header. It then submits the original packet, along with TPF 211 information, to the IPv4 protocol engine. 213 The IPv4 protocol engine executes a special forwarding procedure. It 214 forwards the packet through the interface identified by TPF 215 information, without searching the FIB. 217 5. TPF Information Semantics 219 TPF information is opaque. While it must be understood by the entry- 220 point node and the exit-point node, it does not need to be understood 221 by any other node. 223 6. Virtual Private Networking (VPN) Applications 225 The IPv6 TPF option is useful in deployments where IPv6 tunnels 226 carry: 228 o Layer 3 Virtual Private Network (L3VPN) [RFC4364] traffic. 230 o Ethernet Virtual Private Network (EVPN) [RFC7432] traffic. 232 When an IPv6 tunnel carries L3VPN traffic, VPN context information 233 can be encoded in an IPv6 TPF option. Therefore, the MPLS service 234 label that is normally present in an L3VPN packet can be eliminated. 236 When an IPv6 tunnel carries EVPN traffic, VPN context information can 237 be encoded in an IPv6 TPF option. Therefore, the UDP and VXLAN 238 headers that might otherwise be present can be eliminated. 240 7. Security Considerations 242 TPF information MUST NOT be accepted from untrusted sources. The 243 following are acceptable methods of risk mitigation: 245 o Authenticate the IPv6 TPF option using the IPv6 Authentication 246 Header (AH) [RFC4302] or the IPv6 Encapsulating Security Payload 247 (ESP) Header [RFC4303]. 249 o Maintain a secure TPF domain. 251 All nodes at the edge of a secure TPF domain discard packets that 252 satisfy the following criteria: 254 o Contain an IPv6 TPF option. 256 o Contain an IPv6 Destination Address that represents an interface 257 inside of the secure TPF domain. 259 8. IANA Considerations 261 IANA is requested to allocate a code point from the Destination 262 Options and Hop-by-hop Options registry 263 (https://www.iana.org/assignments/ipv6-parameters/ 264 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called 265 "Tunnel Payload Forwarding Option". The "act" bits are 01 and the 266 "chg" bit is 0. The suggested value is 33. 268 9. Acknowledgements 270 Thanks to Dr. Vanessa Ameen, Brian Carpenter, Adrian Farrel, Tom 271 Herbert, John Leddy, Srihari Sangli and Tony Li for their 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 USA 344 Email: rbonica@juniper.net 346 Yuji Kamite 347 NTT Communications Corporation 348 3-4-1 Shibaura, Minato-ku 349 Tokyo 108-8118 350 Japan 352 Email: y.kamite@ntt.com 353 Luay Jalil 354 Verizon 355 Richardson, Texas 356 USA 358 Email: luay.jalil@one.verizon.com 360 Yifeng Zhou 361 ByteDance 362 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian 363 District 364 Beijing 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 100193 373 P.R. China 375 Email: phdgang@gmail.com