rfc7348 - Virtual eXtensible Local Area Network (VXLAN)：一种在Layer 3网络上叠加虚拟化Layer 2网络的框架

VXLAN (Virtual eXtensible Local Area Network):一种将虚拟的二层网络覆盖在三层网络上的框架

摘要

本文描述了Virtual eXtensible Local Area Network (VXLAN)。VXLAN 用于满足虚拟化数据中心中支持多个租户的覆盖网络的需求。该方案及相关协议可用于云服务提供商和企业数据中心的网络。本文记录了已部署的VXLAN协议，以供互联网社区参考。

本备忘录现状

本文档不是互联网标准跟踪规范;它是为了提供信息而出版的。

这是对 RFC 系列的一项贡献，与任何其他 RFC 流无关。RFC 编辑自行决定是否出版本文档，并不对其在实施或部署方面的价值发表任何声明。RFC 编辑批准出版的文档不适用于任何互联网标准的级别，详见 RFC 5741 第 2 节。

可以在http://www.rfc-editor.org/info/rfc7348获取有关该文档的当前状态、勘误以及如何提供反馈的信息。

1. 简介

服务器虚拟化对物理网络基础设施提出了更高的要求。现在，一个物理服务器上有多个虚拟机（VM），每个虚拟机都有自己的媒体访问控制（MAC）地址。这要求交换式以太网络中的MAC地址表更大，以便处理可能连接和通信数十万个虚拟机。

如果数据中心中的虚拟机按照它们的虚拟局域网（VLAN：Virtual LAN ）进行分组，则可能需要数千个VLAN来根据虚拟机所属的特定组来对流量进行分区。在这种情况下，当前的 VLAN 限制 4094 是不够的。

数据中心通常需要托管多个租户，每个租户都有自己的隔离网络域。由于使用专用基础架构实现这一点并不经济，因此网络管理员选择在共享网络上实现隔离。在这种情况下，一个常见的问题是，每个租户可能会独立地分配MAC地址和VLAN ID，从而导致这些地址和 VLAN ID 在物理网络上可能重复。

使用第2层物理基础设施的虚拟化环境的一个重要要求是，需要让第2层网络在整个数据中心甚至在数据中心之间可进行扩展，以实现高效的计算、网络和存储资源分配。在此类网络中，使用生成树协议 （STP：Spanning Tree Protocol） 等传统方法实现无环路拓扑可能会导致大量链路被禁用。

最后一种情况是网络运营商倾向于使用IP来进行物理基础设施的互连（例如，例如，通过等价多路径（ECMP：Equal-Cost Multipath）实现多路径可扩展性，从而避免禁用链路）。即使在此类环境中，也需要保留第 2 层模型以进行 VM 间通信。

上述场景导致了对覆盖网络（overlay network）的需求。这个覆盖层用于将来自各个vm的MAC流量以封装格式通过逻辑“隧道（tunnel）”传输过来。

本文详细介绍了一个被称为"Virtual eXtensible Local Area Network (VXLAN)"的框架，该框架提供了一种封装方案，以满足上述各种需求。这份备忘录记录了已部署的VXLAN协议，以造福互联网社区。

1.1. 缩略语和定义

• ACL： 访问控制列表（Access Control List）

• ECMP： 等价多路径（Equal-Cost Multipath）

• IGMP： 联网组管理协议(Internet Group Management Protocol)

• IHL： Internet报头长度(Internet Header Length)

• MTU： 最大传输单元(Maximum Transmission Unit)

• PIM： 协议无关组播(Protocol Independent Multicast)

• SPB： 最短路径桥接(Shortest Path Bridging)

• STP： 生成树协议(Spanning Tree Protocol)

• ToR： 机架顶部(Top of Rack)

• TRILL： 大量链路的透明互联（Transparent Interconnection of Lots of Links）

• VLAN： 虚拟局域网（Virtual Local Area Network）

• VM： VM 虚拟机（Virtual Machine）

• VNI： VXLAN 网络标识符（或 VXLAN 分段 ID）（VXLAN Network Identifier (or VXLAN Segment ID)）

• VTEP： VXLAN 隧道端点。发起和/或终止 VXLAN 隧道的实体（VXLAN Tunnel End Point. An entity that originates and/or terminates VXLAN tunnels）

• VXLAN： 虚拟可扩展局域网（Virtual eXtensible Local Area Network）

• VXLAN Segment： VXLAN 第 2 层覆盖网络，虚拟机通过该网络进行通信（VXLAN Layer 2 overlay network over which VMs communicate）

• VXLAN Gateway： 用于在 VXLAN 之间转发流量的实体（an entity that forwards traffic between VXLANs）

2. 本文档中使用的约定

本文档中的关键字“MUST”、“MUST NOT”、“REQUIRED”、“SHALL”、“SHALL NOT”、“SHOULD”、“SHOULD NOT”、“RECOMMENDED”、“MAY”和“OPTIONAL”应按照 RFC 2119 [RFC2119] 中的描述进行解释。

3. VXLAN问题陈述

本节提供了VXLAN希望解决的更多细节。重点关注数据中心内的网络基础设施及其相关问题。

3.1 生成树和VLAN范围的限制

当前的二层网络使用IEEE 802.1D Spanning Tree Protocol (STP) [802.1D]来避免由于重复路径而导致网络中出现环路。STP 会阻断使用某些链路，以避免数据帧被重复传输和循环。一些数据中心运营商认为这是第 2 层网络的一个问题，因为使用STP意味着他们实际上真正使用更多的端口和链路。此外，STP模型无法提供多路径冗余。新的倡议（如TRILL[RFC6325]和SPB [802.1aq]）已经被提出，以帮助解决多路径的问题，并克服STP的一些问题。通过将机架（rack）内的服务器配置为在同一个第三层网络中，可以避免STP的限制，并在机架内部和机架之间（rack and between racks）实现第三层交换。然而，这与在VM之间进行二层通信的模型不兼容。

二层数据中心网络的一个关键特征是它们使用虚拟局域网(VLAN)来提供广播隔离。以太网数据帧中使用 12 位 VLAN ID 将较大的第 2 层网络划分为多个广播域。这适用于许多需要少于 4094 个 VLAN 的数据中心。随着虚拟化的日益普及，这一上限正面临压力。此外，由于 STP，一些数据中心限制了可以使用的 VLAN 数量。此外，如第 3.3 节所述，对多租户环境的要求加速了对更大 VLAN 限制的需求。

3.2. 多租户环境

云计算涉及为多租户环境按需弹性配置资源。最常见的云计算示例是公共云，其中云服务提供商在同一物理基础设施上向多个客户/租户提供这些弹性服务。

租户可以通过二层或三层网络来隔离网络流量。对于二层网络，通常使用VLAN来分隔流量，因此一个租户可以通过自己的VLAN来标识。由于云服务提供商可能为大量租户提供服务，4094个VLAN的限制通常是不够的。此外，通常每个租户需要多个VLAN，这加剧了这个问题。

相关的使用案例是跨 Pod 扩展。一个 Pod 通常由一台或多台服务器的机架（racks of servers）以及相关的网络和存储连接组成。租户可能最初在一个 Pod 上启动，并由于扩展而需要在其他 Pod 上的服务器/虚拟机，特别是在其他 Pod 上的租户未充分利用其所有资源时。此使用案例需要一个"扩展"的二层环境，连接各个服务器/虚拟机（VM）。

三层网络对于多租户来说也不是一个全面的解决方案。两个租户可能在他们的网络中使用相同的三层地址集，这就要求云提供商以其他形式提供隔离。此外，要求所有租户使用IP排除了那些依赖直接的二层或非IP三层协议进行虚拟机（VM）间通信的客户。

3.3 ToR交换机的表格大小不足

如今的虚拟化环境对连接服务器的顶级交换机（ToR：Top-of-Rack）的MAC地址表提出了额外的要求。现在，ToR不仅需要学习每个服务器链接的一个MAC地址，而且还需要学习每个虚拟机的MAC地址（每个服务器可能会有数百个虚拟机）。这是必需的，因为从虚拟机到物理网络的流量将通过服务器和交换机之间的链接进行传输。一个典型的ToR交换机可以连接24个或48个服务器，具体取决于其面向服务器的端口数量。一个数据中心可能由多个机架组成，因此每个ToR交换机都需要维护一个通信虚拟机的地址表，跨越不同的物理服务器。这相对于非虚拟化环境会对表格容量产生更大需求。

如果表格溢出，交换机可能会停止学习新的地址，直到空闲条目过时，这将导致大量未知目标帧的泛洪。

4. VXLAN

VXLAN（Virtual eXtensible Local Area Network）通过在多租户环境中存在虚拟机的条件下，满足Layer 2和Layer 3数据中心网络基础设施的上述要求。它在现有的网络基础设施上运行，并提供了一种“延伸”Layer 2网络的方法。简单来说，VXLAN是在Layer 3网络上的一种Layer 2覆盖方案（overlay scheme）。每个覆盖称为一个VXLAN段（VXLAN segment）。只有在同一VXLAN段内的虚拟机之间才能相互通信。每个VXLAN段通过24位段ID（称为“VXLAN网络标识符（VNI：VXLAN Network Identifier）”）进行标识。这允许最多16M个VXLAN段在同一个管理域内共存。

VNI (Virtual Network Identifier) 用于标识由各个虚拟机 (VM) 生成的内部 MAC 帧的范围。因此，您可以跨网段拥有重叠的 MAC 地址，但永远不会有流量“交叉”，因为流量是使用 VNI 隔离的。VNI 位于封装由 VM 生成的内部 MAC 帧的外部头部中。在接下来的几节中，“VXLAN 段”一词可与“VXLAN 覆盖网络”互换使用。

由于这种封装，VXLAN 也可称为一种在第三层网络之上覆盖第二层网络的隧道方案。这些隧道是无状态的，因此每个帧都按照一组规则进行封装。以下各节中讨论的隧道端点（VXLAN Tunnel End Point 或 VTEP）位于托管 VM 的服务器上的虚拟机监控程序中。。因此，VNI 和 VXLAN 相关的隧道/外部头部封装只对 VTEP 可见 - 虚拟机看不到它（参见图1）。需要注意的是，VTEP 也可以位于物理交换机或物理服务器上，并且可以以软件或硬件的形式实现。在 VXLAN 部署方案的第 6 节中讨论了 VTEP 是物理交换机的一种使用情况。

以下部分讨论 VXLAN 环境中使用一种控制方案（数据平面学习）的典型流量场景。在这里，虚拟机的MAC与VTEP的IP地址的关联是通过源地址学习发现的。多播用于传输未知目标、广播和多播帧。

除了基于学习的控制平面外，还有其他方案可用于分发 VTEP IP 至 VM MAC 映射信息。例如，可选方案可能包括由各个 VTEP 进行基于中央管理机构/目录的查找，中央管理机构向 VTEP 分发此映射信息等等。这些有时被称为推拉模型。本文档将重点介绍作为 VXLAN 控制平面的数据平面学习方案。

4.1. 单播虚拟机到虚拟机通信

考虑一个位于 VXLAN 虚拟网络中的虚拟机。该虚拟机不知道 VXLAN 的存在。若它要与另一台主机上的虚拟机通信，则会像通常一样发送一个针对目标虚拟机的 MAC 帧。物理主机上的 VTEP 查找此 VM 所关联的 VNI。然后，它确定目标 MAC 是否位于同一段，并确定是否有一个将目标 MAC 地址映射到远程 VTEP 的映射关系。如果是这样，就会在原始 MAC 帧前添加一个包括外部 MAC、外部 IP 头和 VXLAN 头的外部头（参见第 5 节的图1以获取帧格式）。封装后的数据包将转发到远程 VTEP。在接收时，远程 VTEP 验证 VNI 的有效性，以及是否有一个使用匹配内部目标 MAC 地址的 MAC 地址连接到该 VNI 上的 VM。如果是这样，数据包就会被剥离其封装头部并传递到目标 VM。目标 VM 永远不会知道 VNI 或者该帧是通过 VXLAN 封装传输的。

除了将数据包转发到目标 VM，远程 VTEP 还可从内部源 MAC 到外部源 IP 地址进行映射学习。它将此映射存储在表中，以便在目标 VM 发送响应数据包时，不需要响应数据包的“未知目标”泛洪。

在源 VM 发送数据包之前确定目标 VM 的 MAC 地址的方法与非 VXLAN 环境相同，除非在第 4.2 节中描述的情况下。广播帧仍然被使用，但是会被封装在一个多播数据包中，具体细节在第 4.2 节中有详细说明。

4.2. 广播通信和映射到组播

考虑源主机上的 VM 尝试使用 IP 与目标 VM 进行通信。假设它们都在同一个子网上，VM 发送一个地址解析协议 (ARP) 广播帧。在非 VXLAN 环境中，这个帧将被以 MAC 广播的方式发送到携带该 VLAN 的所有交换机上。

使用 VXLAN，在数据包的开头插入一个包含 VXLAN VNI 的头部，同时还包括 IP 头部和 UDP 头部。然而，这个广播数据包会被发送到 VXLAN 覆盖网络（VXLAN overlay network）实现的 IP 多播组。

为此，我们需要在 VXLAN VNI 和它将使用的 IP 多播组之间建立映射关系。这个映射是在管理层进行的，并通过管理通道提供给各个 VTEP。利用这个映射关系，VTEP 可以向上游交换机/路由器提供 IGMP 成员报告，根据需要加入/退出与 VXLAN 相关的 IP 多播组。这将根据特定的多播流量地址基于是否在此主机上使用特定的多播地址的成员来修剪叶节点（参见[RFC4541]）。此外，使用多播路由协议，如协议独立多播 - 稀疏模式 (PIM-SM：Protocol Independent Multicast - Sparse Mode，见[RFC4601])，将在第三层网络内提供高效的多播树。

VTEP 将使用 (*,G) 加入方式。这是因为 VXLAN 隧道源的集合是未知的，并且可能经常变化，因为 VM 在不同的主机上启动/关闭。另一个值得注意的地方是，由于每个 VTEP 可以同时作为多播数据包的源和目的地，像双向 PIM (BIDIR-PIM，参见[RFC5015]) 这样的协议将更加高效。

目标虚拟机使用IP单播发送标准ARP响应。该帧将通过IP单播VXLAN封装返回到连接源虚拟机的VTEP。这是可能的，因为之前通过ARP请求了解到ARP响应的目标MAC地址与VXLAN隧道终端点（VXLAN tunnel end point，VTEP）IP的映射关系。

需要注意的是，多播帧和“未知MAC目的地”的帧也使用多播树发送，类似于广播帧。

4.3. 物理基础设施要求

当网络基础设施中使用IP多播时，可以通过网络中的各个层 3 IP 路由器/交换机使用诸如PIM-SM之类的多播路由协议。这用于构建高效的多播转发树，以便仅将多播帧发送到请求接收它们的主机。

同样，连接源虚拟机和目标虚拟机的实际网络不一定必须是一个层3网络：VXLAN也可以在层2网络上运行。无论哪种情况，都可以使用IGMP监听来在层2网络内实现高效的多播复制。

VTEP不得对VXLAN数据包进行分片。由于帧大小较大，中间路由器可能会分片封装的VXLAN数据包。目标VTEP可以默默地丢弃这样的VXLAN分片。为了确保端到端的流量传递不会出现分片，建议在物理网络基础架构中设置MTU（最大传输单元）以适应封装后的较大帧大小。还可以使用路径MTU发现等其他技术（参见[RFC1191]和[RFC1981]）来满足此要求。

5. VXLAN帧格式

下面是VXLAN数据帧格式。从帧的底部（即FCS上方）开始解析，会看到一个内部MAC帧，该帧具有自己的以太网头部信息，包括源MAC地址、目标MAC地址和以太网类型，还可能有一个可选的VLAN标识。有关内部VLAN标记处理的进一步详细信息，请参见第6节。

VXLAN帧格式如下图所示。从帧的底部解析它 - 在外部帧检查序列（FCS：Frame Check Sequence ）上方，有一个内部MAC帧，它有自己的以太网报头，包括源、目标MAC地址以及以太网类型，以及一个可选的VLAN。有关内部 VLAN 标记处理的更多详细信息，请参阅第 6 节。

内部 MAC 帧由以下四个报头封装（从最内层报头开始）：

VXLAN Header：这是一个 8 字节字段，具有：

• Flags (8 bits)：对于有效的 VXLAN 网络 ID （VNI），I 标志必须设置为 1。其他 7 位（指定为“R”）是保留字段，必须在传输时设置为零，并在接收时忽略。

• VXLAN Segment ID/VXLAN Network Identifier (VNI):这是一个24位值，用于指定通信vm所在的各个VXLAN覆盖网络（VXLAN overlay network）。不同VXLAN覆盖网络下的虚拟机之间无法通信。

• Reserved fields (24 bits and 8 bits):必须在传输时设置为零，在接收时忽略。

Outer UDP Header:这是外部UDP头部，源端口由VTEP提供，目标端口为众所周知的UDP端口。

• Destination Port: IANA已经指定了VXLAN UDP端口的值为4789，应默认使用此值作为目标UDP端口。一些早期的VXLAN实现使用其他值作为目标端口。为了实现与这些实现的互操作性，应该能够配置目标端口。

• Source Port: 建议使用内部数据包字段的哈希值来计算UDP源端口号，例如内部以太网帧头的哈希值。这样可以为跨VXLAN覆盖的VM到VM流量的ECMP/负载均衡提供一定程度的熵。按照这种方式计算UDP源端口号时，建议将其值设置在动态/私有端口范围49152-65535 [RFC6335]内。

• UDP Checksum: 它应该以零的形式传输。当收到 UDP 校验和为零的数据包时，必须接受该数据包进行解封装。或者，如果封装端点包含非零 UDP 校验和，则必须在整个数据包（包括 IP 报头、UDP 报头、VXLAN 报头和封装的 MAC 帧）上正确计算。当解封端点收到校验和为非零的数据包时，它可以选择验证校验和值。如果它选择执行此类验证，并且验证失败，则必须丢弃数据包。如果解封目标选择不执行验证，或者成功执行验证，则必须接受数据包进行解封。

Outer IP Header: 这是外部IP头，源IP地址指示通信的VM (由内部源MAC地址表示)所在的VTEP的IP地址。目标IP地址可以是单播或组播IP地址(见第4.1和4.2节)。当它是单播IP地址时，表示VTEP连接通信虚拟机的IP地址，由内部目标 MAC 地址表示。有关多播目标IP地址，请参阅第4.2节中详细的场景。

外部以太网头部（示例）: 图1是一个示例，显示了在outer Ethernet+IP+UDP+VXLAN头部中封装的内部以太网帧。此帧中的外部目标MAC地址可以是目标VTEP的地址或中间的第三层路由器的地址。外部VLAN标签是可选的。如果存在，它可以用于在局域网上划分VXLAN流量。

图 1：具有 IPv4 外部报头的 VXLAN 帧格式

上述帧格式显示了使用IPv4进行传输的以太网帧封装。下面详细介绍了在IPv6传输中使用VXLAN的方法。

图 2：具有 IPv6 外部报头的 VXLAN 帧格式

6. VXLAN部署场景

VXLAN通常部署在数据中心的虚拟化主机上，这些主机可能分布在多个机架（multiple racks）上。单个机架可能是不同第 3 层网络的一部分，也可能位于单个第 2 层网络中。VXLAN 分段/叠加网络覆盖在这些第 2 层或第 3 层网络之上。

请看图3，它描述了两个连接到第 3 层基础架构的虚拟服务器。这些服务器可能位于同一机架上，也可能位于不同的机架上，或者在同一管理域内的数据中心之间。有四个被标识为VNIs 22、34、74和98的VXLAN 叠加网络。考虑服务器 1 中的 VM1-1 和服务器 2 中的 VM2-4 的情况，它们位于由 VNI 22 标识的同一VXLAN覆盖网络上。VM 不知道覆盖网络和传输方法，因为封装和解封装在服务器 1 和 2 上的 VTEP 上透明地进行。其他覆盖网络及其相应的VM是：服务器 1上的 VM1-2 和服务器 2 上的 VM2-1，它们都在 VNI 34 上；服务器 1 上的 VM1-3 和服务器 2 上的 VM2-2 在 VNI 74 上；最后，服务器 1 上的 VM1-4和服务器 2 上的 VM2-3 在 VNI 98 上。

图 3：VXLAN 部署 - 跨第 3 层网络的 VTEP

一个部署场景是隧道终结点是一个理解VXLAN的物理服务器。另一个场景是VXLAN覆盖网络上的节点需要与可能基于VLAN的传统网络上的节点进行通信。这些节点可以是物理节点或虚拟机。为了实现此通信，网络可以包括VXLAN网关（参见下图4，其中交换机充当VXLAN网关），用于在VXLAN和非VXLAN环境之间转发流量。

在下面的讨论中，请参考图4。对于VXLAN连接的接口上的入站帧，网关会剥离VXLAN头，并根据内部以太网帧的目标MAC地址将其转发到物理端口。除非明确配置要将带有内部VLAN ID的解封装帧传递到非VXLAN接口，否则应该丢弃解封装后带有内部VLAN ID的帧。在相反的方向上，针对非VXLAN接口的入站帧根据帧中的VLAN ID映射到特定的VXLAN覆盖网络。除非明确配置要在封装为VXLAN之前将该VLAN ID保留在封装帧中，否则该VLAN ID将被移除。

提供VXLAN隧道终结功能的这些网关可以是ToR/接入交换机或数据中心网络拓扑中更高级别的交换机，例如核心交换机甚至是WAN边缘设备。最后一种情况（WAN边缘）可能涉及终止混合云环境中VXLAN隧道的提供者边缘（PE：Provider Edge）路由器。在所有这些实例中，需要注意的是网关功能可以在软件或硬件中实现。

图 4：VXLAN 部署 - VXLAN 网关

6.1. 内部VLAN标签处理

VTEP和VXLAN网关中的内部VLAN标记处理应符合以下规定：

除非另有配置，否则应丢弃带有内部 VLAN 标记的解封装 VXLAN 帧。在封装端，除非另有配置，否则 VTEP 不应在隧道数据包上包含内部 VLAN 标记。当带有 VLAN 标记的数据包是 VXLAN 隧道的候选数据包时，封装的 VTEP 应剥离 VLAN 标记，除非另有配置。

7. 安全注意事项

传统上，层2网络只能从内部被恶意终端攻击，这些攻击方式包括非法访问局域网并监听流量，通过伪造的数据包来接管另一个MAC地址，或者通过洪水攻击导致服务拒绝。而使用MAC-over-IP机制传输层2流量会显著扩大这种攻击面。恶意程序通过订阅一个或多个组播组（承载 VXLAN 网段的广播流量）将自己注入网络，或者同时将MAC-over- udp帧注入传输网络以注入虚假流量，可能还会劫持MAC地址。

本文档没有包含针对此类攻击的具体措施，而是依赖于在IP上面进行分层的其他传统机制。本节概述了 VXLAN 环境中一些可能的安全方法。

通过限制在VXLAN环境中部署和管理虚拟机/网关的部署和管理范围，可以缓解恶意终端的传统层2攻击。此外，可以通过像802.1X [802.1X] 这样的方案来增加管理措施，以控制单个终端的准入。此外，使用基于UDP的VXLAN封装可以在物理交换机中配置和使用基于五元组的ACL（访问控制列表：Access Control List）功能。

通过在IP网络上进行隧道传输的流量可以使用传统的安全机制，比如IPsec，对VXLAN流量进行身份验证和可选的加密。当然，这需要与授权的终端建立一个认证基础设施，以获取和分发凭据。

VXLAN叠加网络是在现有的局域网络基础设施上指定和运行的。为了确保VXLAN终端和它们的VTEP在局域网上得到授权，建议为VXLAN流量指定一个VLAN，并且服务器/VTEP通过该VLAN发送VXLAN流量，以提供一定的安全性措施。

此外，VXLAN 需要在这些叠加网络中正确映射 VNI 和虚拟机成员身份。预期这种映射使用现有的安全方法完成，并将其传达给VTEP和网关上的管理实体。

8. IANA 注意事项

IANA 在 VXLAN 的服务名称和传输协议端口号注册表中分配了一个众所周知的 UDP 端口 （4789）。有关端口号的讨论，请参阅第 5 节。

9. 参考资料

9.1. 规范性参考文献

[RFC2119] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.

9.2. 信息参考

[802.1aq] IEEE, “Standard for Local and metropolitan area networks –
Media Access Control (MAC) Bridges and Virtual Bridged
Local Area Networks – Amendment 20: Shortest Path
Bridging”, IEEE P802.1aq-2012, 2012.

[802.1D] IEEE, “Draft Standard for Local and Metropolitan Area
Networks/ Media Access Control (MAC) Bridges”, IEEE
P802.1D-2004, 2004.

[802.1X] IEEE, “IEEE Standard for Local and metropolitan area
networks – Port-Based Network Acces Control”, IEEE Std
802.1X-2010, February 2010.

[RFC1191] Mogul, J. and S. Deering, “Path MTU discovery”, RFC 1191,
November 1990.

[RFC1981] McCann, J., Deering, S., and J. Mogul, “Path MTU Discovery
for IP version 6”, RFC 1981, August 1996.

[RFC4541] Christensen, M., Kimball, K., and F. Solensky,
“Considerations for Internet Group Management Protocol
(IGMP) and Multicast Listener Discovery (MLD) Snooping
Switches”, RFC 4541, May 2006.

[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
“Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)”, RFC 4601, August 2006.

[RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano,
“Bidirectional Protocol Independent Multicast (BIDIR-PIM)”,
RFC 5015, October 2007.

[RFC6325] Perlman, R., Eastlake 3rd, D., Dutt, D., Gai, S., and A.
Ghanwani, “Routing Bridges (RBridges): Base Protocol
Specification”, RFC 6325, July 2011.

[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, “Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry”, BCP 165, RFC
6335, August 2011.