idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-04.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2019) is 1867 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 316, 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: 1 error (**), 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 X. Xu 5 Expires: September 11, 2019 Alibaba Inc 6 C. Lenart 7 Verizon 8 G. Presbury 9 Hughes Network Systems 10 G. Chen 11 Baidu 12 Y. Zhu 13 G. Yang 14 China Telecom 15 March 10, 2019 17 The IPv6 Virtual Private Network (VPN) Context Information Option 18 draft-bonica-6man-vpn-dest-opt-04 20 Abstract 22 This document defines a new IPv6 Destination Option that can be used 23 to encode Virtual Private Network (VPN) context information. It is 24 applicable when VPN payload is transported over IPv6. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 11, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 62 3. VPN Context Information . . . . . . . . . . . . . . . . . . . 4 63 4. The VPN Context Information Option . . . . . . . . . . . . . 5 64 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 65 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 66 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 69 8.2. Informative References . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 Virtual Private Network (VPN) technologies allow network providers to 75 emulate private networks with shared infrastructure. For example, 76 assume that a red sites and blue sites connect to a provider network. 77 The provider network facilitates communication among red sites and 78 facilitates communication among blue sites. However, it prevents 79 communication between red sites and blue sites. 81 The IETF has standardized many VPN technologies, including: 83 o Layer 2 VPN (L2VPN) [RFC6624]. 85 o Layer 3 VPN (L3VPN) [RFC4364]. 87 o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. 89 o Ethernet VPN (EVPN) [RFC7432]. 91 o Pseudowires [RFC8077]. 93 The above-mentioned technologies include the following components: 95 o Customer Edge (CE) devices. 97 o Provider Edge (PE) devices. 99 o Routing Instances. 101 o VPN context information. 103 o Transport tunnels. 105 CE devices participate in closed communities called VPNs. CEs that 106 participate in one VPN can communicate with one another but cannot 107 communicate with CEs that participate in another VPN. 109 CE devices connect to provider networks through PE devices. Each PE 110 maintains one Routing Instance for each VPN that it supports. A 111 Routing Instance is a VPN specific Forwarding Information Base (FIB). 112 In EVPN, Routing Instances are called Ethernet Virtual Instances 113 (EVI). 115 Assume that one CE sends a packet through a provider network to 116 another CE. The packet enters the provider network through an 117 ingress PE and leaves the provider network through an egress PE. The 118 packet may traverse one or more intermediate nodes on route from PE 119 to PE. 121 When the ingress PE receives the packet, it: 123 o Identifies the Routing Instance that supports the originating CE's 124 VPN. 126 o Searches that Routing Instance for the packet's destination. 128 If the search fails, the ingress PE discards the packet. If the 129 search succeeds, it yields the following: 131 o VPN context information. 133 o The egress PE's IP address. 135 The ingress PE prepends VPN context information and a transport 136 header to the packet, in that order. It then forwards the packet 137 through a transport tunnel to the egress PE. 139 The egress PE removes the transport header, if it has not already 140 been removed by an upstream device. It then examines and removes the 141 VPN context information. Finally, it uses the VPN context 142 information to forward the packet to its destination (i.e., a 143 directly connected CE). 145 In the above-mentioned VPN technologies, the ingress PE encodes VPN 146 context information in a Multiprotocol Label Switching (MPLS) 147 [RFC3031] label. Depending upon the transport tunnel type, the 148 transport header can be: 150 o A MPLS label or label stack. 152 o An IPv4 [RFC0791] header. 154 o An IPv6 [RFC8200] header. 156 o A Generic Routing Encapsulation (GRE) [RFC2784] header 157 encapsulated in IPv4 or IPv6. 159 Some PE devices cannot process MPLS headers. While these devices 160 have several alternatives to MPLS-based transport tunnels, they 161 require an alternative to MPLS-based encoding of VPN context 162 information. This document defines a new IPv6 Destination Option 163 that can be used to encode VPN context information. It is applicable 164 when VPN payload is transported over IPv6. 166 2. Requirements Language 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 170 "OPTIONAL" in this document are to be interpreted as described in BCP 171 14 [RFC2119] [RFC8174] when, and only when, they appear in all 172 capitals, as shown here. 174 3. VPN Context Information 176 VPN context information specifies a forwarding procedure to be 177 executed by the egress PE. However, VPN context information values 178 are not globally mapped to forwarding procedures. Each egress PE 179 maps each forwarding procedure that it supports to a VPN context 180 information value. Therefore, VPN context information values are 181 locally scoped to the egress PE. 183 PE devices can acquire VPN Context Information: 185 o From one another, using a distributed, control plane protocol 186 (e.g., BGP [RFC4271] [RFC4760]) 188 o From a controller. 190 The mechanisms by which PE devices acquire VPN Context Information 191 are beyond the scope of this document. 193 4. The VPN Context Information Option 195 0 1 2 3 196 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 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Option Type | Opt Data Len | VPN Context Information ... 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 201 Figure 1 203 Figure 1 depicts the VPN Context Information Option. 205 Option fields are as follows: 207 o Option Type - VPN Context Information option. Value TBD by IANA. 208 See Notes below. 210 o Opt Data Len - Length of Option Data, measured in bytes. 212 o VPN Context Information - Specifies a forwarding procedure to be 213 executed by the egress PE. 215 The VPN Context Information Option MAY appear in a Destination 216 Options header that precedes an upper-layer header. It MUST NOT 217 appear in a Hop-by-hop Options header and SHOULD NOT appear in a 218 Destination Options header that precedes a Routing header. If it 219 appears in a Hop-by-hop Options header, the processing node will 220 discard the packet and send an ICMPv6 [RFC4443] Parameter Problem, 221 Code 2, message to the packet's Source Address, pointing to the 222 Option Type. If it appears in a Destination Options header that 223 precedes a Routing header, the processing node will attempt to 224 process the option, because it has not yet encountered the Routing 225 header. 227 If the VPN Context Information appears in a Destination Options 228 header, it SHOULD be the final option listed in the header. Because 229 the VPN Context Information Option causes the packet to be 230 decapsulated and forwarded, all options listed after the VPN Context 231 Information Option will be ignored. 233 NOTE 1: The highest-order two bits of the Option Type (i.e., the 234 "act" bits) are 10. These bits specify the action taken by a 235 destination node that does not recognize VPN Context Information 236 option. The required action is to discard the packet and, regardless 237 of whether or not the packet's Destination Address was a multicast 238 address, send an ICMPv6 Parameter Problem, Code 2, message to the 239 packet's Source Address, pointing to the unrecognized Option Type. 241 NOTE 2: The third highest-order bit of the Option Type (i.e., the 242 "chg" bit) is 0. This indicates that Option Data cannot be modified 243 along the path between the packet's source and its destination. 245 5. Security Considerations 247 A VPN can be deployed: 249 o In a walled-garden environment. 251 o In an over-the-top environment. 253 In a walled-garden environment, all PE devices and all devices that 254 connect PEs to one another reside in the same security domain. 255 Therefore, there is no risk that a packet might be modified as it 256 travels from PE to PE. 258 In an over-the-top environment, all PE devices reside in one security 259 domain while devices that connect PEs to one another can reside in a 260 different security domain. In that case, there is significant risk 261 that a packet might be modified as it travels from PE to PE. 263 Therefore, the VPN Context Information option MUST be authenticated 264 when used in over-the-top environments. In this scenario, an IPv6 265 Encapsulating Security Payload (ESP) [RFC4303] MUST proceed the 266 Destination Options header that carries the VPN Context Information 267 option. The ESP integrity service MUST be enabled. 269 6. IANA Considerations 271 IANA is requested to allocate a codepoint from the Destination 272 Options and Hop-by-hop Options registry 273 (https://www.iana.org/assignments/ipv6-parameters/ 274 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called "VPN 275 Context Information". The "act" bits are 10 and the "chg" bit is 0. 277 7. Acknowledgements 279 Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert and John Leddy 280 for their comments. 282 8. References 284 8.1. Normative References 286 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 287 DOI 10.17487/RFC0791, September 1981, 288 . 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, 292 DOI 10.17487/RFC2119, March 1997, 293 . 295 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 296 RFC 4303, DOI 10.17487/RFC4303, December 2005, 297 . 299 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 300 Control Message Protocol (ICMPv6) for the Internet 301 Protocol Version 6 (IPv6) Specification", STD 89, 302 RFC 4443, DOI 10.17487/RFC4443, March 2006, 303 . 305 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 306 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 307 May 2017, . 309 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 310 (IPv6) Specification", STD 86, RFC 8200, 311 DOI 10.17487/RFC8200, July 2017, 312 . 314 8.2. Informative References 316 [I-D.ietf-6man-segment-routing-header] 317 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 318 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 319 (SRH)", draft-ietf-6man-segment-routing-header-16 (work in 320 progress), February 2019. 322 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 323 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 324 DOI 10.17487/RFC2784, March 2000, 325 . 327 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 328 Label Switching Architecture", RFC 3031, 329 DOI 10.17487/RFC3031, January 2001, 330 . 332 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 333 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 334 DOI 10.17487/RFC4271, January 2006, 335 . 337 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 338 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 339 2006, . 341 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 342 "Multiprotocol Extensions for BGP-4", RFC 4760, 343 DOI 10.17487/RFC4760, January 2007, 344 . 346 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 347 LAN Service (VPLS) Using BGP for Auto-Discovery and 348 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 349 . 351 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 352 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 353 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 354 . 356 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 357 Virtual Private Networks Using BGP for Auto-Discovery and 358 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 359 . 361 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 362 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 363 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 364 2015, . 366 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 367 Maintenance Using the Label Distribution Protocol (LDP)", 368 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 369 . 371 Authors' Addresses 373 Ron Bonica 374 Juniper Networks 375 2251 Corporate Park Drive 376 Herndon, Virginia 20171 377 USA 379 Email: rbonica@juniper.net 381 Xiaohu Xu 382 Alibaba Inc 383 Alibaba Park 384 Hangzhou 385 P.R. China 387 Email: xiaohu.xxh@alibaba-inc.com 389 Chris Lenart 390 Verizon 391 22001 Loudoun County Parkway 392 Ashburn, Virginia 20147 393 USA 395 Email: chris.lenart@verizon.com 397 Greg Presbury 398 Hughes Network Systems 399 11717 Exploration Lane 400 Germantown, Maryland 20876 401 USA 403 Email: greg.presbury@hughes.com 405 Gang Chen 406 Baidu 407 Baidu Technology Park Building No.2, No.10 Xibeiwang East Road Haidian District 408 Beijing 100193 409 P.R. China 411 Email: phdgang@gmail.com 412 Yongqing Zhu 413 China Telecom 414 109 West Zhongshan Ave, Tianhe District 415 Guangzhou 416 P.R. China 418 Email: zhuyq.gd@chinatelecom.cn 420 Guangming Yang 421 China Telecom 422 109 West Zhongshan Ave, Tianhe District 423 Guangzhou 424 P.R. China 426 Email: yanggm.gd@chinatelecom.cn