idnits 2.17.1 draft-bonica-6man-vpn-dest-opt-01.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 (December 10, 2018) is 1954 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) == Outdated reference: A later version (-26) exists of draft-ietf-6man-segment-routing-header-15 Summary: 0 errors (**), 0 flaws (~~), 2 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: June 13, 2019 Verizon 6 G. Presbury 7 Hughes Network Systems 8 December 10, 2018 10 The IPv6 Virtual Private Network (VPN) Context Information Option 11 draft-bonica-6man-vpn-dest-opt-01 13 Abstract 15 This document defines a new IPv6 Destination Option that can be used 16 to encode Virtual Private Network (VPN) context information. It is 17 applicable when VPN payload is transported over IPv6. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on June 13, 2019. 36 Copyright Notice 38 Copyright (c) 2018 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 55 3. VPN Context Information . . . . . . . . . . . . . . . . . . . 4 56 4. The VPN Context Information Option . . . . . . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 8.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 65 1. Introduction 67 Virtual Private Network (VPN) technologies allow network providers to 68 emulate private networks with shared infrastructure. For example, 69 assume that a red sites and blue sites connect to a provider network. 70 The provider network facilitates communication among red sites and 71 facilitates communication among blue sites. However, it prevents 72 communication between red sites and blue sites. 74 The IETF has standardized many VPN technologies, including: 76 o Layer 2 VPN (L2VPN) [RFC6624]. 78 o Layer 3 VPN (L3VPN) [RFC4364]. 80 o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. 82 o Ethernet VPN (EVPN) [RFC7432]. 84 o Pseudowires [RFC8077]. 86 The above-mentioned technologies include the following components: 88 o Customer Edge (CE) devices. 90 o Provider Edge (PE) devices. 92 o Routing Instances. 94 o VPN context information. 96 o Transport tunnels. 98 CE devices participate in closed communities called VPNs. CEs that 99 participate in one VPN can communicate with one another but cannot 100 communicate with CEs that participate in another VPN. 102 CE devices connect to provider networks through PE devices. Each PE 103 maintains one Routing Instance for each VPN that it supports. A 104 Routing Instance is a VPN specific Forwarding Information Base (FIB). 105 In EVPN, Routing Instances are called Ethernet Virtual Instances 106 (EVI). 108 Assume that one CE sends a packet through a provider network to 109 another CE. The packet enters the provider network through an 110 ingress PE and leaves the provider network through an egress PE. The 111 packet may traverse one or more intermediate nodes on route from PE 112 to PE. 114 When the ingress PE receives the packet, it: 116 o Identifies the Routing Instance that supports the originating CE's 117 VPN. 119 o Searches that Routing Instance for the packet's destination. 121 If the search fails, the ingress PE discards the packet. If the 122 search succeeds, it yields the following: 124 o VPN context information. 126 o The egress PE's IP address. 128 The ingress PE prepends VPN context information and a transport 129 header to the packet, in that order. It then forwards the packet 130 through a transport tunnel to the egress PE. 132 The egress PE removes the transport header, if it has not already 133 been removed by an upstream device. It then examines and removes the 134 VPN context information. Finally, it uses the VPN context 135 information to forward the packet to its destination (i.e., a 136 directly connected CE). 138 In the above-mentioned VPN technologies, the ingress PE encodes VPN 139 context information in a Multiprotocol Label Switching (MPLS) 140 [RFC3031] label. Depending upon the transport tunnel type, the 141 transport header can be: 143 o A MPLS label or label stack. 145 o An IPv4 [RFC0791] header. 147 o An IPv6 [RFC8200] header. 149 o A Generic Routing Encapsulation (GRE) [RFC2784] header 150 encapsulated in IPv4 or IPv6. 152 If the outermost transport header is IPv6, it may be followed by a 153 Segment Routing Header (SRH) [I-D.ietf-6man-segment-routing-header]. 155 Some PE devices cannot process MPLS headers. While these devices 156 have several alternatives to MPLS-based transport tunnels, they 157 require an alternative to MPLS-based encoding of VPN context 158 information. This document defines a new IPv6 Destination Option 159 that can be used to encode VPN context information. It is applicable 160 when VPN payload is transported over IPv6. 162 2. Requirements Language 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 166 "OPTIONAL" in this document are to be interpreted as described in BCP 167 14 [RFC2119] [RFC8174] when, and only when, they appear in all 168 capitals, as shown here. 170 3. VPN Context Information 172 VPN context information specifies a forwarding procedure to be 173 executed by the egress PE. However, VPN context information values 174 are not globally mapped to forwarding procedures. Each egress PE 175 maps each forwarding procedure that it supports to a VPN context 176 information value. Therefore, VPN context information values are 177 locally scoped to the egress PE. 179 PE devices can acquire VPN Context Information: 181 o From one another, using a distributed, control plane protocol 182 (e.g., BGP [RFC4271] [RFC4760]) 184 o From a controller. 186 The mechanisms by which PE devices acquire VPN Context Information 187 are beyond the scope of this document. 189 4. The VPN Context Information Option 191 0 1 2 3 192 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 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Option Type | Opt Data Len | VPN Context Information ... 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 197 Figure 1 199 Figure 1 depicts the VPN Context Information Option. The IPv6 200 Destination Options header MAY include the VPN Context Information 201 option. The IPv6 Hop-by-hop header MUST NOT include the VPN Context 202 Information option. 204 Option fields are as follows: 206 o Option Type - VPN Context Information option. Value TBD by IANA. 207 See Notes below. 209 o Opt Data Len - Length of Option Data, measured in bytes. 211 o VPN Context Information - Specifies a forwarding procedure to be 212 executed by the egress PE. 214 The VPN Context Information Option MUST NOT appear multiple times in 215 a single packet. If a node receives a packet that contains multiple 216 instances of the VPN Context Information Option, it MUST discard the 217 packet and send and ICMP Parameter Problem, Code 2, message to the 218 packet's source. 220 NOTE 1: The highest-order two bits of the Option Type (i.e., the 221 "act" bits) are 10. These bits specify the action taken by a 222 destination node that does not recognize VPN Context Information 223 option. The required action is to discard the packet and, regardless 224 of whether or not the packet's Destination Address was a multicast 225 address, send an ICMPv6 [RFC4443] Parameter Problem, Code 2, message 226 to the packet's Source Address, pointing to the unrecognized Option 227 Type. 229 NOTE 2: The third highest-order bit of the Option Type (i.e., the 230 "chg" bit) is 0. This indicates that Option Data cannot be modified 231 along the path between the packet's source and its destination. 233 5. Security Considerations 235 A VPN can be deployed: 237 o In a walled-garden environment. 239 o In an over-the-top environment. 241 In a walled-garden environment, all PE devices and all devices that 242 connect PEs to one another reside in the same security domain. 243 Therefore, there is no risk that a packet might be modified as it 244 travels from PE to PE. 246 In an over-the-top environment, all PE devices reside in one security 247 domain while devices that connect PEs to one another can reside in a 248 different security domain. In that case, there is significant risk 249 that a packet might be modified as it travels from PE to PE. 251 Therefore, the VPN Context Information option MUST be authenticated 252 when used in over-the-top environments. In this scenario, an IPv6 253 Encapsulating Security Payload (ESP) [RFC4303] MUST proceed the 254 Destination Options header that carries the VPN Context Information 255 option. The ESP integrity service MUST be enabled. 257 6. IANA Considerations 259 IANA is requested to allocate a codepoint from the Destination 260 Options and Hop-by-hop Options registry 261 (https://www.iana.org/assignments/ipv6-parameters/ 262 ipv6-parameters.xhtml#ipv6-parameters-2). This option is called "VPN 263 Context Information". The "act" bits are 10 and the "chg" bit is 0. 265 7. Acknowledgements 267 Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert and John Leddy 268 for their comments. 270 8. References 272 8.1. Normative References 274 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 275 DOI 10.17487/RFC0791, September 1981, 276 . 278 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 279 Requirement Levels", BCP 14, RFC 2119, 280 DOI 10.17487/RFC2119, March 1997, 281 . 283 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 284 RFC 4303, DOI 10.17487/RFC4303, December 2005, 285 . 287 [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet 288 Control Message Protocol (ICMPv6) for the Internet 289 Protocol Version 6 (IPv6) Specification", STD 89, 290 RFC 4443, DOI 10.17487/RFC4443, March 2006, 291 . 293 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 294 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 295 May 2017, . 297 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 298 (IPv6) Specification", STD 86, RFC 8200, 299 DOI 10.17487/RFC8200, July 2017, 300 . 302 8.2. Informative References 304 [I-D.ietf-6man-segment-routing-header] 305 Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and 306 d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header 307 (SRH)", draft-ietf-6man-segment-routing-header-15 (work in 308 progress), October 2018. 310 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 311 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 312 DOI 10.17487/RFC2784, March 2000, 313 . 315 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 316 Label Switching Architecture", RFC 3031, 317 DOI 10.17487/RFC3031, January 2001, 318 . 320 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 321 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 322 DOI 10.17487/RFC4271, January 2006, 323 . 325 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 326 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 327 2006, . 329 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 330 "Multiprotocol Extensions for BGP-4", RFC 4760, 331 DOI 10.17487/RFC4760, January 2007, 332 . 334 [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private 335 LAN Service (VPLS) Using BGP for Auto-Discovery and 336 Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, 337 . 339 [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private 340 LAN Service (VPLS) Using Label Distribution Protocol (LDP) 341 Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, 342 . 344 [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 345 Virtual Private Networks Using BGP for Auto-Discovery and 346 Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, 347 . 349 [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., 350 Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based 351 Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 352 2015, . 354 [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and 355 Maintenance Using the Label Distribution Protocol (LDP)", 356 STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, 357 . 359 Authors' Addresses 361 Ron Bonica 362 Juniper Networks 363 2251 Corporate Park Drive 364 Herndon, Virginia 20171 365 USA 367 Email: rbonica@juniper.net 368 Chris Lenart 369 Verizon 370 22001 Loudoun County Parkway 371 Ashburn, Virginia 20147 372 USA 374 Email: chris.lenart@verizon.com 376 Greg Presbury 377 Hughes Network Systems 378 11717 Exploration Lane 379 Germantown, Maryland 20876 380 USA 382 Email: greg.presbury@hughes.com