Internet DRAFT - draft-xie-v6ops-evn6
draft-xie-v6ops-evn6
v6ops Working Group C. Xie
Internet-Draft China Telecom
Intended status: Standards Track X. Li
Expires: 12 May 2024 C. Bao
CERNET Center/Tsinghua University
M. Smith
9 November 2023
EVN6: A Framework of Mapping of Ethernet Virtual Network to IPv6
Underlay
draft-xie-v6ops-evn6-00
Abstract
This document describes the mechanism of mapping of Ethernet Virtual
Network to IPv6 Underlay for transmission. Unlike the existing
methods, this approach places the Ethernet frames to be transmitted
directly in the payload of IPv6 packets, i.e., L2 over IPv6, and uses
stateless mapping to generate IPv6 source and destination addresses
from the host's MAC addresses, Ethernet Virtual Network identifier
and site prefixes. The IPv6 packets generated in this way carry
Ethernet frames and are routed to the destination site across public
IPv6 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 https://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 12 May 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xie, et al. Expires 12 May 2024 [Page 1]
Internet-Draft EVN6 November 2023
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://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 Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overall Architecture . . . . . . . . . . . . . . . . . . . . 4
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Network Creation Procedures . . . . . . . . . . . . . . . 6
4.2. Data Transmission Procedures . . . . . . . . . . . . . . 7
4.3. Data Receiving Procedures . . . . . . . . . . . . . . . . 9
5. Link layer Broadcast . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
Ethernet Virtual Network is network model of Layer-2 built on top of
the underlay to provide connectivity between dispersed customer sites
across public network. This overlay L2 virtual network is used to
carry the Ethernet data traffic from the individual hosts in an
encapsulated format over a logical tunnel, as if they were connected
using the same LAN. Ethernet Virtual Network can serve scenarios
such as campus networks, enterprise branch interconnections, data
center networks, wide area IP bearer networks, and SD-WAN. There have
been multiple solutions, they may differ in the types of underlying
networks or encapsulation methods, besides, they usually serve
different scenarios.
Xie, et al. Expires 12 May 2024 [Page 2]
Internet-Draft EVN6 November 2023
VXLAN [RFC7348] is a network virtualization technology which has been
used mainly in data centers. VXLAN uses MAC-in-UDP encapsulation for
packets, specifically, it encapsulates original Ethernet frames into
UDP packets. It then encapsulates the UDP packets with the IP header
and Ethernet header of the physical network as outer headers,
enabling these packets to be routed across the network like ordinary
IP packets.
VPLS [RFC4762] make use of MPLS and VPN protocols to provide a
virtual LAN between multiple locations. It is basically a way to
provide Ethernet-based multi-point to multi-point communication over
MPLS networks. VPLS operates by creating a virtual ‘switch’ at the
customer’s edge (CE) and the provider’s edge (PE) of their respective
networks.
The new framework, namely EVN6, proposed in this document aims to
efficiently carry Ethernet Virtual Networks in IPv6 networks. It
provides a methodology for dynamically creating a tunnel on the IPv6
network to transparently forward Ethernet frame when communication is
required between a source and destination node in a Ethernet Virtual
Network. In this scheme, Ethernet frame to be transmitted is
directly placed in the payload field of IPv6 packet without adding
additional payload, the MAC address of the hosts that needs to
communicate, the identification of the Ethernet Virtual Network and
the IPv6 prefix of the site can be directly mapped to the IPv6
addresses. With EVN6 implementation, any two host can communicate,
regardless of the underlying IPv6 network structure and other
details. This document specifies EVN6’s overall architecture,
typical workflow and Layer-2 broadcast processing, etc.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Terminology
The following terms are defined and used in this document,
EVN6: Multi-site Ethernet Virtual Network built on IPv6 Network
E-ADPT: Ethernet Adaptor
IID: Interface Identifier(Section 2.5.1 of [RFC4291])
Xie, et al. Expires 12 May 2024 [Page 3]
Internet-Draft EVN6 November 2023
VEI: Virtual Ethernet Identification, VEI is used to identify and
distinguish different Ethernet Virtual Network instances across the
entire network, the length of VEI is 32 bits
MAC-VRF: A Virtual Routing and Forwarding table for Media Access
Control (MAC) addresses on a PE（Section 3 of [RFC8365]）, it stores
IPv6 site prefix, VEI of the Ethernet Virtual Network and other
information of each MAC address
PE: Provider Edge Router
3. Overall Architecture
As a common underlay infrastructure, IPv6 network should
simultaneously support multiple Ethernet Virtual Networks. To
distinguish different Ethernet Virtual Network instances, VEI with a
length of 32-bits is used to globally identify them, and it can
identify up to 4.29 billion Ethernet Virtual Networks.
Generally, Ethernet Virtual Network consists of multiple sites
distributed in different geographically locations, and each site is
connected to the IPv6 network through local PE at the edge of the
IPv6 network. The PE device supports Ethernet Virtual Network
services by introducing E-ADPT functional subsystem. E-ADPT directly
encapsulates the Ethernet data frames to be transmitted by the
customer site into IPv6 packets and sends them to the IPv6 network.
For the received IPv6 packets destined to one of this local sites,
E-ADPT removes their packet header and restores the original Ethernet
frames.
--------------- ---------
+---+ Pref6-1 | +----+-----+ | | | Pref6-2 +---+
| H1+---------+--+ E-ADPT | | | +---------+ H2|
+---+ Site1 | +----------+ | | | Site2 +---+
| | | | | |
| | +-------+ | | |
| | |MAC-VRF| | | |
| | +-------+ | | |
|+-------------+| ----------- | |
||IPv6 Network || / \ | |
|| Layer |--|IPv6 network |--| |
|+-------------+| \ / | |
--------------- ----------- ---------
PE1 PE2
Figure 1: EVN6 System Architecture
Xie, et al. Expires 12 May 2024 [Page 4]
Internet-Draft EVN6 November 2023
For a given Ethernet Virtual Network, E-ADPT uses the IPv6 site
prefix, i.e., Pref6 to identify different sites, so the Pref6 of
different sites within a given Ethernet Virtual Network is also
different. There are no special requirements for the type of address
block used for Pref6, as long as it belongs to the global unicast
address type and is reachable in global routing system. The Pref6
for each site can be allocated from the IPv6 address space owned by
the operator. It should be noted that the length of Pref6 can be
flexibly selected, it can be equal to or less than 64 bits. For
Ethernet Virtual Network which has multiple sites, there is a 1: N
relationship between the VEI and the site prefix of its sites.
In order to send Ethernet frames to the correct destination site
through the IPv6 network, MAC-VRF table in PE is used to store the
MAC addresses of all hosts in the Ethernet Virtual Network, the
corresponding VEI of the Ethernet Virtual Network and Pref6 of the
sites they belong to. The format of each record in MAC-VRF is shown
in figure 2, it contains MAC address, the VEI value, prefix of the
corresponding site.
+-----------------------------------------------------------+
| MAC Address | VEI | Length of Pref6 | Pref6 |
+-----------------------------------------------------------+
Pref6:Site Prefix
Figure 2: Data Structure of the Record in MAC-VRF
For E-ADPT, MAC-VRF provides a data foundation for encapsulating
Ethernet frames into corresponding IPv6 packets, the data in it
should be available before sending Ethernet frame to other sites, so
the mechanism requires the sites to pre-send host MAC/Pref6 Mapping
Advertisement to other sites. After receiving mapping relationship
data of a host sent by other PEs, the PE stores the mapping data in
the local MAC-VRF. The exchange of MAC/Pref6 can be carried out
through the control layer, such as extending EVPN[RFC7432], however,
this has been out of the scope of this document and will be discussed
in other documents. When receiving Ethernet frame data sent by the
host within the site, PE uses the destination MAC address as an index
to search for the local MAC-VRF table. If a corresponding entry is
found, PE extracts its site prefix Pref6 and VEI value, then uses the
process in section 4.2 to encapsulate the Ethernet frame in an IPv6
packet. Afterwards, the IPv6 data packet is transmitted to the IPv6
network.
Xie, et al. Expires 12 May 2024 [Page 5]
Internet-Draft EVN6 November 2023
4. Operation
In this section, the Ethernet Virtual Network in figure 3 is used as
an example to illustrate the workflow, its profile includes: the VEI
value is N1, it has three branch sites connected to PE1, PE2, and
PE3, with site prefixes Pref6-1, Pref6-2, and Pref6-3, respectively.
Hosts H1, H2, H3 and H4 are located at sites 1, site 2 and site 3,
respectively.
+-------------------+
| |
| +--+--+ +----+
+---+ +--+--+ | | Site2(Pref6-2) | |
| |Site1(Pref6-1)| | | PE2 +-------------------+ H2 |
| H1+--------------+ PE1 | | | | | Mac2
| | | | +--+--+ +----+
+---+ +--+--+ | +----+
Mac1 | IPv6 | | |
| network | ----+ H3 |
| +--+--+ | | | MAC3
| | |Site3(Pref6-3)| +----+
| | PE3 +--------------|
| | | | +----+
| +--+--+ | | |
| | ----+ H4 |
+-------------------+ | | MAC4
+----+
Figure 3: Diagram of Typical EVN6 Instance
The workflow of EVN6 is illustrated as follows:
4.1. Network Creation Procedures
Step 1: EVN6 network creation on each PE device
When creating an Ethernet Virtual Network instance on an IPv6
network, it should firstly enable the EVN6 function is in PE1, PE2,
and PE3, then configure the relevant information of the Ethernet
Virtual Network on this site, configure the Ethernet Virtual Network
identifier VEI as N1, and set the site prefix Pref6 on the interface
of the PE that the site accesses, indicating that the VEI of the
Ethernet Virtual Network to which the site belongs to is N1, and its
local site prefix is Pref6. This process can be configured manually
or using specific systems such as network management. When the EVN6
instance is running, the sites within it exchange host MAC/Pref6
Mapping through the connected PEs, as described in Section 3.
Xie, et al. Expires 12 May 2024 [Page 6]
Internet-Draft EVN6 November 2023
4.2. Data Transmission Procedures
Step 2: Host information search
Host H2 in site 2 sends an Ethernet frame with the destination being
Host H1 in site 1. Its frame header contains the MAC source address
and MAC destination address, which are the MAC addresses of hosts H2
and H1, respectively. In this case, PE2 is the source PE and PE1 is
the destination PE. After receiving the Ethernet frame in Site 2,
PE2 uses the destination MAC address as an index to search for the
local MAC-VRF table. If a corresponding entry is found, the Pref6 of
remote site (i.e. Pref6-1) and VEI information are extracted; If not
found, do not encapsulate and forward.
Step 3: Address mapping and frame encapsulation
In EVN6, each Ethernet frame needs to be associated with the VEI of
the Ethernet Virtual Network to which the frame originates. Upon
receiving the Ethernet frame, PE2 can determine its VEI value based
on local configuration. Then the VEI obtained is divided into two
sub-segments: VEI-S1 and VEI-S2, the first 16 bits are VEI-S1, and
the last 16 bits are VEI-S2. VEI-S1 and VEI-S2 will be respectively
put into IPv6 source and destination address of the new IPv6 packet
as below.
-The IPv6 source address is created by stateless mapping.
Specifically, 64-bits Pref6-2 is put into the network prefix field,
16-bits VEI-S1 and source MAC address of the Ethernet frame is put
into the field of Interface Identifier, i.e. IID, in order.
-The IPv6 destination address is created by stateless mapping too.
Specifically, 64-bits Pref6-1 is put into the network prefix field,
16-bits VEI-S2 and destination MAC address of the Ethernet frame is
put into the field of Interface Identifier, i.e. IID, in order.
The format of IPv6 source and destination addresses generated are
shown in figure 4.
Xie, et al. Expires 12 May 2024 [Page 7]
Internet-Draft EVN6 November 2023
0 64 80 127
+-------------------+--------+------------+
IPv6 Source Address | Pref6 of | VEI-S1 | Source MAC |
| Source PE | | Address |
+-------------------+--------+------------+
|<---------IID------->|
0 64 80 127
+-------------------+--------+------------+
IPv6 Destination Address | Pref6 of | VEI-S2 | Destination|
| Destination PE | | MAC Address|
+-------------------+--------+------------+
|<--------IID-------->|
Figure 4: Format of IPv6 Source and Destination Addresses
Moreover, the Ethernet frame is put into the payload of IPv6 packet
and the value of the "Next header" in the header is set to 143,
indicating that the payload of the IPv6 packet is an Ethernet frame.
+-------------------------------+
| Ethernet Frame |
+-------------------------------+
|
V
+-----------------+-------------------------------+
| IPv6 Header | Palyload(Ethernet Frame) |
+-----------------+-------------------------------+
Figure 5: Encapsulation of Ethernet Frame into IPv6 Packet
After the IPv6 packet is generated, it is sent to the IPv6 network
via the underlying IPv6 network layer.
Step 4: Packet forwarding in IPv6 network
When receiving an IPv6 packet, routers in an IPv6 network use the
destination address in the packet to look up the routing table and
forward it. Since the IPv6 destination address contains the site
prefix of the destination site, i.e. Pref6-1 in this case, which
provides the egress PE of the packet, routers can forward the IPv6
packet carrying the Ethernet frame to the destination PE, i.e. PE1 in
this case. It should be noted that this process does not require
additional functionality for non-PE routers in the network, nor does
it require extra IPv6 routing information to be added to the IPv6
network.
Xie, et al. Expires 12 May 2024 [Page 8]
Internet-Draft EVN6 November 2023
4.3. Data Receiving Procedures
Step 5: Packet de-capsulation and Ethernet frame restoration
As shown in figure 6, when receiving a IPv6 packet, the receiving PE,
i.e., PE1, checks whether the destination address prefix matches the
site prefix Pref6-1 on PE1? If yes, it extracts VEI-s1 and VEI-s2
from the IIDs of the source and destination IPv6 addresses, and
concatenates them into VEI, then check if the VEI value is equal to
N1? If yes, it then checks if the "Next header" value in the IPv6
header is 143? If yes, it then discards the IPv6 header, takes out
the Ethernet frame, and sends the Ethernet frame to H1 within Site 1
based on its destination MAC address. Otherwise, the packet is
discarded due to abnormal situation.
Xie, et al. Expires 12 May 2024 [Page 9]
Internet-Draft EVN6 November 2023
+--------------------------+
|PE1 receices a IPv6 packet|
+--------------------------+
|
V
+-----+
/Does the \
N /destination\
-------------------+ address +
| \ match /
V \ Pref6-1 /
+------------------------+ +------+
|PE1 continues forwarding| Y|
|forwarding IPv6 packet | V
+------------------------+ +-------------------------+
|PE1 extracts VEI from the|
|IIDs of IPv6 source and |
|destination addresses |
+-------------------------+
|
V
+--+
N / \
---------------------+ VEI=N1?+
| \ /
V +--+
+----------------------------+ Y|
|The packet is discarded due| |
|to abnormal situation | V
+----------------------------+ +-----+
/ The \
N / value of \
-------------------+"Next header"+
| \ is 143? /
V \ /
+----------------------------+ +-----+
|The packet is discarded due | Y|
|to abnormal situation | |
+----------------------------+ V
+------------------------------------------+
|PE1 decapsulates IPv6 packet and sends the|
| released Ethernet frame to H1 based on |
| the destination MAC address |
+------------------------------------------+
Figure 6: Process of Ethernet Frame Restoration in PE
Xie, et al. Expires 12 May 2024 [Page 10]
Internet-Draft EVN6 November 2023
5. Link layer Broadcast
Link layer broadcast is used to send data to all hosts in the Layer-2
network where they are located. The destination address of the
broadcast frame is FF-FF-FF-FF-FF-FF, and all hosts in the same
Layer-2 network will receive the broadcast frame. Link layer
broadcast is often used for IPv4 ARP and IPv6 neighbor discovery with
ICMPv6 packet of type NS (type 135) [RFC4861][RFC4861]. In Ethernet
Virtual Network scenarios, it needs to support link layer broadcast
as well.
When PE receives a broadcast frame from a local site, it analyzes the
VEI of the Ethernet Virtual Network to which the MAC belongs and uses
the VEI value as an index to retrieve all other N sites of the
Ethernet Virtual Network in MAC-VRF: Site-1, Site-2, …, Site-N.
Then, for each remote site, the following operations should be
performed recurrently by the source PE,
1) Generate new IPv6 packets with the site prefix of the remote
site using the method of section 4.2.
2) Forward the IPv6 packet to the IPv6 network.
Through the above N cycles the broadcast Ethernet frame is
encapsulated into IPv6 packets and send the data out, then all other
member remote sites will receive the Layer-2 broadcast data.
6. Security Considerations
In the EVN6 framework, PE devices located at the edge of the network
encapsulate Ethernet frames in IPv6 packets and support transmission
between different sites. When generating the outer IPv6 header, the
PE device maps information such as the IPv6 address prefix of the
site, the Mac address of the host, and the identity of the virtual
network to the IPv6 address of the outer encapsulation header, which
applies to both the source and destination addresses. In this way,
the outer IPv6 address is dynamically generated based on information
such as MAC address. For any host to host communication, even if the
source and destination hosts are in the same virtual private network,
when their source and destination address pairs are different, the
generated outer encapsulated IP address is also different. The outer
IPv6 address varies with the MAC address of the Ethernet frame, This
is different from the traditional encapsulation scheme of pre-
configuring tunnel IP addresses, as statically configured tunnel
endpoint addresses are likely to become the target of DDOS attacks.
In EVN6, tunnel encapsulation adopts dynamically generated tunnel
endpoint IPv6 addresses, which avoids the occurrence of DDOS attacks
caused by statically pre-configured tunnel addresses. From this
Xie, et al. Expires 12 May 2024 [Page 11]
Internet-Draft EVN6 November 2023
perspective, this solution improves the security of Ethernet virtual
networks.
7. IANA Considerations
There are no other special IANA considerations.
8. Acknowledgment
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
Xie, et al. Expires 12 May 2024 [Page 12]
Internet-Draft EVN6 November 2023
[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,
<https://www.rfc-editor.org/info/rfc7348>.
[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
Kreeger, L., and M. Napierala, "Problem Statement:
Overlays for Network Virtualization", RFC 7364,
DOI 10.17487/RFC7364, October 2014,
<https://www.rfc-editor.org/info/rfc7364>.
[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, <https://www.rfc-editor.org/info/rfc7365>.
[RFC8365] Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
Uttaro, J., and W. Henderickx, "A Network Virtualization
Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
DOI 10.17487/RFC8365, March 2018,
<https://www.rfc-editor.org/info/rfc8365>.
[RFC8926] Gross, J., Ed., Ganga, I., Ed., and T. Sridhar, Ed.,
"Geneve: Generic Network Virtualization Encapsulation",
RFC 8926, DOI 10.17487/RFC8926, November 2020,
<https://www.rfc-editor.org/info/rfc8926>.
Authors' Addresses
Chongfeng Xie
China Telecom
Beiqijia Town, Changping District
Beijing
102209
China
Email: xiechf@chinatelecom.cn
Xing Li
CERNET Center/Tsinghua University
Shuangqing Road No.30, Haidian District
Beijing
100084
China
Email: xing@cernet.edu.cn
Xie, et al. Expires 12 May 2024 [Page 13]
Internet-Draft EVN6 November 2023
Congxiao Bao
CERNET Center/Tsinghua University
Shuangqing Road No.30, Haidian District
Beijing
100084
China
Email: congxiao@cernet.edu.cn
Mark Smith
PO BOX 521
Heidelberg 3084
Australia
Email: markzzzsmith@gmail.com
Xie, et al. Expires 12 May 2024 [Page 14]
