Internet DRAFT - draft-smith-enhance-vne-with-ipv6
draft-smith-enhance-vne-with-ipv6
Internet Engineering Task Force M. Smith
Internet-Draft October 1, 2015
Intended status: Informational
Expires: April 3, 2016
Enhancing Virtual Network Encapsulation with IPv6
draft-smith-enhance-vne-with-ipv6-07
Abstract
A variety of network virtualization over layer 3 methods are
currently being developed and deployed. These methods treat IPv4 and
IPv6 as equivalent underlay network technologies. This memo suggests
how IPv6's additional capabilities may be used to enhance Virtual
Network encapsulation over an IPv6 Underlay Network.
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 Internet-Draft will expire on April 3, 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.
Smith Expires April 3, 2016 [Page 1]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Carrying the Virtual Network Context ID in the Flow Label
Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Using /64s to Identify NVEs . . . . . . . . . . . . . . . . . 5
5. Carrying Tenant Packet Address and Other Information in IIDs 6
5.1. Carrying Tenant Packet Addresses . . . . . . . . . . . . 6
5.2. Carrying Other Tenant Packet Information . . . . . . . . 8
5.3. Indicating IID Contents . . . . . . . . . . . . . . . . . 9
6. Permanent Virtual Network Multicast Group Identifier . . . . 9
7. Per-Virtual Network Multicast Group Addresses . . . . . . . . 9
8. Summary of Methods and Benefits . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
11. Change Log [RFC Editor please remove] . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
A variety of network virtualization over layer 3 methods are
currently being developed and deployed
[RFC7348][RFC7637][I-D.davie-stt]. Each of these methods treat both
IPv4 and IPv6 as functionally equivalent underlay network
technologies, with both providing general unicast and multicast
capabilities.
IPv6 provides a number of capabilities not available in IPv4. This
memo suggests how they may be used to enhance the encapsulation of
Virtual Network traffic when forwarded over an IPv6 Underlay Network.
This memo does not consider how Virtual Network signalling protocols
could be enhanced using IPv6. However, it may be possible to use
techniques similar to those suggested in this memo to enhance these
signalling protocols when being carried over IPv6.
2. Terminology
This memo adopts the terminology described in [RFC7365], summarised
and supplemented below.
Tenant System - a device operated by the user of the Virtual Network
service. It may be a host or a network element such as a router, and
is not aware of the Virtual Network service.
Smith Expires April 3, 2016 [Page 2]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
IPv6 Underlay Network - the IPv6 network across which Tenant Packets
are carried, encapsulated within IPv6, and possibly also within some
other network virtualization header. It is assumed by this memo that
this network supports both unicast and multicast IPv6 packet
forwarding services.
Tenant Packet - a packet originated by a Tenant System, tunnelled
within IPv6 across the IPv6 Underlay Network. The most common Tenant
Packet is likely to be an Ethernet/IEEE 802.3 frame [IEEE8023],
although other link-layer frame types, and other network layer
packets such as IPv6 or IPv4 packets could be Tenant Packets.
Virtual Network - a single conceptual network interconnecting Tenant
Systems, representing a single link or subnetwork. The IPv6 Underlay
Network provides packet forwarding service for some or all of the
Virtual Network.
Virtual Network Context Identifier (Virtual Network Context ID) - an
identifier used to specify the Virtual Network a Tenant Packet
belongs to while the packet is carried over the IPv6 Underlay
Network.
Network Virtualization Edge (NVE) - a device or function within a
device that performs IPv6 encapsulation of Tenant Packets on ingress
to the IPv6 Underlay Network and IPv6 decapsulation of Tenant Packets
on egress from the IPv6 Underlay Network. Other network
virtualization related headers may be added or removed during the
IPv6 encapsulation or decapsulation procedure.
3. Carrying the Virtual Network Context ID in the Flow Label Field
The IPv6 Flow Label field is a 20 bit field in a fixed location early
in the IPv6 header [RFC2460][RFC6437]. It is intended to be used to
identify flows between a pair of source and destination IPv6
addresses, as an alternative to identifying flows using transport
layer header port numbers [RFC0793][RFC0768][RFC4960][RFC4340], which
may be located deeper within the IPv6 packet, perhaps following a
number of other IPv6 extension headers, or hidden by IPsec [RFC4301].
One of the expected and encouraged uses of the Flow Label field is as
an input into link or path selection when using stateless load
balancing of traffic across multiple links [RFC6436][RFC6438], using
methods such as Equal Cost Multi-Path (ECMP) [RFC2991] or Link
Aggregation Groups (LAGs) [IEEE8021AX].
The Flow Label field could be used to carry a whole or partial copy
of the Virtual Network Context ID, providing it as an input into a
Smith Expires April 3, 2016 [Page 3]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
stateless load balancing method, operating within the IPv6 Underlay
Network.
Alternatively, the Flow Label field could carry the Virtual Network
Context ID itself, providing support for up to 1 Million Virtual
Networks. This would reduce the encapsulation overhead of tunnelling
over IPv6.
A drawback of using the Flow Label to carry the Virtual Network
Context ID is that it is a 'best effort' field, meaning that it may
be changed as it transits the network without any protection by an
end-to-end checksum, including when other fields in the IPv6 header
are protected by the IPsec Authentication Header [RFC4302]. A change
of the Flow Label field value when used to carry the Virtual Network
Context ID would mean the Tenant Packet would either be delivered to
the incorrect Virtual Network or would be dropped because the
specified Virtual Network does not exist. Incorrect Virtual Network
delivery would likely be unacceptable to the Virtual Network's user
for security reasons.
This could be resolved by protecting the integrity of the Flow Label
field value using a checksum carried in some other Virtual Network
related header, and validating that checksum when the IPv6 tunnelling
header is removed, before delivery to the corresponding Virtual
Network.
[RFC6437] advises that Flow Label values should be uniformly
distributed. If the Flow Label field carries the Virtual Network
Context IDs, then ideally they should also be uniformly distributed.
This would be easier to achieve if Virtual Network Context IDs are
generated algorithmically, rather than chosen by a human operator.
Note that some of the load distribution mechanisms described in
[RFC7424] may reduce the importance of uniform distribution of Flow
Label values when used in a closed network, such as the IPv6 Underlay
Network.
[RFC6437] also advises that forwarding nodes must not depend upon
uniform distribution of Flow Label values. When used as a hash key
for load distribution, the Flow Label bits must be combined with
other sources within the packet. If a 3-tuple of Flow Label, Source
and Destination Addresses fields are used as hash keys, the method of
carrying Tenant Packet addresses in the IPv6 Underlay Network packet
source and destination address IIDs, or source address IIDs,
described later in Section 5, should result in a constant hash value
across a flow of IPv6 Underlay Network packets between a pair of
Tenant Systems, or one source Tenant System and a single broadcast or
multicast destination, within the same Virtual Network.
Smith Expires April 3, 2016 [Page 4]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
A Flow Label value of zero has been deemed to mean that the Flow
Label value has not been set [RFC6437], and can therefore be changed
as the the IPv6 packet traverses the network. This would preclude
the use of the Flow Label field to carry a Virtual Network Context ID
value of zero, as if it was changed by an intermediary device it
would fail the Flow Label integrity check using checksum information
carried by some other Virtual Network header.
Carrying Virtual Network Context ID information in the Flow Label
field is also likely to assist with IPv6 Underlay Network
troubleshooting and facilitate traffic analysis using IPv6 tools that
can analyse the Flow Label field.
4. Using /64s to Identify NVEs
Networks operating IPv6 have large numbers of /64 subnets; at a
minimum, even the smallest end site is expected to be assigned a /56
or 256 /64s [RFC6177], where as a single ULA /48 prefix [RFC4193]
provides more than 65 000 /64 subnets.
Instead of identifying an NVE in the IPv6 Underlay Network using a
single unicast IPv6 address, an NVE could be identified using a /64
prefix. An NVE would then announce its /64 prefix into the IPv6
Underlay Network's routing domain, using an IGP or EGP such as OSPFv3
[RFC5340] or BGP [RFC4271][I-D.ietf-rtgwg-bgp-routing-large-dc].
This would provide reachability and availability information to other
NVEs, and support multihoming and load sharing when an NVE has
multiple attachments to the IPv6 Underlay Network. Automated
discovery of NVEs could be facilitated by attaching a widely known
identifier to the NVE /64 route announcements, using mechanisms such
as OSPFv3's External Route Tag or a BGP community [RFC1997][RFC5701].
The NVE identifying /64 would be separate from the IPv6 prefixes and
addresses used to logically or physically attach the NVE to the IPv6
Underlay Network. Notionally, the NVE /64 could be considered both
internal to the NVE, and at least one hop away from the NVE's IPv6
Underlay Network attachment prefixes. Configuration and monitoring
of the Network Virtualization encapsulation/decapsulation function
could be exposed to the NVE's operator using a logical or virtual
interface (commonly known as a "tunnel" interface) for the NVE's /64
(with an NVE that has multiple Network Virtualization /64s having
multiple corresponding logical or virtual interfaces). This could
include exposing Virtual Network encapsulation/decapsulation
performance and other metrics via SNMP variables, including interface
variables [RFC1213][RFC1229].
As the NVEs are now identified by /64 prefixes, for unicast Tenant
Packets, the source and destination IPv6 addresses used for the IPv6
Smith Expires April 3, 2016 [Page 5]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
encapsulation can be the Subnet-Router anycast address, the result of
the NVE /64 prefix and an IID portion value of all zeros [RFC4291].
For multicast traffic, the source used can be the Subnet-Router
anycast address, while the destination address used is an IPv6
multicast address used to reach the appropriate NVEs.
[RFC7421] reports that some IPv6 routers provide optimal forwarding
performance for /64 or shorter prefixes. Assigning /64s to NVEs
would gain the best performance from this class of IPv6 routers when
carrying traffic across the IPv6 Underlay Network.
5. Carrying Tenant Packet Address and Other Information in IIDs
If /64s are used to identify NVEs, then the IPv6 Underlay Network's
packets' 8 octet IID portions in their source and possibly
destination addresses can be used to carry Tenant Packet address
information and possibly other information. This is instead of
setting the IID portions to the Subnet-Router anycast address IID
suggested in Section 4.
Carrying Tenant Packet addresses and other fields in the address IID
portions of the IPv6 Underlay Network header should improve load
balancing, and would expose this information to IPv6 traffic analysis
tools such as IPFIX [RFC7011][RFC7015], providing the IPv6 Underlay
Network operator with information about individual Tenant Systems and
the traffic volumes between them.
5.1. Carrying Tenant Packet Addresses
During encapsulation in IPv6, upon ingress to the IPv6 Underlay
Network, Tenant Packet addresses could be copied into the IID
portions of the IPv6 address fields. For unicast Tenant Packets, the
source and destination addresses are copied into the corresponding
IPv6 Underlay Packet address IID portions. For multicast Tenant
Packets, the source address is copied into the IPv6 Underlay Packet
source address IID portion, while the destination address is an
appropriate IPv6 multicast address.
As the IPv6 source and destination address fields can be used as
inputs for stateless load balancing across the IPv6 Underlay Network,
the entropy in the IID portions of the address, as a result of being
Tenant Packet address values, should improve the effectiveness of
load balancing, while preserving in-order delivery of Tenant Packets
between pairs of Tenant Systems. This will also assist with flow
recognition when mechanisms described in [RFC7424] are used in the
IPv6 Underlay Network.
Smith Expires April 3, 2016 [Page 6]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
For most types of Tenant Packet addresses, the 8 octet IPv6 IID field
will be large enough to hold a complete copy of the Tenant Packet
addresses. To reduce tunnelling overhead, these address fields could
be removed from the Tenant Packet while being tunnelled, and restored
when the IPv6 packet arrives at the destination NVE, as part of the
process of IPv6 decapsulation.
Note that the IPv6 header is not protected by an end-to-end checksum
[RFC2460], so removing the Tenant Packet address fields during IPv6
encapsulation should only be performed when the removed fields are
protected by a suitable network virtualization header checksum or a
Tenant Packet checksum.
In the case of a network virtualization header checksum covering the
Tenant Packet addresses when carried in the IPv6 address IID
portions, the validation of this checksum would occur when the Tenant
Packet is reconstructed by the destination NVE.
Alternatively, if the Tenant Packet checksum originally covered the
Tenant Packet addresses, validation could be left to the Tenant
Packet destination, increasing NVE performance at the cost of
possibly forwarding corrupted Tenant Packets after IPv6
decapsulation. As Tenant Packet corruption is likely to be rare when
forwarded across the IPv6 Underlay Network, it is recommended to
leave this validation to the final Tenant Packet destination. It
would be useful for a network operator to be able to switch on
validation at an NVE temporarily for troubleshooting purposes.
If Tenant Packet addresses are larger than the IPv6 address IID
portions, then the portion of the Tenant Packet addresses that would
provide the best input into load balancing should be copied. For
example, if Tenant Packets are raw IPv6 packets (i.e., without a
link-layer header), then the Tenant Packet address 64 bit IID
portions should be copied into the IPv6 Underlay Network packet
address IID fields, and then perhaps removed from the Tenant Packets.
Tenant Packets carrying IID portions generated using either [RFC7217]
or [RFC4941] will provide the best IID values, as those IID values
are the result of a pseudo-random or hash function.
When the IPv6 IID portions are used to carry Tenant Packet values,
the receiving NVE would not consider any of the received IID values
to have any significance. In other words, none of the IID values
described in [RFC5453] are to be considered reserved. This is
consistent with [RFC7136], which states that only a local context can
give the IID bits semantic meaning.
Smith Expires April 3, 2016 [Page 7]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
5.2. Carrying Other Tenant Packet Information
If the Tenant Packet addresses are smaller than the IPv6 address IID
portions, other Tenant Packet field values could be copied into the
remaining parts of the IPv6 address IIDs portion, and also possibly
be removed from the Tenant Packet, which will further reduce
tunnelling overhead, and may further increase stateless load-
balancing effectiveness.
For example, for Ethernet/IEEE 802.3 Tenant Packets, both the 6 octet
Ethernet/IEEE 802.3 source address and subsequent 2 octet type/length
field values could be copied into the IPv6 source address 8 octet IID
portion in a single operation, and then removed from the original
Tenant Packet. This should be beneficial to stateless load-balancing
when the type/length field is carrying a variety of payload type
values.
If the Ethernet/IEEE 802.3 type/length field is carrying length
values when copied into the IPv6 source address IID portion, out of
original sending order delivery of Tenant Packets could be the
result, caused by the stateless load-balancing method being used by
the IPv6 Underlay network. This may negatively impact the
performance or possibly in the worst case cause failure of the
corresponding upper layer protocol.
If lower performance or possible upper layer protocol failure is
unacceptable, only the Ethernet/IEEE 802.3 source address could be
copied into the the IPv6 source address IID portion for these
'length' Ethernet/IEEE 802.3 frames. To distinguish between these
Tenant Packets and those where both the Ethernet/IEEE 802.3 source
address and type field values are copied into the IPv6 source address
IID field, either a different Virtual Network Context ID could be
used, or some other indicator field in an additional Virtual Network
header could indicate the different 'length' value encapsulation. If
a different Virtual Network Context ID is used for these 'length'
Tenant Packets, at the decapsulating NVE, these frames would be
merged back into the single Virtual Network.
Upon NVE encapsulation, rather than perform a less than or equal to
1500 comparison operation on the type/length field to identify
'length' Ethernet/IEEE 802.3 frames [IEEE8023], a simpler and likely
faster implementation in hardware could perform an exact match
comparison on the type/length field value against a set of common
protocol types, such as IPv4 [RFC0894], ARP [RFC0826], IPv6 [RFC2464]
and IEEE 802.1Q [IEEE8021Q]. For those frames that match, both the
Ethernet/IEEE 802.3 source address and type/length field values are
copied into the IPv6 Underlay Network packet source address IID
portion, where as for all other frames, just the Ethernet/IEEE 802.3
Smith Expires April 3, 2016 [Page 8]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
source address value would be copied into the IPv6 Underlay Network
packet source address IID portion.
5.3. Indicating IID Contents
This optimisation of carrying Tenant Packet field values in the IPv6
encapsulating header's address field IIDs portions and removing them
from the Tenant Packet could be indicated to the destination NVE
implicitly by the Virtual Network Context ID, or via some other
header carried in the IPv6 packet.
6. Permanent Virtual Network Multicast Group Identifier
To simplify and automate configuration, a permanent IPv6 multicast
group identifier could be assigned by IANA, in accordance with the
allocation guidelines specified in [RFC3307], to be used for
encapsulation of multicast Tenant Packets in IPv6 multicast packets.
This group ID would be used to form Interface-Local, Link-Local, and
Site-Local scope multicast addresses. Each NVE would then subscribe
to these scoped multicast addresses for the permanent group ID. The
range of different scopes will allow an origin NVE to constrain the
forwarding domain of IPv6 multicast packets holding multicast Tenant
Packets if necessary or useful.
Other multicast scopes that may be useful for NVE encapsulation
operation might be the Realm-Local, Admin-Local, and Organization-
Local scopes [RFC7346], also used with the IANA reserved group ID.
7. Per-Virtual Network Multicast Group Addresses
Using a single well known multicast group to flood IPv6 encapsulated
multicast or broadcast Tenant Packets to all NVEs for all Virtual
Networks may eventually impact network performance, due to the volume
of multicast traffic being sent to NVEs at which the corresponding
Virtual Network is not present.
Reducing network load may be achieved by using multiple multicast
groups to distribute IPv6 encapsulated multicast or broadcast Tenant
Packets to NVEs where the Virtual Network is present. Optionally, an
NVE might only become and remain a member of the Virtual Network
specific multicast group when it is aware that there is at least one
Tenant System present in the local Virtual Network segment.
[RFC3306] describes how to create multicast addresses using a unicast
IPv6 prefix, between 0 and 64 bits in length. For each unicast IPv6
derived multicast prefix, 32 bits are available for the Group ID.
These group IDs are created using the guidelines specified in
Smith Expires April 3, 2016 [Page 9]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
[RFC3307]. For dynamically created multicast addresses, [RFC3307]
restricts the group ID range to (in IPv6 address form) ::8000:0000 to
::ffff:ffff, a range of 31 bits or approximately 2 billion unique
groups. The leading high order bit in the Group ID corresponds to
the 'T' bit value in the multicast address flag, which indicates a
Temporary multicast address. This ensures that when the multicast
group is mapped to a multicast link-layer address, by copying the
lower 32 bits of the multicast address to the link-layer multicast
address range (e.g., 33-33-XX-XX-XX-XX for Ethernet/IEEE 802.3
[RFC2464]), the link-layer multicast address does not collide with
Permanent IPv6 multicast addresses at the link-layer.
These 31 bits of dynamic group IDs, available for a unicast prefix,
could be used to form a unique multicast group address per Virtual
Network, using the Virtual Network Context ID, by combining it with
an IPv6 prefix used by all NVEs. The NVEs would be informed of the
common IPv6 prefix using manual configuration or a signalling
protocol.
The common IPv6 prefix used to form these addresses does not have to
be related to any of the /64 prefixes being used by the NVEs.
However it is recommended to relate them intuitively, by using a
shorter aggregate prefix that covers the set of identifying /64
prefixes being used by the NVEs attached to the same IPv6 Underlay
Network. This would simplify configuration, reduce errors and
simplify troubleshooting.
With larger numbers of Virtual Networks, one multicast group per
Virtual Network may exceed the IPv6 Underlay Network's capacity to
reliably track multicast group membership for all of the present
multicast groups. NVEs would participate directly in the IPv6
Underlay Network's multicast routing protocol [RFC5110], limiting the
number of multicast groups to the IPv6 Underlay Network's multicast
routing protocol implementations' maximum capacity.
The preferred option in this situation would be to create another
IPv6 Underlay Network, and to move some, and ideally half of the
Virtual Networks to the new IPv6 Underlay Network. This would
preserve the efficiency of one multicast group per Virtual Network,
as well as increasing encapsulation network unicast and multicast
traffic capacity.
An alternative, although less efficient option would be to map
multiple Virtual Networks onto each multicast group, on a many-to-one
basis. A simple scheme would be to map the Virtual Networks equally
onto the available multicast groups. This may be easier to implement
if the Virtual Network Context IDs have been uniformly distributed as
suggested previously in Section 3. More advanced mapping schemes
Smith Expires April 3, 2016 [Page 10]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
might take into consideration other Virtual Network attributes such
as the number of Tenant Systems attached to the individual Virtual
Networks, the maximum allowed number of Tenant Systems in each
Virtual Network or the number of NVEs where Tenant System network
segments for each Virtual Network are present, with a goal of trying
to equally balance multicast traffic across the available multicast
groups.
8. Summary of Methods and Benefits
o Carrying a full or partial copy of the Virtual Network Context ID
value in the Flow Label field would expose it to the IPv6 Underlay
Network load balancing mechanisms and troubleshooting tools.
o Carrying the Virtual Network Context ID in the Flow Label field
would reduce tunnelling overhead.
o Using /64s to identify NVEs within the IPv6 Underlay Network would
support the use of more conventional IPv6 routing methods and
protocols, may provide more efficient forwarding, and allows for
other uses of the IID portions of the IPv6 addresses.
o Carrying full or partial copies of Tenant Packet addresses and
other information in the IID portions of the IPv6 address fields
would expose those values to the IPv6 Underlay Network load
balancing mechanisms and other IPv6 troubleshooting and analysis
tools, such as IPFIX.
o Carrying Tenant Packet addresses and other field information in
the IID portions of the IPv6 address fields, and then removing
those fields from the original Tenant Packets while being carried
across the IPv6 Underlay Network, would reduce tunnelling
overhead.
o Using an IANA assigned permanent multicast group ID, used by all
NVEs, would both simplify and allow automated configuration of NVE
multicast.
o Per-Virtual Network multicast groups would reduce the volume of
multicast or broadcast Tenant Packets being sent to NVEs at which
the destination Virtual Network does not exist.
o When the IPv6 Underlay Network's multicast group capacity is
exceeded, mapping multiple Virtual Networks to multiple multicast
groups, on a many-to-one basis, would be more efficient than using
a single multicast group for all Virtual Networks.
Smith Expires April 3, 2016 [Page 11]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
o Use of the Interface-Local, Link-Local, and Site-Local scopes for
the various Virtual Network multicast addresses would allow origin
NVEs to better control the forwarding domain of multicast IPv6
Underlay Network traffic they send.
9. Security Considerations
Within a trusted IPv6 Underlay Network, copying or carrying Virtual
Network or Tenant Packet attributes in IPv6 header fields will not
significantly further expose them to untrusted parties, as they are
likely to already exist in clear text within the IPv6 packet payload.
However, if the IPv6 Underlay Network is to span portions of the
Internet, the IPv6 packets should be carried within IPsec [RFC4301]
or some other secure tunnelling protocol that provides
confidentiality, integrity and authenticity, to mitigate pervasive
monitoring [RFC7258] and other security concerns.
In particular, when using IPsec, tunnel mode should be used with at
least the IPsec Encapsulating Security Payload protocol [RFC4303], as
the IPv6 Underlay Packets or their Tenant System packets would
facilitate analysis of Tenant System traffic, by exposing detailed
information about the numbers and identities of the Virtual Networks,
possibly globally unique details of individual Tenant Systems, and
volumes of traffic between distinct Tenant Systems.
To reduce the possibility of accidental forwarding of IPv6 Underlay
Network traffic onto the Internet, it is recommended that the IPv6
Underlay Network is numbered using a single ULA /48, with egress
packet filters dropping ULA source or destination packets at the
network's Internet boundary, as described in [RFC4193]. Additional
egress packet filters at the edge of the IPv6 Underlay Network, for
the ULA address space in use within the IPv6 Underlay Network, would
provide further protection against accidental forwarding of IPv6
Underlay Network traffic onto the Internet.
10. Acknowledgements
Thanks to (in alphabetical order) Fred Baker, Brian Carpenter and Tom
Herbert for their encouragement, review and comments.
This memo was prepared using the xml2rfc tool.
11. Change Log [RFC Editor please remove]
draft-smith-enhance-vne-with-ipv6-00, initial version, 2014-06-02
draft-smith-enhance-vne-with-ipv6-01, 2014-07-22
Smith Expires April 3, 2016 [Page 12]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
o issues with 'length' Ethernet Tenant Packets
o uniform distribution of flow label values/virtual network context
IDs
o more descriptive and clarifying text
draft-smith-enhance-vne-with-ipv6-02, 2014-07-28
o methods and benefits summary section
draft-smith-enhance-vne-with-ipv6-03, 2014-07-29
o fix some references
draft-smith-enhance-vne-with-ipv6-04, 2014-08-16
o some clarifications around per-NVE /64s
draft-smith-enhance-vne-with-ipv6-05, 2014-08-26
o Remove suggestion of sharing a single /64 between multiple NVEs,
as for it to be reliable, all virtual networks would need to be
available at the shared /64 NVEs all of the time, which can't be
guaranteed
draft-smith-enhance-vne-with-ipv6-06, 2015-06-16
o virtual/tunnel interface to represent NVE /64
o IDs/RFC references updates
draft-smith-enhance-vne-with-ipv6-07, 2015-10-02
o completely remove per-NVE multicast groups section - should have
done for -06 revision
12. References
12.1. Normative References
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
DOI 10.17487/RFC0768, August 1980,
<http://www.rfc-editor.org/info/rfc768>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
Smith Expires April 3, 2016 [Page 13]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or
Converting Network Protocol Addresses to 48.bit Ethernet
Address for Transmission on Ethernet Hardware", STD 37,
RFC 826, DOI 10.17487/RFC0826, November 1982,
<http://www.rfc-editor.org/info/rfc826>.
[RFC0894] Hornig, C., "A Standard for the Transmission of IP
Datagrams over Ethernet Networks", STD 41, RFC 894,
DOI 10.17487/RFC0894, April 1984,
<http://www.rfc-editor.org/info/rfc894>.
[RFC6177] Narten, T., Huston, G., and L. Roberts, "IPv6 Address
Assignment to End Sites", BCP 157, RFC 6177,
DOI 10.17487/RFC6177, March 2011,
<http://www.rfc-editor.org/info/rfc6177>.
[RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken,
"Specification of the IP Flow Information Export (IPFIX)
Protocol for the Exchange of Flow Information", STD 77,
RFC 7011, DOI 10.17487/RFC7011, September 2013,
<http://www.rfc-editor.org/info/rfc7011>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <http://www.rfc-editor.org/info/rfc7258>.
12.2. Informative References
[I-D.davie-stt]
Davie, B. and J. Gross, "A Stateless Transport Tunneling
Protocol for Network Virtualization (STT)", draft-davie-
stt-06 (work in progress), April 2014.
[I-D.ietf-rtgwg-bgp-routing-large-dc]
Lapukhov, P., Premji, A., and J. Mitchell, "Use of BGP for
routing in large-scale data centers", draft-ietf-rtgwg-
bgp-routing-large-dc-07 (work in progress), August 2015.
[IEEE8021AX]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Link Aggregation", IEEE Std
802.1AX-2012 (R2012), 2008.
[IEEE8021Q]
IEEE, "IEEE Standard for Local and metropolitan area
networks - Media Access Control (MAC) Bridges and Virtual
Bridge Local Area Networks", IEEE Std 802.1Q-2011 (R2011),
2011.
Smith Expires April 3, 2016 [Page 14]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
[IEEE8023]
IEEE, "IEEE Standard for Ethernet", IEEE Std
802.3-2012 (R2012), 2012.
[RFC1213] McCloghrie, K. and M. Rose, "Management Information Base
for Network Management of TCP/IP-based internets: MIB-II",
STD 17, RFC 1213, DOI 10.17487/RFC1213, March 1991,
<http://www.rfc-editor.org/info/rfc1213>.
[RFC1229] McCloghrie, K., "Extensions to the generic-interface MIB",
RFC 1229, DOI 10.17487/RFC1229, May 1991,
<http://www.rfc-editor.org/info/rfc1229>.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998,
<http://www.rfc-editor.org/info/rfc2464>.
[RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
Multicast Next-Hop Selection", RFC 2991,
DOI 10.17487/RFC2991, November 2000,
<http://www.rfc-editor.org/info/rfc2991>.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306,
August 2002, <http://www.rfc-editor.org/info/rfc3306>.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002,
<http://www.rfc-editor.org/info/rfc3307>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>.
[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,
<http://www.rfc-editor.org/info/rfc4271>.
Smith Expires April 3, 2016 [Page 15]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<http://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<http://www.rfc-editor.org/info/rfc4303>.
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram
Congestion Control Protocol (DCCP)", RFC 4340,
DOI 10.17487/RFC4340, March 2006,
<http://www.rfc-editor.org/info/rfc4340>.
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy
Extensions for Stateless Address Autoconfiguration in
IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007,
<http://www.rfc-editor.org/info/rfc4941>.
[RFC4960] Stewart, R., Ed., "Stream Control Transmission Protocol",
RFC 4960, DOI 10.17487/RFC4960, September 2007,
<http://www.rfc-editor.org/info/rfc4960>.
[RFC5110] Savola, P., "Overview of the Internet Multicast Routing
Architecture", RFC 5110, DOI 10.17487/RFC5110, January
2008, <http://www.rfc-editor.org/info/rfc5110>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<http://www.rfc-editor.org/info/rfc5340>.
[RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers",
RFC 5453, DOI 10.17487/RFC5453, February 2009,
<http://www.rfc-editor.org/info/rfc5453>.
[RFC5701] Rekhter, Y., "IPv6 Address Specific BGP Extended Community
Attribute", RFC 5701, DOI 10.17487/RFC5701, November 2009,
<http://www.rfc-editor.org/info/rfc5701>.
Smith Expires April 3, 2016 [Page 16]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
[RFC6436] Amante, S., Carpenter, B., and S. Jiang, "Rationale for
Update to the IPv6 Flow Label Specification", RFC 6436,
DOI 10.17487/RFC6436, November 2011,
<http://www.rfc-editor.org/info/rfc6436>.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437,
DOI 10.17487/RFC6437, November 2011,
<http://www.rfc-editor.org/info/rfc6437>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
for Equal Cost Multipath Routing and Link Aggregation in
Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
<http://www.rfc-editor.org/info/rfc6438>.
[RFC7015] Trammell, B., Wagner, A., and B. Claise, "Flow Aggregation
for the IP Flow Information Export (IPFIX) Protocol",
RFC 7015, DOI 10.17487/RFC7015, September 2013,
<http://www.rfc-editor.org/info/rfc7015>.
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6
Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136,
February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7217] Gont, F., "A Method for Generating Semantically Opaque
Interface Identifiers with IPv6 Stateless Address
Autoconfiguration (SLAAC)", RFC 7217,
DOI 10.17487/RFC7217, April 2014,
<http://www.rfc-editor.org/info/rfc7217>.
[RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346,
DOI 10.17487/RFC7346, August 2014,
<http://www.rfc-editor.org/info/rfc7346>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
eXtensible Local Area Network (VXLAN): A Framework for
Overlaying Virtualized Layer 2 Networks over Layer 3
Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
<http://www.rfc-editor.org/info/rfc7348>.
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network
Virtualization", RFC 7365, DOI 10.17487/RFC7365, October
2014, <http://www.rfc-editor.org/info/rfc7365>.
Smith Expires April 3, 2016 [Page 17]
Internet-Draft Enhancing VN Encapsulation with IPv6 October 2015
[RFC7421] Carpenter, B., Ed., Chown, T., Gont, F., Jiang, S.,
Petrescu, A., and A. Yourtchenko, "Analysis of the 64-bit
Boundary in IPv6 Addressing", RFC 7421,
DOI 10.17487/RFC7421, January 2015,
<http://www.rfc-editor.org/info/rfc7421>.
[RFC7424] Krishnan, R., Yong, L., Ghanwani, A., So, N., and B.
Khasnabish, "Mechanisms for Optimizing Link Aggregation
Group (LAG) and Equal-Cost Multipath (ECMP) Component Link
Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424,
January 2015, <http://www.rfc-editor.org/info/rfc7424>.
[RFC7637] Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
Virtualization Using Generic Routing Encapsulation",
RFC 7637, DOI 10.17487/RFC7637, September 2015,
<http://www.rfc-editor.org/info/rfc7637>.
Author's Address
Mark Smith
PO BOX 521
HEIDELBERG, VIC 3084
AU
Email: markzzzsmith+id@gmail.com
Smith Expires April 3, 2016 [Page 18]
