Network Working Group T. Melsen
Request for Comments: 4562 S. Blake
Category: Informational Ericsson
June 2006
Network Working Group T. Melsen
Request for Comments: 4562 S. Blake
Category: Informational Ericsson
June 2006
MAC-Forced Forwarding: A Method for Subscriber Separation on an Ethernet Access Network
MAC强制转发：以太网接入网中用户分离的一种方法
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes a mechanism to ensure layer-2 separation of Local Area Network (LAN) stations accessing an IPv4 gateway over a bridged Ethernet segment.
本文档描述了一种机制，以确保通过桥接以太网段访问IPv4网关的局域网（LAN）站的第2层分离。
The mechanism - called "MAC-Forced Forwarding" - implements an Address Resolution Protocol (ARP) proxy function that prohibits Ethernet Media Access Control (MAC) address resolution between hosts located within the same IPv4 subnet but at different customer premises, and in effect directs all upstream traffic to an IPv4 gateway. The IPv4 gateway provides IP-layer connectivity between these same hosts.
这种称为“MAC强制转发”的机制实现了地址解析协议（ARP）代理功能，该功能禁止位于同一IPv4子网内但位于不同客户场所的主机之间的以太网媒体访问控制（MAC）地址解析，并实际上将所有上行通信量定向到IPv4网关。IPv4网关在这些相同的主机之间提供IP层连接。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Access Network Requirements ................................3
1.2. Using Ethernet as an Access Network Technology .............4
2. Terminology .....................................................5
3. Solution Aspects ................................................6
3.1. Obtaining the IP and MAC Addresses of the Access Routers ...6
3.2. Responding to ARP Requests .................................7
3.3. Filtering Upstream Traffic .................................8
3.4. Restricted Access to Application Servers ...................8
4. Access Router Considerations ....................................8
5. Resiliency Considerations .......................................9
6. Multicast Considerations ........................................9
7. IPv6 Considerations ............................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
1. Introduction ....................................................2
1.1. Access Network Requirements ................................3
1.2. Using Ethernet as an Access Network Technology .............4
2. Terminology .....................................................5
3. Solution Aspects ................................................6
3.1. Obtaining the IP and MAC Addresses of the Access Routers ...6
3.2. Responding to ARP Requests .................................7
3.3. Filtering Upstream Traffic .................................8
3.4. Restricted Access to Application Servers ...................8
4. Access Router Considerations ....................................8
5. Resiliency Considerations .......................................9
6. Multicast Considerations ........................................9
7. IPv6 Considerations ............................................10
8. Security Considerations ........................................10
9. Acknowledgements ...............................................11
10. References ....................................................11
10.1. Normative References .....................................11
10.2. Informative References ...................................12
The main purpose of an access network is to provide connectivity between customer hosts and service provider access routers (ARs), typically offering reachability to the Internet and other IP networks and/or IP-based applications.
接入网络的主要目的是提供客户主机和服务提供商接入路由器（AR）之间的连接，通常提供对Internet和其他IP网络和/或基于IP的应用程序的可达性。
An access network may be decomposed into a subscriber line part and an aggregation network part. The subscriber line - often referred to as "the first mile" - is characterized by an individual physical (or logical, in the case of some wireless technologies) connection to each customer premises. The aggregation network - "the second mile" - performs aggregation and concentration of customer traffic.
接入网络可以分解为用户线路部分和聚合网络部分。用户线路（通常称为“第一英里”）的特点是与每个客户场所的单独物理（或逻辑，在某些无线技术的情况下）连接。聚合网络——“第二英里”——对客户流量进行聚合和集中。
The subscriber line and the aggregation network are interconnected by an Access Node (AN). Thus, the AN constitutes the border between individual subscriber lines and the common aggregation network. This is illustrated in the following figure.
用户线和聚合网络通过接入节点（an）互连。因此，AN构成了单个用户线路和公共聚合网络之间的边界。下图对此进行了说明。
Access Aggregation Access Subscriber Customer
Routers Network Nodes Lines Premises
Networks
+----+ |
--+ AR +-----------| +----+
+----+ | | +----------------[]--------
|--------+ AN |
| | +----------------[]--------
| +----+
|
| +----+
| | +----------------[]--------
|--------+ AN |
| | +----------------[]--------
| +----+
|
| +----+
| | +----------------[]--------
|--------+ AN |
+----+ | | +----------------[]--------
--+ AR +-----------| +----+
+----+ |
Access Aggregation Access Subscriber Customer
Routers Network Nodes Lines Premises
Networks
+----+ |
--+ AR +-----------| +----+
+----+ | | +----------------[]--------
|--------+ AN |
| | +----------------[]--------
| +----+
|
| +----+
| | +----------------[]--------
|--------+ AN |
| | +----------------[]--------
| +----+
|
| +----+
| | +----------------[]--------
|--------+ AN |
+----+ | | +----------------[]--------
--+ AR +-----------| +----+
+----+ |
There are two basic requirements that an access network solution must satisfy:
接入网解决方案必须满足两个基本要求：
1. Layer-2 separation between customer premises.
1. 第2层客户场所之间的隔离。
2. High IPv4 address assignment efficiency.
2. IPv4地址分配效率高。
It is required that all traffic to and from customer hosts located at different premises (i.e., accessed via different subscriber lines or via different access networks) be forwarded via an AR, and not bridged or switched at layer-2 (Requirement 1; see also requirement R-40 in [TR101]). This enables the access network service provider to use the AR(s) to perform security filtering, policing, and accounting of all customer traffic. This implies that within the access network, layer-2 traffic paths should not exist that circumvent an AR (with some exceptions; see Section 3.4).
要求与位于不同场所（即通过不同用户线路或通过不同接入网络访问）的客户主机之间的所有通信量通过AR转发，而不是在第2层桥接或交换（要求1；另见[TR101]中的要求R-40]）。这使得接入网络服务提供商能够使用AR对所有客户流量执行安全过滤、监控和记帐。这意味着在接入网络中，不应存在绕过AR的第2层通信路径（某些例外情况；参见第3.4节）。
In ATM-based access networks, the separation of individual customer hosts' traffic is an intrinsic feature achieved by the use of ATM permanent virtual connections (PVCs) between the customers' access device (e.g., DSL modem) and the AR (typically co-located/integrated with access control functionality in a Broadband Remote Access Server
在基于ATM的接入网络中，通过在客户接入设备（例如DSL调制解调器）和AR（通常与宽带远程接入服务器中的接入控制功能位于同一位置/集成）之间使用ATM永久虚拟连接（PVC）来实现单个客户主机通信量的分离
(BRAS)). In this case, the AN is an ATM-based Digital Subscriber Line Access Multiplexer (DSLAM).
（胸罩）。在这种情况下，AN是基于ATM的数字用户线接入多路复用器（DSLAM）。
This document, however, targets Ethernet-based access networks. Techniques other than ATM PVCs must be employed to ensure the desired separation of traffic to and from individual customer hosts.
然而，本文档的目标是基于以太网的接入网络。必须采用ATM PVC以外的技术，以确保与单个客户主机之间的通信量达到预期的分离。
Efficient address assignment is necessary to minimize consumption of the scarce IPv4 address space (Requirement 2). See [RFC3069] for further discussion. Address assignment efficiency is improved if host addresses are assigned out of one or more large pools, rather than by being assigned out of separate, smaller subnet blocks allocated to each customer premises. IPv6 address assignment efficiency is of much less concern, and it is anticipated that IPv6 deployments will allocate separate IPv6 subnet blocks to each customer premises [v6BB].
高效的地址分配对于最小化稀缺IPv4地址空间的消耗是必要的（要求2）。有关进一步的讨论，请参见[RFC3069]。如果从一个或多个大型池中分配主机地址，而不是从分配给每个客户场所的单独、较小的子网块中分配主机地址，则地址分配效率会提高。IPv6地址分配效率不太受关注，预计IPv6部署将为每个客户场所分配单独的IPv6子网块[v6BB]。
A major aspect of using Ethernet as an access technology is that traffic pertaining to different customer hosts is conveyed over a shared broadcast network. Layer-2 isolation between customer premises networks could be provided by implementing access router functionality in each EAN, treating each subscriber line as a separate IP interface. However, there are a variety of reasons why it is often desirable to avoid IP routing in the access network, including the need to satisfy regulatory requirements for direct layer-2 accessibility to multiple IP service providers. In addition, this solution would not solve Requirement 2.
使用以太网作为接入技术的一个主要方面是，与不同客户主机相关的流量通过共享广播网络传输。通过在每个EAN中实现接入路由器功能，将每个用户线路视为一个单独的IP接口，可以提供客户场所网络之间的第2层隔离。然而，有多种原因可以解释为什么通常希望避免接入网络中的IP路由，包括需要满足多个IP服务提供商直接第2层可访问性的监管要求。此外，此解决方案无法解决需求2。
To avoid IP routing within the access network, the Ethernet aggregation network is bridged via EANs to individual Ethernet networks at the customers' premises. If the EANs were standard Ethernet bridges, then there would be direct layer-2 visibility between Ethernet stations (hosts) located at different customers' premises. Specifically, hosts located within the same IP subnet would have this visibility. This violates Requirement 1 (Section 1.1) and introduces security issues, as malicious end-users thereby can attack hosts at other customers' premises directly at the Ethernet layer.
为了避免接入网络内的IP路由，以太网聚合网络通过EANs桥接到客户场所的各个以太网。如果EAN是标准以太网网桥，那么位于不同客户场所的以太网站点（主机）之间将有直接的第2层可见性。具体来说，位于同一IP子网内的主机将具有这种可见性。这违反了要求1（第1.1节），并引入了安全问题，因为恶意最终用户因此可以直接在以太网层攻击其他客户场所的主机。
Existing standardized solutions may be deployed to prevent layer-2 visibility between stations:
可以部署现有的标准化解决方案，以防止站点之间的第二层可见性：
o PPP over Ethernet [RFC2516]. The use of PPPoE creates individual PPP sessions between hosts and one or more BRASes over a bridged Ethernet topology. Traffic always flows between a BRAS and hosts,
o 以太网PPP[RFC2516]。PPPoE的使用通过桥接以太网拓扑在主机和一个或多个BRASE之间创建单独的PPP会话。流量始终在BRAS和主机之间流动，
never directly between hosts. The AN can force upstream traffic to flow only to the BRAS initially selected by the host.
永远不要直接在主机之间。AN可以强制上游流量仅流向主机最初选择的BRA。
o VLAN per-customer premises network [RFC3069]. Traffic to/from each customer premises network can be separated into different VLANs across the aggregation network between the AN and the AR.
o 每个客户场所网络的VLAN[RFC3069]。通过AN和AR之间的聚合网络，进出每个客户场所网络的流量可以分离为不同的VLAN。
Both solutions provide layer-2 isolation between customer hosts, but they are not considered optimal for broadband access networks, because:
这两种解决方案都提供了客户主机之间的第2层隔离，但它们并不被认为是宽带接入网络的最佳选择，因为：
o PPPoE does not support efficient multicast: packets must be replicated on each PPPoE session to hosts listening on a specific multicast group. This negates one of the major advantages of using Ethernet (instead of ATM) as an access technology. This is an especially problematic limitation for services such as IPTV, which require high bandwidth per-multicast group (channel), and which may often have hundreds or thousands of listening customer hosts per group.
o PPPoE不支持高效多播：必须在每个PPPoE会话上将数据包复制到侦听特定多播组的主机。这否定了使用以太网（而不是ATM）作为接入技术的主要优势之一。对于IPTV这样的服务来说，这是一个特别有问题的限制，它要求每个多播组（通道）具有高带宽，并且每个组通常有数百或数千个侦听客户主机。
o Using VLANs to isolate individual customer premises networks also forces multicast packets to be replicated to each VLAN with a listening host. Furthermore, the basic limit of a maximum of 4096 VLANs per-Ethernet network limits the scalability of the solution. This scalability limit can be removed by deploying VLAN stacking techniques within the access network, but this approach increases provisioning complexity.
o 使用VLAN隔离单个客户场所网络还强制使用侦听主机将多播数据包复制到每个VLAN。此外，每个以太网最多4096个VLAN的基本限制限制了解决方案的可扩展性。通过在接入网络中部署VLAN堆叠技术，可以消除这种可扩展性限制，但这种方法增加了资源调配的复杂性。
The solution proposed in this document avoids these problems.
本文件中提出的解决方案避免了这些问题。
Access Node (AN) The entity interconnecting individual subscriber lines to the shared aggregation network.
接入节点（AN）将单个用户线路与共享聚合网络互连的实体。
Access Router (AR) The entity interconnecting the access network to the Internet or other IP-based networks. The AR provides connectivity between hosts on the access network at different customer premises. It is also used to provide security filtering, policing, and accounting of customer traffic.
接入路由器（AR）将接入网络与Internet或其他基于IP的网络互连的实体。AR在不同客户场所的接入网络上提供主机之间的连接。它还用于提供客户流量的安全过滤、监控和记帐。
Application Server (AS) A server, usually owned by a service provider, that attaches directly to the aggregation network and is directly reachable at layer-2 by customer hosts.
应用程序服务器（AS）通常由服务提供商拥有的服务器，直接连接到聚合网络，客户主机可在第2层直接访问。
Ethernet Access Node (EAN) An Access Node supporting Ethernet-based subscriber lines and uplinks to an Ethernet-based aggregation network and MAC-Forced Forwarding. For example, for xDSL access, the EAN is an Ethernet-centric DSLAM. The EAN is a special type of filtering bridge that does not forward Ethernet broadcast and multicast frames originating on a subscriber line to other subscriber lines, but either discards them or forwards them upstream (towards the aggregation network). The EAN also discards unicast Ethernet frames that originate on a subscriber line and are not addressed to an AR.
以太网接入节点（EAN）支持基于以太网的用户线路和到基于以太网的聚合网络和MAC强制转发的上行链路的接入节点。例如，对于xDSL访问，EAN是以以太网为中心的DSLAM。EAN是一种特殊类型的过滤网桥，它不会将源自用户线路的以太网广播和多播帧转发到其他用户线路，而是丢弃它们或将它们转发到上游（朝向聚合网络）。EAN还丢弃源自用户线路且未寻址到AR的单播以太网帧。
The basic property of the solution is that the EAN ensures that upstream traffic is always sent to a designated AR, even if the IP traffic should ultimately flow between customer hosts located within the same IP subnet.
该解决方案的基本特性是，EAN确保始终将上游流量发送到指定的AR，即使IP流量最终应在位于同一IP子网内的客户主机之间流动。
The solution has three major aspects:
解决方案有三个主要方面：
1. Initially, the EAN obtains the IP and MAC addresses of the allowed target ARs for each customer host.
1. 最初，EAN为每个客户主机获取允许的目标AR的IP和MAC地址。
2. The EAN replies to any upstream ARP request [RFC0826] from customer hosts with the MAC address of an allowed target AR.
2. EAN使用允许的目标AR的MAC地址回复来自客户主机的任何上游ARP请求[RFC0826]。
3. The EAN discards any upstream unicast traffic to MAC addresses other than the allowed target ARs. The EAN also discards all non-essential broadcast and multicast packets received on subscriber lines.
3. EAN丢弃除允许的目标ARs之外的MAC地址的任何上游单播通信量。EAN还丢弃在用户线路上接收的所有非必要广播和多播数据包。
These aspects are discussed in the following sections.
以下各节将讨论这些方面。
An access network may contain multiple ARs, and different hosts may be assigned to different (groups of) ARs. This implies that the EAN must register the assigned AR addresses on a per-customer host basis.
一个接入网络可以包含多个AR，并且可以将不同的主机分配给不同的（组）AR。这意味着EAN必须在每个客户主机的基础上注册分配的AR地址。
For each customer host, one of the ARs is acting as the default gateway. If a customer has simultaneous access to multiple ARs, the other ARs typically will provide access to other IP networks.
对于每个客户主机，其中一个ARs充当默认网关。如果客户同时访问多个AR，则其他AR通常将提供对其他IP网络的访问。
The EAN learns the IPv4 address of the allowed target ARs in one of two ways, depending on the host IPv4 address assignment method. For each host using Dynamic Host Configuration Protocol (DHCP), the EAN learns the AR IPv4 addresses dynamically by snooping the DHCPACK
EAN通过以下两种方式之一学习允许的目标AR的IPv4地址，具体取决于主机IPv4地址分配方法。对于使用动态主机配置协议（DHCP）的每个主机，EAN通过窥探DHCPACK动态地学习AR IPv4地址
reply to a host [RFC2131]. If a host using DHCP shall have simultaneous access to multiple ARs, DHCP option 121 [RFC3442] or DHCP option 33 [RFC2132] must be used to specify them for that host. If static address assignment is used instead of DHCP, then AR IPv4 addresses must be pre-provisioned in the EAN by the network operator. In both cases, the EAN will ARP to determine the ARs' corresponding MAC addresses. This can be done immediately after the IPv4 addresses are learned or when the MAC addresses are first required.
回复主机[RFC2131]。如果使用DHCP的主机应同时访问多个AR，则必须使用DHCP选项121[RFC3442]或DHCP选项33[RFC2132]为该主机指定它们。如果使用静态地址分配而不是DHCP，则网络运营商必须在EAN中预先设置AR IPv4地址。在这两种情况下，EAN将使用ARP来确定ARs的相应MAC地址。这可以在IPv4地址读入后或首次需要MAC地址时立即完成。
The DHCP server can associate customer hosts with subscriber lines if the EAN uses the DHCP Relay Agent Information Option (82) to convey a subscriber line identifier to the DHCP server in DHCP messages flowing upstream from the customer host [RFC3046].
如果EAN使用DHCP中继代理信息选项（82）在从客户主机向上游流动的DHCP消息中向DHCP服务器传送订户线路标识符，则DHCP服务器可以将客户主机与订户线路相关联[RFC3046]。
If all customer networks were assigned individual IP subnet blocks (and if routing protocols were blocked inside the access network), then all upstream traffic would normally go to an AR (typically the default gateway), and the EAN could validate all upstream traffic by checking that the destination MAC address matched that of an AR.
如果为所有客户网络分配了单独的IP子网块（并且如果在接入网络内阻塞了路由协议），则所有上游流量通常都将流向AR（通常为默认网关），并且EAN可以通过检查目标MAC地址是否与AR地址匹配来验证所有上游流量。
However, to comply with Requirement 2 of Section 1.1, residential customer networks are not (usually) assigned individual IPv4 subnet blocks. In other words, several hosts located at different premises are within the same IPv4 subnet. Consequently, if a host wishes to communicate with a host at another premises, an ARP request is issued to obtain that host's corresponding MAC address. This request is intercepted by the EAN's ARP proxy, and an ARP reply is sent, specifying an allowed AR MAC address (typically the default gateway's) as the requested layer-2 destination address, in a manner similar to the "proxy ARP" mechanism described in [RFC1812]. In this way, the ARP table of the requesting host will register an AR MAC address as the layer-2 destination for any host within that IPv4 subnet (except those at the same customer premises; see below).
然而，为了符合第1.1节的要求2，住宅用户网络（通常）不分配单独的IPv4子网块。换句话说，位于不同场所的多个主机位于同一IPv4子网内。因此，如果主机希望与另一场所的主机通信，则发出ARP请求以获取该主机的相应MAC地址。EAN的ARP代理截获该请求，并发送ARP回复，以类似于[RFC1812]中描述的“代理ARP”机制的方式，指定允许的AR MAC地址（通常为默认网关）作为请求的第2层目标地址。这样，请求主机的ARP表将注册一个AR MAC地址作为该IPv4子网内任何主机的第2层目的地（位于同一客户场所的主机除外；见下文）。
ARP requests for an IPv4 address of an allowed target AR are replied to by the EAN's ARP proxy with that AR's MAC address, rather than the MAC address of the default gateway AR.
允许的目标AR的IPv4地址的ARP请求由EAN的ARP代理用该AR的MAC地址而不是默认网关AR的MAC地址来响应。
An exception is made when a host is ARPing for another host located within the same premises network. If this ARP request reaches the EAN, it should be discarded, because it is assumed to be answered directly by the target host within the premises network. The EAN must keep track of all assigned IPv4 addresses on a subscriber line so that it can detect these ARP requests and discard them.
当一台主机正在为位于同一网络内的另一台主机ARP时，会出现例外情况。如果此ARP请求到达EAN，则应将其丢弃，因为假定该请求由本地网络内的目标主机直接应答。EAN必须跟踪用户线路上所有分配的IPv4地址，以便能够检测这些ARP请求并丢弃它们。
Since the EAN's ARP proxy will always reply with the MAC address of an AR, the requesting host will never learn MAC addresses of hosts located at other premises. However, malicious customers or malfunctioning hosts may still try to send traffic using other unicast destination MAC addresses. The EAN must discard all unicast frames received on a subscriber line that are not addressed to a destination MAC address for an allowed AR (with some exceptions; see Section 3.4.
由于EAN的ARP代理将始终使用AR的MAC地址进行回复，因此请求主机将永远不会了解位于其他场所的主机的MAC地址。但是，恶意客户或出现故障的主机仍可能尝试使用其他单播目标MAC地址发送流量。EAN必须丢弃在订户线路上接收的所有单播帧，这些帧没有针对允许的AR地址发送到目标MAC地址（有些例外；请参见第3.4节）。
Similarly, broadcast or multicast packets received on a subscriber line must never be forwarded on other subscriber lines, but only on EAN uplinks to the aggregation network. An EAN must discard all non-ARP broadcast packets received on subscriber lines, except when DHCP is in use, in which case, the EAN must forward client-to-server DHCP broadcast messages (DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE, DHCPINFORM) [RFC2131] upstream. An EAN should rate limit upstream broadcast packets.
类似地，在用户线路上接收的广播或多播数据包决不能在其他用户线路上转发，而只能在到聚合网络的EAN上行链路上转发。EAN必须丢弃在用户线路上接收的所有非ARP广播数据包，除非DHCP正在使用，在这种情况下，EAN必须将客户端转发到服务器DHCP广播消息（DHCPDISCOVER、DHCPREQUEST、DHCPDEVEN、DHCPINFORM）[RFC2131]上游。EAN应限制上行广播数据包的速率。
Broadcast packets forwarded on an EAN uplink may be forwarded to other EANs by the aggregation network. EANs should discard all broadcast packets received from the aggregation network, except ARPs from ARs for subscriber hosts and server-to-client DHCP messages (DHCPOFFER, DHCPACK, DHCPNAK) [RFC2131], when DHCP is in use.
在EAN上行链路上转发的广播分组可以由聚合网络转发到其他EAN。当DHCP正在使用时，EANs应丢弃从聚合网络接收的所有广播数据包，但从ARs接收的用于订户主机和服务器到客户端DHCP消息（DHCPOFFER、DHCPACK、DHCPNAK）[RFC2131]的ARP除外。
Filtering of multicast packets to and from an EAN uplink is discussed in Section 6.
在第6节中讨论了从EAN上行链路到EAN上行链路的多播分组的过滤。
The previous discussion (Section 3.1) describes how customer hosts are allowed direct layer-2 connectivity only to one or more ARs. Similarly, a customer host could be allowed direct layer-2 access to one or more Application Servers (ASes) which are directly connected to the aggregation network. There is no functional difference in the way MAC-Forced Forwarding treats access to ARs and ASes.
前面的讨论（第3.1节）描述了如何允许客户主机仅与一个或多个AR直接进行第2层连接。类似地，可以允许客户主机直接第2层访问直接连接到聚合网络的一个或多个应用服务器（ASE）。MAC强制转发处理ARs和ASE访问的方式没有功能上的差异。
Traffic between customer hosts that belong to the same IPv4 subnet but are located at different customer premises will always be forwarded via an AR. In this case, the AR will forward the traffic to the originating network, i.e., on the same interface from where it was received. This normally results in an ICMP redirect message [RFC0792] being sent to the originating host. To prevent this behavior, the ICMP redirect function for aggregation network interfaces must be disabled in the AR.
属于同一IPv4子网但位于不同客户场所的客户主机之间的流量将始终通过AR转发。在这种情况下，AR将流量转发到发起网络，即在接收流量的同一接口上。这通常会导致ICMP重定向消息[RFC0792]被发送到发起主机。为了防止这种行为，必须在AR中禁用聚合网络接口的ICMP重定向功能。
The operation of MAC-Forced Forwarding does not interfere with or delay IP connectivity recovery in the event of a sustained AR failure. Use of DHCP to configure hosts with information on multiple, redundant ARs, or use of Virtual Router Redundancy Protocol (VRRP) [RFC3768] to implement AR redundancy, allows IP connectivity to be maintained.
在持续AR故障的情况下，MAC强制转发的操作不会干扰或延迟IP连接恢复。使用DHCP配置具有多个冗余AR信息的主机，或使用虚拟路由器冗余协议（VRRP）[RFC3768]实现AR冗余，允许保持IP连接。
MAC-Forced Forwarding is a stateful protocol. If static IPv4 address assignment is used in the access network, then the EAN must be pre-provisioned with state information for the customer hosts which may be reached via a subscriber line, and the ARs associated with those hosts. In the event of a transient EAN failure, the EAN's state database can be quickly recovered from its configuration storage.
MAC强制转发是一种有状态协议。如果在接入网络中使用静态IPv4地址分配，则必须为EAN预先提供可通过订户线路到达的客户主机的状态信息，以及与这些主机关联的ARs。在EAN出现短暂故障的情况下，可以从其配置存储中快速恢复EAN的状态数据库。
If DHCP is used to assign IPv4 addresses in the access network, then MAC-Forced Forwarding operates as a soft-state protocol. Since the DHCP and ARP messages that are snooped to construct the EAN state database are usually sent infrequently, a transient failure may not be detected by either the AR(s) or the customer hosts. Therefore, a transient failure of an EAN could lead to an extended loss of connectivity. To minimize connectivity loss, an EAN should maintain its dynamic state database in resilient storage to permit timely database and connectivity restoration.
如果使用DHCP在接入网络中分配IPv4地址，则MAC强制转发作为软状态协议运行。由于窥探以构建EAN状态数据库的DHCP和ARP消息通常不经常发送，因此AR或客户主机可能无法检测到瞬时故障。因此，EAN的瞬时故障可能会导致连接的长期中断。为了最大限度地减少连接损失，EAN应在弹性存储中维护其动态数据库，以允许及时恢复数据库和连接。
The EAN is a single point of attachment between a subscriber line and the aggregation network; hence, the EAN is a single point of connectivity failure. Customers seeking more resilient connectivity should multi-home.
EAN是用户线路和聚合网络之间的单个连接点；因此，EAN是单点连接故障。寻求更具弹性的连接的客户应选择多个家庭。
Multicast traffic delivery for streams originating within the aggregation network or further upstream and delivered to one or more customer hosts in an access network is supported in a scalable manner by virtue of Ethernet's native multicast capability. Bandwidth efficiency can be enhanced if the EAN behaves as an IGMP snooping bridge; e.g., if it snoops on IGMP Membership Report and Leave Group messages originating on subscriber lines to prune the set of subscriber lines on which to forward particular multicast groups [RFC3376].
借助于以太网的本机多播能力，以可伸缩的方式支持对源自聚合网络内或更上游并传送到接入网络中的一个或多个客户主机的流的多播业务传送。如果EAN充当IGMP侦听网桥，则可以提高带宽效率；e、 例如，如果它窥探IGMP成员资格报告，并保留源自订户线路的组消息，以修剪用于转发特定多播组的订户线路集[RFC3376]。
An EAN must discard all IPv4 multicast packets received on a subscriber line other than IGMP Membership Report and Leave Group messages [RFC3376]. If a customer host wishes to source multicast packets to a group, the host must tunnel them upstream to a multicast router; e.g., an AR acting as a Protocol Independent Multicast -
EAN必须丢弃在除IGMP成员资格报告之外的订户线路上接收的所有IPv4多播数据包，并保留组消息[RFC3376]。如果客户主机希望向组发送多播数据包，则主机必须通过隧道将其上行传输到多播路由器；e、 例如，作为协议独立多播的AR-
Sparse Mode (PIM-SM) Designated Router [RFC2362]. An AR will forward them back into the access network if there are any listening customer hosts.
稀疏模式（PIM-SM）指定路由器[RFC2362]。如果有任何正在侦听的客户主机，AR将把它们转发回接入网络。
EAN processing of IPv6 multicast packets is discussed in the next section.
下一节将讨论IPv6多播数据包的EAN处理。
MAC-Forced Forwarding is not directly applicable for IPv6 access networks for the following reasons:
MAC强制转发不直接适用于IPv6接入网络，原因如下：
1. IPv6 access networks do not require the same efficiency of address allocation as IPv4 access networks. It is expected that customer premises networks will be allocated unique network prefixes (e.g., /48) accommodating large numbers of customer subnets and hosts [v6BB].
1. IPv6接入网络不需要与IPv4接入网络相同的地址分配效率。预计将为客户场所网络分配唯一的网络前缀（例如，/48），以容纳大量客户子网和主机[v6BB]。
2. IPv6 nodes do not use ARP, but instead use the Neighbor Discovery Protocol [RFC2461] for layer-2 address resolution.
2. IPv6节点不使用ARP，而是使用邻居发现协议[RFC2461]进行第二层地址解析。
To simultaneously support both IPv6 and MAC-Forced Forwarding for IPv4, an EAN can implement the unicast, broadcast, and multicast filtering rules described in Section 3.3. To correctly perform unicast filtering, the EAN must learn the IPv6 and MAC addresses of the allowed ARs for a particular subscriber line. It can learn these addresses either through static configuration or by snooping Router Discovery messages exchanged between the customer premises router and one or more ARs [RFC2461].
为了同时支持IPv4的IPv6和MAC强制转发，EAN可以实现第3.3节中描述的单播、广播和多播过滤规则。为了正确执行单播过滤，EAN必须了解特定用户线路允许的AR的IPv6和MAC地址。它可以通过静态配置或通过窥探在客户场所路由器和一个或多个ARs之间交换的路由器发现消息来了解这些地址[RFC2461]。
Multicast is an intrinsic part of the IPv6 protocol suite. Therefore, an EAN must not indiscriminately filter IPv6 multicast packets flowing upstream, although it may rate limit them. Detailed IPv6 multicast filtering rules are not discussed in this document.
多播是IPv6协议套件的固有部分。因此，EAN不能不加区别地过滤流向上游的IPv6多播数据包，尽管它可能会对它们进行速率限制。本文档中不讨论详细的IPv6多播过滤规则。
MAC-Forced Forwarding is, by its nature, a security function, ensuring layer-2 isolation of customer hosts sharing a broadcast access medium. In that sense, it provides security equivalent to alternative PVC-based solutions. Security procedures appropriate for any shared access medium are equally appropriate when MAC-Forced Forwarding is employed. It does not introduce any additional vulnerabilities over those of standard Ethernet bridging.
MAC强制转发本质上是一种安全功能，确保共享广播访问介质的客户主机的第二层隔离。从这个意义上讲，它提供的安全性相当于基于PVC的替代解决方案。当采用MAC强制转发时，适用于任何共享访问介质的安全程序同样适用。与标准以太网桥接相比，它不会引入任何额外的漏洞。
In addition to layer-2 isolation, an EAN implementing MAC-Forced Forwarding must discard all upstream broadcast packets, except for valid DHCP messages, and ARP requests (which are proxied by the EAN).
除了第2层隔离之外，实现MAC强制转发的EAN必须丢弃所有上游广播数据包，有效DHCP消息和ARP请求（由EAN代理）除外。
In particular, the EAN must discard any DHCP server replies originating on a subscriber line. Further, an EAN may rate limit upstream broadcast DHCP messages.
特别是，EAN必须丢弃来自订户线路的任何DHCP服务器应答。此外，EAN可以对上行广播DHCP消息进行速率限制。
An EAN implementing MAC-Forced Forwarding must keep track of IPv4 addresses allocated on subscriber lines. Therefore, the EAN has sufficient information to discard upstream traffic with spoofed IPv4 source addresses.
实现MAC强制转发的EAN必须跟踪在订户线路上分配的IPv4地址。因此，EAN有足够的信息来丢弃具有伪造IPv4源地址的上游流量。
The authors would like to thank Ulf Jonsson, Thomas Narten, James Carlson, Rolf Engstrand, Tomas Thyni, and Johan Kolhi for their helpful comments.
作者要感谢乌尔夫·琼森、托马斯·纳滕、詹姆斯·卡尔森、罗尔夫·恩格斯特兰德、托马斯·蒂尼和约翰·科利的有益评论。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]Postel，J.，“互联网控制消息协议”，STD 5，RFC 792，1981年9月。
[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, November 1982.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]Alexander，S.和R.Droms，“DHCP选项和BOOTP供应商扩展”，RFC 21321997年3月。
[RFC2362] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[RFC2362]Estrin，D.，Farinaci，D.，Helmy，A.，Thaler，D.，Deering，S.，Handley，M.，Jacobson，V.，Liu，C.，Sharma，P.，和L.Wei，“协议独立多播稀疏模式（PIM-SM）：协议规范”，RFC 2362，1998年6月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC3046，2001年1月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4", RFC 3442, December 2002.
[RFC3442]Lemon，T.，Cheshire，S.，和B.Volz，“动态主机配置协议（DHCP）版本4的无类静态路由选项”，RFC 3442，2002年12月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，“IP版本4路由器的要求”，RFC1812，1995年6月。
[RFC3768] Hinden, R., "Virtual Router Redundancy Protocol (VRRP)", RFC 3768, April 2004.
[RFC3768]Hinden，R.，“虚拟路由器冗余协议（VRRP）”，RFC 3768，2004年4月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
[RFC2516]Mamakos，L.，Lidl，K.，Evarts，J.，Carrel，D.，Simone，D.，和R.Wheeler，“通过以太网传输PPP（PPPoE）的方法”，RFC 2516，1999年2月。
[RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for Efficient IP Address Allocation", RFC 3069, February 2001.
[RFC3069]McPherson，D.和B.Dykes，“有效IP地址分配的VLAN聚合”，RFC 3069，2001年2月。
[TR101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation", Technical Report TR-101, April 2006.
[TR101]DSL论坛，“迁移到基于以太网的DSL聚合”，技术报告TR-101，2006年4月。
[v6BB] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and J. Palet, "ISP IPv6 Deployment Scenarios in Broadband Access Networks", Work in Progress.
[v6BB]Asadullah，S.，Ahmed，A.，Popoviciu，C.，Savola，P.，和J.Palet，“宽带接入网络中的ISP IPv6部署场景”，正在进行中。
Authors' Addresses
作者地址
Torben Melsen Ericsson Faelledvej Struer DK-7600 Denmark
托本·梅尔森·爱立信·费勒德韦伊·斯特鲁尔DK-7600丹麦
EMail: Torben.Melsen@ericsson.com
EMail: Torben.Melsen@ericsson.com
Steven Blake Ericsson 920 Main Campus Drive Suite 500 Raleigh, NC 27606 USA
史蒂文·布莱克·爱立信920美国北卡罗来纳州罗利市主校区大道500号套房，邮编：27606
Phone: +1 919 472 9913
EMail: steven.blake@ericsson.com
Phone: +1 919 472 9913
EMail: steven.blake@ericsson.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78和www.rfc-editor.org/copyright.html中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。