The IPv6 Virtual Private Network (VPN) Context Information Option
draft-bonica-6man-vpn-dest-opt-02
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
---|---|---|---|
Authors | Ron Bonica , Chris Lenart , Greg Presbury | ||
Last updated | 2019-02-27 | ||
RFC stream | (None) | ||
Formats | |||
Additional resources | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | I-D Exists | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-bonica-6man-vpn-dest-opt-02
6man R. Bonica Internet-Draft Juniper Networks Intended status: Standards Track C. Lenart Expires: August 31, 2019 Verizon G. Presbury Hughes Network Systems February 27, 2019 The IPv6 Virtual Private Network (VPN) Context Information Option draft-bonica-6man-vpn-dest-opt-02 Abstract This document defines a new IPv6 Destination Option that can be used to encode Virtual Private Network (VPN) context information. It is applicable when VPN payload is transported over IPv6. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 31, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of Bonica, et al. Expires August 31, 2019 [Page 1] Internet-Draft VPN Dest Opt February 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 3. VPN Context Information . . . . . . . . . . . . . . . . . . . 4 4. The VPN Context Information Option . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 8.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Virtual Private Network (VPN) technologies allow network providers to emulate private networks with shared infrastructure. For example, assume that a red sites and blue sites connect to a provider network. The provider network facilitates communication among red sites and facilitates communication among blue sites. However, it prevents communication between red sites and blue sites. The IETF has standardized many VPN technologies, including: o Layer 2 VPN (L2VPN) [RFC6624]. o Layer 3 VPN (L3VPN) [RFC4364]. o Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]. o Ethernet VPN (EVPN) [RFC7432]. o Pseudowires [RFC8077]. The above-mentioned technologies include the following components: o Customer Edge (CE) devices. o Provider Edge (PE) devices. o Routing Instances. o VPN context information. Bonica, et al. Expires August 31, 2019 [Page 2] Internet-Draft VPN Dest Opt February 2019 o Transport tunnels. CE devices participate in closed communities called VPNs. CEs that participate in one VPN can communicate with one another but cannot communicate with CEs that participate in another VPN. CE devices connect to provider networks through PE devices. Each PE maintains one Routing Instance for each VPN that it supports. A Routing Instance is a VPN specific Forwarding Information Base (FIB). In EVPN, Routing Instances are called Ethernet Virtual Instances (EVI). Assume that one CE sends a packet through a provider network to another CE. The packet enters the provider network through an ingress PE and leaves the provider network through an egress PE. The packet may traverse one or more intermediate nodes on route from PE to PE. When the ingress PE receives the packet, it: o Identifies the Routing Instance that supports the originating CE's VPN. o Searches that Routing Instance for the packet's destination. If the search fails, the ingress PE discards the packet. If the search succeeds, it yields the following: o VPN context information. o The egress PE's IP address. The ingress PE prepends VPN context information and a transport header to the packet, in that order. It then forwards the packet through a transport tunnel to the egress PE. The egress PE removes the transport header, if it has not already been removed by an upstream device. It then examines and removes the VPN context information. Finally, it uses the VPN context information to forward the packet to its destination (i.e., a directly connected CE). In the above-mentioned VPN technologies, the ingress PE encodes VPN context information in a Multiprotocol Label Switching (MPLS) [RFC3031] label. Depending upon the transport tunnel type, the transport header can be: o A MPLS label or label stack. Bonica, et al. Expires August 31, 2019 [Page 3] Internet-Draft VPN Dest Opt February 2019 o An IPv4 [RFC0791] header. o An IPv6 [RFC8200] header. o A Generic Routing Encapsulation (GRE) [RFC2784] header encapsulated in IPv4 or IPv6. Some PE devices cannot process MPLS headers. While these devices have several alternatives to MPLS-based transport tunnels, they require an alternative to MPLS-based encoding of VPN context information. This document defines a new IPv6 Destination Option that can be used to encode VPN context information. It is applicable when VPN payload is transported over IPv6. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. VPN Context Information VPN context information specifies a forwarding procedure to be executed by the egress PE. However, VPN context information values are not globally mapped to forwarding procedures. Each egress PE maps each forwarding procedure that it supports to a VPN context information value. Therefore, VPN context information values are locally scoped to the egress PE. PE devices can acquire VPN Context Information: o From one another, using a distributed, control plane protocol (e.g., BGP [RFC4271] [RFC4760]) o From a controller. The mechanisms by which PE devices acquire VPN Context Information are beyond the scope of this document. 4. The VPN Context Information Option Bonica, et al. Expires August 31, 2019 [Page 4] Internet-Draft VPN Dest Opt February 2019 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Opt Data Len | VPN Context Information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 1 Figure 1 depicts the VPN Context Information Option. Option fields are as follows: o Option Type - VPN Context Information option. Value TBD by IANA. See Notes below. o Opt Data Len - Length of Option Data, measured in bytes. o VPN Context Information - Specifies a forwarding procedure to be executed by the egress PE. The VPN Context Information Option MAY appear in a Destination Options header that precedes an upper-layer header. It MUST NOT appear in a Hop-by-hop Options header and SHOULD NOT appear in a Destination Options header that precedes a Routing header. If it appears in a Hop-by-hop Options header, the processing node will discard the packet and send an ICMPv6 [RFC4443] Parameter Problem, Code 2, message to the packet's Source Address, pointing to the Option Type. If it appears in a Destination Options header that precedes a Routing header, the processing node will attempt to process the option, because it has not yet encountered the Routing header. If the VPN Context Information appears in a Destination Options header, it SHOULD be the final option listed in the header. Because the VPN Context Information Option causes the packet to be decapsulated and forwarded, all options listed after the VPN Context Information Option will be ignored. NOTE 1: The highest-order two bits of the Option Type (i.e., the "act" bits) are 10. These bits specify the action taken by a destination node that does not recognize VPN Context Information option. The required action is to discard the packet and, regardless of whether or not the packet's Destination Address was a multicast address, send an ICMPv6 Parameter Problem, Code 2, message to the packet's Source Address, pointing to the unrecognized Option Type. Bonica, et al. Expires August 31, 2019 [Page 5] Internet-Draft VPN Dest Opt February 2019 NOTE 2: The third highest-order bit of the Option Type (i.e., the "chg" bit) is 0. This indicates that Option Data cannot be modified along the path between the packet's source and its destination. 5. Security Considerations A VPN can be deployed: o In a walled-garden environment. o In an over-the-top environment. In a walled-garden environment, all PE devices and all devices that connect PEs to one another reside in the same security domain. Therefore, there is no risk that a packet might be modified as it travels from PE to PE. In an over-the-top environment, all PE devices reside in one security domain while devices that connect PEs to one another can reside in a different security domain. In that case, there is significant risk that a packet might be modified as it travels from PE to PE. Therefore, the VPN Context Information option MUST be authenticated when used in over-the-top environments. In this scenario, an IPv6 Encapsulating Security Payload (ESP) [RFC4303] MUST proceed the Destination Options header that carries the VPN Context Information option. The ESP integrity service MUST be enabled. 6. IANA Considerations IANA is requested to allocate a codepoint from the Destination Options and Hop-by-hop Options registry (https://www.iana.org/assignments/ipv6-parameters/ ipv6-parameters.xhtml#ipv6-parameters-2). This option is called "VPN Context Information". The "act" bits are 10 and the "chg" bit is 0. 7. Acknowledgements Thanks to Brian Carpenter, Adrian Farrel, Tom Herbert and John Leddy for their comments. 8. References 8.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <https://www.rfc-editor.org/info/rfc791>. Bonica, et al. Expires August 31, 2019 [Page 6] Internet-Draft VPN Dest Opt February 2019 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, December 2005, <https://www.rfc-editor.org/info/rfc4303>. [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>. [RFC8174] Leiba, B., Dierks & Rescorla Expires January 8, 2015 [Page 81] Internet-Draft TLS July 2014 Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse the connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client. Earlier versions of the TLS specification were not fully clear on what the record layer version number (TLSPlaintext.version) should contain when sending ClientHello (i.e., before it is known which version of the protocol will be employed). Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers, but this is a complex topic beyond the scope of this document. E.2. Compatibility with SSL 2.0 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST contain the same version number as would be used for ordinary ClientHello, and MUST encode the supported TLS cipher suites in the CIPHER-SPECS-DATA field as described below. Warning: The ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste, since the newer ClientHello format provides better mechanisms for moving to newer versions and negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. However, even TLS servers that do not support SSL 2.0 MAY accept version 2.0 CLIENT-HELLO messages. The message is presented below in sufficient detail for TLS server implementors; the true definition is still assumed to be [SSL2]. For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same way as a ClientHello with a "null" compression method and no extensions. Note that this message MUST be sent directly on the wire, not wrapped as a TLS record. For the purposes of calculating Finished and CertificateVerify, the msg_length field is not considered to be a part of the handshake message. Dierks & Rescorla Expires January 8, 2015 [Page 82] Internet-Draft TLS July 2014 uint8 V2CipherSpec[3]; struct { uint16 msg_length; uint8 msg_type; Version version; uint16 cipher_spec_length; uint16 session_id_length; uint16 challenge_length; V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; opaque session_id[V2ClientHello.session_id_length]; opaque challenge[V2ClientHello.challenge_length; } V2ClientHello; msg_length The highest bit MUST be 1; the remaining bits contain the length of the following data in bytes. msg_type This field, in conjunction with the version field, identifies a version 2 ClientHello message. The value MUST be 1. version Equal to ClientHello.client_version. cipher_spec_length This field is the total length of the field cipher_specs. It cannot be zero and MUST be a multiple of the V2CipherSpec length (3). session_id_length This field MUST have a value of zero for a client that claims to support TLS 1.2. challenge_length The length in bytes of the client's challenge to the server to authenticate itself. Historically, permissible values are between 16 and 32 bytes inclusive. When using the SSLv2 backward- compatible handshake the client SHOULD use a 32-byte challenge. cipher_specs This is a list of all CipherSpecs the client is willing and able to use. In addition to the 2.0 cipher specs defined in [SSL2], this includes the TLS cipher suites normally sent in ClientHello.cipher_suites, with each cipher suite prefixed by a zero byte. For example, the TLS cipher suite {0x00,0x0A} would be sent as {0x00,0x00,0x0A}. Dierks & Rescorla Expires January 8, 2015 [Page 83] Internet-Draft TLS July 2014 session_id This field MUST be empty. challenge Corresponds to ClientHello.random. If the challenge length is less than 32, the TLS server will pad the data with leading (note: not trailing) zero bytes to make it 32 bytes long. Note: Requests to resume a TLS session MUST use a TLS client hello. E.3. Avoiding Man-in-the-Middle Version Rollback When TLS clients fall back to Version 2.0 compatibility mode, they MUST use special PKCS#1 block formatting. This is done so that TLS servers will reject Version 2.0 sessions with TLS-capable clients. When a client negotiates SSL 2.0 but also supports TLS, it MUST set the right-hand (least-significant) 8 random bytes of the PKCS padding (not including the terminal null of the padding) for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding bytes are 0x03. If they are not, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match). Note that reporting the error situation to the client could make the server vulnerable to attacks described in [BLEI]. Appendix F. Security Analysis The TLS protocol is designed to establish a secure connection between a client and a server communicating over an insecure channel. This document makes several traditional assumptions, including that attackers have substantial computational resources and cannot obtain secret information from sources outside the protocol. Attackers are assumed to have the ability to capture, modify, delete, replay, and otherwise tamper with messages sent over the communication channel. This appendix outlines how TLS has been designed to resist a variety of attacks. F.1. Handshake Protocol The handshake protocol is responsible for selecting a cipher spec and generating a master secret, which together comprise the primary cryptographic parameters associated with a secure session. The handshake protocol can also optionally authenticate parties who have Dierks & Rescorla Expires January 8, 2015 [Page 84] Internet-Draft TLS July 2014 certificates signed by a trusted certificate authority. F.1.1. Authentication and Key Exchange TLS supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel is secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked. The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret (see Section 8.1). The master_secret is required to generate the Finished messages and record protection keys (see Section 7.4.8 and Section 6.3). By sending a correct Finished message, parties thus prove that they know the correct pre_master_secret. F.1.1.1. Anonymous Key Exchange Completely anonymous sessions can be established using Diffie-Hellman for key exchange. The server's public parameters are contained in the server key exchange message, and the client's are sent in the client key exchange message. Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e., the pre_master_secret). Warning: Completely anonymous connections only provide protection against passive eavesdropping. Unless an independent tamper-proof channel is used to verify that the Finished messages were not replaced by an attacker, server authentication is required in environments where active man-in-the-middle attacks are a concern. F.1.1.2. Diffie-Hellman Key Exchange with Authentication When Diffie-Hellman key exchange is used, the server can either supply a certificate containing fixed Diffie-Hellman parameters or use the server key exchange message to send a set of temporary Diffie-Hellman parameters signed with a DSA or RSA certificate. Temporary parameters are hashed with the hello.random values before signing to ensure that attackers do not replay old parameters. In Dierks & Rescorla Expires January 8, 2015 [Page 85] Internet-Draft TLS July 2014 either case, the client can verify the certificate or signature to ensure that the parameters belong to the server. If the client has a certificate containing fixed Diffie-Hellman parameters, its certificate contains the information required to complete the key exchange. Note that in this case the client and server will generate the same Diffie-Hellman result (i.e., pre_master_secret) every time they communicate. To prevent the pre_master_secret from staying in memory any longer than necessary, it should be converted into the master_secret as soon as possible. Client Diffie-Hellman parameters must be compatible with those supplied by the server for the key exchange to work. If the client has a standard DSA or RSA certificate or is unauthenticated, it sends a set of temporary parameters to the server in the client key exchange message, then optionally uses a certificate verify message to authenticate itself. If the same DH keypair is to be used for multiple handshakes, either because the client or server has a certificate containing a fixed DH keypair or because the server is reusing DH keys, care must be taken to prevent small subgroup attacks. Implementations SHOULD follow the guidelines found in [RFC2785]. Small subgroup attacks are most easily avoided by using one of the DHE cipher suites and generating a fresh DH private key (X) for each handshake. If a suitable base (such as 2) is chosen, g^X mod p can be computed very quickly; therefore, the performance cost is minimized. Additionally, using a fresh key for each handshake provides Perfect Forward Secrecy. Implementations SHOULD generate a new X for each handshake when using DHE cipher suites. Because TLS allows the server to provide arbitrary DH groups, the client should verify that the DH group is of suitable size as defined by local policy. The client SHOULD also verify that the DH public exponent appears to be of adequate size. [RFC3766] provides a useful guide to the strength of various group sizes. The server MAY choose to assist the client by providing a known group, such as those defined in [RFC4307] or [RFC3526]. These can be verified by simple comparison. F.1.2. Version Rollback Attacks Because TLS includes substantial improvements over SSL Version 2.0, attackers may try to make TLS-capable clients and servers fall back to Version 2.0. This attack can occur if (and only if) two TLS- capable parties use an SSL 2.0 handshake. Dierks & Rescorla Expires January 8, 2015 [Page 86] Internet-Draft TLS July 2014 Although the solution using non-random PKCS #1 block type 2 message padding is inelegant, it provides a reasonably secure way for Version 3.0 servers to detect the attack. This solution is not secure against attackers who can brute-force the key and substitute a new ENCRYPTED-KEY-DATA message containing the same key (but with normal padding) before the application-specified wait threshold has expired. Altering the padding of the least-significant 8 bytes of the PKCS padding does not impact security for the size of the signed hashes and RSA key lengths used in the protocol, since this is essentially equivalent to increasing the input block size by 8 bytes. F.1.3. Detecting Attacks Against the Handshake Protocol An attacker might try to influence the handshake exchange to make the parties select different encryption algorithms than they would normally choose. For this attack, an attacker must actively change one or more handshake messages. If this occurs, the client and server will compute different values for the handshake message hashes. As a result, the parties will not accept each others' Finished messages. Without the master_secret, the attacker cannot repair the Finished messages, so the attack will be discovered. F.1.4. Resuming Sessions When a connection is established by resuming a session, new ClientHello.random and ServerHello.random values are hashed with the session's master_secret. Provided that the master_secret has not been compromised and that the secure hash operations used to produce the record protection kayes are secure, the connection should be secure and effectively independent from previous connections. Attackers cannot use known keys to compromise the master_secret without breaking the secure hash operations. Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes, since an attacker who obtains a master_secret may be able to impersonate the compromised party until the corresponding session ID is retired. Applications that may be run in relatively insecure environments should not write session IDs to stable storage. Dierks & Rescorla Expires January 8, 2015 [Page 87] Internet-Draft TLS July 2014 "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>. [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, <https://www.rfc-editor.org/info/rfc8200>. 8.2. Informative References [I-D.ietf-6man-segment-routing-header] Filsfils, C., Previdi, S., Leddy, J., Matsushima, S., and d. daniel.voyer@bell.ca, "IPv6 Segment Routing Header (SRH)", draft-ietf-6man-segment-routing-header-16 (work in progress), February 2019. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, DOI 10.17487/RFC2784, March 2000, <https://www.rfc-editor.org/info/rfc2784>. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, <https://www.rfc-editor.org/info/rfc3031>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <https://www.rfc-editor.org/info/rfc4271>. Bonica, et al. Expires August 31, 2019 [Page 7] Internet-Draft VPN Dest Opt February 2019 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <https://www.rfc-editor.org/info/rfc4760>. [RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private LAN Service (VPLS) Using BGP for Auto-Discovery and Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007, <https://www.rfc-editor.org/info/rfc4761>. [RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007, <https://www.rfc-editor.org/info/rfc4762>. [RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2 Virtual Private Networks Using BGP for Auto-Discovery and Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012, <https://www.rfc-editor.org/info/rfc6624>. [RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>. [RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017, <https://www.rfc-editor.org/info/rfc8077>. Authors' Addresses Ron Bonica Juniper Networks 2251 Corporate Park Drive Herndon, Virginia 20171 USA Email: rbonica@juniper.net Bonica, et al. Expires August 31, 2019 [Page 8] Internet-Draft VPN Dest Opt February 2019 Chris Lenart Verizon 22001 Loudoun County Parkway Ashburn, Virginia 20147 USA Email: chris.lenart@verizon.com Greg Presbury Hughes Network Systems 11717 Exploration Lane Germantown, Maryland 20876 USA Email: greg.presbury@hughes.com Bonica, et al. Expires August 31, 2019 [Page 9]