Network Working Group O. Vandezande, Ed. Internet-Draft Dimension Data, s.a. Intended status: Standards Track July 20, 2015 Expires: January 20, 2016 IPv6 IPVPN Option (IPv6VPNO) draft-vandezande-6man-ipv6-ipvpn-option-01 Abstract In new generation IP networks, where virtualization is highly used, an IPVPN identifier (environment) associated to the target node IP address is needed to deliver the IP packet in the right environment. IPVPN support brings some complexity in the IP networks (e.g. routing protocols, tunneling techniques, etc). Associating the IPVPN information natively in IPv6 with the destination IP address using an IPv6 destination option simplifies IPVPN support. This draft describes the IPv6 IPVPN Destination Option Type and how it is used by IPv6 IPVPN capable nodes. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 http://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 document is an individual submission. Comments are solicited and should be addressed to the author(s). Vandezande Expires January 20, 2016 [Page 1] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 This Internet-Draft will expire on January 20, 2016. Copyright Notice Copyright (c) 2015 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 (http://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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Vandezande Expires January 20, 2016 [Page 2] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 Table of Contents 1. Structure of this document . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Method Overview . . . . . . . . . . . . . . . . . . . . . 5 3. IPv6 IPVPN Identification . . . . . . . . . . . . . . . . . . 5 4. IPv6 IPVPN Option Header (IPv6VPNO) . . . . . . . . . . . . . 6 5. IPv6VPNO and RFC2460 behavior . . . . . . . . . . . . . . . . 8 6. IPv6VPNO Operations . . . . . . . . . . . . . . . . . . . . . 8 6.1. The ingress IPv6 IPVPN capable node . . . . . . . . . . . 8 6.2. The transit IPv6 nodes . . . . . . . . . . . . . . . . . . 9 6.3. The egress IPv6 IPVPN capable node . . . . . . . . . . . . 9 6.4. The original destination node . . . . . . . . . . . . . . 10 7. IPv6VPNO Optimization . . . . . . . . . . . . . . . . . . . . 10 8. IPv6VPNO and tunneling . . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Vandezande Expires January 20, 2016 [Page 3] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 1. Structure of this document Section 2 gives an introduction on the IPv6 IPVPN option (IPv6VPNO) allowing IPVPN support natively in the IPv6 dataplane. Section 3 defines the IPv6 IPVPN Identification representation. Section 4 describes the IPv6 IPVPN Option Header (IPv6VPNO). Section 5 discusses some requirements imposed by [RFC2460]. Section 6 details the procedures of the IPv6 IPVPN Option. Section 7 defines the possible optimizations of IPv6VPNO. Section 8 discusses about the interaction with IPv6VPNO when a tunneling protocol is used. Section 9 defines some IPv6VPNO considerations for IANA. Section 10 describes the security aspect of the IPv6 IPVPN Option. 2. Introduction This document describes a method by which an Enterprise may use an IPv6 network infrastructure (e.g. LAN, WAN, Data Center, inter-Cloud) to provide IP Virtual Private Networks (IPVPNs) for its connected nodes natively with IPv6. A new IP option is defined for the optional IPv6 Destination Options Header containing the information needed for the IPv6 IPVPN capable node to make its internet-layer lookup into the right Virtual Routing and Forwarding table (VRF associated to the IPVPN). An IPv6 IPVPN capable node is any device working at the internet layer like a router, a firewall, a load balancer, an application server,... This method focuses only at the data plane layer. Current protocols at control plane layer remain unchanged. This IPv6 IPVPN method may be combined with other IPv6 features benefiting from the optional extension headers like IPv6 Segment routing (draft-previdi-6man-segment-routing-header-06) when an IPv6 network needs to support a full features set like IPVPN, FRR, TE,... The IPv6 IPVPN (IPv6VPN) method targets IPv6 networks requiring IPVPN support and where MPLS-VPN data-plane is not used or, IPv6 networks using VRF-Lite as IPVPN method but requiring more simplicity and Vandezande Expires January 20, 2016 [Page 4] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 more scalability in their IPVPN network infrastructure. 2.1 Assumptions It is assumed that the enterprise IP networks (e.g. Campus, Branch, Backbone, Data center, inter-Cloud) are up and running eventually with one IGP instance per domain (Campus, WAN, Backbone, DC, Cloud). This method also assumes that the enterprise network wants to support multiple environments (IPVPNs/VRFs). Therefore, the enterprise has configured an internet-layer isolation technique (like VRF-lite) at the edge of its network (may be a single domain, part of a single domain or across multiple domains of its networks), and has eventually configured a control plane protocol (e.g. MP-BGP) between its IPVPN network edge nodes to exchange the VPNV6 prefixes. Typically, the IPv6 IPVPN capable node obtains the IPVPN label it has to use for a given IPv6 packet flow through either local configuration, an IPVPN capable routing protocol or through an interaction with an external server such as an SDN controller. 2.2 Method Overview The IPv6 IPVPN capable ingress node encodes an IP option into the IPv6 destination options header that contains the IPVPN label of the environment's VPN, and the packet is forwarded towards the last hop of the IPv6 IPVPN capable network into the domain. The IPv6 IPVPN capable egress node uses the IPv6VPNO to identify the associated VRF table to make the route lookup. The IPv6VPNO MAY be removed from the packet prior to send it to its original destination. When traveling through the IPv6 network infrastructure, a packet may traverse IPv6 IPVPN capable nodes or non IPv6 IPVPN capable nodes. These nodes will forward the packet based on its DA regardless the content of the IPv6VPNO as mandated by [RFC2460], as the IPv6VPNO is encoded into the Destination Option Header. Therefore, interoperability between IPv6VPN-capable and non-IPv6VPN-capable nodes being ensured, a gradual deployment of IPv6VPN in existing networks is possible. The details of the procedures of IPv6VPNO are described in Section 6. 3. IPv6 IPVPN Identification The identification for an IPVPN is a VPN aggregate label. As this label may be distributed by an existing control plane protocol like MP-BGP, the IPv6 IPVPN identification is the same label as defined in MPLS-ENCAPS specified in [RFC3032]. This label is 3 octets long. Vandezande Expires January 20, 2016 [Page 5] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 4. IPv6 IPVPN Option Header (IPv6VPNO) The Destination Options header is used to carry the IPv6 IPVPN information as recommended in [RFC6564]. This IPVPN information is examined only by the packet's destination node (which is the egress IPv6 IPVPN capable node). A new IP option type for the destination options header is used as specified in [RFC2460]. This new IP option number has to be assigned by IANA for the IPv6VPNO. More information on the new IP option type is provided in the IANA considerations section 9. The IPv6 IPVPN Option (IPv6VPNO) is defined as follows: 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 | Label (3 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Label Cont.) | (Reserved) | Control | HMAC Key ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original IPv6 Destination Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Original IPv6 Source Address | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | | | HMAC (256 bits) | | (optional) | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where: o Option Type: 8-bit identifier of the type of option. TBD, to be assigned by IANA. o Opt Data Len: 8-bit unsigned integer. Length of the Option Data field of this option, in octets. Vandezande Expires January 20, 2016 [Page 6] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 o Label: The Label field carries the VPN aggregate label (same as labels for MPLS-ENCAPS). Each label is encoded as 3 octets. o (Reserved): 8-bit for 8-byte header alignment. MAY be used for future extension of the label size, or other fields. MUST be zero while not allocated. o Control: 8-bit. This field contains - Bit-0: Clean-up Bit. Set to instruct the egress IPv6 IPVPN node to remove the IPv6VPNO from the destination options header of the packet. - Bit-1: DA Replace bit. Set to indicated that the original IPv6 destination address has been replaced. The original IPv6 destination address is present when set. - Bit-2: SA Replace bit. Set to indicated that the original IPv6 source address has been replaced. The original IPv6 source address is present when set. o HMAC Key ID: 8-bit, if HMAC key-id is null, then there is no HMAC field. o Original IPv6 Destination Address: IPv6 address originally present in the DA field of the IPv6 packet. If Replace bit in control field is not set, then there is no original IPv6 destination address field. o Original IPv6 Source Address: IPv6 address originally present in the SA field of the IPv6 packet. If SA Replace bit in control field is not set, then there is no original IPv6 source address field. o HMAC: 256 bits wide. The HMAC field is the output of the hash of the concatenation of: - the Label - the (reserved) field - the control byte - the HMAC key id - the original IPv6 Destination Address - the original IPv6 Source Address - a pre-shared secret between IPv6 IPVPN nodes. The purpose of the HMAC field is to verify the validity and authorization of the IPVPN option. If an outsider of the IPVPN domain does not have access to the pre-shared secret, then it cannot compute the right HMAC field and the ingress (or egress) IPVPN capable node on the path check the validity of the HMAC and reject the packet if not valid. Vandezande Expires January 20, 2016 [Page 7] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 5. IPv6VPNO and RFC2460 behavior The IPv6VPNO being a new IP Option in the Destination Options Header, it has the associated properties: - Can only appear once in the packet. - Only the IPv6 IPVPN node whose address is in the DA field of the packet header MUST inspect the IPv6VPNO. 6. IPv6VPNO Operations In this section we describe the different procedures on the IPv6VPNO. Different behaviours happen at: o The ingress IPv6 IPVPN capable node o The transit IPv6 nodes o The egress IPv6 IPVPN capable node o The original destination node 6.1. The ingress IPv6 IPVPN capable node The ingress IPv6 IPVPN capable node may be a device operating at the internet layer (e.g. a router, a firewall,...) at the edge of the IPv6 IPVPN domain. When the ingress IPv6 IPVPN capable node receives an IPv6 packet, it does the following: o Determine the associated IPVPN aggregate label by either: - Local configuration like ingress interface VRF configuration, - local policy configuration or - through an interaction with an external server such as an SDN controller. o Encode the IPv6 IPVPN option into the destination options header. If no destination options header is present in the IPv6 packet, encode the IPv6 destination options header according to [RFC2460]. If the destination options header is present, encode the IPv6VPNO. When creating the IPv6VPNO, the following is done: - Option Type and Opt Data Len fields are set according to [RFC2460] taking into account the additional length for the IPv6VPNO. The option Type field is set as TBD (IPv6VPNO). - Label is set according to the VPN aggregate label determined previously. Vandezande Expires January 20, 2016 [Page 8] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 - Control bit-0 is set to 1 when the egress IPv6 IPVPN node must remove the IPv6VPNO. - Control bit-1 is set to 1 when the original DA is replaced by the IPv6 address of the egress IPv6 IPVPN node and the original DA is copied into the Original IPv6 Destination Address field of the IPv6VPNO. - Control bit-2 is set to 1 when the original SA is replaced by the IPv6 address of the ingress IPv6 IPVPN node and the original SA is copied into the Original IPv6 Source Address field of the IPv6VPNO. - Original IPv6 Destination Address is set with the copy of the original IPv6 Destination Address. - Original IPv6 Source Address is set with the copy of the original IPv6 Source Address. o Replace the original Destination Address with the IPv6 address of the egress IPv6 IPVPN capable node. o Replace the original Source Address with the IPv6 address of the ingress IPv6 IPVPN capable node. o The packet is sent out towards the egress IPv6 IPVPN capable node. 6.2. The transit IPv6 nodes The transit IPv6 node may be an IPv6 IPVPN capable node or a non-IPv6 IPVPN capable node that operates at the internet layer (e.g. a router, a firewall,...) inside of the IPv6 IPVPN domain. When the transit node receives an IPv6 packet with the IPv6VPNO, it processes the packet independently of the destination options header as specified in [RFC2460]. 6.3. The egress IPv6 IPVPN capable node The egress IPv6 IPVPN capable node may be a device operating at the internet layer (e.g. a router, a firewall,...) at the edge of the IPv6 IPVPN domain. When the egress IPv6 IPVPN capable node receives an IPv6 packet, targeted to itself, it checks if an IPv6VPNO is present into the packet and if present, does the following: Vandezande Expires January 20, 2016 [Page 9] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 o Replace the DA with the Original IPv6 Destination Address encoded into the IPv6VPN0 If the DA Replace bit is set. o Replace the SA with the Original IPv6 Source Address encoded into the IPv6VPN0 If SA Replace bit is set. o Determine the IPVPN based on the IPv6VPNO VPN aggregate label. o Remove the IPv6VPNO. Eventually remove the destination options header if the IPv6VPNO is the only option of the extension header. o Process the packet based on its destination address and IPVPN information. 6.4. The original destination node The original destination node is the original IPv6 targeted node at the generation of the IPv6 packet by the source. The original destination node MAY receive an IPv6 packet containing an IPv6VPNO. If the node is IPv6 IPVPN capable, it MAY process it if of interest. If the node is NOT IPv6 IPVPN capable, it MUST skip over this option and continue processing the header. 7. IPv6VPNO Optimization When the original IPv6 DA is already associated to the egress IPv6 IPVPN capable node, the DA does not need to be replaced, so the original IPv6 Destination Address MAY not be encoded in the IPv6VPNO. In this case, the control field bit-1 MUST be set to 0. Likewise for the Source address, when the original IPv6 SA is already associated to the ingress IPv6 IPVPN capable node, the SA does not need to be replaced, so the original IPv6 Source Address MAY not be encoded in the IPv6VPNO. In this case, the control field bit-2 MUST be set to 0. 8. IPv6VPNO and tunneling Outer encapsulation tunneling is the traditional method where an additional IPv6 header is prepended to the packet. The original IPv6 header being encapsulated, everything is preserved and the packet is switched/routed according to the outer header (that COULD contain an IPv6VPNO). The IPv6VPNO part of the encapsulated IPv6 packet MUST NOT be copied to the outer header. Vandezande Expires January 20, 2016 [Page 10] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 9. IANA Considerations TBD The two-highest-order bit of the IPVPN Option Type MUST be '00' as defined in [RFC2460]. It means that the action that must be taken if the processing IPv6 node does not recognize the Option Type is "skip over this option and continue processing the header". The third-highest-order bit of the Option Type specifying whether or not the Option Data of that option can change en-route to the packet's final destination. This bit MUST be set to 0 as the Option Data does not change en-route. 10. Security Considerations This section lists some potential security issues and presents the associated solutions related to the new IPVPN IP option (IPv6VPNO). The IPv6 IPVPN option is a new IP option encoded into the destination options header as described in [RFC2460] and is: o inserted when entering the IPv6 IPVPN domain which could be done by an Internet-layer node (e.g. router, firewall) o processed by the node of the IP header destination address. Routers on the path simply forward an IPv6 packet (i.e. the IPv6 destination address is not one of theirs) independently of the IPv6 destination options header. Routers whose one IPv6VPN0 enabled interface has an IPv6 address equals the destination address field of the IPv6 packet may process the IPv6VPNO if supported. Different security issues could happen like: o Source node attack, where an IPv6 source node insert an IPv6VPNO while member of an IPVPN, trying to send IPv6 packets into another IPVPN o Man-in-the-middle attack, where: - an internal transit node could generate an IPv6 packet with an IPv6VPNO while not being part of the IPv6 IPVPN network domain; this issue could happen in the transition phase to IPv6VPNO when all transit nodes are not IPv6 IPVPN capable - an internal transit node not part of the IPv6 IPVPN network could replace an IPv6 packet with an IPv6VPNO secured by a HMAC with an IPv6 packet with an IPv6VPNO not secured by a Vandezande Expires January 20, 2016 [Page 11] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 HMAC; this issue could happen in the transition phase to IPv6VPNO when all transit nodes are not IPv6 IPVPN capable - an external transit node could generate an IPv6 packet with an IPv6VPNO spoofing the address of an authorized inter-domain peer. Solutions to face the above security issues are: o For the source node attack, the ingress IPv6 IPVPN capable node receiving an IPv6 packet coming from an interface associated to an IPVPN MUST encode the IPv6VPNO. As an IPv6VPNO is already present in the destination options header and only one IPv6VPNO is allowed the ingress IPv6 IPVPN capable node MUST discard the IPv6 packet o For the man-in-the-middle node attacks, the HMAC field is made for that. The purpose of the HMAC field is to verify the validity and authorization of the IPv6VPNO itself. If a non-authorized outsider or non-authorized insider of the IPVPN domain does not have access to the pre-shared secret, then it cannot compute the right HMAC field and the ingress IPv6 IPVPN capable node or the egress IPv6 IPVPN capable node on the path processing the IPv6VPNO and configure to check the validity of the HMAC will simply discard the packet. When a key is configued for the domain, receiving an IPv6VPNO packet without the associated HMAC MUST be discarded as well. The HMAC Key-id field behaviour is similar to the one described into the IPv6 Segment routing in the I-D draft-previdi-6man-segment-routing-header-00. The following explanation is copied and adapted to IPv6VPNO from this draft: The HMAC Key-id field allows for the simultaneous existence of several hash algorithms (SHA-128, SHA-256, ... or future ones) as well as pre-shared keys. This allows for pre-shared key roll-over when two pre-shared keys are supported for a while when all IPv6 IPVPN nodes converged to a newer pre-shared key. The HMAC key-id is opaque, i.e., it has no syntax except as an index to the right combination of pre-shared key and hash algorithm. It also allows for interoperation among different IPVPN domains if allowed by local policy. How HMAC key-id and pre-shared secret are synchronized between participating nodes in the IPVPN domain is outside of the scope of this document ([RFC6407] GDOI could be a basis). The HMAC key SHOULD be shared inside a whole domain and/or per neighbour. The HMAC key has performance penalties and SHOULD be mainly used to secure inter-domain cases. Vandezande Expires January 20, 2016 [Page 12] Internet-Draft IPv6 IPVPN Option (IPv6VPNO) July 2015 11. Acknowledgements The author would like to thank Silvia Hagen (IPv6 Council Switzerland) and Eric Vyncke (IPv6 Council Belgium) for their initial comments on the idea of the IPv6VPNO. 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. [RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and M. Bhatia, "A Uniform Format for IPv6 Extension Headers", RFC 6564, April 2012. [RFC6407] Weis, B., Rowles, S., and T. Hardjono, "The Group Domain of Interpretation", RFC 6407, October 2011. 12.2. Informative References [IANA-IP] Internet Assigned Numbers Authority, "IP OPTION NUMBERS", . [I-D.previdi-6man-segment-routing-header] Previdi, S., Filsfils, C., Field, B., and I. Leung, "IPv6 Segment Routing Header (SRH)", draft-previdi-6man-segment- routing-header-00 (work in progress), March 2014. Authors' Addresses Olivier Vandezande (editor) Dimension Data, S.A. Alte Winterthurerstrasse 14A, 8304 Wallisellen Switzerland Email: olivier.vandezande@dimensiondata.com Vandezande Expires January 20, 2016 [Page 13]