[要約] RFC 7436は、IP-Only LAN Service（IPLS）の要約と目的を説明しています。IPLSは、IPベースのローカルエリアネットワーク（LAN）サービスを提供するためのプロトコルです。このRFCは、IPLSの概要と設計目標を提供しています。
Internet Engineering Task Force (IETF) H. Shah
Request for Comments: 7436 Cinea Corp.
Category: Historic E. Rosen
ISSN: 2070-1721 Juniper Networks
F. Le Faucheur
G. Heron
Cisco Systems
January 2015
IP-Only LAN Service (IPLS)
IP専用LANサービス（IPLS）
Abstract
概要
A Virtual Private LAN Service (VPLS) is used to interconnect systems across a wide-area or metropolitan-area network, making it appear that they are on a private LAN. The systems that are interconnected may themselves be LAN switches. If, however, they are IP hosts or IP routers, certain simplifications to the operation of the VPLS are possible. We call this simplified type of VPLS an "IP-only LAN Service" (IPLS). In an IPLS, as in a VPLS, LAN interfaces are run in promiscuous mode, and frames are forwarded based on their destination Media Access Control (MAC) addresses. However, the maintenance of the MAC forwarding tables is done via signaling, rather than via the MAC address learning procedures specified in the IEEE's "Media Access Control (MAC) Bridges". This document specifies the protocol extensions and procedures for support of the IPLS service.
仮想プライベートLANサービス（VPLS）は、広域ネットワークまたはメトロポリタンエリアネットワーク全体でシステムを相互接続するために使用され、それらがプライベートLAN上にあるように見せます。相互接続されているシステム自体がLANスイッチである場合があります。ただし、それらがIPホストまたはIPルーターである場合、VPLSの操作に特定の簡略化が可能です。この単純化されたタイプのVPLSを「IP専用LANサービス」（IPLS）と呼びます。 IPLSでは、VPLSと同様に、LANインターフェイスは混合モードで実行され、フレームは宛先のメディアアクセス制御（MAC）アドレスに基づいて転送されます。ただし、MAC転送テーブルの保守は、IEEEの「Media Access Control（MAC）Bridges」で指定されているMACアドレス学習手順ではなく、シグナリングを介して行われます。このドキュメントでは、IPLSサービスをサポートするためのプロトコル拡張と手順を指定します。
The original intent was to provide an alternate solution to VPLS for those Provider Edge (PE) routers that were not capable of learning MAC addresses through data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and it is published simply as a historic record of the ideas.
当初の目的は、データプレーンを介してMACアドレスを学習できないプロバイダーエッジ（PE）ルーターに対して、VPLSの代替ソリューションを提供することでした。これは、新しいハードウェアでは問題にはなりませんでした。このドキュメントで提示された概念は依然として価値があり、L2VPNワーキンググループのイーサネットVPNや考えられるデータセンターアプリケーションなどの新しい研究によって、何らかの形で採用されています。現時点では、このドキュメントを更新するための追加のアクションは計画されておらず、アイデアの歴史的記録として公開されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for the historical record.
このドキュメントはInternet Standards Trackの仕様ではありません。歴史的な記録として掲載されています。
This document defines a Historic Document for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットコミュニティの歴史的ドキュメントを定義しています。このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7436.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7436で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview ........................................................4
1.1. Terminology ................................................7
2. Topology ........................................................9
3. Configuration ..................................................10
4. Discovery ......................................................10
4.1. CE Discovery ..............................................10
4.1.1. IPv4-Based CE Discovery ............................11
4.1.2. IPv6-Based CE Discovery (RFC 4861) .................11
5. PW Creation ....................................................11
5.1. Receive Unicast Multipoint-to-Point PW ....................11
5.2. Receive Multicast Multipoint-to-Point PW ..................12
5.3. Send Multicast Replication Tree ...........................13
6. Signaling ......................................................13
6.1. IPLS PW Signaling .........................................13
6.2. IPv6 Capability Advertisement .............................17
6.3. Signaling Advertisement Processing ........................18
7. IANA Considerations ............................................19
7.1. LDP Status Messages .......................................19
7.2. Interface Parameters ......................................19
8. Forwarding .....................................................20
8.1. Non-IP or Non-ARP Traffic .................................20
8.2. Unicast IP Traffic ........................................20
8.3. Broadcasts and Multicast IP Traffic .......................20
8.4. ARP Traffic ...............................................21
8.5. Discovery of IPv6 CE Devices ..............................21
8.5.1. Processing of Neighbor Solicitations ...............22
8.5.2. Processing of Neighbor Advertisements ..............22
8.5.3. Processing of Inverse Neighbor
Solicitations and Advertisement ....................22
8.5.4. Processing of Router Solicitations and
Advertisements .....................................23
8.6. Encapsulation .............................................23
9. Attaching to IPLS via ATM or Frame Relay (FR) ..................24
10. VPLS vs. IPLS .................................................24
11. IP Protocols ..................................................25
12. Dual-Homing with IPLS .........................................25
13. Proxy ARP Function ............................................26
13.1. ARP Proxy - Responder ....................................26
13.2. ARP Proxy - Generator ....................................26
14. Data Center Applicability .....................................27
15. Security Considerations .......................................27
15.1. Control-Plane Security ...................................27
15.2. Data-Plane Security ......................................28
16. References ....................................................29
16.1. Normative References .....................................29
16.2. Informative References ...................................30
Acknowledgements ..................................................31
Contributors ......................................................31
Authors' Addresses ................................................32
As emphasized in [RFC4762], Ethernet has become popular as an access technology in metropolitan- and wide-area networks. [RFC4762] describes how geographically dispersed customer LANs can be interconnected over a service provider's network. The VPLS service is provided by Provider Edge (PE) devices that connect Customer Edge (CE) devices. The VPLS architecture provides this service by incorporating bridging functions such as MAC address learning in the PE devices.
[RFC4762]で強調されているように、イーサネットはメトロポリタンおよびワイドエリアネットワークのアクセステクノロジーとして人気を博しています。 [RFC4762]は、地理的に分散した顧客LANをサービスプロバイダーのネットワークを介して相互接続する方法を説明しています。 VPLSサービスは、カスタマーエッジ（CE）デバイスを接続するプロバイダーエッジ（PE）デバイスによって提供されます。 VPLSアーキテクチャは、PEデバイスにMACアドレスラーニングなどのブリッジング機能を組み込むことにより、このサービスを提供します。
PE platforms are designed primarily to be IP routers rather than LAN switches. To add VPLS capability to a PE router, one has to add MAC-address-learning capabilities, along with aging and other mechanisms native to Ethernet switches [IEEE802.1D]. This may be fairly complex to add to the forwarding-plane architecture of an IP router. As discussed in [RFC4664], in scenarios where the CE devices are NOT LAN switches, but rather are IP hosts or IP routers, it is possible to provide the VPLS service without requiring MAC address learning and aging on the PE. Instead, a PE router has to have the capability to match the destination MAC address in a packet received from a CE to an outbound pseudowire (PW). The requirements for the IPLS service are described in [RFC4665]. The purpose of this document is to specify a solution optimized for IPLS.
PEプラットフォームは、主にLANスイッチではなくIPルーターとして設計されています。 VPLS機能をPEルーターに追加するには、MACアドレス学習機能と、イーサネットスイッチに固有のエージングおよび他のメカニズム[IEEE802.1D]を追加する必要があります。これは、IPルーターの転送プレーンアーキテクチャに追加するのがかなり複雑になる場合があります。 [RFC4664]で説明されているように、CEデバイスがLANスイッチではなく、IPホストまたはIPルーターであるシナリオでは、PEでMACアドレスの学習とエージングを必要とせずにVPLSサービスを提供できます。代わりに、PEルータには、CEから受信したパケットの宛先MACアドレスを発信疑似配線（PW）に照合する機能が必要です。 IPLSサービスの要件は、[RFC4665]で説明されています。このドキュメントの目的は、IPLSに最適化されたソリューションを指定することです。
IPLS provides a VPLS-like service using PE routers that are not designed to perform general LAN bridging functions. One must be willing to accept the restriction that an IPLS be used for IP traffic only, and not used to interconnect CE devices that are themselves LAN switches. This is an acceptable restriction in many environments, given that IP is the predominant type of traffic in today's networks.
IPLSは、一般的なLANブリッジ機能を実行するように設計されていないPEルーターを使用して、VPLSのようなサービスを提供します。 IPLSはIPトラフィックにのみ使用され、LANスイッチであるCEデバイスの相互接続には使用されないという制限を受け入れることをいとわない必要があります。今日のネットワークではIPが主流のトラフィックであるため、これは多くの環境で許容できる制限です。
The original intent was to provide an alternate solution to VPLS for those PE routers that were not capable of learning MAC addresses in the data plane. This became a non-issue with newer hardware. The concepts put forth by this document are still valuable and are adopted in one form or other by newer work such as Ethernet VPN in the L2VPN working group and possible data center applications. At this point, no further action is planned to update this document and is published simply as a historic record of the ideas.
当初の目的は、データプレーンでMACアドレスを学習できないPEルーターに対して、VPLSの代替ソリューションを提供することでした。これは、新しいハードウェアでは問題にはなりませんでした。このドキュメントで提示された概念は依然として価値があり、L2VPNワーキンググループのイーサネットVPNや可能なデータセンターアプリケーションなどの新しい成果によって、何らかの形で採用されています。現時点では、このドキュメントを更新するためのさらなるアクションは計画されておらず、単にアイデアの歴史的な記録として公開されています。
In IPLS, a PE device implements multipoint LAN connectivity for IP traffic using the following key functions:
IPLSでは、PEデバイスは、次の主要機能を使用して、IPトラフィックのマルチポイントLAN接続を実装します。
1. CE Address Discovery: Each PE device discovers the MAC address of the locally attached CE IP devices, for each IPLS instance configured on the PE device. In some configurations, the PE also learns the IP address of the CE device (when performing ARP proxy functions, described later in the document).
1. CEアドレスの検出：各PEデバイスは、PEデバイスに構成されているIPLSインスタンスごとに、ローカルに接続されたCE IPデバイスのMACアドレスを検出します。一部の構成では、PEはCEデバイスのIPアドレスも学習します（このドキュメントで後述するARPプロキシ機能を実行する場合）。
2. Pseudowire (PW) for Unicast Traffic: For each locally attached CE device in a given IPLS instance, a PE device sets up a pseudowire (PW) to each of the other PEs that supports the same IPLS instance.
2. ユニキャストトラフィックの疑似配線（PW）：特定のIPLSインスタンスでローカルに接続されたCEデバイスごとに、PEデバイスは、同じIPLSインスタンスをサポートする他の各PEへの疑似配線（PW）を設定します。
For instance, if PEx and PEy both support IPLS I, and PEy is locally attached to CEa and CEb, PEy will initiate the setup of two PWs between itself and PEx. One of these will be used to carry unicast traffic from any of PEx's CE devices to CEa. The other will be used to carry unicast traffic from any of PEx's CE devices to CEb.
たとえば、PExとPEyの両方がIPLS Iをサポートし、PEyがローカルにCEaとCEbに接続されている場合、PEyはそれ自体とPEx間の2つのPWのセットアップを開始します。これらの1つは、PExのCEデバイスのいずれかからCEaにユニキャストトラフィックを伝送するために使用されます。もう1つは、PExのCEデバイスからCEbへのユニキャストトラフィックの伝送に使用されます。
Note that these PWs carry traffic only in one direction. Further, while the PW implicitly identifies the destination CE of the traffic, it does not identify the source CE; packets from different source CEs bound to the same destination CE are sent on a single PW.
これらのPWは一方向にのみトラフィックを伝送することに注意してください。さらに、PWは暗黙的にトラフィックの宛先CEを識別しますが、送信元CEを識別しません。同じ宛先CEにバインドされた異なる送信元CEからのパケットは、単一のPWで送信されます。
3. Pseudowires for Multicast Traffic: In addition, every PE supporting a given IPLS instance will set up a special 'multicast' pseudowire to every other PE in that IPLS instance. If, in the above example, one of PEx's CE devices sends a multicast packet, PEx would forward the multicast packet to PEy on the special 'multicast' pseudowire. PEy would then send a copy of that packet to CEa and a copy to CEb.
3. マルチキャストトラフィックの疑似配線：さらに、特定のIPLSインスタンスをサポートするすべてのPEは、そのIPLSインスタンス内の他のすべてのPEへの特別な「マルチキャスト」疑似配線をセットアップします。上記の例で、PExのCEデバイスの1つがマルチキャストパケットを送信する場合、PExはマルチキャストパケットを特別な「マルチキャスト」疑似配線上のPEyに転送します。次に、PEyはそのパケットのコピーをCEaに、コピーをCEbに送信します。
The 'multicast' pseudowire carries Ethernet frames of multicast/broadcast IP, ARP, and ICMP (Inverse) Neighbor Discovery (ND/IND) packets for IPv6. Thus, when a PE sends a multicast packet across the network, it sends one copy to each remote PE (supporting the given IPLS instance). If a particular remote PE has more than one CE device in that IPLS instance, the remote PE must replicate the packet and send one copy to each of its local CEs.
「マルチキャスト」疑似配線は、IPv6のマルチキャスト/ブロードキャストIP、ARP、およびICMP（逆）近隣探索（ND / IND）パケットのイーサネットフレームを伝送します。したがって、PEがネットワークを介してマルチキャストパケットを送信すると、1つのコピーが各リモートPE（指定されたIPLSインスタンスをサポート）に送信されます。特定のリモートPEがそのIPLSインスタンスに複数のCEデバイスを持っている場合、リモートPEはパケットを複製し、1つのコピーを各ローカルCEに送信する必要があります。
As with the pseudowires that are used for unicast traffic, packets travel in only one direction on these pseudowires, and packets from different sources may be freely intermixed.
ユニキャストトラフィックに使用される疑似配線と同様に、パケットはこれらの疑似配線上で一方向にのみ移動し、異なるソースからのパケットは自由に混合できます。
4. Signaling: The necessary pseudowires can be set up and maintained using the signaling procedures based on the Label Distribution Protocol (LDP) described in [RFC4447].
4. シグナリング：[RFC4447]で説明されているラベル配布プロトコル（LDP）に基づくシグナリング手順を使用して、必要な疑似配線を設定および維持できます。
A PE may assign the same label to each of the unicast pseudowires that lead to a given CE device, in effect creating a multipoint-to-point pseudowire.
PEは、特定のCEデバイスにつながるユニキャスト疑似配線のそれぞれに同じラベルを割り当てることができ、事実上、マルチポイントツーポイント疑似配線を作成します。
Similarly, a PE may assign the same label to each of the 'multicast' pseudowires for a given IPLS instance, in effect creating a multipoint-to-point pseudowire. When setting up a pseudowire to be used for unicast traffic, the PE must also signal the MAC address of the corresponding CE device. It should also, optionally, advertise the IP address of the local CE device, especially when ARP proxy function is configured or simply for operational management purposes. Similarly, for IPv6 support, PE may optionally advertise the IPv6 addresses of the local CE device.
同様に、PEは、特定のIPLSインスタンスの「マルチキャスト」疑似配線のそれぞれに同じラベルを割り当てることができ、事実上、マルチポイントツーポイント疑似配線を作成します。ユニキャストトラフィックに使用する疑似配線を設定する場合、PEは対応するCEデバイスのMACアドレスにも通知する必要があります。また、オプションで、特にARPプロキシ機能が構成されている場合、または単に運用管理目的である場合に、ローカルCEデバイスのIPアドレスをアドバタイズする必要もあります。同様に、IPv6サポートの場合、PEはオプションでローカルCEデバイスのIPv6アドレスをアドバタイズできます。
5. ARP Packet Forwarding: ARP packets [RFC826] are forwarded from the attachment circuit (AC) to 'multicast' pseudowires in the Ethernet frame format as described by [RFC4448]. The following rules are observed when processing ARP packets:
5. ARPパケット転送：ARPパケット[RFC826]は、[RFC4448]で説明されているように、アタッチメント回路（AC）からイーサネットフレーム形式の「マルチキャスト」疑似配線に転送されます。 ARPパケットの処理時には、次のルールが守られます。
a. Both broadcast (request) and unicast (response) ARP packets are sent over the 'multicast' pseudowire.
a. ブロードキャスト（要求）とユニキャスト（応答）の両方のARPパケットは、「マルチキャスト」疑似配線を介して送信されます。
b. When an ARP packet is received from an AC, the packet is copied to the control plane for the purpose of learning the MAC address of the CE. Optionally, an IP address is also learned to record the association of the IP and MAC address.
b. ACからARPパケットを受信すると、CEのMACアドレスを学習する目的で、パケットがコントロールプレーンにコピーされます。オプションで、IPアドレスとMACアドレスの関連付けを記録するためにIPアドレスも学習されます。
c. All Ethernet packets, including ARP packets, received from the 'multicast' pseudowire are forwarded out to all the ACs associated with the IPLS instance. These packets are not copied to the control plane.
c. 「マルチキャスト」疑似配線から受信したすべてのイーサネットパケット（ARPパケットを含む）は、IPLSインスタンスに関連付けられているすべてのACに転送されます。これらのパケットはコントロールプレーンにコピーされません。
6. ICMP IPv6 ND/IND-related Packet Forwarding: ND/IND IPv6 packets from an AC are replicated and a copy is sent to other ACs and to 'multicast' PWs associated with the IPLS instance in the native Ethernet format, unchanged. A copy is also submitted to the control plane to learn the MAC address and, optionally, corresponding IPv6 addresses.
6. ICMP IPv6 ND / IND関連のパケット転送：ACからのND / IND IPv6パケットは複製され、コピーは他のACと、ネイティブイーサネット形式のIPLSインスタンスに関連付けられた「マルチキャスト」PWに変更されずに送信されます。コピーは、MACアドレスと、オプションで対応するIPv6アドレスを学習するために、コントロールプレーンにも送信されます。
7. Multicast IP packet forwarding: An IP Ethernet frame received from an AC is replicated to other ACs and the 'multicast' PWs associated with the IPLS instance. An IP Ethernet frame received from a 'multicast' PW is replicated to all the egress ACs associated with the IPLS instance.
7. マルチキャストIPパケット転送：ACから受信したIPイーサネットフレームは、他のACおよびIPLSインスタンスに関連付けられた「マルチキャスト」PWに複製されます。 「マルチキャスト」PWから受信したIPイーサネットフレームは、IPLSインスタンスに関連付けられたすべての出力ACに複製されます。
8. Unicast IP packet forwarding: An IP packet received from the AC is forwarded based on the destination MAC address lookup in the forwarding table. If a match is found, the packet is forwarded to the associated egress interface. If the egress interface is unicast PW, the packet is sent without a MAC header. If the egress interface is a local AC, the Ethernet frame is forwarded as such. An IP packet received from the unicast PW is forwarded to the egress AC with the MAC header prepended. The destination MAC address is derived from the forwarding table while the source MAC address is the MAC address of the PE.
8. ユニキャストIPパケット転送：ACから受信したIPパケットは、転送テーブルの宛先MACアドレス検索に基づいて転送されます。一致が見つかった場合、パケットは関連付けられた出力インターフェイスに転送されます。出力インターフェイスがユニキャストPWの場合、パケットはMACヘッダーなしで送信されます。出力インターフェイスがローカルACの場合、イーサネットフレームはそのまま転送されます。ユニキャストPWから受信したIPパケットは、MACヘッダーを前に付けて出力ACに転送されます。宛先MACアドレスは転送テーブルから取得され、送信元MACアドレスはPEのMACアドレスです。
Both VPLS [RFC4762] and IPLS require the ingress PE to forward a frame based on its destination MAC address. However, two key differences between VPLS and IPLS can be noted from the above description:
VPLS [RFC4762]とIPLSの両方で、その宛先MACアドレスに基づいてフレームを転送するために、入力PEが必要です。ただし、VPLSとIPLSの2つの重要な違いは、上記の説明から確認できます。
- In VPLS, MAC entries are placed in the Forwarding Information Base (FIB) of the ingress PE as a result of MAC address learning (which occurs in the data plane); whereas, in IPLS, MAC entries are placed in the FIB as a result of PW signaling operations (control plane).
- VPLSでは、MACアドレス学習（データプレーンで発生）の結果として、MACエントリが入力PEの転送情報ベース（FIB）に配置されます。一方、IPLSでは、PWシグナリング操作（コントロールプレーン）の結果として、MACエントリがFIBに配置されます。
- In VPLS, the egress PE looks up a frame's destination MAC address to determine the egress AC; in IPLS, the egress AC is determined entirely by the ingress PW label.
- VPLSでは、出力PEはフレームの宛先MACアドレスを検索して、出力ACを決定します。 IPLSでは、出力ACは完全に入力PWラベルによって決定されます。
The following sections describe the details of the IPLS scheme.
次のセクションでは、IPLSスキームの詳細について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
IPLS IPLS stands for IP-only LAN service (a type of Virtual Private LAN Service that is restricted to IP traffic only).
IPLS IPLSは、IP専用LANサービス（IPトラフィックのみに制限される一種の仮想プライベートLANサービス）を表します。
MP2P PW A Multipoint-to-Point Pseudowire is a PW that carries traffic from remote PE devices to a PE device that signals the PW. The signaling PE device advertises the same PW label to all remote PE devices that participate in the IPLS service instance. In IPLS, for a given IPLS instance, an MP2P PW used for IP unicast traffic is established by a PE for each CE device locally attached to that PE. It is a unidirectional tree whose leaves consist of the remote PE peers (which connect at least one AC associated with the same IPLS instance) and whose root is the signaling PE. Traffic flows from the leaves towards the root.
MP2P PWマルチポイントツーポイント疑似配線は、リモートPEデバイスからPWに信号を送るPEデバイスにトラフィックを運ぶPWです。シグナリングPEデバイスは、IPLSサービスインスタンスに参加するすべてのリモートPEデバイスに同じPWラベルをアドバタイズします。 IPLSでは、特定のIPLSインスタンスに対して、IPユニキャストトラフィックに使用されるMP2P PWは、そのPEにローカルに接続されている各CEデバイスのPEによって確立されます。これは、リーフがリモートPEピア（同じIPLSインスタンスに関連付けられた少なくとも1つのACを接続する）で構成され、ルートがシグナリングPEである単方向ツリーです。トラフィックはリーフからルートに向かって流れます。
Multicast PW A Multicast/broadcast Pseudowire is a special kind of MP2P PW that carries IP multicast/broadcast traffic, all ARP frames and ICMP (I)ND frames for IPv6. In the IPLS architecture, for each IPLS instance supported by a PE, that PE device establishes exactly one multicast PW. Multicast PW uses Ethernet encapsulation.
マルチキャストPWマルチキャスト/ブロードキャスト疑似配線は、IPマルチキャスト/ブロードキャストトラフィック、すべてのARPフレーム、およびIPv6のICMP（I）NDフレームを伝送する特別な種類のMP2P PWです。 IPLSアーキテクチャでは、PEによってサポートされるIPLSインスタンスごとに、そのPEデバイスは1つのマルチキャストPWを確立します。マルチキャストPWはイーサネットカプセル化を使用します。
Unicast PW A Unicast pseudowire carries IP unicast packets. A PE creates unicast PW for each locally attached CE. The unicast PW uses IP Layer 2 (L2) transport encapsulation.
ユニキャストPWユニキャスト疑似配線は、IPユニキャストパケットを伝送します。 PEは、ローカルに接続されたCEごとにユニキャストPWを作成します。ユニキャストPWは、IPレイヤー2（L2）トランスポートカプセル化を使用します。
CE In this document, a Customer Edge (CE) is any IP node (host or router) connected to the IPLS LAN service.
CEこのドキュメントでは、カスタマーエッジ（CE）は、IPLS LANサービスに接続された任意のIPノード（ホストまたはルーター）です。
Send The collection of all multicast PWs and ACs Multicast that are members of an IPLS service instance on a Replication given PE. When a PE receives a multicast/broadcast Tree packet from an AC, the PE device sends a copy of the packet to every multicast PW and AC of the Send Multicast Replication Tree, excluding the AC on which the packet was received. When a PE receives a packet from a multicast PW, the PE device sends a copy of the packet to all the ACs of the Send Multicast Replication Tree and never to other PWs.
送信指定されたPEのレプリケーション上のIPLSサービスインスタンスのメンバーであるすべてのマルチキャストPWおよびACマルチキャストのコレクション。 PEがACからマルチキャスト/ブロードキャストツリーパケットを受信すると、PEデバイスは、パケットが受信されたACを除いて、送信マルチキャストレプリケーションツリーのすべてのマルチキャストPWおよびACにパケットのコピーを送信します。 PEがマルチキャストPWからパケットを受信すると、PEデバイスはパケットのコピーを送信マルチキャストレプリケーションツリーのすべてのACに送信し、他のPWには送信しません。
(I)ND (Inverse) Neighbor Discovery in IPv6 uses ICMP Neighbor Solicitation (NS) and Neighbor Advertisement (NA) packets.
（I）ND（逆）IPv6での近隣探索は、ICMP近隣要請（NS）および近隣アドバタイズ（NA）パケットを使用します。
RS Router Solicitation is when hosts generate all-routers multicast ICMP packets to discover the IPv6 router on the local link.
RSルーター要請は、ローカルリンク上のIPv6ルーターを検出するために、ホストが全ルーターマルチキャストICMPパケットを生成する場合です。
RA Router Advertisement occurs when a router generates all-nodes multicast ICMP packets to advertise its presence on the link. A unicast response is also sent when RS is received.
RAルーターアドバタイズは、ルーターが全ノードマルチキャストICMPパケットを生成してリンク上に存在をアドバタイズするときに発生します。 RSを受信すると、ユニキャスト応答も送信されます。
NS Neighbor Solicitation in IPv6 uses (multicast) ICMP packets to resolve the association of the IPv6 interface address to the MAC address.
IPv6のNS近隣要請は、（マルチキャスト）ICMPパケットを使用して、IPv6インターフェースアドレスとMACアドレスの関連付けを解決します。
NA Neighbor Advertisement in IPv6 uses (unicast) ICMP packets to respond to NS.
IPv6のNAネイバーアドバタイズメントは、（ユニキャスト）ICMPパケットを使用してNSに応答します。
The CE devices are IP nodes (hosts or routers) that are connected to PE devices either directly or via an Ethernet network. We assume that the PE/CE connection may be regarded by the PE as an "interface" to which one or more CEs are attached. This interface may be a physical LAN interface or a VLAN. The PE routers are MPLS Label Edge Routers (LERs) that serve as PW endpoints.
CEデバイスは、直接またはイーサネットネットワーク経由でPEデバイスに接続されるIPノード（ホストまたはルーター）です。 PE / CE接続は、PEによって、1つ以上のCEが接続されている「インターフェース」と見なされると想定します。このインターフェースは、物理LANインターフェースまたはVLANの場合があります。 PEルータは、PWエンドポイントとして機能するMPLSラベルエッジルータ（LER）です。
+----+ +----+
+ S1 +---+ ........................... +---| S2 |
+----+ | | . . | +----+
IPa | | +----+ +----+ | IPe
+ +---| PE1|---MPLS and/or IP---| PE2|---+
/ \ +----+ |Network +----+ |
+----+ +---+ . | . | +----+
+ S1 + | S1| . +----+ . +---| S2 |
+----+ +---+ ..........| PE3|........... +----+
IPb IPc +----+ IPf
|
|
+----+
| S3 |
+----+
IPd
In the above diagram, an IPLS instance is shown with three sites: site S1, site S2, and site S3. In site S3, the CE device is directly connected to its PE. In the other two sites, there are multiple CEs connected to a single PE. More precisely, the CEs at these sites are on an Ethernet (switched at site 1 and shared at site 2) network (or VLAN), and the PE is attached to that same Ethernet network or VLAN). We impose the following restriction: if one or more CEs attach to a PE by virtue of being on a common LAN or VLAN, there MUST NOT be more than one PE on that LAN or VLAN.
上の図では、サイトS1、サイトS2、およびサイトS3の3つのサイトを持つIPLSインスタンスが示されています。サイトS3では、CEデバイスはそのPEに直接接続されています。他の2つのサイトには、単一のPEに接続された複数のCEがあります。より正確には、これらのサイトのCEはイーサネット（サイト1で切り替えられ、サイト2で共有）ネットワーク（またはVLAN）上にあり、PEは同じイーサネットネットワークまたはVLANに接続されています。次の制限を課します。1つ以上のCEが共通のLANまたはVLAN上にあるためにPEに接続する場合、そのLANまたはVLAN上に複数のPEがあってはなりません。
PE1, PE2, and PE3 are shown as connected via an MPLS network; however, other tunneling technologies, such as Generic Routing Encapsulation (GRE), Layer 2 Tunneling Protocol version 3 (L2TPv3), etc., could also be used to carry the PWs.
PE1、PE2、およびPE3は、MPLSネットワーク経由で接続されているものとして示されています。ただし、Generic Routing Encapsulation（GRE）、レイヤー2トンネリングプロトコルバージョン3（L2TPv3）などの他のトンネリングテクノロジーを使用してPWを伝送することもできます。
An IPLS instance is a single broadcast domain, such that each IP end station (e.g., IPa) appears to be co-located with other IP end stations (e.g., IPb through IPf) on the same subnet. The IPLS service is transparent to the CE devices and requires no changes to them.
IPLSインスタンスは単一のブロードキャストドメインであり、各IPエンドステーション（IPaなど）は、同じサブネット上の他のIPエンドステーション（IPbからIPfなど）と同じ場所に配置されているように見えます。 IPLSサービスはCEデバイスに対して透過的であり、それらに変更を加える必要はありません。
Each PE router is configured with one or more IPLS service instances, and each IPLS service instance is associated with a unique VPN-ID. For a given IPLS service instance, a set of ACs is identified. Each AC can be associated with only one IPLS instance. An AC, in this document, is either a customer-facing Ethernet port, or a particular VLAN (identified by an IEEE 802.1Q VLAN ID) on a customer-facing Ethernet port.
各PEルータは1つ以上のIPLSサービスインスタンスで設定され、各IPLSサービスインスタンスは一意のVPN-IDに関連付けられています。特定のIPLSサービスインスタンスについて、ACのセットが識別されます。各ACは、1つのIPLSインスタンスにのみ関連付けることができます。このドキュメントでのACは、顧客に面したイーサネットポート、または顧客に面したイーサネットポート上の特定のVLAN（IEEE 802.1Q VLAN IDで識別）のいずれかです。
The PE router can optionally be configured with a local MAC address to be used as a source MAC address when IP packets are forwarded from a PW to an AC. By default, a PE uses the MAC address of the customer-facing Ethernet interface for this purpose.
PEルーターには、IPパケットがPWからACに転送されるときにソースMACアドレスとして使用されるローカルMACアドレスをオプションで構成できます。デフォルトでは、PEはこの目的のために顧客側イーサネットインターフェイスのMACアドレスを使用します。
The discovery process includes: - Remote PE discovery - VPN (i.e., IPLS) membership discovery - IP CE end station discovery
検出プロセスには以下が含まれます。-リモートPE検出-VPN（つまり、IPLS）メンバーシップの検出-IP CEエンドステーションの検出
This document does not discuss the remote PE discovery or VPN membership discovery. This information can either be user configured or can be obtained using auto-discovery techniques described in [RFC6074] or other methods. However, the discovery of the CE is an important operational step in the IPLS model and is described below.
このドキュメントでは、リモートPE検出またはVPNメンバーシップ検出については説明しません。この情報は、ユーザーが構成するか、[RFC6074]で説明されている自動検出技術または他の方法を使用して取得できます。ただし、CEの発見はIPLSモデルの重要な運用手順であり、以下で説明します。
Each PE actively detects the presence of local CEs by snooping IP and ARP frames received over the ACs. When an AC configured in an IPLS instance becomes operational, it enters the CE discovery phase. In this phase, the PE examines each multicast/broadcast Ethernet frame. For link-local IP broadcast/multicast frames (e.g., IPv4 packets with destination addresses within 224.0.0/24 [RFC5771]), the CE's (source) MAC address is extracted from the Ethernet header and the (source) IP address is obtained from the IP header.
各PEは、AC経由で受信したIPおよびARPフレームをスヌーピングすることにより、ローカルCEの存在をアクティブに検出します。 IPLSインスタンスで構成されたACが動作可能になると、CE検出フェーズに入ります。このフェーズでは、PEは各マルチキャスト/ブロードキャストイーサネットフレームを調べます。リンクローカルIPブロードキャスト/マルチキャストフレーム（たとえば、宛先アドレスが224.0.0 / 24 [RFC5771]のIPv4パケット）の場合、CEの（ソース）MACアドレスがイーサネットヘッダーから抽出され、（ソース）IPアドレスが取得されますIPヘッダーから。
For each CE, the PE maintains the following tuple: <Attachment Circuit identification info, VPN-ID, MAC address, IP address (optional)>.
各CEについて、PEは次のタプルを維持します：<接続回線識別情報、VPN-ID、MACアドレス、IPアドレス（オプション）>。
As indicated earlier, a copy of each ARP frame received over the AC is submitted to the control plane. The PE learns the MAC address and optionally the IP address of the CE from the source address fields of the ARP PDU.
前述のように、ACを介して受信された各ARPフレームのコピーがコントロールプレーンに送信されます。 PEは、ARP PDUの送信元アドレスフィールドからCEのMACアドレスとオプションでIPアドレスを学習します。
Once a CE is discovered, its status is monitored continuously by examining the received ARP frames and by periodically generating ARP requests. The absence of an ARP response from a CE after a configurable number of ARP requests is interpreted as loss of connectivity with the CE.
CEが検出されると、受信されたARPフレームを調べ、定期的にARP要求を生成することにより、CEのステータスが継続的に監視されます。構成可能な数のARP要求の後にCEからのARP応答がない場合、CEとの接続が失われたと解釈されます。
A copy of Neighbor and Router Discovery frames received over the AC are submitted to the control plane in the PE.
ACを介して受信されたネイバーおよびルータディスカバリフレームのコピーは、PEのコントロールプレーンに送信されます。
If the PE receives an NS message, and the source IP address of the message is not the unspecified address, the PE learns the MAC address and optionally the IP address of the CE.
PEがNSメッセージを受信し、メッセージの送信元IPアドレスが未指定のアドレスでない場合、PEはMACアドレスを学習し、オプションでCEのIPアドレスを学習します。
If the PE receives an unsolicited NA message, the PE learns the source MAC address and optionally the IP address of the CE.
PEが非送信請求NAメッセージを受信した場合、PEは送信元MACアドレスを学習し、オプションでCEのIPアドレスを学習します。
If the PE receives an RS, and the source IP address of the message is not the unspecified address, the PE learns source MAC address and optionally the IP address of the CE.
PEがRSを受信し、メッセージの送信元IPアドレスが未指定のアドレスでない場合、PEは送信元MACアドレスと、オプションでCEのIPアドレスを学習します。
If the PE receives an RA, it learns the source MAC address and optionally the IP address of the CE.
PEはRAを受信すると、送信元MACアドレスと、オプションでCEのIPアドレスを学習します。
The PE will periodically generate NS messages for the IP address of the CE as a means of verifying the continued existence of the address and its MAC address binding. The absence of a response from the CE device for a given number of retries could be interpreted as a loss of connectivity with the CE.
PEは、アドレスとそのMACアドレスバインディングの継続的な存在を確認する手段として、CEのIPアドレスのNSメッセージを定期的に生成します。所定の再試行回数に対するCEデバイスからの応答がない場合、CEとの接続が失われたと解釈できます。
As the PE discovers each locally attached CE, a unicast multipoint-to-point pseudowire (MP2P PW) associated exclusively with that CE is created by distributing the MAC address and optionally the IP address of the CE along with a PW label to all the remote PE peers that participate in the same IPLS instance. Note that the same value of a PW label SHOULD be distributed to all the remote PE peers for a given CE. The MP2P PW thus created is used by remote PEs to send unicast IP traffic to a specific CE.
PEがローカルに接続された各CEを検出すると、そのCEに排他的に関連付けられたユニキャストマルチポイントツーポイント疑似配線（MP2P PW）が、すべてのリモートにPWラベルとともにCEのMACアドレスとオプションでIPアドレスを配布することによって作成されます。同じIPLSインスタンスに参加するPEピア。同じ値のPWラベルが、特定のCEのすべてのリモートPEピアに配布される必要があることに注意してください。このようにして作成されたMP2P PWは、特定のCEにユニキャストIPトラフィックを送信するためにリモートPEによって使用されます。
(The same functionality can be provided by a set of point-to-point PWs, and the PE is not required to send the same PW label to all the other PEs. For convenience, however, we will use the term MP2P PWs, which may be implemented using a set of point-to-point PWs.)
（ポイントツーポイントPWのセットによって同じ機能を提供でき、PEは他のすべてのPEに同じPWラベルを送信する必要はありません。ただし、便宜上、MP2P PWという用語を使用します。ポイントツーポイントPWのセットを使用して実装できます。）
The PE forwards a frame received over this MP2P PW to the associated AC.
PEは、このMP2P PWを介して受信したフレームを関連するACに転送します。
The unicast PW uses IP Layer 2 Transport encapsulation as defined in [RFC4447].
ユニキャストPWは、[RFC4447]で定義されているIPレイヤー2トランスポートカプセル化を使用します。
When a PE is configured to participate in an IPLS instance, it advertises a 'multicast' PW label to every other PE that is a member of the same IPLS. The advertised PW label value is the same for each PE, which creates an MP2P PW. There is only one such multicast MP2P PW per PE for each IPLS instance, and this PW is used exclusively to carry IP multicast/broadcast, ARP traffic, and (inverse) Neighbor Discovery packets for IPv6 from the remote PEs to this PE for this IPLS instance.
PEがIPLSインスタンスに参加するように構成されている場合、PEは「マルチキャスト」PWラベルを同じIPLSのメンバーである他のすべてのPEにアドバタイズします。アドバタイズされたPWラベル値は各PEで同じであり、MP2P PWを作成します。各IPLSインスタンスのPEごとにそのようなマルチキャストMP2P PWは1つだけあり、このPWは、IPマルチキャスト/ブロードキャスト、ARPトラフィック、および（逆）IPv6の近隣探索パケットを、リモートPEからこのPEへのこのPEへ、このIPLSに運ぶためにのみ使用されます。インスタンス。
Note that no special functionality is expected from this PW. We call it a 'multicast' PW because we use it to carry multicast and broadcast IP, ARP, and IPv6 Neighbor Discovery traffic. The PW itself need not provide any different service than any of the unicast PWs.
このPWには特別な機能は必要ありません。マルチキャストおよびブロードキャストIP、ARP、およびIPv6近隣探索トラフィックを運ぶために使用するため、これを「マルチキャスト」PWと呼びます。 PW自体は、どのユニキャストPWとも異なるサービスを提供する必要はありません。
In particular, the Receive multicast MP2P PW does not perform any replication of frames itself. Rather, it is there to signify to the PE that the PE may need to replicate a copy of a frame received over this MP2P PW onto all the ACs that are associated with the IPLS instance of the MP2P PW.
特に、受信マルチキャストMP2P PWは、フレーム自体の複製を実行しません。むしろ、PEがこのMP2P PWを介して受信したフレームのコピーをMP2P PWのIPLSインスタンスに関連付けられているすべてのACに複製する必要がある場合があることをPEに示す必要があります。
The multicast MP2P PW is considered the principal PW in the bundle of MP2P PWs that consists of one multicast MP2P PW and a variable number of unicast MP2P PWs for a given IPLS instance. In a principal role, multicast PW represents the IPLS instance. The life of all unicast PWs in the IPLS instance depends on the existence of the multicast PW. If, for some reason, multicast PWs cease to exist, all the associated unicast PWs in the bundle would be removed.
マルチキャストMP2P PWは、1つのマルチキャストMP2P PWと、特定のIPLSインスタンスの可変数のユニキャストMP2P PWで構成されるMP2P PWのバンドルの主要なPWと見なされます。主要な役割では、マルチキャストPWはIPLSインスタンスを表します。 IPLSインスタンス内のすべてのユニキャストPWの寿命は、マルチキャストPWの存在に依存します。何らかの理由でマルチキャストPWが存在しなくなった場合は、バンドル内の関連するすべてのユニキャストPWが削除されます。
The multicast PW uses Ethernet encapsulation as defined in [RFC4448].
マルチキャストPWは、[RFC4448]で定義されているイーサネットカプセル化を使用します。
The use of PWs that are specially optimized for multicast is for further study.
マルチキャスト用に特別に最適化されたPWの使用は、今後の検討課題です。
The PE creates a Send Multicast Replication Tree for each IPLS instance, which consists of the collection of all ACs and all the 'multicast' PWs of the IPLS instance.
PEは、IPLSインスタンスごとに送信マルチキャストレプリケーションツリーを作成します。これは、すべてのACのコレクションと、IPLSインスタンスのすべての「マルチキャスト」PWで構成されます。
Any ARP, Neighbor Discovery, or broadcast/multicast IP Ethernet frame received over an AC is replicated to the other ACs and to the MP2P multicast PW of the Send Multicast Replication Tree. The Send Multicast Replication Tree deals mostly with broadcast/multicast Ethernet MAC frames. One exception to this is unicast ARP and IPv6 Neighbor Discovery frame, the processing of which is described in the following section.
ACを介して受信されたARP、近隣探索、またはブロードキャスト/マルチキャストIPイーサネットフレームは、他のACと送信マルチキャストレプリケーションツリーのMP2PマルチキャストPWに複製されます。送信マルチキャストレプリケーションツリーは、主にブロードキャスト/マルチキャストイーサネットMACフレームを扱います。これに対する1つの例外は、ユニキャストARPおよびIPv6ネイバー探索フレームです。その処理については、次のセクションで説明します。
Any Ethernet frame received over the multicast PW is replicated to all the ACs of the Send Multicast Replication Tree of the IPLS instance associated with the incoming PW label: one exception is unicast ARP and Neighbor Discovery frames used for IPv6, the processing of which is described in the following section.
マルチキャストPWを介して受信されたイーサネットフレームは、着信PWラベルに関連付けられたIPLSインスタンスの送信マルチキャストレプリケーションツリーのすべてのACに複製されます。1つの例外は、IPv6に使用されるユニキャストARPおよび近隣探索フレームで、その処理について説明します次のセクションで。
[RFC4447] uses LDP to exchange PW FECs in the Label Mapping message in a downstream unsolicited mode. The PW FEC comes in two forms; PWid and Generalized PWid FEC elements. These FEC elements define some fields that are common between them. The discussions below refer to these common fields for IPLS-related extensions. Note that the use of multipoint-to-point and unidirectional characteristics of the PW makes BGP the ideal candidate for PW FEC signaling. The use of BGP for such purposes is for future study.
[RFC4447]はLDPを使用して、ダウンストリーム非送信請求モードでラベルマッピングメッセージのPW FECを交換します。 PW FECには2つの形式があります。 PWidおよび一般化されたPWid FEC要素。これらのFEC要素は、それらの間で共通のいくつかのフィールドを定義します。以下の説明では、IPLS関連の拡張に関するこれらの共通フィールドを参照しています。 PWのマルチポイントツーポイントおよび単方向特性の使用により、BGPはPW FECシグナリングの理想的な候補になります。そのような目的でのBGPの使用は、将来の研究のためです。
An IPLS carries IP packets as payload over its unicast PWs and Ethernet frames as payload over its multicast PW. The PW type to be used for unicast PW is the IP PW, defined in [RFC4447] as IP Layer 2 Transport. The PW type to be used for multicast PW is the Ethernet PW as defined in [RFC4448]. The PW type values for these encapsulations are defined in [RFC4446].
IPLSは、ユニキャストPW上のペイロードとしてIPパケットを伝送し、マルチキャストPW上のペイロードとしてイーサネットフレームを伝送します。ユニキャストPWに使用されるPWタイプは、[RFC4447]でIPレイヤー2トランスポートとして定義されているIP PWです。マルチキャストPWに使用されるPWタイプは、[RFC4448]で定義されているイーサネットPWです。これらのカプセル化のPWタイプ値は[RFC4446]で定義されています。
When processing a received PW FEC, the PE matches the PW Id with the locally configured PW Id for the IPLS instance. If the PW type is Ethernet, the PW FEC is for multicast PWs. If the PW type is 'IP Layer 2 transport', the PW FEC is for unicast PWs.
受信したPW FECを処理するとき、PEはPW IdをIPLSインスタンスのローカルに構成されたPW Idと照合します。 PWタイプがイーサネットの場合、PW FECはマルチキャストPW用です。 PWタイプが「IPレイヤ2トランスポート」の場合、PW FECはユニキャストPW用です。
For unicast PWs, the PE must check the presence of a MAC Address TLV in the optional parameter fields of the Label Mapping message. If this parameter is absent, a Label Release message must be issued with a status code meaning "MAC Address of the CE is absent" (note: status code 0x000000XX is pending IANA allocation (see Section 7)), to reject the establishment of the unicast PW with the remote PE.
ユニキャストPWの場合、PEはラベルマッピングメッセージのオプションパラメータフィールドでMACアドレスTLVの存在を確認する必要があります。このパラメータが存在しない場合、「CEのMACアドレスが存在しない」という意味のステータスコードを含むラベルリリースメッセージを発行する必要があります（注：ステータスコード0x000000XXはIANA割り当てを保留しています（セクション7を参照））。リモートPEとのユニキャストPW。
The PE may optionally include an IP address TLV based on the user configuration for the advertising of the IP addresses of the local CE.
PEは、ローカルCEのIPアドレスをアドバタイズするためのユーザー構成に基づいて、IPアドレスTLVをオプションで含めることができます。
The processing of the Address List TLV is as follows.
アドレスリストTLVの処理は以下の通りです。
o If a PW is configured for ACs with IPv4 CEs only, the PE should advertise an Address List TLV with an Address Family type of an IPv4 address. The PE should process the IPv4 address list TLV as described in this document.
o PWがIPv4 CEのみのAC用に構成されている場合、PEはIPv4アドレスのアドレスファミリタイプを使用してアドレスリストTLVをアドバタイズする必要があります。 PEは、このドキュメントで説明されているように、IPv4アドレスリストTLVを処理する必要があります。
o If a PW is configured for ACs with both IPv4 and IPv6 CEs, the PE should advertise IPv6 capability using the procedures described in the section below.
o PWがIPv4 CEとIPv6 CEの両方を備えたAC用に構成されている場合、PEは、以下のセクションで説明されている手順を使用してIPv6機能をアドバタイズする必要があります。
o If a PE does not receive any IP Address List TLV or IPv6 capability advertisement, it MAY assume IPv4 behavior.
o PEがIPアドレスリストTLVまたはIPv6機能アドバタイズを受信しない場合、IPv4の動作を想定する場合があります。
The IPLS uses the Address List TLV as defined in [RFC5036] to signal the MAC (and optionally IP) address of the local CE. There are two TLVs defined below: the IP Address TLV and MAC Address TLV. The MAC Address TLV must be included in the optional parameter field of the Label Mapping message when establishing the unicast IP PW for IPLS.
IPLSは、[RFC5036]で定義されているアドレスリストTLVを使用して、ローカルCEのMAC（およびオプションでIP）アドレスを通知します。以下に2つのTLVが定義されています。IPアドレスTLVとMACアドレスTLVです。 IPアドレスのユニキャストIP PWを確立するとき、MACアドレスTLVをラベルマッピングメッセージのオプションのパラメーターフィールドに含める必要があります。
When configured to support a specific type of IP traffic (IPv4 or IPv6), the PE verifies the type of IP traffic the PW will carry. If there is a mismatch between the received Address Family value and the expectation of an IPLS instance to which the PW belongs, the PE must issue a Label Release message with a status code meaning "IP Address type mismatch" (status code 0x0000004A) to reject the PW establishment.
特定のタイプのIPトラフィック（IPv4またはIPv6）をサポートするように構成されている場合、PEはPWが伝送するIPトラフィックのタイプを確認します。受信したアドレスファミリ値と、PWが属するIPLSインスタンスの期待値との間に不一致がある場合、PEは、「IPアドレスタイプの不一致」を意味するステータスコード（ステータスコード0x0000004A）を含むラベルリリースメッセージを発行して拒否する必要があります。 PWの確立。
The encoding of the IP Address TLV is as follows:
IPアドレスTLVのエンコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | CE IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CE IP Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length When an Address Family is IPv4, the Length is equal to 6 bytes; 2 bytes for the Address Family and 4 bytes of IP address. The Length is 18 bytes when the Address Family is IPv6; 2 bytes for the Address Family and 16 bytes of IP address.
長さアドレスファミリがIPv4の場合、長さは6バイトです。アドレスファミリ用に2バイト、IPアドレス用に4バイト。アドレスファミリがIPv6の場合、長さは18バイトです。アドレスファミリ用に2バイト、IPアドレス用に16バイト。
Address Family Two-octet quantity containing a value from the "Address Family Numbers" registry [ADDR-IANA] that encodes the addresses contained in the Addresses field.
アドレスファミリ[アドレスファミリ番号]レジストリ[ADDR-IANA]からの値を含む2オクテットの量。アドレスフィールドに含まれるアドレスをエンコードします。
CE IP Address IP address of the CE attached to the advertising PE. The encoding of the individual address depends on the Address Family.
CE IPアドレスアドバタイジングPEに接続されたCEのIPアドレス。個々のアドレスのエンコーディングは、アドレスファミリによって異なります。
The following address encodings are defined by this version of the protocol:
次のアドレスエンコーディングは、このバージョンのプロトコルで定義されています。
Address Family Address Encoding
アドレスファミリアドレスエンコーディング
IPv4 (1) 4-octet full IPv4 address
IPv4（1）4オクテットの完全なIPv4アドレス
IPv6 (2) 16-octet full IPv6 address
IPv6（2）16オクテットの完全なIPv6アドレス
Note that more than one instance of the IP address TLV may exist, especially when support for IPv6 is configured.
特にIPv6のサポートが構成されている場合、IPアドレスTLVのインスタンスが複数存在する場合があることに注意してください。
The encoding of the MAC Address TLV is as follows:
MACアドレスTLVのエンコーディングは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0| Address List (0x0101) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Family | CE's MAC Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Length The Length field is set to a value of 8 (2 bytes for the Address Family, 6 bytes for the MAC address)
長さ長さフィールドは、8の値に設定されます（アドレスファミリでは2バイト、MACアドレスでは6バイト）。
Address Family Two-octet quantity containing a value from the "Address Family Numbers" registry [ADDR-IANA] that encodes the addresses contained in the Addresses field.
アドレスファミリ[アドレスファミリ番号]レジストリ[ADDR-IANA]からの値を含む2オクテットの量。アドレスフィールドに含まれるアドレスをエンコードします。
CE's MAC Address MAC address of the CE attached to the advertising PE. The encoding of the individual address depends on the Address Family.
CEのMACアドレスアドバタイジングPEに接続されたCEのMACアドレス。個々のアドレスのエンコーディングは、アドレスファミリによって異なります。
The following address encodings are defined by this version of the protocol:
次のアドレスエンコーディングは、このバージョンのプロトコルで定義されています。
Address Family Address Encoding
アドレスファミリアドレスエンコーディング
MAC (6) 6-octet full Ethernet MAC address
MAC（6）6オクテットのフルイーサネットMACアドレス
The IPv4 address of the CE is also supplied in the optional parameters field of the LDP Notification message along with the PW FEC. The LDP Notification message is used to signal any change in the status of the CE's IPv4 address.
CEのIPv4アドレスは、PW FECとともにLDP通知メッセージのオプションパラメータフィールドでも提供されます。 LDP通知メッセージは、CEのIPv4アドレスのステータスの変更を通知するために使用されます。
Note that Notification message does not apply to the MAC Address TLV since an update to the MAC address of the CE should result in label withdrawal followed by establishment of a new PW with a new MAC address of the CE. However, advertisement of IP address(es) of the CE is optional, and changes may become known after the establishment of unicast PW.
CEのMACアドレスを更新するとラベルが取り消され、その後にCEの新しいMACアドレスで新しいPWが確立されるため、通知メッセージはMACアドレスTLVには適用されないことに注意してください。ただし、CEのIPアドレスのアドバタイズはオプションであり、ユニキャストPWの確立後に変更が認識される可能性があります。
The encoding of the LDP Notification message is as follows.
LDP通知メッセージのエンコードは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| Notification (0x0001) | Message Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status (TLV) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address List TLV (as defined above) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PWId FEC or Generalized ID FEC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Status TLV status code is set to 0x0000002C "IP address of CE", to indicate that an IP address update follows. Since this notification does not refer to any particular message, the Message ID and Message Type fields are set to 0.
ステータスTLVステータスコードは0x0000002C "CEのIPアドレス"に設定され、IPアドレスの更新が続くことを示します。この通知は特定のメッセージを参照しないため、メッセージIDおよびメッセージタイプフィールドは0に設定されます。
The PW FEC TLV SHOULD NOT include the interface parameters as they are ignored in the context of this message.
このメッセージのコンテキストでは無視されるため、PW FEC TLVにはインターフェイスパラメータを含めないでください。
A 'Stack Capability' Interface Parameter sub-TLV is signaled by the two PEs so that they can agree which stack(s) they should be using. It is assumed, by default, that the IP PW will always be capable of carrying IPv4 packets. Thus, this capability sub-TLV is used to indicate if other stacks need to be supported concurrently with IPv4.
「スタック機能」インターフェイスパラメータサブTLVは2つのPEから通知されるため、使用するスタックを合意できます。デフォルトでは、IP PWは常にIPv4パケットを伝送できると想定されています。したがって、この機能サブTLVは、他のスタックをIPv4と同時にサポートする必要があるかどうかを示すために使用されます。
The 'Stack Capability' sub-TLV is part of the interface parameters of the PW FEC. The proposed format for the 'Stack Capability' Interface Parameter sub-TLV is as follows:
「スタック機能」サブTLVは、PW FECのインターフェイスパラメータの一部です。 「Stack Capability」インターフェイスパラメータサブTLVの推奨フォーマットは次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameter ID | Length | Stack Capability |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Parameter ID = 0x16
パラメータID = 0x16
Length = 4
Stack Capability = 0x000X to indicate IPv6 stack capability The value of Stack Capability is dependent on the PW type context. For IP PW type, a setting of 0x000X indicates IPv6 stack capability.
スタック機能= IPv6スタック機能を示す0x000Xスタック機能の値は、PWタイプのコンテキストに依存します。 IP PWタイプの場合、0x000Xの設定はIPv6スタック機能を示します。
A PE that supports IPv6 on an IP PW MUST signal the 'Stack Capability' sub-TLV in the initial Label Mapping message for the PW. The PE nodes compare the value advertised by the remote PE with the local configuration and only use a capability that is advertised by both. If a PE that supports IPv6 does not receive a 'Stack Capability' sub-TLV from the far-end PE in the initial Label Mapping message, or one is received but it is set to a reserved value, the PE MUST send an unsolicited release for the PW label with the LDP status code meaning "IP Address type mismatch" (status code 0x0000004A).
IP PWでIPv6をサポートするPEは、PWの初期ラベルマッピングメッセージで「スタック機能」サブTLVを通知する必要があります。 PEノードは、リモートPEによってアドバタイズされた値をローカル構成と比較し、両方によってアドバタイズされた機能のみを使用します。 IPv6をサポートするPEが最初のラベルマッピングメッセージで遠端PEから「Stack Capability」サブTLVを受信しない場合、または受信したが予約済みの値に設定されている場合、PEは非送信請求リリースを送信する必要がありますLDPステータスコードが「IPアドレスタイプの不一致」を意味するPWラベルの場合（ステータスコード0x0000004A）。
The behavior of a PE that does not understand an interface parameter sub-TLV is specified in RFC 4447 [RFC4447].
インターフェイスパラメータサブTLVを理解しないPEの動作は、RFC 4447 [RFC4447]で指定されています。
A PE should process a received [RFC4447] advertisement with a PW type of IP Layer 2 Transport for IPLS as follows:
PEは、受信した[RFC4447]アドバタイズメントを次のようにIPLSのPWタイプのIPレイヤ2トランスポートで処理する必要があります。
- Verify the IPLS VPN membership by matching the VPN-ID signaled in the Attachment Group Identifier (AGI) field or the PWid field with all the VPN-IDs configured in the PE. Discard and release the PW label if VPN-ID is not found.
- Attachment Group Identifier（AGI）フィールドまたはPWidフィールドで通知されたVPN-IDを、PEで構成されているすべてのVPN-IDと照合して、IPLS VPNメンバーシップを確認します。 VPN-IDが見つからない場合は、PWラベルを破棄して解放します。
- Program the FIB such that when a unicast IP packet is received from an AC with its destination MAC address matching the advertised MAC address, the packet is forwarded out over the tunnel to the advertising PE with the advertised PW label as the inner label.
- アドバタイズされたMACアドレスと一致する宛先MACアドレスでユニキャストIPパケットがACから受信されると、パケットがトンネルを介して、アドバタイズされたPWラベルを内部ラベルとしてアドバタイジングPEに転送されるように、FIBをプログラムします。
A PE should process a received [RFC4447] advertisement with the PW type of Ethernet for IPLS as follows:
PEは受信した[RFC4447]アドバタイズメントをPWタイプのイーサネットのIPLSで次のように処理する必要があります。
- Verify the IPLS VPN membership by matching the VPN-ID signaled in the AGI field or the PWid field with all the VPN-IDs configured in the PE. Discard and release the PW label if VPN-ID is not found.
- AGIフィールドまたはPWidフィールドで通知されたVPN-IDを、PEで構成されているすべてのVPN-IDと照合して、IPLS VPNメンバーシップを確認します。 VPN-IDが見つからない場合は、PWラベルを破棄して解放します。
- Add the PW label to the send broadcast replication tree for the VPN-ID. This enables the sending of a copy of a multicast/broadcast IP Ethernet frame, ARP Ethernet frame, or Neighbor Discovery frame from the AC to this PW.
- VPN-IDの送信ブロードキャスト複製ツリーにPWラベルを追加します。これにより、マルチキャスト/ブロードキャストIPイーサネットフレーム、ARPイーサネットフレーム、または近隣探索フレームのコピーをACからこのPWに送信できます。
Since this document is being published as Historic, no registration of IANA code points is necessary. However, in the future, if interest to pursue this proposal arises, the following IANA code registrations would become necessary.
このドキュメントは歴史的なものとして公開されているため、IANAコードポイントの登録は必要ありません。ただし、将来的には、この提案を追求する興味が生じた場合、以下のIANAコード登録が必要になります。
This document uses a new LDP status code. IANA already maintains the "Status Code Name Space" registry defined by [RFC5036]. The following allocation would be needed from the LDP Status Code Name Space.
このドキュメントでは、新しいLDPステータスコードを使用しています。 IANAはすでに[RFC5036]で定義されている "Status Code Name Space"レジストリを維持しています。 LDPステータスコード名前空間から次の割り当てが必要になります。
0x000000XX "MAC Address of CE is absent"
0x000000XX "CEのMACアドレスがありません"
This document proposes a new Interface Parameters sub-TLV, to be assigned from the "Pseudowire Interface Parameters Sub-TLV type Registry". The following allocation would be needed for the Parameter ID:
このドキュメントは、「Pseudowire Interface Parameters Sub-TLV type Registry」から割り当てられる新しいInterface ParametersサブTLVを提案します。パラメータIDには次の割り当てが必要です。
0xXX "Stack Capability"
0xXX「スタック機能」
IANA would also be requested to set up an "L2VPN PE Stack Capabilities" registry. This is a 16-bit field. The Stack Capability value (0x000X) is specified in Section 6.2 of this document. The remaining bit field values (0x0002,..,0x8000) would be assigned by IANA using the "IETF Consensus" policy defined in [RFC5226].
IANAは、「L2VPN PE Stack Capabilities」レジストリのセットアップも要求されます。これは16ビットのフィールドです。スタック機能の値（0x000X）は、このドキュメントのセクション6.2で指定されています。残りのビットフィールド値（0x0002、..、0x8000）は、[RFC5226]で定義されている「IETFコンセンサス」ポリシーを使用してIANAによって割り当てられます。
L2VPN PE Stack Capabilities:
L2VPN PEスタック機能：
Bit (Value) Description
=============== ==========================================
Bit 0 (0x000X) IPv6 stack capability
Bit 1 (0x000X) Reserved
Bit 2 (0x000X) Reserved
.
.
.
Bit 14 (0xX000) Reserved
Bit 15 (0xX000) Reserved
In an IPLS VPN, a PE forwards only IP and ARP traffic. All other frames are dropped silently. If the CEs must pass non-IP traffic to each other, they must do so through IP tunnels that terminate at the CEs themselves.
IPLS VPNでは、PEはIPおよびARPトラフィックのみを転送します。他のすべてのフレームはサイレントにドロップされます。 CEが非IPトラフィックを相互に渡す必要がある場合、CE自体で終了するIPトンネルを介して渡す必要があります。
In IPLS, IP traffic is forwarded from the AC to the PW based on the destination MAC address of the L2 frame (and not based on the IP header).
IPLSでは、IPトラフィックはL2フレームの宛先MACアドレスに基づいて（IPヘッダーに基づいてではなく）ACからPWに転送されます。
The PE identifies the FIB associated with an IPLS instance based on the AC or the PW label. When a frame is received from an AC, the PE uses the destination MAC address as the lookup key. When a frame is received from a PW, the PE uses the PW label as the lookup key. The frame is dropped if the lookup fails.
PEは、ACまたはPWラベルに基づいて、IPLSインスタンスに関連付けられたFIBを識別します。フレームはACから受信されると、宛先MACアドレスをルックアップキーとして使用します。 PWからフレームを受信すると、PEはPWラベルをルックアップキーとして使用します。ルックアップが失敗した場合、フレームはドロップされます。
For IPv6 support, the unicast IP ICMP frame of Neighbor Discovery Protocol [RFC4861] is bi-casted; one copy is submitted to the control plane and other copy to the PW, based on the destination MAC address.
IPv6サポートの場合、近隣探索プロトコル[RFC4861]のユニキャストIP ICMPフレームがバイキャストされます。 1つのコピーはコントロールプレーンに送信され、他のコピーは宛先MACアドレスに基づいてPWに送信されます。
When the destination MAC address is either broadcast or multicast, a copy of the frame is sent to the control plane for CE discovery purposes (see Section 4.1). It is important to note that stricter rate-limiting criteria is applied to frames sent to the control plane, in order to avoid overwhelming it under adverse conditions such as DoS attacks. The service provider should also provide a configurable limitation to prevent the overflowing of the learned source addresses in a given IPLS instance. Also, caution must be used such that only link-local multicasts and broadcast IP packets are sent to the control plane.
宛先MACアドレスがブロードキャストまたはマルチキャストの場合、フレームのコピーがCE検出の目的でコントロールプレーンに送信されます（セクション4.1を参照）。 DoS攻撃などの悪条件下でフレームが圧倒されないようにするため、コントロールプレーンに送信されるフレームには、より厳しいレート制限基準が適用されることに注意してください。サービスプロバイダーは、特定のIPLSインスタンスで学習された送信元アドレスのオーバーフローを防ぐために、構成可能な制限も提供する必要があります。また、リンクローカルマルチキャストとブロードキャストIPパケットのみがコントロールプレーンに送信されるように注意する必要があります。
When a multicast/broadcast IP packet is received from an AC, the PE replicates it onto the Send Multicast Replication Tree (see Section 5.3). When a multicast/broadcast IP Ethernet frame is received from a PW, the PE forwards a copy of the frame to all the ACs associated with the respective IPLS VPN instance. Note that 'multicast' PW uses Ethernet encapsulation; hence, it does not require additional header manipulations.
マルチキャスト/ブロードキャストIPパケットがACから受信されると、PEはそれを送信マルチキャストレプリケーションツリーに複製します（セクション5.3を参照）。マルチキャスト/ブロードキャストIPイーサネットフレームがPWから受信されると、PEはフレームのコピーを、それぞれのIPLS VPNインスタンスに関連付けられているすべてのACに転送します。 「マルチキャスト」PWはイーサネットカプセル化を使用することに注意してください。したがって、追加のヘッダー操作は必要ありません。
When a broadcast ARP frame is received over the AC, a copy of the frame is sent to the control plane for CE discovery purposes. The PE replicates the frame onto the Send Multicast Replication Tree (see Section 5.3), which results in a copy to be delivered to all the remote PEs on the 'multicast' PW and other local CEs through the egress ACs.
ブロードキャストARPフレームがACを介して受信されると、フレームのコピーがCE検出目的でコントロールプレーンに送信されます。 PEはフレームを送信マルチキャストレプリケーションツリー（セクション5.3を参照）に複製します。これにより、出力ACを通じて、「マルチキャスト」PW上のすべてのリモートPEおよびその他のローカルCEにコピーが配信されます。
When a broadcast Ethernet ARP frame is received over the 'multicast' PW, a copy of the Ethernet ARP frame is sent to all the ACs associated with the IPLS instance.
ブロードキャストイーサネットARPフレームが「マルチキャスト」PW経由で受信されると、イーサネットARPフレームのコピーがIPLSインスタンスに関連付けられているすべてのACに送信されます。
When a unicast Ethernet ARP frame is received over the AC, a copy of the frame is sent to the control plane for CE discovery purposes. The PE may optionally do destination MAC address lookup in the forwarding table and send the ARP frame to a specific egress interface (AC or 'multicast' PW to a remote PE) or replicate the frame onto the Send Multicast Replication Tree (see Section 5.3).
ユニキャストイーサネットARPフレームがAC経由で受信されると、フレームのコピーがCE検出のためにコントロールプレーンに送信されます。 PEはオプションで、転送テーブルで宛先MACアドレスルックアップを実行し、ARPフレームを特定の出力インターフェイスに送信（ACまたは「マルチキャスト」PWをリモートPEに）するか、フレームを送信マルチキャストレプリケーションツリーに複製することができます（セクション5.3を参照） 。
When a unicast ARP Ethernet frame is received over the 'multicast' PW, the PE may optionally do destination MAC address lookup in the forwarding table and forward it to the AC where the CE is located. If the CE is not accessible through any local AC, the frame is dropped. Conversely, the PE may simply forward the frame to all the ACs associated with that IPLS instance without any lookup in the forwarding table.
ユニキャストARPイーサネットフレームが「マルチキャスト」PWを介して受信されると、PEはオプションで転送テーブルで宛先MACアドレスルックアップを実行し、CEが配置されているACに転送します。ローカルACを介してCEにアクセスできない場合、フレームはドロップされます。逆に、PEは転送テーブルを検索せずに、そのIPLSインスタンスに関連付けられているすべてのACにフレームを転送するだけの場合もあります。
A PE device that supports IPv6 MUST be capable of:
IPv6をサポートするPEデバイスは、次の機能を備えている必要があります。
- Intercepting ICMPv6 Neighbor Discovery [RFC4861] packets received over the AC.
- AC経由で受信したICMPv6近隣探索[RFC4861]パケットの傍受。
- Recording the IPv6 interface addresses and CE link-layer addresses present in these packets
- これらのパケットに存在するIPv6インターフェイスアドレスとCEリンク層アドレスの記録
- Forwarding them towards the original destination. A PE device may also intercept Router Discovery packets in order to discover the link-layer address and IPv6 interface address(es) of the CE. The following sections describe the details.
- 元の宛先に転送します。 PEデバイスは、CEのリンク層アドレスとIPv6インターフェイスアドレスを検出するために、ルーター検出パケットを傍受することもあります。次のセクションで詳細を説明します。
The PE device MUST learn the link-layer address of the local CE and be able to use it when forwarding traffic between CEs. The PE MAY also wish to monitor the source link-layer address of data packets received from the CE and discard packets not matching its learned CE link-layer address. The PE device may also optionally learn a list of CE IPv6 interface addresses for its directly attached CE.
PEデバイスは、ローカルCEのリンク層アドレスを学習し、CE間でトラフィックを転送するときにそれを使用できる必要があります。 PEは、CEから受信したデータパケットのソースリンク層アドレスを監視し、学習したCEリンク層アドレスに一致しないパケットを破棄することもできます（MAY）。 PEデバイスは、オプションで、直接接続されているCEのCE IPv6インターフェイスアドレスのリストを学習することもできます。
When a multicast NS frame is received over the AC, a copy of the frame is sent to the control plane for CE discovery purposes. The PE replicates the frame onto the Send Multicast Replication Tree (see Section 5.3), which results in a copy to be delivered to all the remote PEs on the 'multicast' PW and other local CEs through the egress ACs. The PE may optionally learn an IPv6 interface address (If provided -- this will not be the case for Duplicate Address Detection) when present.
マルチキャストNSフレームがACを介して受信されると、フレームのコピーがCE検出の目的でコントロールプレーンに送信されます。 PEはフレームを送信マルチキャストレプリケーションツリー（セクション5.3を参照）に複製します。これにより、出力ACを通じて、「マルチキャスト」PW上のすべてのリモートPEおよびその他のローカルCEにコピーが配信されます。 PEは、存在する場合、オプションでIPv6インターフェースアドレス（提供されている場合-これは重複アドレス検出の場合には該当しません）を学習できます。
When a multicast Ethernet NS frame is received over the 'multicast' PW, a copy is sent to all the ACs associated with the IPLS instance.
マルチキャストイーサネットNSフレームが「マルチキャスト」PWを介して受信されると、IPLSインスタンスに関連付けられているすべてのACにコピーが送信されます。
When a unicast NA is received over the AC, a copy of the frame is sent to the control plane for the CE discovery purposes. The PE may optionally do destination MAC address lookup in the forwarding table and send the NA frame to a specific egress interface (AC or 'multicast' PW to a remote PE) or replicate the frame onto the Send Multicast Replication Tree (see Section 5.3).
ユニキャストNAがACを介して受信されると、フレームのコピーがCE検出の目的でコントロールプレーンに送信されます。 PEはオプションで、転送テーブルで宛先MACアドレスルックアップを実行し、NAフレームを特定の出力インターフェイスに送信（ACまたは「マルチキャスト」PWをリモートPEに）するか、フレームを送信マルチキャストレプリケーションツリーに複製します（セクション5.3を参照）。 。
Optionally, the PE could learn the IPv6 Interface address of the CE.
オプションで、PEはCEのIPv6インターフェイスアドレスを学習できます。
When a unicast NA frame is received over the 'multicast' PW, the PE may optionally do destination MAC address lookup in the forwarding table and forward it to the AC where the CE is located. If the CE is not accessible through any local AC, the frame is dropped. Conversely, the PE may simply forward the frame to all the ACs associated with that IPLS instance without any lookup in the forwarding table.
ユニキャストNAフレームが「マルチキャスト」PWを介して受信されると、PEはオプションで転送テーブルで宛先MACアドレスルックアップを行い、CEが配置されているACに転送します。ローカルACを介してCEにアクセスできない場合、フレームはドロップされます。逆に、PEは転送テーブルを検索せずに、そのIPLSインスタンスに関連付けられているすべてのACにフレームを転送するだけの場合もあります。
Inverse Neighbor Discovery is typically used on non-broadcast links, but is allowed on broadcast links as well [RFC3122]. A PE may optionally intercept Inverse Neighbor Solicitation and Advertisement and learn the MAC and IPv6 interface address list of the attached CE from the copy of the frame sent to the control plane. The PE may optionally do destination MAC address lookup in the forwarding table and send another copy of the frame to a specific egress interface (AC or 'multicast' PW to a remote PE) or replicate the frame onto the Send Multicast Replication Tree (see Section 5.3).
Inverse Neighbor Discoveryは通常、非ブロードキャストリンクで使用されますが、ブロードキャストリンクでも許可されています[RFC3122]。 PEは、オプションで逆近傍要請およびアドバタイズを傍受し、コントロールプレーンに送信されたフレームのコピーから、接続されたCEのMACおよびIPv6インターフェイスアドレスリストを学習できます。 PEはオプションで、転送テーブルで宛先MACアドレスルックアップを実行し、フレームの別のコピーを特定の出力インターフェイスに送信（ACまたは「マルチキャスト」PWをリモートPEに）するか、フレームを送信マルチキャストレプリケーションツリーに複製することができます（セクションを参照） 5.3）。
RSs are multicast while RAs can be unicast or multicast Ethernet frames. The PE could optionally intercept RS and RA frames and send a copy to the control plane. The PE may learn the MAC address and a list of interface addresses for the attached CE.
RSはマルチキャストですが、RAはユニキャストまたはマルチキャストイーサネットフレームです。 PEはオプションでRSおよびRAフレームを代行受信し、コピーをコントロールプレーンに送信できます。 PEは、接続されたCEのMACアドレスとインターフェイスアドレスのリストを学習できます。
For unicast RA, the PE may optionally do destination MAC address lookup in the forwarding table and send the RA frame to a specific egress interface (AC or 'multicast' PW to a remote PE) or replicate the frame onto the Send Multicast Replication Tree (see Section 5.3). The multicast RA and RS Ethernet frames are replicated using the Send Multicast Replication Tree as described in Section 5.3.
ユニキャストRAの場合、PEはオプションで転送テーブルで宛先MACアドレスルックアップを実行し、RAフレームを特定の出力インターフェイスに送信（ACまたは「マルチキャスト」PWをリモートPEに）するか、フレームを送信マルチキャストレプリケーションツリー（セクション5.3を参照してください）。マルチキャストRAおよびRSイーサネットフレームは、セクション5.3で説明されているように、送信マルチキャストレプリケーションツリーを使用して複製されます。
The Ethernet MAC header of a unicast IP packet received from an AC is stripped before forwarding the frame to the unicast PW. However, the MAC header is retained for the following cases,
ACから受信したユニキャストIPパケットのイーサネットMACヘッダーは、フレームをユニキャストPWに転送する前に取り除かれます。ただし、次の場合はMACヘッダーが保持されます。
- when a frame is a unicast IP packet that is directed to a local AC.
- フレームがローカルACに送信されるユニキャストIPパケットである場合。
- when a frame is a broadcast/multicast IP packet
- フレームがブロードキャスト/マルチキャストIPパケットの場合
- when a frame is an ARP packet
- フレームがARPパケットの場合
- when a frame is Neighbor/Router Solicitation/Advertisement
- フレームがネイバー/ルーター要請/アドバタイズである場合
An IP frame received over a unicast PW is prepended with a MAC header before transmitting it on the appropriate AC(s). The fields in the MAC header are filled in as follows:
ユニキャストPWを介して受信されたIPフレームには、適切なACで送信する前にMACヘッダーが付加されます。 MACヘッダーのフィールドには、次のように入力されます。
- The destination MAC address is the MAC address associated with the PW label in the FIB.
- 宛先MACアドレスは、FIBのPWラベルに関連付けられたMACアドレスです。
- The source MAC address is the PE's own local MAC address or a MAC address that has been specially configured on the PE for this use.
- 送信元MACアドレスは、PE自体のローカルMACアドレス、またはこの使用のためにPEで特別に構成されたMACアドレスです。
- The Ethernet Type field is 0x0800 if IPv4 or 0x86DD if IPv6 [RFC2464].
- イーサネットタイプフィールドは、IPv4の場合は0x0800、IPv6 [RFC2464]の場合は0x86DDです。
- The frame may be IEEE 802.1Q tagged based on the VLAN information associated with the AC.
- フレームは、ACに関連付けられたVLAN情報に基づいてタグ付けされたIEEE 802.1Qである場合があります。
A Frame Check Sequence (FCS) is appended to the frame.
フレームチェックシーケンス（FCS）がフレームに追加されます。
In addition to (i) an Ethernet port and a (ii) combination of Ethernet port and a VLAN ID, an AC to IPLS may also be (iii) an ATM or FR Virtual Circuit (VC) carrying encapsulated bridged Ethernet frames or (iv) the combination of an ATM or FR VC and a VLAN ID.
（i）イーサネットポートと（ii）イーサネットポートとVLAN IDの組み合わせに加えて、ACからIPLSは、（iii）カプセル化されたブリッジイーサネットフレームを運ぶATMまたはFR Virtual Circuit（VC）または（iv ）ATMまたはFR VCとVLAN IDの組み合わせ。
The ATM/FR VC is just used as a way to transport Ethernet frames between a customer site and the PE. The PE terminates the ATM/FR VC and operates on the encapsulated Ethernet frames exactly as if those were received on a local Ethernet interface. When a frame is propagated from PW to an ATM or FR VC, the PE prepends the Ethernet frame with the appropriate bridged encapsulation header as defined in [RFC2684] and [RFC2427], respectively. Operation of an IPLS over ATM/FR VC is exactly as described above, with the exception that the AC is then identified via the ATM VCI/VPI or Frame Relay Data Link Connection Identifier (DLCI) (instead of via a local Ethernet port ID), or a combination of those with a VLAN ID.
ATM / FR VCは、カスタマーサイトとPEの間でイーサネットフレームを転送する方法として使用されます。 PEはATM / FR VCを終端し、カプセル化されたイーサネットフレームをローカルイーサネットインターフェイスで受信した場合とまったく同じように動作します。フレームがPWからATMまたはFR VCに伝播されると、PEはイーサネットフレームの前に、それぞれ[RFC2684]および[RFC2427]で定義されている適切なブリッジドカプセル化ヘッダーを付加します。 IPLS over ATM / FR VCの動作は、ACが（ローカルイーサネットポートIDではなく）ATM VCI / VPIまたはフレームリレーデータリンク接続識別子（DLCI）を介して識別されることを除いて、上記とまったく同じです。 、またはVLAN IDとの組み合わせ。
The VPLS approach proposed in [RFC4762] provides VPN services for IP as well as other protocols. The IPLS approach described in this document is similar to VPLS in many respects:
[RFC4762]で提案されているVPLSアプローチは、IPおよびその他のプロトコルにVPNサービスを提供します。このドキュメントで説明されているIPLSアプローチは、多くの点でVPLSに似ています。
- It provides a Provider-Provisioned Virtual LAN service with multipoint capability where a CE connected via a single attachment circuit can reach many remote CEs
- 単一の接続回線を介して接続されたCEが多数のリモートCEに到達できるマルチポイント機能を備えたプロバイダープロビジョニングの仮想LANサービスを提供します
- It appears as a broadcast domain and a single subnet
- ブロードキャストドメインおよび単一のサブネットとして表示されます
- Forwarding is based on destination MAC addresses
- 転送は宛先MACアドレスに基づいています
However, unlike VPLS, IPLS is restricted to IP traffic only. By restricting the scope of the service to the predominant type of traffic in today's environment, IPLS eliminates the need for service provider edge routers to implement some bridging functions such as MAC address learning in the data path (by, instead, distributing MAC information in the control plane). Thus, this solution offers a number of benefits:
ただし、VPLSとは異なり、IPLSはIPトラフィックのみに制限されます。 IPLSは、サービスのスコープを今日の環境で主なタイプのトラフィックに制限することで、サービスプロバイダーのエッジルーターがデータパスでMACアドレスラーニングなどのブリッジ機能を実装する必要をなくします（代わりに、MAC情報をコントロールプレーン）。したがって、このソリューションには多くの利点があります。
- It facilitates Virtual LAN services in instances where PE devices cannot or cannot efficiently (or are specifically configured not to) perform MAC address learning.
- これは、PEデバイスがMACアドレスラーニングを実行できない、または効率的に実行できない（または特に構成されていない）場合に、仮想LANサービスを容易にします。
- Unknown Unicast frames are never flooded as would be the case in VPLS.
- VPLSの場合のように、不明なユニキャストフレームがフラッディングされることはありません。
- Encapsulation is more efficient (the MAC header is stripped) for unicast IP packets while traversing the backbone network.
- カプセル化は、バックボーンネットワークを通過するユニキャストIPパケットに対してより効率的です（MACヘッダーが削除されます）。
- PE devices are not burdened with the processing overhead associated with traditional bridging (e.g., Spanning Tree Protocol (STP) processing, etc.). Note, however, that some of these overheads (e.g., STP processing) could optionally be turned off with a VPLS solution in the case where it is known that only IP devices are interconnected.
- PEデバイスは、従来のブリッジング（たとえば、スパニングツリープロトコル（STP）処理など）に関連する処理オーバーヘッドを負担しません。ただし、これらのオーバーヘッドの一部（STP処理など）は、IPデバイスのみが相互接続されていることがわかっている場合、VPLSソリューションを使用してオプションでオフにできることに注意してください。
- Loops (perhaps through backdoor links) are minimized since a PE could easily reject (via label release) a duplicate IP to MAC address advertisement.
- PEは重複したIPからMACアドレスへのアドバタイズを（ラベルのリリースを介して）簡単に拒否できるため、ループ（おそらくバックドアリンクを介して）は最小限に抑えられます。
- Greater control over CE topology distribution is available.
- CEトポロジの配布をより詳細に制御できます。
The solution described in this document offers IPLS service for IPv4 and IPv6 traffic only. For this reason, the MAC header is not carried over the unicast PW. It is reconstructed by the PE when receiving a packet from a unicast PW and the Ethertype 0x0800 or 0x86DD is used in the MAC header since IPv4 or IPv6, respectively, is assumed.
このドキュメントで説明するソリューションは、IPv4およびIPv6トラフィックに対してのみIPLSサービスを提供します。このため、MACヘッダーはユニキャストPWで伝送されません。これは、ユニキャストPWからパケットを受信したときにPEによって再構築され、MACヘッダーでIPv4またはIPv6がそれぞれ想定されているため、Ethertype 0x0800または0x86DDが使用されます。
However, this solution may be extended to carry other types of important traffic such as IS-IS , which does not use Ethernet-II, an EtherType-based header. In order to permit the propagation of such packets correctly, one may create a separate set of PWs, or pass protocol information in the "control word" of a "multiprotocol" PW, or encapsulate the Ethernet MAC header in the PW. The selection of appropriate multiplexing/demultiplexing schemes is the subject of future study. The current document focuses on IPLS service for IPv4 and IPv6 traffic.
ただし、このソリューションを拡張して、EtherTypeベースのヘッダーであるEthernet-IIを使用しないIS-ISなどの他のタイプの重要なトラフィックを伝送することもできます。このようなパケットの伝播を正しく許可するには、別のPWのセットを作成するか、「マルチプロトコル」PWの「コントロールワード」でプロトコル情報を渡すか、PWでイーサネットMACヘッダーをカプセル化します。適切な多重化/逆多重化スキームの選択は、将来の研究の主題です。現在のドキュメントは、IPv4およびIPv6トラフィックのIPLSサービスに焦点を当てています。
As stated in previous sections, IPLS prohibits the connection of a common LAN or VLAN to more than one PE. However, the CE device itself can connect to more than one instance of IPLS through two separate LAN or VLAN connections to separate PEs. To the CE IP device, these separate connections appear as connections to two IP subnets. The failure of reachability through one subnet is then resolved via the other subnet using IP routing protocols.
前のセクションで述べたように、IPLSは複数のPEへの共通LANまたはVLANの接続を禁止します。ただし、CEデバイス自体は、別々のPEへの2つの別々のLANまたはVLAN接続を介して、IPLSの複数のインスタンスに接続できます。 CE IPデバイスには、これらの個別の接続は2つのIPサブネットへの接続として表示されます。 1つのサブネットを介した到達可能性の障害は、IPルーティングプロトコルを使用して、他のサブネットを介して解決されます。
The earlier version of this proposal used IP-PW to carry both the broadcast/multicast and unicast IP traffic. It also discussed how PE proxy functionality responds to the ARP requests of the local CE on behalf of remote CE. The current version of the document eliminated these functions and instead uses Ethernet PW to carry broadcast, multicast and ARP frames to remote PEs. The motivation to use Ethernet PW and propagate ARP frames in the current version is to support configuration like back-to-back IPLS (similar to Inter-AS option-A configurations in [RFC4364]).
この提案の以前のバージョンでは、IP-PWを使用して、ブロードキャスト/マルチキャストとユニキャストの両方のIPトラフィックを伝送していました。また、PEプロキシ機能がリモートCEに代わってローカルCEのARP要求に応答する方法についても説明しました。ドキュメントの現在のバージョンでは、これらの機能が排除され、代わりにイーサネットPWを使用して、ブロードキャスト、マルチキャスト、およびARPフレームがリモートPEに伝送されています。現在のバージョンでイーサネットPWを使用してARPフレームを伝播する動機は、バックツーバックIPLS（[RFC4364]のInter-ASオプションA構成と同様）のような構成をサポートすることです。
The termination and controlled propagation of ARP frames is still a desirable option for security, DoS, and other purposes. For these reasons, we reintroduce the ARP Proxy [RFC925] function in this revision as an optional feature. The following sections describe this option.
ARPフレームの終了と制御された伝播は、セキュリティ、DoS、およびその他の目的にとって依然として望ましいオプションです。これらの理由により、このリビジョンではオプション機能としてARPプロキシ[RFC925]機能を再導入しています。次のセクションでは、このオプションについて説明します。
As a local configuration, a PE can enable the ARP Proxy Responder function. In this mode, the local PE responds to ARP requests received over the Attachment Circuit via learned IP and MAC address associations, which are advertised by the remote PEs. In addition, the PE may utilize local policies to determine if ARP requests should be responded based on the source of the ARP request, rate at which the ARP requests are generated, etc. In a nutshell, when this feature is enabled, ARP requests are not propagated to remote PE routers that are members of the same IPLS instance.
ローカル設定として、PEはARPプロキシレスポンダ機能を有効にできます。このモードでは、ローカルPEは、リモートPEによってアドバタイズされた、学習したIPアドレスとMACアドレスの関連付けを介して、接続回線を介して受信したARP要求に応答します。さらに、PEはローカルポリシーを使用して、ARP要求のソース、ARP要求が生成されるレートなどに基づいてARP要求に応答する必要があるかどうかを判断します。簡単に言えば、この機能が有効になっている場合、ARP要求は同じIPLSインスタンスのメンバーであるリモートPEルーターには伝播されません。
As a local configuration, a PE can enable the ARP Proxy Generator function. In this mode, the PE generates an ARP request for each IP and MAC address association received from the remote PEs. The remote CE's IP and MAC address is used as the source information in the ARP request while the destination IP address in the request is obtained from the local configuration (that is, user needs to configure an IP address when this feature is enabled). The ARP request is sent on the ACs that have ARP Proxy Generator enabled and is associated with the given IPLS instance.
ローカル構成として、PEはARPプロキシジェネレーター機能を有効にできます。このモードでは、PEは、リモートPEから受信したIPおよびMACアドレスの関連付けごとにARP要求を生成します。リモートCEのIPおよびMACアドレスはARP要求のソース情報として使用されますが、要求の宛先IPアドレスはローカル構成から取得されます（つまり、この機能が有効な場合、ユーザーはIPアドレスを構成する必要があります）。 ARP要求は、ARPプロキシジェネレーターが有効になっていて、特定のIPLSインスタンスに関連付けられているACで送信されます。
In addition, the PE may utilize local policies to determine which IP/MAC addresses are candidate for ARP request generation.
さらに、PEはローカルポリシーを利用して、どのIP / MACアドレスがARP要求生成の候補であるかを判断できます。
The ARP Proxy Generator feature is required to support back-to-back IPLS configuration when any member of the IPLS instance is using the ARP Proxy Responder function. An example of a back-to-back IPLS is a configuration where PE-1 (ASBR) in an IPLS cloud in one Autonomous System (say, AS-1) is connected via an AC to another PE-2 (ASBR) in an IPLS cloud in another Autonomous System (say, AS- 2) where each PE appears as CE to each other. Such configuration is described in [RFC4364] as option-A for inter-AS connectivity. The Proxy ARP Responder feature prevents propagation of ARP requests to PE-1 (ASBR) in AS-1. This necessitates that PE-1 (ASBR) in AS-1 generates an ARP request on behalf of each CE connected to the IPLS instance in AS-1 as a mean to 'advertise' the reachability to IPLS cloud in AS-2.
IPLSインスタンスのメンバーがARPプロキシレスポンダー機能を使用している場合、バックツーバックIPLS構成をサポートするには、ARPプロキシジェネレーター機能が必要です。バックツーバックIPLSの例は、1つの自律システム（たとえば、AS-1）のIPLSクラウド内のPE-1（ASBR）がACを介して別のPE-2（ASBR）に接続されている構成です各PEが互いにCEとして表示される別の自律システム（AS-2など）のIPLSクラウド。このような構成は、AS間接続のオプションAとして[RFC4364]で説明されています。プロキシARPレスポンダ機能は、AS-1のPE-1（ASBR）へのARP要求の伝播を防ぎます。これにより、AS-1のPE-1（ASBR）が、AS-2のIPLSクラウドへの到達可能性を「アドバタイズ」する手段として、AS-1のIPLSインスタンスに接続された各CEに代わってARP要求を生成する必要があります。
The resurgence of interest in providing an IP/MPLS-based solution for Data Center Networks (DCNs) deserves another look at the IPLS methodologies described in this document. The key requirement of a DCN to permit Virtual Machine (VM) mobility within or across a DCN necessitates extending the reachability of IP subnet over a LAN, transparently. In addition, VMs tendency to generate frequent gratuitous ARPs for location discovery necessitates a solution that curbs broadcasts closest to the source.
データセンターネットワーク（DCN）にIP / MPLSベースのソリューションを提供することへの関心の復活は、このドキュメントで説明されているIPLS方法論をもう一度検討する価値があります。 DCN内またはDCN全体で仮想マシン（VM）モビリティを許可するDCNの主要な要件は、LAN上のIPサブネットの到達可能性を透過的に拡張することを必要とします。さらに、VMはロケーション検出のために頻繁に不要なARPを生成する傾向があるため、ソースに最も近いブロードキャストを抑制するソリューションが必要です。
The IPLS solution facilitates VM mobility by the PE closest to the new location signaling the MAC address to all remote peers. In addition, control-plane-based MAC learning mechanisms prevent flooding of unknown unicast across a DCN. The optional ARP proxy mechanisms further reduce ARP broadcast floods by preventing its reach across a local PE.
IPLSソリューションは、新しい場所に最も近いPEがすべてのリモートピアにMACアドレスをシグナリングすることにより、VMモビリティを促進します。さらに、コントロールプレーンベースのMAC学習メカニズムにより、DCNを介した未知のユニキャストのフラッディングが防止されます。オプションのARPプロキシメカニズムは、ローカルPEを介した到達を防ぐことにより、ARPブロードキャストフラッドをさらに削減します。
A more comprehensive description of the security issues involved in L2VPNs are covered in [RFC4111]. Most of the security issues can be avoided through implementation of appropriate guards. The security aspect of this solution is addressed for two planes: the control plane and data plane.
L2VPNに関連するセキュリティ問題のより包括的な説明は[RFC4111]でカバーされています。セキュリティ問題のほとんどは、適切なガードを実装することで回避できます。このソリューションのセキュリティ面は、コントロールプレーンとデータプレーンの2つのプレーンに対応しています。
The control-plane security pertains to establishing the LDP connection, PW establishment and CE's IP and MAC address distribution. The LDP connection between two trusted PEs can be achieved by each PE verifying the incoming connection against the configured peer's address and authenticating the LDP messages by verifying keyed digests. The PW establishments between two secure LDP peers do not pose security issue but mis-wiring could occur due to configuration error. Some checks, such as, proper PW type and other PW options may prevent mis-wiring due to configuration errors.
コントロールプレーンのセキュリティは、LDP接続の確立、PWの確立、CEのIPおよびMACアドレスの配布に関係しています。 2つの信頼できるPE間のLDP接続は、各PEが設定されたピアのアドレスに対して着信接続を検証し、キー付きダイジェストを検証することによってLDPメッセージを認証することで実現できます。 2つのセキュアLDPピア間のPW確立はセキュリティ問題を引き起こしませんが、設定エラーが原因で誤配線が発生する可能性があります。適切なPWタイプやその他のPWオプションなどの一部のチェックは、構成エラーによる誤配線を防ぐことができます。
The learning of the appropriate CE's IP and MAC address can be a security issue. It is expected that the local attachment circuit to CE be physically secured. If this is a concern, the PE must be configured with the CE's IP and MAC address. During each ARP frame processing, the PE must verify the received information against the configuration before accepting. This prevents theft of service, denial of service to a subscriber, or DoS attacks to all subscribers by malicious use of network services.
適切なCEのIPおよびMACアドレスを学習することは、セキュリティ上の問題になる可能性があります。 CEへのローカル接続回線が物理的に保護されることが期待されています。これが問題になる場合は、PEにCEのIPアドレスとMACアドレスを設定する必要があります。各ARPフレーム処理中に、PEは受け入れる前に、構成に対して受信した情報を検証する必要があります。これにより、サービスの盗難、加入者へのサービス拒否、またはネットワークサービスの悪意のある使用によるすべての加入者へのDoS攻撃が防止されます。
The IPLS also provides MAC anti-spoofing by preventing the use of already known MAC address. For instance, if a PE has already learned a presence of a CE through a local connection or from another PE, and subsequently an advertisement for the same MAC and/or IP address is received from a different PE, the receiving PE can terminate service to that CE (either through label release and/or removing the ARP entry from the FIB) and raise the alarm.
IPLSは、既知のMACアドレスの使用を防止することにより、MACスプーフィングも防止します。たとえば、PEがローカル接続または別のPEを介してすでにCEの存在を学習していて、その後同じMACやIPアドレスのアドバタイズが別のPEから受信された場合、受信側PEはサービスを終了して、そのCE（ラベルの解放またはFIBからのARPエントリの削除、あるいはその両方）によって、アラームが発生します。
The IPLS learns and distributes CE reachability through the control plane. This provides greater control over CE topology distribution through the application of local policies.
IPLSは、コントロールプレーンを通じてCEの到達可能性を学習および配信します。これにより、ローカルポリシーを適用して、CEトポロジの配布をより詳細に制御できます。
The data traffic between the CE and PE is not encrypted. In an insecure environment, it is possible that a malicious user may tap into the CE-to-PE connection and could conduct an active or passive attack. An example of an active attack would be generating traffic using the spoofed destination MAC address on the Ethernet Attachment Circuit and a passive attack could include targeted or passive monitoring between the CE and PE. In order to avoid such hijacking, the local PE may verify the source MAC address of the received frame against the MAC address of the admitted connection. The frame is forwarded to the PW only when authenticity is verified. When spoofing is detected, the PE must sever the connection with the local CE, tear down the PW, and start over.
CEとPE間のデータトラフィックは暗号化されません。安全でない環境では、悪意のあるユーザーがCEからPEへの接続を利用し、アクティブまたはパッシブ攻撃を実行する可能性があります。アクティブな攻撃の例としては、イーサネット接続回線のスプーフィングされた宛先MACアドレスを使用してトラフィックを生成することや、パッシブな攻撃に、CEとPEの間のターゲットまたはパッシブなモニタリングが含まれる場合があります。このようなハイジャックを回避するために、ローカルPEは、受信したフレームの送信元MACアドレスを、許可された接続のMACアドレスと照合して検証します。信頼性が確認された場合にのみ、フレームがPWに転送されます。スプーフィングが検出されると、PEはローカルCEとの接続を切断し、PWを切断して、最初からやり直す必要があります。
Each IPLS instance uses its own FIB. This prevents leaking of one customer data into another.
各IPLSインスタンスは独自のFIBを使用します。これにより、ある顧客データが別の顧客データに漏洩するのを防ぎます。
[IEEE802.1D] ISO/IEC 10038, ANSI/IEEE Std 15802-3:1998, "MAC Bridges".
[IEEE802.1D] ISO / IEC 10038、ANSI / IEEE Std 15802-3：1998、「MAC Bridges」。
[RFC826] 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, <http://www.rfc-editor.org/info/rfc826>.
[RFC826] Plummer、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスをイーサネットハードウェアでの送信用に48ビットのイーサネットアドレスに変換する」、STD 37、RFC 826、1982年11月、<http：//www.rfc- editor.org/info/rfc826>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.
[RFC2464] Crawford、M。、「Transmission of IPv6 Packets over Ethernet Networks」、RFC 2464、1998年12月、<http://www.rfc-editor.org/info/rfc2464>。
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001, <http://www.rfc-editor.org/info/rfc3122>.
[RFC3122] Conta、A。、「Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification」、RFC 3122、2001年6月、<http://www.rfc-editor.org/info/rfc3122>。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006, <http://www.rfc-editor.org/info/rfc4446>.
[RFC4446] Martini、L。、「IANA Allocations for Pseudowire Edge to Edge Emulation（PWE3）」、BCP 116、RFC 4446、2006年4月、<http://www.rfc-editor.org/info/rfc4446>。
[RFC4447] Martini, L., Ed., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006, <http://www.rfc-editor.org/info/rfc4447>.
[RFC4447] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、Smith、T.、and G. Heron、 "Pseudowire Setup and Maintenance Using the Label Distribution Protocol（LDP）"、RFC 4447 、2006年4月、<http://www.rfc-editor.org/info/rfc4447>。
[RFC4448] Martini, L., Ed., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006, <http://www.rfc-editor.org/info/rfc4448>.
[RFC4448] Martini、L.、Ed。、Rosen、E.、El-Aawar、N.、and G. Heron、 "Encapsulation Methods for Transport of Ethernet over MPLS Networks"、RFC 4448、April 2006、<http：/ /www.rfc-editor.org/info/rfc4448>。
[RFC4762] Lasserre, M., Ed., and V. Kompella, Ed., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC 4762, January 2007, <http://www.rfc-editor.org/info/rfc4762>.
[RFC4762] Lasserre、M。、編、およびV. Kompella、編、「Label Distribution Protocol（LDP）シグナリングを使用した仮想プライベートLANサービス（VPLS）」、RFC 4762、2007年1月、<http：// 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, September 2007, <http://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月、<http：//www.rfc- editor.org/info/rfc4861>。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007、<http://www.rfc-editor.org / info / rfc5036>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月、<http://www.rfc-editor.org/info/rfc5226> 。
[ADDR-IANA] IANA, "Address Family Numbers", http://www.iana.org/assignments/address-family-numbers/.
[ADDR-IANA] IANA、「Address Family Numbers」、http：//www.iana.org/assignments/address-family-numbers/。
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984, <http://www.rfc-editor.org/info/rfc925>.
[RFC925] Postel、J。、「Multi-LAN address resolution」、RFC 925、1984年10月、<http://www.rfc-editor.org/info/rfc925>。
[RFC2427] Brown, C. and A. Malis, "Multiprotocol Interconnect over Frame Relay", STD 55, RFC 2427, September 1998, <http://www.rfc-editor.org/info/rfc2427>.
[RFC2427] Brown、C。およびA. Malis、「Multiprotocol Interconnect over Frame Relay」、STD 55、RFC 2427、1998年9月、<http://www.rfc-editor.org/info/rfc2427>。
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999, <http://www.rfc-editor.org/info/rfc2684>.
[RFC2684] Grossman、D。およびJ. Heinanen、「ATMアダプテーションレイヤー5上のマルチプロトコルカプセル化」、RFC 2684、1999年9月、<http://www.rfc-editor.org/info/rfc2684>。
[RFC4111] Fang, L., Ed., "Security Framework for Provider-Provisioned Virtual Private Networks (PPVPNs)", RFC 4111, July 2005, <http://www.rfc-editor.org/info/rfc4111>.
[RFC4111] Fang、L。、編、「Provider-Provisioned Virtual Private Networks（PPVPNs）のセキュリティフレームワーク」、RFC 4111、2005年7月、<http://www.rfc-editor.org/info/rfc4111>。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>.
[RFC4364] Rosen、E.およびY. Rekhter、「BGP / MPLS IP Virtual Private Networks（VPNs）」、RFC 4364、2006年2月、<http://www.rfc-editor.org/info/rfc4364>。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006, <http://www.rfc-editor.org/info/rfc4664>.
[RFC4664] Andersson、L.、Ed。およびE. Rosen、Ed。、 "Framework for Layer 2 Virtual Private Networks（L2VPNs）"、RFC 4664、2006年9月、<http://www.rfc-editor.org / info / rfc4664>。
[RFC4665] Augustyn, W., Ed., and Y. Serbest, Ed., "Service Requirements for Layer 2 Provider-Provisioned Virtual Private Networks", RFC 4665, September 2006, <http://www.rfc-editor.org/info/rfc4665>.
[RFC4665] Augustyn、W。、編、およびY. Serbest、編、「レイヤー2プロバイダーが提供する仮想プライベートネットワークのサービス要件」、RFC 4665、2006年9月、<http：//www.rfc-editor。 org / info / rfc4665>。
[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>.
[RFC5771]綿、M。、ベゴダ、L。、およびD.マイヤー、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 5771、2010年3月、<http://www.rfc-editor.org/ info / rfc5771>。
[RFC6074] Rosen, E., Davie, B., Radoaca, V., and W. Luo, "Provisioning, Auto-Discovery, and Signaling in Layer 2 Virtual Private Networks (L2VPNs)", RFC 6074, January 2011, <http://www.rfc-editor.org/info/rfc6074>.
[RFC6074]ローゼン、E。、デイビー、B。、ラドアカ、V。、およびW.ルオ、「プロビジョニング、自動検出、およびレイヤー2仮想プライベートネットワーク（L2VPN）でのシグナリング」、RFC 6074、2011年1月、< http://www.rfc-editor.org/info/rfc6074>。
Acknowledgements
謝辞
Authors would like to thank Alp Dibirdi from Alcatel, Xiaohu Xu from Huawei, and other L2VPN working group members for their valuable comments.
著者は、AlcatelのAlp Dibirdi、HuaweiのXiaohu Xu、およびその他のL2VPNワーキンググループメンバーの貴重なコメントに感謝します。
Contributors
貢献者
This document is the combined effort of the following individuals and many others who have carefully reviewed this document and provided the technical clarifications.
このドキュメントは、以下の個人と、このドキュメントを注意深く確認し、技術的な説明を提供した他の多くの人々の努力を組み合わせたものです。
K. Arvind Fortress Vach Kompella Alcatel-Lucent Matthew Bocci Alcatel-Lucent Shane Amante Apple
K.アーヴィンドフォートレスバッハコンペラアルカテルルーセントマシューボッチアルカテルルーセントシェーンアマンテアップル
Authors' Addresses
著者のアドレス
Himanshu Shah Ciena Corp 3939 North 1st Street San Jose, CA 95110 United States
Himanshu Shah Ciena Corp 3939 North 1st Street San Jose、CA 95110アメリカ合衆国
EMail: hshah@ciena.com
Eric Rosen Juniper Networks, Inc. 10 Technology Park Drive Westford, MA, 01886 United States
Eric Rosen Juniper Networks、Inc. 10 Technology Park Drive Westford、MA、01886アメリカ合衆国
EMail: erosen@juniper.net
Francois Le Faucheur Cisco Systems, Inc. Batiment D, 45 Allee des Ormes 06254 Mougins France
Francois Le Faucheur Cisco Systems、Inc. Batiment D、45 Allee des Ormes 06254ムージャンフランス
EMail: flefauch@cisco.com
Giles Heron Cisco Systems 9-11 New Square Bedfont Lakes Feltham Middlesex TW14 8HA United Kingdom
Giles Heron Cisco Systems 9-11 New Square Bedfont Lakes Feltham Middlesex TW14 8HAイギリス
EMail: giheron@cisco.com