| Network Working Group | D. Fan |
| Internet-Draft | L. Xia |
| Intended status: Standards Track | Huawei |
| Expires: April 11, 2015 | Z. Cao |
| China Mobile | |
| N. Kim | |
| KT | |
| October 8, 2014 |
L2TP-VP: Layer Two Tunneling Protocol - Virtualization Profile
draft-fan-l2tp-vp-02
This document describes Layer Two Tunneling Protocol (L2TP)'s virtualization profile (L2TP-VP), which reuses session header of L2TP data message to securely support overlay networks for multiple tenants, and simplifies tunnel setup by disabling all kinds of L2TP control messages.
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 11, 2015.
Copyright (c) 2014 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.
Traditional data centre network uses global VLAN ID to distinguish different tenants. Usually, a tenant consumes several VLAN IDs, for example, one for web server, one for application server and one for database server. When the number of tenants increases, the number of available VLAN IDs becomes insufficient.
When services provided by cloud via Internet becomes popular, a tenant's local area network needs to securely and smoothly reach anywhere via Internet if it wants. For example, a tenant can access its office IT services hosted in cloud data centers consisting of many geographically dispersed physical data centers. So, VPN access to cloud data centers becomes very important.
Layer Two Tunneling Protocol - Version 3 (L2TPv3) [RFC3931] is a mature and practical protocol that provides secure remote access service and layer 2 over IP service, but L2TPv3 aslo uses complicated control messages to setup tunnel. At the same time, L2TPv3 uses dynamical session id that is controlled by signaling mechanism and only has local significance. Currently, L2TPv3 is complex and does not support multiple tenants though it provides basic overlay functions.
This document will describe Layer Two Tunneling Protocol (L2TP)'s virtualization profile (L2TP-VP), which reuses session header of L2TP data message to securely support overlay networks for multiple tenants, and simplifies tunnel setup by disabling all kinds of L2TP control messages. Essentially, L2TP-VP defines a subset of L2TPv3 via fine and back-compatible reuse, and then extends L2TP's usage to network virtualization. L2TP is widely deployed and used whatever for operators' network or enterprises' network, L2TP-VP brings L2TP to the entire cloud network by further covering data center network.
The motivation of this draft is to propose an altenative L3-based overlay technology, besides the existed VxLAN [RFC7348] , NVGRE [NVGRE], based on the following consideration:
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].
In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance.
L2TPv3 message format is specified in [RFC3931]. In order to support virtualization and reduce complexity from the control messages, two key fields are added into L2TP header to carry the original payload type and TNI (Tenant Network Identifier).The example of packet format for Ethernet encapsulation in L2TP-VP is shown in Figure 1.
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
Outer Ethernet Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination MAC Address | Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional Ethertype=C-Tag 802.1Q| Outer VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype 0x0800 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Outer IPv4 Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 115 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L2TP-VP Header:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M| Reserved#0 | Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tenant Network Identifier (TNI) | Reserved#1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Cookie (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inner Ethernet Header
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Destination MAC Address | Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Source MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Optional Ethertype=C-Tag 802.1Q| Inner VLAN Tag Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype of Original Payload |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Original Ethernet Payload:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Original Ethernet Payload |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 L2TP-VP Encapsulation Frame Format
The original Ethernet frame is encapsulated with L2TP-VP Header, Outer IP Header and Outer Ethernet Header.
L2TP-VP Header:
Outer IP Header: Both IPv4 and IPv6 can be used as encapsulation IP header. Figure 1 shows an example of IPv4. The source IP address is filled with IP address of L2TP-VP endpoint which encapsulates the original packet with L2TP-VP frame format. The destination IP address is unicast address obtained by lookup of address table. Also it may be a multicast address representing this packet may be used for address learning.
Outer Ethernet Header: The destination MAC address in Figure 1 may be the address of next hop device. The Optional Vlan Tag may be used to limit the area of the broadcast.
In order to reduce complexity coming from control messages, there is no separate control plane in L2TP-VP. All kinds of control messages defined in [RFC3931] are disabled. All tunnel endpoints are expected to be configured by management plane(e.g., OSS).
For the E2E link and tunnel setup of L2TP-VP overlay network, the forwarding information including tenant systems’ address, and its associated L2TP-VP endpoint address and TNI should be populated in the network. There are several options to support address learning:
Ingress L2TP-VP endpoint firstly gets the destination address from the unicast traffic, then obtains IP address of the egress endpoint and the TNI by lookup of address table, at last encapsulates the original packet in L2TP-VP frame format. The source IP address in outer IP header is filled with its own IP address and the destination IP address is filled with egress endpoint's IP address.
There are several proven methods to process BUM traffic.
One method needs the multicast support of underlay network. All BUM traffic originating from within a TNI is terminated by the L2TP-VP endpoint, then encapsulated and sent to the assigned multicast address. The binding relation of the TNI and the multicast address of underlay network can be configured by the management plane.
Another method is ingress replication. One BUM frame in a TNI can be replicated to multiple unicast frames which will be sent to all the egress L2TP-VP endpoints in the same TNI.
L2TP-VP overlay header can cause the MTU of the path to the egress tunnel endpoint to be exceeded. Here lists some solutions:
QoS of underlay network can be provided without problem due to the fact that it’s an IP network.
QoS of the overlay network may need to support the mapping of CoS marking between different network layers (e.g., Tenant Systems, Overlays, and/or Underlay) in L2TP-VP endpoints, for enabling each networking layer to independently enforce its own CoS policies.
TS’s QoS fields (e.g. IP DSCP and/or Ethernet 802.1p) and policies can be defined to indicate application level CoS requirements. L2TP-VP endpoint can use the new service CoS fields in the overlay header to indicate the proper service CoS to be applied across the overlay network. This field can be mapped from the TS’s QoS fields or other mechanism (e.g. DPI).
Because the outer header is standard IP header, the L2TP-VP endpoint SHOULD provide ECMP. Basically the L2TP-VP endpoint uses a hash of various fields of the outer Ethernet header and outer IP header, furthermore it can uses the fields of L2TP-VP header or even inner original packet. And the endpoint can select different fields for hash according to the requirement.
Management plane is needed to configure access type, TNI, QoS, Cookie, etc. In some scenarios, management plane should support to configure the forwarding information or policies for data plane and control plane , such as routing table, address table, etc. Management plane can be OSS or SDN controller.
TBD.
Like L2TPv3, L2TP-VP continues to adopt Cookie Field as an additional check to the received packet. A 32-bit random field is difficult to be cracked so that it can afford protection against brute-force, blind and insertion attacks.
When the network is open network and someone can sniff the whole traffic through the network , it will need other security measures. Traditional security mechanisms based on IP technique will provide authentication/encryption function ,such as IPSec.
TBD.
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", March 1997. |
| [RFC3931] | Lau, J., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", March 2005. |
| [RFC7348] | Mahalingam , M., "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", August 2014. |
| [NVGRE] | Sridharan , M., "NVGRE: Network Virtualization using Generic Routing Encapsulation", ID draft-sridharan-virtualization-nvgre-06, October 2014. |