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
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-強制転送」と呼ばれる - は、同じIPv4サブネット内が異なる顧客宅内に設置ホスト間でイーサネットのMAC（Media Access Control）アドレス解決を禁止しているアドレス解決プロトコル（ARP）プロキシ機能を実装し、実際に指示します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
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.
アクセスネットワークの主な目的は、典型的には、インターネットや他のIPネットワークおよび/またはIPベースのアプリケーションへの到達可能性を提供し、顧客のホストとサービスプロバイダアクセスルータ（ARS）との間の接続を提供することです。
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 +-----------| +----+
+----+ |
There are two basic requirements that an access network solution must satisfy:
アクセス・ネットワーク・ソリューションを満たさなければならない2つの基本的な要件があります。
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でスイッチングする必要がある。も参照します要求R-40 [TR101]で）。これは、すべての顧客のトラフィックのセキュリティフィルタリング、ポリシング、およびアカウンティングを実行するためにAR（複数可）を使用するアクセスネットワークサービスプロバイダを可能にします。 （; 3.4節を参照のいくつかの例外を除いて）これは、アクセスネットワーク内の、レイヤ2トラフィックのパスはそれがARを回避存在してはならないことを意味します。
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 (BRAS)). In this case, the AN is an ATM-based Digital Subscriber Line Access Multiplexer (DSLAM).
ATMベースのアクセス・ネットワークでは、個々の顧客のホストの分離一般的にコ - （アクセスデバイス（例えば、DSLモデム）とARのトラフィックは、顧客間のATM PVCを使用することによって達成固有の機能ですブロードバンドリモートアクセスサーバ（BRAS））でのアクセス制御機能を備えた統合/設置。この場合、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の展開は、各顧客宅内[v6BB]に別のIPv6サブネット・ブロックを割り当てることが予想されます。
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.
アクセス技術として、イーサネットを使用しての主な特徴は、別の顧客のホストに関連するトラフィックが共有放送ネットワークを介して搬送されていることです。顧客構内ネットワーク間のレイヤ2分離は、各EANにアクセスルータの機能を実装する別のIPインタフェースとして各加入者線を処理することによって提供することができます。しかし、複数のIPサービスプロバイダに直接レイヤ2のアクセシビリティのための規制要件を満たすために必要性を含む、アクセスネットワークでIPルーティングを避けることが望ましい場合が多い理由の様々なものがあります。また、このソリューションは、要件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を経由して架設されています。 EANSは、標準のイーサネットブリッジであった場合には、異なる顧客構内に位置するイーサネットステーション（ホスト）との間の直接レイヤ2視認性が存在するであろう。具体的には、同じIPサブネット内に配置されたホストは、この可視性を持っているでしょう。これは、要件1（1.1節）に違反し、悪質なエンドユーザーは、それによって直接イーサネットレイヤで他のお客さまの構内にホストを攻撃できるように、セキュリティ上の問題を紹介します。
Existing standardized solutions may be deployed to prevent layer-2 visibility between stations:
既存の標準化されたソリューションは、ステーション間のレイヤ2の可視性を防止するために配備されてもよいです。
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, never directly between hosts. The AN can force upstream traffic to flow only to the BRAS initially selected by the host.
イーサネット上のPPP [RFC2516] O。 PPPoEの使用は、ブリッジイーサネットトポロジー上のホストと1つ以上のBRASes間の個々のPPPセッションを作成します。トラフィックは常に、決して直接ホスト間で、BRASとホストの間を流れます。 ANは、最初にホストによって選択されたBRASへの流れのみをアップストリームトラフィックを強制することができます。
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.
個々の顧客宅内ネットワークを分離するためのVLANを使用してoをもリスニングホストと各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）は、インターネットまたは他の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は、IPトラフィックは、最終的に同じIPサブネット内に配置された顧客ホストの間を流れる必要がある場合でも、アップストリームトラフィックは常に、指定されたARに送信されることを保証していることです。
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は、MACへのアップストリームのユニキャストトラフィックが許可ターゲットのAR以外のアドレスを廃棄します。 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を含んでいてもよいし、異なるホストは異なるアクセスルータ（群）に割り当てることができます。これは、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.
各顧客のホストの場合は、のARの一つは、デフォルトゲートウェイとして機能しています。顧客が複数の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 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.
EANは、ホストのIPv4アドレス割り当て方法に応じて、次のいずれかの方法で許可ターゲットのARのIPv4アドレスを学習します。 DHCP（Dynamic Host Configuration Protocol）を使用して、各ホストについて、EANは、ARのIPv4ホスト[RFC2131]にDHCPACK応答をスヌーピングによって動的にアドレスを学習します。 DHCPを使用して、ホストが複数のARへの同時アクセスを持たなければならない場合は、DHCPオプション121 [RFC3442]またはDHCPオプション33 [RFC2132]はそのホストのためにそれらを指定するために使用する必要があります。静的アドレスの割り当ては、代わりにDHCPを使用する場合、AR IPv4アドレスは、ネットワークオペレータによってEANに予めプロビジョニングされなければなりません。どちらの場合も、EANは、ARを対応するMACアドレスを決定するためにARPを実行します。これは、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は、顧客ホスト[RFC3046]から上流に流れるDHCPメッセージ内のDHCPサーバに、加入者回線識別子を伝えるためにDHCPリレーエージェント情報オプション（82）を使用している場合、DHCPサーバは、加入者線を顧客ホストを関連付けることができます。
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応答が送信され、要求されたレイヤ2宛先アドレスとして許容AR MACアドレス（典型的には、デフォルトゲートウェイの）を指定し、説明した「プロキシARP」機構と同様に[RFC1812]インチこのように、要求ホストのARPテーブルは、IPv4サブネット内の任意のホストのレイヤ2宛先としてAR MACアドレスを登録します（同じ顧客宅内におけるものを除くと、以下を参照のこと）。
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のそのARのMACアドレスを持つARPプロキシではなく、デフォルトゲートウェイの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に達した場合、構内ネットワーク内のターゲットホストが直接回答することを想定されているので、それは、破棄されなければなりません。それはこれらのARP要求を検出し、それらを捨てることができるようにEANは加入者線に割り当てられているすべてのIPv4アドレスを追跡する必要があります。
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アドレスを返信させていただきますので、要求しているホストは、他の構内にあるhostsの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ブロードキャストパケットを廃棄しなければならない場合には、EANは、クライアントからサーバーへのDHCPブロードキャストメッセージ（DHCPDISCOVER、DHCPREQUEST、DHCPDECLINE、DHCPINFORM）[RFC2131]を転送する必要があり、DHCPを使用している場合を除き、加入者回線上で受信上流の。 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アップリンクで転送ブロードキャストパケットをアグリゲーションネットワークによって他のEANSに転送されてもよいです。 DHCPが使用されているときEANSは、加入者のホストとサーバからクライアントへのDHCPメッセージ（DHCPOFFER、DHCPACK、DHCPNAK）[RFC2131]のためのARからのARPを除き、アグリゲーションネットワークから受信した全てのブロードキャストパケットを破棄すべきです。
Filtering of multicast packets to and from an EAN uplink is discussed in Section 6.
EANアップリンクへとからマルチキャストパケットのフィルタリングは、セクション6で説明されています。
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節）は、顧客のホストが1つのまたはそれ以上のARへの直接レイヤ2接続を許可されている方法を説明します。同様に、顧客のホストが直接アグリゲーションネットワークに接続された1台の以上のアプリケーションサーバ（のAS）に直接レイヤ2アクセスを許可することができます。 MAC-強制転送扱いはのARとのASにアクセスする方法には機能的な違いはありません。
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]になります。この動作を回避するには、アグリゲーションネットワークインターフェイスのICMPリダイレクト機能がARに無効にする必要があります。
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.
MAC-強制フォワーディングの動作が妨害または持続的なARの障害発生時にIP接続の回復を遅らせることはありません。 ARの冗長性を実現するために複数の冗長のARに関する情報、又は仮想ルータ冗長プロトコル（VRRP）を使用する[RFC3768]とホストを設定するためにDHCPを使用すると、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は、加入者線を介して到達することができる顧客のホスト、およびそれらのホストに関連付けられたアクセスルータの状態情報で事前プロビジョニングされなければなりません。過渡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（S）または顧客のホストのいずれかによって検出されなくてもよいです。したがって、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].
マルチキャストトラフィックアグリゲーションネットワーク内の発信ストリームの送達またはさらに上流及びアクセスネットワーク内の1つのまたは複数の顧客ホストに配信は、イーサネットのネイティブマルチキャスト能力のおかげでスケーラブルな方法で支持されています。 EANは、IGMPスヌーピングブリッジとして動作している場合、帯域幅の効率を向上させることができます。例えば、それは特定のマルチキャストグループを転送するための加入者回線のセットを剪定する加入者回線から発信IGMPメンバーシップレポートとのLeave Groupメッセージ[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メンバーシップレポートとのLeave Groupメッセージ[RFC3376]以外の加入者回線で受信すべてのIPv4マルチキャストパケットを破棄しなければなりません。顧客ホストグループ、マルチキャストルータにそれらを上流のホスト必須トンネルにマルチキャストパケットをソースすることを望む場合。例えば、プロトコル独立マルチキャストとして動作する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アクセスネットワークなどのアドレス割り当ての同じ効率を必要としません。顧客構内ネットワークは、顧客のサブネットとホストの多数[v6BB]を収容する（例えば、/ 48）固有のネットワークプレフィックスを割り当てられることが予想されます。
2. IPv6 nodes do not use ARP, but instead use the Neighbor Discovery Protocol [RFC2461] for layer-2 address resolution.
2. IPv6ノードは、ARPを使用して、その代わりにレイヤ2アドレス解決のために近隣探索プロトコル[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アドレスを学習する必要があります。これは、顧客宅内ルータと1つまたは複数のAR [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強制転送は、ブロードキャストアクセス媒体を共有する顧客ホストのレイヤ2のアイソレーションを確保する、その性質上、セキュリティ機能です。その意味で、それは代替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への単離、有効なDHCPメッセージを除いて、すべてのアップストリームブロードキャストパケットを廃棄しなければならないMAC強制転送を実現EAN、及び（EANによってプロキシされる）ARP要求を。
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.
作者は彼らの役に立つコメントをウルフ・ヨンソン、トーマスNarten氏、ジェームズ・カールソン、ロルフEngstrand、トマスThyni、とヨハンKolhiに感謝したいと思います。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792]ポステル、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]プラマー、D.、「イーサネットアドレス解決プロトコル：またはイーサネットハードウェア上で送信するためのイーサネットアドレスを48ビットに、ネットワーク・プロトコル・アドレス変換」、STD 37、RFC 826、1982年11月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132]アレクサンダー、S.とR. Droms、 "DHCPオプションとBOOTPベンダー拡張機能"、RFC 2132、1997年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.、ファリナッチ、D.、Helmy、A.、ターラー、D.、デアリング、S.、ハンドレー、M.、ヤコブソン、V.、劉、C.、シャルマ、P.、およびL 。魏、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様"、RFC 2362、1998年6月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046]パトリック、M.、 "DHCPリレーエージェント情報オプション"、RFC 3046、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]カイン、B.、デアリング、S.、Kouvelas、I.、フェナー、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]レモン、T.、チェシャー、S.、およびB.フォルツ、RFC 3442 "動的ホスト構成プロトコル（DHCP）バージョン4のためのクラスレス静的ルートオプション"、2002年12月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]ベイカー、F.、RFC 1812、1995年6月 "IPバージョン4つのルータのための要件"。
[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.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、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.、カレル、D.、シモン、D.、およびR.ウィーラー、 "PPPオーバーイーサネット（PPPoEを）送信するための方法"、RFC 2516年2月1999。
[RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for Efficient IP Address Allocation", RFC 3069, February 2001.
"効率的なIPアドレス割り当てのためのVLAN集計" [RFC3069]マクファーソン、D.とB.ダイクス、RFC 3069、2001年2月。
[TR101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation", Technical Report TR-101, April 2006.
[TR101] DSLフォーラム、 "イーサネットベースのDSLアグリゲーションへの移行"、テクニカルレポートTR101、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.、アーメド、A.、Popoviciu、C.、Savola、P.、およびJ. Palet、 "ブロードバンドアクセスネットワークにおけるISPのIPv6展開シナリオ"、ProgressのWork。
Authors' Addresses
著者のアドレス
Torben Melsen Ericsson Faelledvej Struer DK-7600 Denmark
トーベンMelsenエリクソンFaelledvejステュアーDK-7600デンマーク
EMail: Torben.Melsen@ericsson.com
メールアドレス：Torben.Melsen@ericsson.com
Steven Blake Ericsson 920 Main Campus Drive Suite 500 Raleigh, NC 27606 USA
スティーブ・ブレイク・エリクソン920メインキャンパスドライブスイート500ローリー、NC 27606 USA
Phone: +1 919 472 9913 EMail: steven.blake@ericsson.com
電話：+1 919 472 9913 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。