idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-09.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 (February 19, 2020) is 1527 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: August 22, 2020 NTT Communications Corporation 6 L. Jalil 7 Verizon 8 N. So 9 Reliance Jio 10 G. Chen 11 Baidu 12 February 19, 2020 14 The IPv6 Tunnel Payload Forwarding (TPF) Option 15 draft-bonica-6man-vpn-dest-opt-09 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 August 22, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 11.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 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 protocol (e.g., 102 Ethernet, IPv4, IPv6). The Tunnel IPv6 Header is an IPv6 header 103 followed by zero or more extension headers. The resulting packet is 104 a Tunnel IPv6 Packet. 106 The entry-point sends the Tunnel IPv6 Packet to the exit-point and 107 the exit-point 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. When the TPF option appears in a Destination Options 165 header, it MUST be the only option in the header. 167 NOTE : The highest-order two bits of the Option Type (i.e., the "act" 168 bits) are 01. These bits specify the action taken by a destination 169 node that does not recognize the option. The required action is to 170 discard the packet. The third highest-order bit of the Option Type 171 (i.e., the "chg" bit) is 0. This indicates that Option Data cannot 172 be modified along the path between the packet's source and its 173 destination. 175 4. TPF Information Determines Next-Protocol Engine Behavior 177 An exit-point node supports one or more next-protocol engines (e.g., 178 Ethernet, IPv4, IPv6). Each next-protocol engine supports a default 179 forwarding procedure and zero or more special forwarding procedures. 181 When an exit-point node submits a packet to a next-protocol engine 182 without TPF information, the next-protocol engine executes its 183 default forwarding procedure. For example, assume that the exit- 184 point node receives the following Tunnel IPv6 Packet: 186 o The Tunnel IPv6 Packet does not contain TPF information. 188 o The original packet is IPv4. 190 In this case, the exit-point node processes and removes the Tunnel 191 IPv6 Header. It then submits the original packet, without any TPF 192 information, to the IPv4 protocol engine. 194 The IPv4 protocol engine executes its default forwarding procedure. 195 It searches its Forwarding Information Base (FIB) for and entry that 196 matches the original packet's destination address. If the search 197 returns a FIB entry, the protocol engine forwards the packet through 198 an interface that the FIB entry identifies. 200 When an exit-point node submits a packet to a next-protocol engine 201 with TPF information, the next-protocol engine executes a special 202 forwarding procedure. For example, assume that the exit-point node 203 receives the following Tunnel IPv6 packet: 205 o The Tunnel IPv6 Packet contains TPF information that identifies an 206 interface. 208 o The original packet is IPv4. 210 In this case, the exit-point node processes and removes the Tunnel 211 IPv6 Header. It then submits the original packet, along with TPF 212 information, to the IPv4 protocol engine. 214 The IPv4 protocol engine executes a special forwarding procedure. It 215 forwards the packet through the interface identified by TPF 216 information, without searching the FIB. 218 5. TPF Information Semantics 220 TPF information is opaque. While it must be understood by the entry- 221 point node and the exit-point node, it does not need to be understood 222 by any other node. 224 6. Virtual Private Networking (VPN) Applications 226 The IPv6 TPF option is useful in deployments where IPv6 tunnels 227 carry: 229 o Layer 3 Virtual Private Network (L3VPN) [RFC4364] traffic. 231 o Ethernet Virtual Private Network (EVPN) [RFC7432] traffic. 233 When an IPv6 tunnel carries L3VPN traffic, VPN context information 234 can be encoded in an IPv6 TPF option. Therefore, the MPLS service 235 label that is normally present in an L3VPN packet can be eliminated. 237 When an IPv6 tunnel carries EVPN traffic, VPN context information can 238 be encoded in an IPv6 TPF option. Therefore, the UDP and VXLAN 239 headers that might otherwise be present can be eliminated. 241 7. Security Considerations 243 TPF information MUST NOT be accepted from untrusted sources. The 244 following are acceptable methods of risk mitigation: 246 o Authenticate the IPv6 TPF option using the IPv6 Authentication 247 Header (AH) [RFC4302] or the IPv6 Encapsulating Security Payload 248 (ESP) Header [RFC4303]. 250 o Maintain a secure TPF domain. 252 All nodes at the edge of a secure TPF domain discard packets that 253 satisfy the following criteria: 255 o Contain an IPv6 TPF option. 257 o Contain an IPv6 Destination Address that represents an interface 258 inside of the secure TPF domain. 260 8. IANA Considerations 262 IANA is requested to allocate a code point from the Destination 263 Options and Hop-by-hop Options registry 264 (https://www.iana.org/assignments/ipv6-parameters/ 265 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called 266 "Tunnel Payload Forwarding Option". The "act" bits are 01 and the 267 "chg" bit is 0. The suggested value is 33. 269 9. Acknowledgements 271 Thanks to Dr. Vanessa Ameen, Brian Carpenter, Adrian Farrel, Tom 272 Herbert, John Leddy and Tony Li for their comments. 274 10. Contributors 276 Chris Lenart 278 Verizon 280 22001 Loudoun County Parkway 282 Ashburn, Virginia 20147 USA 284 Email: chris.lenart@verizon.com 286 Fengman Xu 288 Reliance Jio 290 3010 Gaylord PKWY, Suite 150 292 Frisco, Texas 75034 USA 294 Email: Fengman.Xu@ril.com 296 Greg Presbury 298 Hughes Network Systems 300 11717 Exploration Lane 302 Germantown, Maryland 20876 USA 304 Email: greg.presbury@hughes.com 306 Yifeng Zhou 308 ByteDance Building 1, AVIC Plaza, 310 43 N 3rd Ring W Rd Haidian District 311 Beijing 100000 P.R. China 313 Email: yifeng.zhou@bytedance.com 315 11. References 317 11.1. Normative References 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, 321 DOI 10.17487/RFC2119, March 1997, 322 . 324 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 325 IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, 326 December 1998, . 328 [RFC4302] Kent, S., "IP Authentication Header", RFC 4302, 329 DOI 10.17487/RFC4302, December 2005, 330 . 332 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 333 RFC 4303, DOI 10.17487/RFC4303, December 2005, 334 . 336 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 337 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 338 May 2017, . 340 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 341 (IPv6) Specification", STD 86, RFC 8200, 342 DOI 10.17487/RFC8200, July 2017, 343 . 345 11.2. Informative References 347 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 348 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 349 2006, . 351 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 352 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 353 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 354 2015, . 356 Authors' Addresses 358 Ron Bonica 359 Juniper Networks 360 2251 Corporate Park Drive 361 Herndon, Virginia 20171 362 USA 364 Email: rbonica@juniper.net 366 Yuji Kamite 367 NTT Communications Corporation 368 3-4-1 Shibaura, Minato-ku 369 Tokyo 108-8118 370 Japan 372 Email: y.kamite@ntt.com 374 Luay Jalil 375 Verizon 376 Richardson, Texas 377 USA 379 Email: luay.jalil@one.verizon.com 381 Ning So 382 Reliance Jio 383 3010 Gaylord PKWY, Suite 150 384 Frisco, Texas 75034 385 USA 387 Email: Ning.So@ril.com 389 Gang Chen 390 Baidu 391 No.10 Xibeiwang East Road Haidian District 392 Beijing 100193 393 P.R. China 395 Email: phdgang@gmail.com