Internet-Draft Svc. Dest. Opt. October 2024
Bonica, et al. Expires 13 April 2025 [Page]
Workgroup:
6man
Internet-Draft:
draft-ietf-6man-vpn-dest-opt-00
Published:
Intended Status:
Experimental
Expires:
Authors:
R. Bonica
Juniper Networks
X. Li
CERNET Center/Tsinghua University
A. Farrel
Old Dog Consulting
Y. Kamite
NTT Communications Corporation
L. Jalil
Verizon

The IPv6 VPN Service Destination Option

Abstract

This document describes an experiment in which VPN service information for both layer 2 and layer 3 VPNs is encoded in a new IPv6 Destination Option. The new IPv6 Destination Option is called the VPN Service Option.

One purpose of this experiment is to demonstrate that the VPN Service Option can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, have been sufficiently addressed. Finally, this document encourages replication of the experiment.

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 13 April 2025.

Table of Contents

1. Introduction

Generic Packet Tunneling [RFC2473] allows a router in one network to encapsulate a packet in an IP header and send that packet across the Internet to another router, creating a virtual link. The receiving router removes the outer IP header and forwards the original packet into its own network. One motivation for Generic Packet Tunneling is to provide connectivity between two networks that share a private addressing [RFC1918] [RFC4193] plan but are not connected by direct links. In this case, all sites in the first network are accessible to all sites in the second network. Likewise, all sites in the second network are accessible to all sites in the first network.

Virtual Private Networks (VPN) technologies provide additional functionality, allowing network providers to emulate private networks by using shared infrastructure. For example, assume that red sites and blue sites connect to a provider network. The provider network allows communication among red sites. It also allows communication among blue sites. However, it prevents communication between red sites and blue sites.

The IETF has standardized many VPN technologies, including:

The VPN technologies mentioned above share the following characteristics:

The mechanism described above requires both PE devices (ingress and egress) to support MPLS. It cannot be deployed where one or both of the PEs does not support MPLS.

This document describes an experiment in which VPN service information for both layer 2 and layer 3 VPNs is encoded in a new IPv6 Destination Option [RFC8200] called the VPN Service Option. This option will allow VPNs to be deployed between Provider Edge routers that support IPv6 but do not support MPLS.

One purpose of this experiment is to demonstrate that the VPN Service Option can be implemented and deployed in a production network. Another purpose is to demonstrate that the security considerations, described in this document, have been sufficiently addressed. Finally, this document encourages replication of the experiment, so that operational issues can be discovered.

2. Conventions and Definitions

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 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

3. The VPN Service Option

The VPN Service Option is an IPv6 Destination Option encoded following the encoding rules defined in [RFC8200].

As shown in section 4.2 of [RFC8200] the IPv6 Destination Option contains three fields: Option Type, Opt Data Len, Option Data. For the VPN Service Option the fields are used as follows:

The VPN Service Option MAY appear in a Destination Options header that precedes an upper-layer header. It MUST NOT appear in any other extension header. If VPN Service option appears in appears in another extension header, the receiver MUST discard the packet.

NOTE : For this experiment, the Option Type is set to '01011110', i.e., 0x5E. The highest-order two bits are set to 01 to indicate that the required action by a destination node that does not recognize the option is to discard the packet. The third highest-order bit is set to 0 to indicate that Option Data cannot be modified along the path between the packet's source and its destination. The remaining low-order bits are set to '11110' to indicate the single IPv6 Destination Option Type code point available in the registry for experimentation.

3.1. VPN Service Option Pseudo-header

Figure 1 depicts the VPN Service Option Pseudo-header. It is used to calculate the checksum in the VPN Service Option.

*---------------------------------------------------------------*
| IPv6 Source Address  |IPv6 Destination Address | Option Data  |
*---------------------------------------------------------------*
Figure 1: Pseudo-header

4. Forwarding Plane Considerations

The ingress PE encapsulates customer payload in a tunnel header. The tunnel header contains:

The IPv6 header contains:

If the Authentication Header is present, it contains:

IPsec processing of the AH and ESP headers would occur before the VPN Service Option is available for processing by tunnel egress PE.

The IPv6 Destination Options Extension Header contains:

5. Control Plane Considerations

The FIB can be populated:

If the FIB is populated using BGP, BGP creates a Label-FIB (LFIB), exactly as it would if VPN service information were encoded in an MPLS service label. The egress PE queries the LFIB to resolve information contained by the VPN Service Option.

6. IANA Considerations

This document does not make any IANA requests.

However, if the experiment described herein succeeds, the authors will reissue this document, to be published on the Standards Track. The reissued document will request an IPv6 Destination Option number.

7. Security Considerations

IETF VPN technologies assume that PE devices trust one another. If an egress PE processes a VPN Service Option from an untrusted device, VPN boundaries can be breached.

The following are acceptable methods of risk mitigation:

All nodes at the edge limited domain maintain Access Control Lists (ACLs) that discard packets that satisfy the following criteria:

The checksum in the VPN Service Option provides some protection against accidental modification of the fields that form the pseudo-header, but it does not provide any additional security for the mechanisms defined in this document because any attacker modifying the pseudo-header can also modify the checksum. It does provide protection against accidental collisions between experiments as described in Section 8 because a packet from another experiment using the same Experimental codepoint will not contain a valid entry in the checksum field and so will be rejected without interfering with the experiment.

8. Deployment Considerations

The VPN Service Option is imposed by an ingress PE and processed by an egress PE. It is not processed by any nodes along the delivery path between the ingress PE and egress PE. So, it is safe to deploy the VPN Service Option across the Internet.

However, some networks discard packets that include IPv6 Destination Options. This is an imediment to deplyment.

Because the VPN Service Option uses an experimental code point, there is a risk of collisions with other experiments. Specifically, the egress PE may process packets from another experiment that uses the same code point. This risk is mitigated by the VPN Service Option checksum. It is highly unlikely that a packet received from the other experiment will pass checksum validation.

It is expected that, as with all experiments with IETF protocols, care is taken by the operator to ensure that all nodes participating in an experiment are carefully configured.

9. Experimental Results

Parties participating in this experiment should publish experimental results within one year of the publication of this document. Experimental results should address the following:

10. Acknowledgements

Thanks to Eliot Lear and Mark Smith for their reviews and contributions to this document.

11. References

11.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC4271]
Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, , <https://www.rfc-editor.org/rfc/rfc4271>.
[RFC4302]
Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, , <https://www.rfc-editor.org/rfc/rfc4302>.
[RFC4303]
Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, DOI 10.17487/RFC4303, , <https://www.rfc-editor.org/rfc/rfc4303>.
[RFC4760]
Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, , <https://www.rfc-editor.org/rfc/rfc4760>.
[RFC5440]
Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, , <https://www.rfc-editor.org/rfc/rfc5440>.
[RFC6241]
Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, , <https://www.rfc-editor.org/rfc/rfc6241>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8200]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, , <https://www.rfc-editor.org/rfc/rfc8200>.

11.2. Informative References

[RFC1918]
Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, , <https://www.rfc-editor.org/rfc/rfc1918>.
[RFC2473]
Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, , <https://www.rfc-editor.org/rfc/rfc2473>.
[RFC3032]
Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, DOI 10.17487/RFC3032, , <https://www.rfc-editor.org/rfc/rfc3032>.
[RFC4193]
Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, DOI 10.17487/RFC4193, , <https://www.rfc-editor.org/rfc/rfc4193>.
[RFC4364]
Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, , <https://www.rfc-editor.org/rfc/rfc4364>.
[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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/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, , <https://www.rfc-editor.org/rfc/rfc8077>.
[V6MSG]
Internet Assigned Numbers Authority (IANA), "Internet Protocol Version 6 (IPv6) Parameters: Destination Options and Hop-by-Hop Options", Web https://www.iana.org/assignments/ipv6-parameters/ipv6-parameters.xhtml#ipv6-parameters-2.

Authors' Addresses

Ron Bonica
Juniper Networks
Herndon, Virginia
United States of America
Xing Li
CERNET Center/Tsinghua University
Beijing
Adrian Farrel
Old Dog Consulting
United Kingdom
Yuji Kamite
NTT Communications Corporation
Minato-ku
Japan
Luay Jalil
Verizon
Richardson, Texas
United States of America