Internet DRAFT - draft-vandezande-6man-ipv6-ipvpn-option
draft-vandezande-6man-ipv6-ipvpn-option
Network Working Group O. Vandezande, Ed.
Internet-Draft Dimension Data, s.a.
Intended status: Standards Track October 05, 2015
Expires: April 07, 2016
IPv6 IPVPN Option (IPv6VPNO)
draft-vandezande-6man-ipv6-ipvpn-option-02
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).
This Internet-Draft will expire on April 07, 2016.
Vandezande Expires April 07, 2016 [Page 1]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
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.
Table of Contents
1. Structure of this document . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Method Overview . . . . . . . . . . . . . . . . . . . . . 4
3. IPv6 IPVPN Identification . . . . . . . . . . . . . . . . . . 4
4. IPv6 IPVPN Option Header (IPv6VPNO) . . . . . . . . . . . . . 4
5. IPv6VPNO and RFC2460 behavior . . . . . . . . . . . . . . . . 6
6. IPv6VPNO Operations . . . . . . . . . . . . . . . . . . . . . 7
6.1. The ingress IPv6 IPVPN capable node . . . . . . . . . . . 7
6.2. The transit IPv6 nodes . . . . . . . . . . . . . . . . . . 8
6.3. The egress IPv6 IPVPN capable node . . . . . . . . . . . . 8
6.4. The original destination node . . . . . . . . . . . . . . 9
7. IPv6VPNO Optimization . . . . . . . . . . . . . . . . . . . . 9
8. IPv6VPNO and tunneling . . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Vandezande Expires April 07, 2016 [Page 2]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 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-08) 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
more scalability in their IPVPN network infrastructure.
Vandezande Expires April 07, 2016 [Page 3]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
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 (or more) IGP instance(s) accros their domains (e.g. 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, or 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.
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
Vandezande Expires April 07, 2016 [Page 4]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
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.
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.
Vandezande Expires April 07, 2016 [Page 5]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
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.
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.
Vandezande Expires April 07, 2016 [Page 6]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
- 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.
- 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.
Vandezande Expires April 07, 2016 [Page 7]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
- 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:
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.
Vandezande Expires April 07, 2016 [Page 8]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
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 be copied
to the outer header.
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.
Vandezande Expires April 07, 2016 [Page 9]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
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
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
Vandezande Expires April 07, 2016 [Page 10]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
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-08. 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.
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.
Vandezande Expires April 07, 2016 [Page 11]
Internet-Draft IPv6 IPVPN Option (IPv6VPNO) October 2015
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",
<http://www.iana.org/assignments/ip-parameters>.
[I-D.previdi-6man-segment-routing-header]
Previdi S., Filsfils C., Field B., Leung I., Linkova J.,
Aries E., Kosigi T., Vyncke E. and Lebrun D., "IPv6
Segment Routing Header (SRH)", draft-previdi-6man-segment-
routing-header-08 (work in progress), October 2015.
Authors' Addresses
Olivier Vandezande (editor)
Dimension Data, S.A.
Alte Winterthurerstrasse 14A,
8304 Wallisellen
Switzerland
Email: olivier.vandezande@dimensiondata.com
Vandezande Expires April 07, 2016 [Page 12]
