| Internet Engineering Task Force | M. Smith |
| Internet-Draft | July 26, 2017 |
| Intended status: Standards Track | |
| Expires: January 27, 2018 |
Skinny IPv6 in IPv6 Tunnelling
draft-smith-skinny-ipv6-in-ipv6-tunnelling-00
This memo proposes a method of tunnelling IPv6 packets inside IPv6 packets with a reduced tunnelling overhead.
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 January 27, 2018.
Copyright (c) 2017 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.
There have been some recent proposals to insert additional information via Extension Headers (EHs) into IPv6 packets that are currently "in-flight", with in-flight meaning that they have left the source host that originated the packet and are on their way across the network towards the packet's destination host [I-D.voyer-6man-extension-header-insertion][I-D.francois-dots-ipv6-signal-option].
The fundamental drawback of inserting EHs into existing packets is that while the inserted EH is present, the IPv6 header's Source Address field's semantics are incorrect, as the device with the recorded source address is not the source of the inserted EH.
If the inserted EH causes the packet to trigger a mechanism that relies on IPv6 header Source Address semantics, such as Path MTU Discovery [RFC1981], the triggered mechanism may fail. This is because the mechanism's messages will be sent to the source address indicated, rather than the device that inserted the EH. The device inserting the EH is not identified in the packet so that messages can be sent to it if necessary.
Troubleshooting is also impacted, in particular when packets are received over long Autonomous System paths across the Internet. If an inserted EH is received and causes failures, it isn't possible to identify which AS inserted the EH from the received packet. Significant time will need to be spent contacting each AS that may have inserted the EH, to then inform them that they aren't removing the EHs they're inserting.
The alternative to inserting EHs is to add EHs using IPv6-in-IPv6 tunnelling e.g., via [RFC2423]. A new IPv6 packet is created with the new EH, with the original packet then being the new IPv6 packet's payload. As the source of the added EH is now identified in the outer IPv6 packet header, mechanisms such as PMTUD will work correctly if addition of the EH triggers the mechanism.
The drawback of conventional IPv6-in-IPv6 tunnelling is the overhead of adding another IPv6 header to the original IPv6 packet, a minimum of an additional 40 octets. It is likely that insertion of EHs into existing in-flight packets was motivated by trying to avoid this tunnelling encapsulation overhead.
From the perspective of the original and inner IPv6 packet, IPv6-in-IPv6 tunnelling is treating the outer or underlying IPv6 network as though it was a link-layer. The inner IPv6 packet is treated by the outer IPv6 packet as a link-layer opaque payload [I-D.ietf-intarea-tunnels].
A property unique to IPv6-in-IPv6 tunnelling, unlike other link-layer encapsulations of IPv6 packets, is that all fixed header fields of the outer IPv6 "link-layer" packet have the same semantics as all fixed header fields of the inner and being carried IPv6 packet.
If opaque treatment of the inner IPv6 packet by the outer IPv6 packet is compromised, matching inner and outer IPv6 packet field semantics provides the opportunity to reduce the IPv6-in-IPv6 tunnelling overhead. This can be achieved by partially or fully using a number of the outer IPv6 packet's fields as proxies for the inner packet's fields while the inner packet is in-flight over the outer IPv6 "link-layer". These inner IPv6 packet's fields are removed during link-layer encapsulation and then restored during link-layer decapsulation, using the values of the fields from the outer IPv6 packet.
This memo describes this method of IPv6-in-IPv6 tunnelling, giving it the name "Skinny IPv6-in-IPv6 Tunnelling". It preserves source address semantics for both the inner and outer packet source addresses, allowing mechanisms such as PMTUD to function, while also reducing tunnelling overhead.
In essence, this memo is a specification for a method of using IPv6 as a link-layer, adding to others in that set such as [RFC2423].
A number of the techniques and concepts have been taken from or inspired by the previous draft [I-D.smith-enhance-vne-with-ipv6].
Terminology used in this memo is from "IP Tunnels in the Internet Architecture" [I-D.ietf-intarea-tunnels].
A virtual link created using this method has the following characteristics:
Initially suggested in [I-D.smith-enhance-vne-with-ipv6], Skinny IPv6-in-IPv6 tunnelling uses individual /64s to identify individual tunnel endpoints, rather than using individual IPv6 addresses (i.e., /128s).
For Skinny IPv6-in-IPv6 unicast tunnelling to a tunnel endpoint, this allows the lower 64 bits of the outer packet's source and destination addresses (the Interface Identifier or IID parts) to carry the corresponding lower 64 bits of the inner packet's source and destination addresses. These two sets of 64 bits are removed from the inner IPv6 packet's addresses, effectively lowering the tunnelling overhead by 16 octets.
Multicast Skinny IPv6-in-IPv6 tunnel endpoints cannot be identified by /64s, as IPv6 multicast groups cannot be uniquely created at the /64 boundary. When multicast tunnelling towards a multicast group of tunnel endpoints, only the inner packet source address lower 64 bits are carried in the outer packet's source address lower 64 bits, and removed from the inner source address. The inner packet's full 128 bit destination address is carried in the Skinny IPv6-in-IPv6 tunnel header. The removal of the inner packet's source address lower 64 bits reduces the tunnelling overhead by 8 octets.
An emergent benefit of this technique of carrying inner packet IIDs in the outer packet's addresses between tunnel endpoints is that inner packet address entropy useful for load balancing is exposed to the network carrying the outer packets.
Skinny IPv6-in-IPv6 tunnel endpoints are expected to be represented as virtual interfaces in routers or hosts, and therefore will have at least a Link-Local unicast /128 address per the [RFC4291] interface address requirements, and perhaps other individual IPv6 addresses.
The use of /64s to identify tunnel endpoints means that for other non-Skinny IPv6-in-IPv6 traffic originated by or sent to the tunnel endpoint, any of the individual IPv6 addresses within the /64 are valid as local source or destination addresses for this traffic. Examples of other types of traffic originated by or sent to tunnel endpoints could be ICMPv6, TCP, or UDP.
When receiving non-Skinny IPv6-in-IPv6 packets, a tunnel endpoint is to consider all destination addresses within its assigned /64 valid and local, passing the received packets' payload to the appropriate upper layer protocol if supported, or dropping if not and possibly emitting an appropriate ICMPv6 message.
When originating non-Skinny IPv6-in-IPv6 packets from a source address within the assigned /64, a common individual address within the /64 should be used for all packets, to avoid confusing a receiver that does not expect a single device to be assigned an entire /64. Alternatively, per connection or per protocol common individual source address could be used if useful. Consistent and expected source address usage by the sender is the requirement at the receiver that needs to be met.
If the tunnel endpoint exists on a router (more specifically, is a forwarding interface), then the source address for tunnel endpoint originated packets could be the Subnet-Router anycast address [RFC4291], the endpoint's /64 plus an IID of all zeros.
Alternatively, if the tunnel endpoint exists on a host (more specifically, is a non-forwarding interface), then the source address should not be the Subnet-Router anycast address. Some other address within the /64, such as a statically configured address, or an address generated by the SLAAC procedure [RFC4862][RFC7217][RFC8064] should be used. Non-Subnet Router anycast source addresses could also be used by tunnel endpoints on routers.
In any of these cases, source and destination address selection will occur per the standard IPv6 default address selection procedure [RFC6724], unless a specific source and/or destination address is provided.
While the inner IPv6 packet is being tunnelled, the following inner packet header fields are proxied by the fields in the outer IPv6 packet header [RFC2460]:
While the inner IPv6 packet is being tunnelled, values of the following inner packet header fields [RFC2460] are carried in fields in the Skinny IPv6-in-IPv6 Extension Header. This allows them to be restored upon decapsulation, as the outer packet's header field values cannot or may not be used.
Conventional link-layers commonly do not have a hop count or hop limit field in their frames to mitigate the effects of link-layer forwarding loops. A separate mechanism or method must be used to prevent forwarding loops occurring.
When IPv6 is being used as a link-layer, the packet's Hop Limit field and processing acts as a link-layer forwarding loop mitigation mechanism.
It could be useful to have the number of hops the outer packet took included in the inner packet's recorded Hop Limit after the inner packet has traversed the tunnel. This would expose the outer IPv6 packet hops that occurred during tunnelling to the inner IPv6 packet's network. This may be useful for troubleshooting, or mitigating forwarding loops sooner.
Alternatively, the number of hops the outer IPv6 packet took could be hidden from the inner IPv6 packet's network, by restoring the Hop Limit value from the Hop Limit field value in the Skinny IPv6-in-IPv6 Extension Header. Restoring the inner packet's pre-Skinny Ipv6-in-IPv6 Hop Limit value is critical when the Neighbor Discovery protocol [RFC4861] is used across the Skinny IPv6-in-IPv6 virtual link. This is necessary as to ensure these ND packets have not come from an off-link source, their Hop Limit is set to 255 upon transmission and the recipient will only accept ND packets that arrive with a Hop Limit value of 255.
Whether to use the outer packet's Hop Limit value or to use the inner Skinny IPv6-in-IPv6 EH preserved Hop Limit value during inner IPv6 packet header reconstruction is indicated by the value of the Skinny IPv6-in-IPv6 EH preserved Hop Limit field value when it arrives at the destination tunnel endpoint. If the value is 0, the outer IPv6 packet header's current Hop Limit value is used during reconstruction, where as if the value is non-zero (e.g., 255 for ND packets), then that value is used during inner IPv6 packet reconstruction.
While the original IPv6 packet is being tunnelled, the Skinny IPv6 Extension Header carries the particles of the original inner IPv6 packet's header that are or may not be being proxied in the outer IPv6 packet header.
[RFC6564] requires justification for the creation of a new Extension Header rather than the creation of a new Destinations Options Header option.
The creation of a Skinny IPv6-in-IPv6 Extension Header is requested for the following reasons:
(ASCII art to come!)
The following steps describe the encapsulation procedure performed by the ingress Skinny IPv6-in-IPv6 tunnel endpoint upon a IPv6 packet that is being tunnelled. Note that it is a functional description, meaning that implementations may perform different and more performance oriented steps that achieve the same functional outcome.
After receiving the packet to be Skinny IPv6-in-IPv6 tunnelled from the upper IPv6 network layer:
The following steps describe the decapsulation procedure performed by the egress Skinny IPv6-in-IPv6 tunnel endpoint upon a IPv6 packet that has been tunnelled. Note that it is a functional description, meaning that implementations may perform different and more performance oriented steps that achieve the same functional outcome. (An obvious optimisation is to utilise the received packet header when reconstructing the original Skinny IPv6-in-IPv6 tunnelled packet's header, avoiding a number of copy operations among other things.)
After receiving the Skinny IPv6-in-IPv6 packet from the network:
Conventional IPv6 tunnelling described in [RFC2423] adds at least another 40 octets to the original packet being tunnelled, as that is the size of the fixed IPv6 header.
Using the method described in this memo, for packets destined to a single (unicast) tunnel endpoint, this 40 octet overhead is reduced to 24 octets, a saving of 16 octets. This is a 40 percent saving.
Using the method described in this memo, for packets destined to multiple tunnel endpoint identified by an IPv6 multicast address, this 40 octet overhead is reduced to 32 octets, a saving of 8 octets. This is a 20 percent saving.
IANA are requested to allocate an IPv6 Next Header value for use by the Skinny IPv6-in-IPv6 Extension header, per [RFC5237].
There are no security considerations specific to Skinny IPv6-in-IPv6 tunnelling. General tunnelling security considerations apply [RFC6169].
Review and comments were provided by YOUR NAME HERE!
This memo was prepared using the xml2rfc tool.
draft-smith-skinny-ipv6-in-ipv6-tunnelling-00, initial version, 2017-07-13
draft-smith-skinny-ipv6-in-ipv6-tunnelling-01, first revision, 2017-07-13
draft-smith-skinny-ipv6-in-ipv6-tunnelling-02, second revision, 2017-07-13
draft-smith-skinny-ipv6-in-ipv6-tunnelling-01, third revision, 2017-0x-xx