idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-05.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 (March 23, 2019) is 1860 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.ietf-6man-segment-routing-header' is defined on line 319, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-16 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 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 C. Lenart 5 Expires: September 24, 2019 Verizon 6 N. So 7 F. Xu 8 Reliance Jio 9 G. Presbury 10 Hughes Network Systems 11 G. Chen 12 Baidu 13 Y. Zhu 14 G. Yang 15 China Telecom 16 Y. Zhou 17 ByteDance 18 March 23, 2019 20 The IPv6 Virtual Private Network (VPN) Context Information Option 21 draft-bonica-6man-vpn-dest-opt-05 23 Abstract 25 This document defines a new IPv6 Destination Option that can be used 26 to encode Virtual Private Network (VPN) context information. It is 27 applicable when VPN payload is transported over IPv6. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at https://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on September 24, 2019. 46 Copyright Notice 48 Copyright (c) 2019 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (https://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 65 3. VPN Context Information . . . . . . . . . . . . . . . . . . . 4 66 4. The VPN Context Information Option . . . . . . . . . . . . . 5 67 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 69 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 71 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 72 8.2. Informative References . . . . . . . . . . . . . . . . . 7 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 75 1. Introduction 77 Virtual Private Network (VPN) technologies allow network providers to 78 emulate private networks with shared infrastructure. For example, 79 assume that a red sites and blue sites connect to a provider network. 80 The provider network facilitates communication among red sites and 81 facilitates communication among blue sites. However, it prevents 82 communication between red sites and blue sites. 84 The IETF has standardized many VPN technologies, including: 86 o Layer 2 VPN (L2VPN) [RFC6624]. 88 o Layer 3 VPN (L3VPN) [RFC4364]. 90 o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. 92 o Ethernet VPN (EVPN) [RFC7432]. 94 o Pseudowires [RFC8077]. 96 The above-mentioned technologies include the following components: 98 o Customer Edge (CE) devices. 100 o Provider Edge (PE) devices. 102 o Routing Instances. 104 o VPN context information. 106 o Transport tunnels. 108 CE devices participate in closed communities called VPNs. CEs that 109 participate in one VPN can communicate with one another but cannot 110 communicate with CEs that participate in another VPN. 112 CE devices connect to provider networks through PE devices. Each PE 113 maintains one Routing Instance for each VPN that it supports. A 114 Routing Instance is a VPN specific Forwarding Information Base (FIB). 115 In EVPN, Routing Instances are called Ethernet Virtual Instances 116 (EVI). 118 Assume that one CE sends a packet through a provider network to 119 another CE. The packet enters the provider network through an 120 ingress PE and leaves the provider network through an egress PE. The 121 packet may traverse one or more intermediate nodes on route from PE 122 to PE. 124 When the ingress PE receives the packet, it: 126 o Identifies the Routing Instance that supports the originating CE's 127 VPN. 129 o Searches that Routing Instance for the packet's destination. 131 If the search fails, the ingress PE discards the packet. If the 132 search succeeds, it yields the following: 134 o VPN context information. 136 o The egress PE's IP address. 138 The ingress PE prepends VPN context information and a transport 139 header to the packet, in that order. It then forwards the packet 140 through a transport tunnel to the egress PE. 142 The egress PE removes the transport header, if it has not already 143 been removed by an upstream device. It then examines and removes the 144 VPN context information. Finally, it uses the VPN context 145 information to forward the packet to its destination (i.e., a 146 directly connected CE). 148 In the above-mentioned VPN technologies, the ingress PE encodes VPN 149 context information in a Multiprotocol Label Switching (MPLS) 150 [RFC3031] label. Depending upon the transport tunnel type, the 151 transport header can be: 153 o A MPLS label or label stack. 155 o An IPv4 [RFC0791] header. 157 o An IPv6 [RFC8200] header. 159 o A Generic Routing Encapsulation (GRE) [RFC2784] header 160 encapsulated in IPv4 or IPv6. 162 Some PE devices cannot process MPLS headers. While these devices 163 have several alternatives to MPLS-based transport tunnels, they 164 require an alternative to MPLS-based encoding of VPN context 165 information. This document defines a new IPv6 Destination Option 166 that can be used to encode VPN context information. It is applicable 167 when VPN payload is transported over IPv6. 169 2. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 3. VPN Context Information 179 VPN context information specifies a forwarding procedure to be 180 executed by the egress PE. However, VPN context information values 181 are not globally mapped to forwarding procedures. Each egress PE 182 maps each forwarding procedure that it supports to a VPN context 183 information value. Therefore, VPN context information values are 184 locally scoped to the egress PE. 186 PE devices can acquire VPN Context Information: 188 o From one another, using a distributed, control plane protocol 189 (e.g., BGP [RFC4271] [RFC4760]) 191 o From a controller. 193 The mechanisms by which PE devices acquire VPN Context Information 194 are beyond the scope of this document. 196 4. The VPN Context Information Option 198 0 1 2 3 199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Option Type | Opt Data Len | VPN Context Information ... 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 204 Figure 1 206 Figure 1 depicts the VPN Context Information Option. 208 Option fields are as follows: 210 o Option Type - VPN Context Information option. Value TBD by IANA. 211 See Notes below. 213 o Opt Data Len - Length of Option Data, measured in bytes. 215 o VPN Context Information - Specifies a forwarding procedure to be 216 executed by the egress PE. 218 The VPN Context Information Option MAY appear in a Destination 219 Options header that precedes an upper-layer header. It MUST NOT 220 appear in a Hop-by-hop Options header and SHOULD NOT appear in a 221 Destination Options header that precedes a Routing header. If it 222 appears in a Hop-by-hop Options header, the processing node will 223 discard the packet and send an ICMPv6 [RFC4443] Parameter Problem, 224 Code 2, message to the packet's Source Address, pointing to the 225 Option Type. If it appears in a Destination Options header that 226 precedes a Routing header, the processing node will attempt to 227 process the option, because it has not yet encountered the Routing 228 header. 230 If the VPN Context Information appears in a Destination Options 231 header, it SHOULD be the final option listed in the header. Because 232 the VPN Context Information Option causes the packet to be 233 decapsulated and forwarded, all options listed after the VPN Context 234 Information Option will be ignored. 236 NOTE 1: The highest-order two bits of the Option Type (i.e., the 237 "act" bits) are 10. These bits specify the action taken by a 238 destination node that does not recognize VPN Context Information 239 option. The required action is to discard the packet and, regardless 240 of whether or not the packet's Destination Address was a multicast 241 address, send an ICMPv6 Parameter Problem, Code 2, message to the 242 packet's Source Address, pointing to the unrecognized Option Type. 244 NOTE 2: The third highest-order bit of the Option Type (i.e., the 245 "chg" bit) is 0. This indicates that Option Data cannot be modified 246 along the path between the packet's source and its destination. 248 5. Security Considerations 250 A VPN can be deployed: 252 o In a walled-garden environment. 254 o In an over-the-top environment. 256 In a walled-garden environment, all PE devices and all devices that 257 connect PEs to one another reside in the same security domain. 258 Therefore, there is no risk that a packet might be modified as it 259 travels from PE to PE. 261 In an over-the-top environment, all PE devices reside in one security 262 domain while devices that connect PEs to one another can reside in a 263 different security domain. In that case, there is significant risk 264 that a packet might be modified as it travels from PE to PE. 266 Therefore, the VPN Context Information option MUST be authenticated 267 when used in over-the-top environments. In this scenario, an IPv6 268 Encapsulating Security Payload (ESP) [RFC4303] MUST proceed the 269 Destination Options header that carries the VPN Context Information 270 option. The ESP integrity service MUST be enabled. 272 6. IANA Considerations 274 IANA is requested to allocate a codepoint from the Destination 275 Options and Hop-by-hop Options registry 276 (https://www.iana.org/assignments/ipv6-parameters/ 277 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called "VPN 278 Context Information". The "act" bits are 10 and the "chg" bit is 0. 280 7. Acknowledgements 282 Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert and John Leddy 283 for their comments. 285 8. References 287 8.1. Normative References 289 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 290 DOI 10.17487/RFC0791, September 1981, 291 . 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, 295 DOI 10.17487/RFC2119, March 1997, 296 . 298 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 299 RFC 4303, DOI 10.17487/RFC4303, December 2005, 300 . 302 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 303 Control Message Protocol (ICMPv6) for the Internet 304 Protocol Version 6 (IPv6) Specification", STD 89, 305 RFC 4443, DOI 10.17487/RFC4443, March 2006, 306 . 308 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 309 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 310 May 2017, . 312 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 313 (IPv6) Specification", STD 86, RFC 8200, 314 DOI 10.17487/RFC8200, July 2017, 315 . 317 8.2. Informative References 319 [I-D.ietf-6man-segment-routing-header] 320 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 321 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 322 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 323 progress), February 2019. 325 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 326 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 327 DOI 10.17487/RFC2784, March 2000, 328 . 330 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 331 Label Switching Architecture", RFC 3031, 332 DOI 10.17487/RFC3031, January 2001, 333 . 335 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 336 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 337 DOI 10.17487/RFC4271, January 2006, 338 . 340 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 341 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 342 2006, . 344 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 345 "Multiprotocol Extensions for BGP-4", RFC 4760, 346 DOI 10.17487/RFC4760, January 2007, 347 . 349 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 350 LAN Service (VPLS) Using BGP for Auto-Discovery and 351 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 352 . 354 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 355 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 356 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 357 . 359 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 360 Virtual Private Networks Using BGP for Auto-Discovery and 361 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 362 . 364 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 365 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 366 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 367 2015, . 369 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 370 Maintenance Using the Label Distribution Protocol (LDP)", 371 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 372 . 374 Authors' Addresses 376 Ron Bonica 377 Juniper Networks 378 2251 Corporate Park Drive 379 Herndon, Virginia 20171 380 USA 382 Email: rbonica@juniper.net 384 Chris Lenart 385 Verizon 386 22001 Loudoun County Parkway 387 Ashburn, Virginia 20147 388 USA 390 Email: chris.lenart@verizon.com 392 Ning So 393 Reliance Jio 394 3010 Gaylord PKWY, Suite 150 395 Frisco, Texas 75034 396 USA 398 Email: Ning.So@ril.com 400 Fengman Xu 401 Reliance Jio 402 3010 Gaylord PKWY, Suite 150 403 Frisco, Texas 75034 404 USA 406 Email: Fengman.Xu@ril.com 408 Greg Presbury 409 Hughes Network Systems 410 11717 Exploration Lane 411 Germantown, Maryland 20876 412 USA 414 Email: greg.presbury@hughes.com 415 Gang Chen 416 Baidu 417 No.10 Xibeiwang East Road Haidian District 418 Beijing 100193 419 P.R. China 421 Email: phdgang@gmail.com 423 Yongqing Zhu 424 China Telecom 425 109 West Zhongshan Ave, Tianhe District 426 Guangzhou 427 P.R. China 429 Email: zhuyq.gd@chinatelecom.cn 431 Guangming Yang 432 China Telecom 433 109 West Zhongshan Ave, Tianhe District 434 Guangzhou 435 P.R. China 437 Email: yanggm.gd@chinatelecom.cn 439 Yifeng Zhou 440 ByteDance 441 Building 1, AVIC Plaza, 43 N 3rd Ring W Rd Haidian District 442 Beijing 100000 443 P.R. China 445 Email: yifeng.zhou@bytedance.com