[要約] RFC 6575は、レイヤ2 VPNのIP相互運用のためのARPメディエーションに関する規格です。このRFCの目的は、異なるレイヤ2 VPN間でのARPトラフィックの効率的な中継と制御を提供することです。
Internet Engineering Task Force (IETF) H. Shah, Ed.
Request for Comments: 6575 Ciena
Category: Standards Track E. Rosen, Ed.
ISSN: 2070-1721 G. Heron, Ed.
Cisco
V. Kompella, Ed.
Alcatel-Lucent
June 2012
Address Resolution Protocol (ARP) Mediation for IP Interworking of Layer 2 VPNs
レイヤー2 VPNのIPインターワーキングのためのアドレス解決プロトコル（ARP）メディエーション
Abstract
概要
The Virtual Private Wire Service (VPWS), detailed in RFC 4664, provides point-to-point connections between pairs of Customer Edge (CE) devices. It does so by binding two Attachment Circuits (each connecting a CE device with a Provider Edge (PE) device) to a pseudowire (connecting the two PEs). In general, the Attachment Circuits must be of the same technology (e.g., both Ethernet or both ATM), and the pseudowire must carry the frames of that technology. However, if it is known that the frames' payload consists solely of IP datagrams, it is possible to provide a point-to-point connection in which the pseudowire connects Attachment Circuits of different technologies. This requires the PEs to perform a function known as "Address Resolution Protocol (ARP) Mediation". ARP Mediation refers to the process of resolving Layer 2 addresses when different resolution protocols are used on either Attachment Circuit. The methods described in this document are applicable even when the CEs run a routing protocol between them, as long as the routing protocol runs over IP.
RFC 4664で詳述されているVirtual Private Wire Service（VPWS）は、カスタマーエッジ（CE）デバイスのペア間のポイントツーポイント接続を提供します。これは、2つの接続回路（それぞれがCEデバイスとプロバイダーエッジ（PE）デバイスを接続する）を疑似配線（2つのPEを接続する）にバインドすることによって行われます。一般に、接続回路は同じテクノロジー（たとえば、両方のイーサネットまたは両方のATM）である必要があり、疑似配線はそのテクノロジーのフレームを伝送する必要があります。ただし、フレームのペイロードがIPデータグラムのみで構成されていることがわかっている場合は、疑似配線がさまざまなテクノロジーの接続回路を接続するポイントツーポイント接続を提供できます。これには、PEが「アドレス解決プロトコル（ARP）メディエーション」と呼ばれる機能を実行する必要があります。 ARPメディエーションとは、いずれかの接続回線で異なる解決プロトコルが使用されている場合に、レイヤー2アドレスを解決するプロセスを指します。このドキュメントで説明されている方法は、ルーティングプロトコルがIPで実行されている限り、CE間でルーティングプロトコルが実行されている場合でも適用できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
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). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（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/rfc6575.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6575で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. ARP Mediation (AM) Function .....................................5
3. IP Layer 2 Interworking Circuit .................................6
4. IP Address Discovery Mechanisms .................................6
4.1. Discovery of IP Addresses of Locally Attached IPv4 CE ......7
4.1.1. Monitoring Local Traffic ............................7
4.1.2. CE Devices Using ARP ................................7
4.1.3. CE Devices Using Inverse ARP ........................8
4.1.4. CE Devices Using PPP ................................9
4.1.5. Router Discovery Method ............................10
4.1.6. Manual Configuration ...............................10
4.2. How a CE Learns the IPv4 Address of a Remote CE ...........10
4.2.1. CE Devices Using ARP ...............................11
4.2.2. CE Devices Using Inverse ARP .......................11
4.2.3. CE Devices Using PPP ...............................11
4.3. Discovery of IP Addresses of IPv6 CE Devices ..............11
4.3.1. Distinguishing Factors between IPv4 and IPv6 .......11
4.3.2. Requirements for PEs ...............................12
4.3.3. Processing of Neighbor Solicitations ...............12
4.3.4. Processing of Neighbor Advertisements ..............13
4.3.5. Processing Inverse Neighbor Solicitations (INSs) ...14
4.3.6. Processing of Inverse Neighbor
Advertisements (INAs) ..............................15
4.3.7. Processing of Router Solicitations .................15
4.3.8. Processing of Router Advertisements ................15
4.3.9. Duplicate Address Detection ........................16
4.3.10. CE Address Discovery for CEs Attached Using PPP ...16
5. CE IPv4 Address Signaling between PEs ..........................16
5.1. When to Signal an IPv4 Address of a CE ....................16
5.2. LDP-Based Distribution of CE IPv4 Addresses ...............17
6. IPv6 Capability Advertisement ..................................20
6.1. PW Operational Down on Stack Capability Mismatch ..........21
6.2. Stack Capability Fallback .................................21
7. IANA Considerations ............................................22
7.1. LDP Status Messages .......................................22
7.2. Interface Parameters ......................................22
8. Security Considerations ........................................22
8.1. Control Plane Security ....................................23
8.2. Data Plane Security .......................................24
9. Acknowledgements ...............................................24
10. Contributors ..................................................24
11. References ....................................................25
11.1. Normative References .....................................25
11.2. Informative References ...................................26
Appendix A. Use of IGPs with IP L2 Interworking L2VPNs ...........27
A.1. OSPF ......................................................27
A.2. RIP .......................................................27
A.3. IS-IS .....................................................28
Layer 2 Virtual Private Networks (L2VPNs) are constructed over a Service Provider IP/MPLS backbone but are presented to the Customer Edge (CE) devices as Layer 2 networks. In theory, L2VPNs can carry any Layer 3 protocol, but in many cases, the Layer 3 protocol is IP. Thus, it makes sense to consider procedures that are optimized for IP.
レイヤー2バーチャルプライベートネットワーク（L2VPN）は、サービスプロバイダーのIP / MPLSバックボーンを介して構築されますが、カスタマーエッジ（CE）デバイスにはレイヤー2ネットワークとして提示されます。理論上、L2VPNは任意のレイヤー3プロトコルを伝送できますが、多くの場合、レイヤー3プロトコルはIPです。したがって、IPに最適化された手順を検討することは理にかなっています。
In a typical implementation, illustrated in the diagram below, the CE devices are connected to the Provider Edge (PE) devices via Attachment Circuits (ACs). The ACs are Layer 2 circuits. In a pure L2VPN, if traffic sent from CE1 via AC1 reaches CE2 via AC2, both ACs would have to be of the same type (i.e., both Ethernet, both Frame Relay, etc.). However, if it is known that only IP traffic will be carried, the ACs can be of different technologies, provided that the PEs provide the appropriate procedures to allow the proper transfer of IP packets.
次の図に示す典型的な実装では、CEデバイスは、接続回路（AC）を介してプロバイダーエッジ（PE）デバイスに接続されます。 ACはレイヤ2回路です。純粋なL2VPNでは、AC1を介してCE1から送信されたトラフィックがAC2を介してCE2に到達する場合、両方のACが同じタイプである必要があります（つまり、両方のイーサネット、両方のフレームリレーなど）。ただし、IPトラフィックのみが伝送されることがわかっている場合、PEがIPパケットの適切な転送を可能にするための適切な手順を提供する限り、ACはさまざまなテクノロジーを使用できます。
+-----+
+------ -----| CE3 |
|AC3 +-----+
+-----+
......| PE3 |...........
. +-----+ .
. | .
. | .
+-----+ AC1 +-----+ Service +-----+ AC2 +-----+
| CE1 |-----| PE1 |--- Provider ----| PE2 |-----| CE2 |
+-----+ +-----+ Backbone +-----+ +-----+
. .
........................
A CE, which is connected via a given type of AC, may use an IP address resolution procedure that is specific to that type of AC. For example, an Ethernet-attached IPv4 CE would use ARP [RFC826] and a Frame-Relay-attached CE might use Inverse ARP [RFC2390]. If we are to allow the two CEs to have a Layer 2 connection between them, even though each AC uses a different Layer 2 technology, the PEs must intercept and "mediate" the Layer-2-specific address resolution procedures.
特定のタイプのACを介して接続されているCEは、そのタイプのACに固有のIPアドレス解決手順を使用できます。たとえば、イーサネット接続のIPv4 CEはARP [RFC826]を使用し、フレームリレー接続のCEはInverse ARP [RFC2390]を使用します。各ACが異なるレイヤー2テクノロジーを使用していても、2つのCE間のレイヤー2接続を許可する場合、PEはレイヤー2固有のアドレス解決手順を傍受し、「仲介」する必要があります。
In this document, we specify the procedures for VPWS services [RFC4664], which the PEs need to implement in order to mediate the IP address resolution mechanism. We call these procedures "ARP Mediation". Consider a Virtual Private Wire Service (VPWS) constructed between CE1 and CE2 in the diagram above. If AC1 and AC2 are of different technologies, e.g., AC1 is Ethernet and AC2 is Frame Relay (FR), then ARP requests coming from CE1 cannot be passed transparently to CE2. PE1 MUST interpret the meaning of the ARP requests and mediate the necessary information with PE2 before responding.
このドキュメントでは、IPアドレス解決メカニズムを仲介するためにPEが実装する必要があるVPWSサービス[RFC4664]の手順を指定します。これらの手順を「ARP調停」と呼びます。上の図のCE1とCE2の間に構築されたVirtual Private Wire Service（VPWS）について考えてみます。 AC1とAC2のテクノロジーが異なる場合（AC1がイーサネットで、AC2がフレームリレー（FR）の場合）、CE1からのARP要求を透過的にCE2に渡すことはできません。 PE1はARP要求の意味を解釈し、応答する前にPE2で必要な情報を仲介する必要があります。
This document uses the term "ARP" to mean any protocol that is used to resolve IP addresses to link-layer addresses. For instance, in IPv4, ARP and Inverse ARP protocols are used for address resolution while in IPv6, Neighbor Discovery [RFC4861] and Inverse Neighbor Discovery [RFC3122] based on ICMPv6 are used for address resolution.
このドキュメントでは、「ARP」という用語を使用して、IPアドレスをリンク層アドレスに解決するために使用されるプロトコルを意味します。たとえば、IPv4では、アドレス解決にARPおよび逆ARPプロトコルが使用されますが、IPv6では、アドレス解決にICMPv6に基づくネイバー探索[RFC4861]およびインバース近接探索[RFC3122]が使用されます。
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]で説明されているように解釈されます。
The ARP Mediation (AM) function is an element of a PE node that deals with the IP address resolution for CE devices connected via a VPWS L2VPN. By placing this function in the PE node, ARP Mediation is transparent to the CE devices.
ARPメディエーション（AM）機能は、VPWS L2VPNを介して接続されたCEデバイスのIPアドレス解決を処理するPEノードの要素です。この機能をPEノードに配置することにより、ARPメディエーションはCEデバイスに対して透過的です。
For a given point-to-point connection between a pair of CEs, the ARP Mediation procedure depends on whether the packets being forwarded are IPv4 or IPv6. A PE that is to perform ARP Mediation for IPv4 packets MUST perform the following logical steps:
CEのペア間の特定のポイントツーポイント接続の場合、ARPメディエーション手順は、転送されるパケットがIPv4かIPv6かによって異なります。 IPv4パケットのARPメディエーションを実行するPEは、次の論理的な手順を実行する必要があります。
1. Discover the IP address of the locally attached CE device.
1. ローカルに接続されたCEデバイスのIPアドレスを検出します。
2. Terminate. Do not forward ARP and Inverse ARP requests from the CE device at the local PE.
2. 終了します。ローカルPEのCEデバイスからのARPおよびInverse ARP要求を転送しないでください。
3. Distribute the IP address to the remote PE using pseudowire control signaling.
3. 疑似配線制御シグナリングを使用して、リモートPEにIPアドレスを配布します。
4. Notify the locally attached CE of the IP address of the remote CE.
4. ローカルに接続されたCEにリモートCEのIPアドレスを通知します。
5. Respond appropriately to ARP and Inverse ARP requests from the local CE device using the IP address of the remote CE and the hardware address of the local PE.
5. リモートCEのIPアドレスとローカルPEのハードウェアアドレスを使用して、ローカルCEデバイスからのARPおよびInverse ARP要求に適切に応答します。
A PE that is to perform ARP Mediation for IPv6 packets MUST perform the following logical steps:
IPv6パケットのARPメディエーションを実行するPEは、次の論理手順を実行する必要があります。
1. Discover the IPv6 addresses of the locally attached CE device, together with those of the remote CE device.
1. ローカルに接続されたCEデバイスのIPv6アドレスと、リモートCEデバイスのIPv6アドレスを検出します。
2. Perform the following steps:
2. 次の手順を実行します。
a. Intercept Neighbor Discovery (ND) and Inverse Neighbor Discovery (IND) packets received from the local CE device.
a. ローカルCEデバイスから受信した傍受ネイバー探索（ND）および逆ネイバー探索（IND）パケット。
b. From these ND and IND packets, learn the IPv6 configuration of the CE.
b. これらのNDおよびINDパケットから、CEのIPv6構成を学習します。
c. Forward the ND and IND packets over the pseudowire to the remote PE.
c. NDおよびINDパケットを疑似配線を介してリモートPEに転送します。
3. Intercept Neighbor Discovery and Inverse Neighbor Discovery packets received over the pseudowire from the remote PE, possibly modifying them (if required for the type of outgoing AC) before forwarding to the local CE and learning information about the IPv6 configuration of the remote CE.
3. ローカルCEに転送してリモートCEのIPv6構成に関する情報を学習する前に、リモートPEから疑似配線を介して受信した傍受ネイバー探索パケットと逆ネイバー探索パケットを変更します（発信ACのタイプに必要な場合）。
Details for the procedures described above are given in the following sections.
上記の手順の詳細については、次のセクションで説明します。
The IP Layer 2 Interworking Circuit refers to interconnection of the Attachment Circuit with the IP Layer 2 Transport pseudowire that carries IP datagrams as the payload. The ingress PE removes the data link header of its local Attachment Circuit and transmits the payload (an IP packet) over the pseudowire with or without the optional control word. If the IP packet arrives at the ingress PE with multiple data link headers (for example, in the case of bridged Ethernet PDU on an ATM Attachment Circuit), all data link headers MUST be removed from the IP packet before transmission over the pseudowire (PW). The egress PE encapsulates the IP packet with the data link header used on its local Attachment Circuit.
IPレイヤ2インターワーキングサーキットは、アタッチメントサーキットと、IPデータグラムをペイロードとして伝送するIPレイヤ2トランスポート疑似配線との相互接続を指します。入力PEは、ローカルの接続回路のデータリンクヘッダーを削除し、オプションの制御ワードの有無にかかわらず、疑似配線を介してペイロード（IPパケット）を送信します。 IPパケットが複数のデータリンクヘッダーを持つ入力PEに到着する場合（たとえば、ATM接続回路のブリッジイーサネットPDUの場合）、すべてのデータリンクヘッダーは、疑似配線（PW ）。出力PEは、ローカル接続回線で使用されるデータリンクヘッダーを使用してIPパケットをカプセル化します。
The encapsulation for the IP Layer 2 Transport pseudowire is described in [RFC4447]. The "IP Layer 2 Interworking Circuit" pseudowire is also referred to as "IP pseudowire" in this document.
IPレイヤ2トランスポート疑似配線のカプセル化は、[RFC4447]で説明されています。 「IPレイヤ2インターワーキング回線」疑似配線は、このドキュメントでは「IP疑似配線」とも呼ばれます。
In the case of an IPv6 L2 Interworking Circuit, the egress PE MAY modify the contents of Neighbor Discovery or Inverse Neighbor Discovery packets before encapsulating the IP packet with the data link header.
IPv6 L2インターワーキングサーキットの場合、出力PEは、データリンクヘッダーでIPパケットをカプセル化する前に、近隣探索パケットまたは逆近隣探索パケットの内容を変更できます（MAY）。
An IP Layer 2 Interworking Circuit enters monitoring state immediately after configuration. During this state, it performs two functions:
IPレイヤ2インターワーキングサーキットは、設定直後にモニタリング状態になります。この状態の間、2つの機能を実行します。
o Discovery of the CE IP device(s)
o CE IPデバイスの検出
o Establishment of the PW
o PWの設立
The establishment of the PW occurs independently from local CE IP address discovery. During the period when the PW has been established but the local CE IP device has not been discovered, only broadcast/multicast IP frames are propagated between the Attachment Circuit and pseudowire; unicast IP datagrams are dropped. The IP destination address is used to classify unicast/multicast packets.
PWの確立は、ローカルCE IPアドレスの検出とは無関係に行われます。 PWが確立されているがローカルCE IPデバイスが検出されていない期間中は、アタッチメント回線と疑似配線の間でブロードキャスト/マルチキャストIPフレームのみが伝播されます。ユニキャストIPデータグラムはドロップされます。 IP宛先アドレスは、ユニキャスト/マルチキャストパケットの分類に使用されます。
Unicast IP frames are propagated between the AC and pseudowire only when CE IP devices on both Attachment Circuits have been discovered and notified and proxy functions have completed.
ユニキャストIPフレームは、両方の接続回線上のCE IPデバイスが検出および通知され、プロキシ機能が完了した場合にのみ、ACと疑似配線の間で伝播されます。
The need to wait for address resolution completion before unicast IP traffic can flow is simple.
ユニキャストIPトラフィックが流れる前にアドレス解決の完了を待つ必要は簡単です。
o PEs do not perform routing operations.
o PEはルーティング操作を実行しません。
o The destination IP address in the packet is not necessarily that of the attached CE.
o パケットの宛先IPアドレスは、必ずしも接続されたCEのアドレスではありません。
o On a broadcast link, there is no way to find out the Media Access Control (MAC) address of the CE based on the destination IP address of the packet.
o ブロードキャストリンクでは、パケットの宛先IPアドレスに基づいてCEのメディアアクセス制御（MAC）アドレスを見つける方法はありません。
A PE MUST support manual configuration of IPv4 CE addresses. This section also describes automated mechanisms by which a PE MAY also discover an IPv4 CE address.
PEはIPv4 CEアドレスの手動構成をサポートする必要があります。このセクションでは、PEがIPv4 CEアドレスも検出できる自動化メカニズムについても説明します。
The PE devices MAY learn the IP addresses of the locally attached CEs from any IP traffic, such as link-local multicast packets (e.g., destined to 224.0.0.x), and are not restricted to the operations below.
PEデバイスは、ローカルに接続されたCEのIPアドレスを、リンクローカルマルチキャストパケット（224.0.0.x宛てなど）などのIPトラフィックから学習できます（以下の操作に限定されません）。
If a CE device uses ARP to determine the IP-address-to-MAC-address binding of its neighbor, the PE processes the ARP requests to learn the IP address of the local CE for the local Attachment Circuit.
CEデバイスがARPを使用してネイバーのIPアドレスとMACアドレスのバインディングを決定する場合、PEはARP要求を処理して、ローカル接続回線のローカルCEのIPアドレスを学習します。
The method described in this document only supports the case where there is a single CE per Attachment Circuit. However, customer-facing access topologies may exist whereby more than one CE appears to be connected to the PE on a single Attachment Circuit. For example, this could be the case when CEs are connected to a shared LAN that connects to the PE. In such a case, the PE MUST select one local CE. The selection could be based on manual configuration or the PE MAY optionally use the following selection criteria. In either case, manual configuration of the IP address of the local CE (and its MAC address) MUST be supported.
このドキュメントで説明する方法は、接続回線ごとにCEが1つある場合のみをサポートします。ただし、顧客向けのアクセストポロジが存在する場合があります。これにより、複数のCEが単一の接続回線上のPEに接続されているように見えます。たとえば、これは、CEがPEに接続する共有LANに接続されている場合です。そのような場合、PEは1つのローカルCEを選択する必要があります。選択は手動構成に基づくか、またはPEはオプションで次の選択基準を使用できます。どちらの場合も、ローカルCEのIPアドレス（およびそのMACアドレス）の手動構成をサポートする必要があります。
o Wait to learn the IP address of the remote CE (through PW signaling) and then select the local CE that is sending the request for IP address of the remote CE.
o （PWシグナリングを介して）リモートCEのIPアドレスを学習するのを待ってから、リモートCEのIPアドレスの要求を送信しているローカルCEを選択します。
o Augment cross-checking with the local IP address learned through listening for link-local multicast packets (as per Section 4.1.1).
o リンクローカルマルチキャストパケットのリッスンを通じて学習したローカルIPアドレスとのクロスチェックを強化します（セクション4.1.1のとおり）。
o Augment cross-checking with the local IP address learned through the Router Discovery Protocol (as described in Section 4.1.5).
o ルーター検出プロトコルを通じて学習したローカルIPアドレスとのクロスチェックを強化します（セクション4.1.5で説明）。
o There is still a possibility that the local PE may not receive an IP address advertisement from the remote PE, and there may exist multiple local IP routers that attempt to 'connect' to remote CEs. In this situation, the local PE MAY use some other criteria to select one IP device from many (such as "the first ARP received"), or an operator MAY configure the IP address of the local CE. Note that the operator does not have to configure the IP address of the remote CE (as that would be learned through pseudowire signaling).
o ローカルPEがリモートPEからIPアドレスアドバタイズを受信できず、リモートCEに「接続」しようとするローカルIPルータが複数存在する可能性があります。この状況では、ローカルPEは他のいくつかの基準を使用して、多くのIPデバイス（「最初に受信したARP」など）から1つを選択するか、またはオペレーターがローカルCEのIPアドレスを構成する場合があります。オペレーターはリモートCEのIPアドレスを構成する必要がないことに注意してください（これは、疑似配線シグナリングによって学習されるため）。
Once the local and remote CEs have been discovered for the given Attachment Circuit, the local PE responds with its own MAC address to any subsequent ARP requests from the local CE with a destination IP address matching the IP address of the remote CE.
特定の接続回線のローカルおよびリモートCEが検出されると、ローカルPEは、リモートCEのIPアドレスと一致する宛先IPアドレスを使用して、ローカルCEからの後続のARP要求に独自のMACアドレスで応答します。
The local PE signals the IP address of the local CE to the remote PE and MAY initiate an unsolicited ARP response to notify the IP-address-to-MAC-address binding for the remote CE to the local CE (again using its own MAC address).
ローカルPEはローカルCEのIPアドレスをリモートPEに通知し、非自発的ARP応答を開始して、リモートCEのIPアドレスとMACアドレスのバインディングをローカルCEに通知できます（再び独自のMACアドレスを使用します）。 ）。
Once the ARP Mediation function is completed (i.e., the PE device knows both the local and remote CE IP addresses), unicast IP frames are propagated between the AC and the established PW.
ARPメディエーション機能が完了すると（つまり、PEデバイスはローカルとリモートの両方のCE IPアドレスを認識）、ユニキャストIPフレームがACと確立されたPWの間で伝播されます。
The PE MAY periodically generate ARP request messages for the IP address of the CE as a means of verifying the continued existence of the IP address and its MAC address binding. The absence of a response from the CE device for a given number of retries could be used as a trigger for withdrawal of the IP address advertisement to the remote PE. The local PE would then re-enter the address resolution phase to rediscover the IP address of the attached CE. Note that this "heartbeat" scheme is needed only where the failure of a CE device may otherwise be undetectable.
PEは、IPアドレスとそのMACアドレスバインディングの継続的な存在を確認する手段として、CEのIPアドレスに対するARP要求メッセージを定期的に生成する場合があります。所定の再試行回数に対するCEデバイスからの応答がないことは、リモートPEへのIPアドレスアドバタイズメントの撤回のトリガーとして使用できます。次に、ローカルPEは、アドレス解決フェーズに入り、接続されているCEのIPアドレスを再検出します。この「ハートビート」スキームは、CEデバイスの障害が検出されない場合にのみ必要であることに注意してください。
If a CE device uses Inverse ARP to determine the IP address of its neighbor, the attached PE processes the Inverse ARP request from the Attachment Circuit and responds with an Inverse ARP reply containing the IP address of the remote CE, if the address is known. If the PE does not yet have the IP address of the remote CE, it does not respond, but records the IP address of the local CE and the circuit information. Subsequently, when the IP address of the remote CE becomes available, the PE MAY initiate an Inverse ARP request as a means of notifying the local CE of the IP address of the remote CE.
CEデバイスがInverse ARPを使用してネイバーのIPアドレスを決定する場合、接続されたPEは、接続回線からのInverse ARP要求を処理し、アドレスがわかっている場合はリモートCEのIPアドレスを含むInverse ARP応答で応答します。 PEがまだリモートCEのIPアドレスを持っていない場合、PEは応答しませんが、ローカルCEのIPアドレスと回線情報を記録します。その後、リモートCEのIPアドレスが使用可能になると、PEは、リモートCEのIPアドレスをローカルCEに通知する手段として、逆ARP要求を開始できます（MAY）。
This is the typical mode of operation for Frame Relay and ATM Attachment Circuits. If the CE does not use Inverse ARP, the PE can still discover the IP address of the local CE using the mechanisms described in Sections 4.1.1 and 4.1.5.
これは、フレームリレーおよびATM接続回線の一般的な動作モードです。 CEがInverse ARPを使用しない場合でも、PEは、セクション4.1.1および4.1.5で説明されているメカニズムを使用して、ローカルCEのIPアドレスを検出できます。
The IP Control Protocol [RFC1332] describes a procedure to establish and configure IP on a point-to-point connection, including the negotiation of IP addresses. When such an Attachment Circuit is configured for IP interworking, PPP negotiation is not performed end-to-end between CE devices. Instead, PPP negotiation takes place between the CE and its local PE. The PE performs proxy PPP negotiation and informs the attached CE of the IP address of the remote CE during IP Control Protocol (IPCP) negotiation using the IP-Address option (0x03).
IP Control Protocol [RFC1332]は、IPアドレスのネゴシエーションを含め、ポイントツーポイント接続でIPを確立および構成する手順を説明しています。このような接続回線がIPインターワーキング用に構成されている場合、PPPネゴシエーションはCEデバイス間でエンドツーエンドで実行されません。代わりに、PPPネゴシエーションはCEとそのローカルPEの間で行われます。 PEはプロキシPPPネゴシエーションを実行し、IPアドレスオプション（0x03）を使用してIP制御プロトコル（IPCP）ネゴシエーション中にリモートCEのIPアドレスを接続されているCEに通知します。
When a PPP link completes Link Control Protocol (LCP) negotiations, the local PE MAY perform the following IPCP actions:
PPPリンクがリンク制御プロトコル（LCP）ネゴシエーションを完了すると、ローカルPEは次のIPCPアクションを実行できます（MAY）。
o The PE learns the IP address of the local CE from the Configure-Request received with the IP-Address option (0x03). If the IP address is non-zero, the PE records the address and responds with Configure-Ack. However, if the IP address is zero, the PE responds with Configure-Reject (as this is a request from the CE to assign it an IP address). Also, the IP-Address option is set with a zero value in the Configure-Reject response to instruct the CE not to include that option in any subsequent Configure-Request.
o PEは、IP-Addressオプション（0x03）で受信したConfigure-RequestからローカルCEのIPアドレスを学習します。 IPアドレスがゼロ以外の場合、PEはアドレスを記録し、Configure-Ackで応答します。ただし、IPアドレスがゼロの場合、PEはConfigure-Rejectで応答します（これはCEからの要求であり、IPアドレスを割り当てるためです）。また、IP-Addressオプションは、Configure-Reject応答でゼロ値で設定され、そのオプションを後続のConfigure-Requestに含めないようにCEに指示します。
o If the PE receives a Configure-Request without the IP-Address option, it responds with a Configure-Ack. In this case, the PE is unable to learn the IP address of the local CE using IPCP; hence, it MUST rely on other means as described in Sections 4.1.1 and 4.1.5. Note that in order to employ other learning mechanisms, the IPCP negotiations MUST have reached the open state.
o PEがIP-AddressオプションなしでConfigure-Requestを受信すると、Configure-Ackで応答します。この場合、PEはIPCPを使用してローカルCEのIPアドレスを学習できません。したがって、セクション4.1.1および4.1.5で説明されている他の手段に依存する必要があります。他の学習メカニズムを使用するには、IPCPネゴシエーションがオープン状態になっている必要があります。
o If the PE does not know the IP address of the remote CE, it sends a Configure-Request without the IP-Address option.
o PEがリモートCEのIPアドレスを知らない場合、IP-AddressオプションなしでConfigure-Requestを送信します。
o If the PE knows the IP address of the remote CE, it sends a Configure-Request with the IP-Address option containing the IP address of the remote CE.
o PEがリモートCEのIPアドレスを知っている場合は、リモートCEのIPアドレスを含むIP-Addressオプションを含むConfigure-Requestを送信します。
The IPCP IP-Address option MAY be negotiated between the PE and the local CE device. Configuration of other IPCP options MAY be rejected. Other Network Control Protocols (NCPs), with the exception of the Compression Control Protocol (CCP) and the Encryption Control Protocol (ECP), MUST be rejected. The PE device MAY reject configuration of the CCP and ECP.
IPCP IPアドレスオプションは、PEとローカルCEデバイスの間でネゴシエートされる場合があります。他のIPCPオプションの構成は拒否される場合があります。圧縮制御プロトコル（CCP）と暗号化制御プロトコル（ECP）を除く他のネットワーク制御プロトコル（NCP）は、拒否する必要があります。 PEデバイスは、CCPおよびECPの構成を拒否する場合があります。
In order to learn the IP address of the CE device for a given Attachment Circuit, the PE device MAY execute the Router Discovery Protocol [RFC1256] whereby a Router Discovery Request (ICMP - Router Solicitation) message is sent using a source IP address of zero. The IP address of the CE device is extracted from the Router Discovery Response (ICMP - Router Advertisement) message from the CE. It is possible that the response contains more than one router address with the same preference level, in which case, some heuristics (such as first on the list) are necessary. The use of the Router Discovery method by the PE is optional.
特定の接続回路のCEデバイスのIPアドレスを学習するために、PEデバイスはルーター発見プロトコル[RFC1256]を実行してもよい（MAY）。これにより、ゼロのソースIPアドレスを使用してルーター発見要求（ICMP-ルーター要請）メッセージが送信されます。 。 CEデバイスのIPアドレスは、CEからのルーター検出応答（ICMP-ルーターアドバタイズ）メッセージから抽出されます。応答に同じ優先レベルを持つ複数のルーターアドレスが含まれている可能性があります。その場合、いくつかのヒューリスティック（リストの最初など）が必要です。 PEによるルーター検出方法の使用はオプションです。
In some cases, it may not be possible to discover the IP address of the local CE device using the mechanisms described in Sections 4.1.1 to 4.1.5. In such cases, manual configuration MAY be used. All implementations of this document MUST support manual configuration of the IPv4 address of the local CE. This is the only REQUIRED mode for a PE to support.
場合によっては、セクション4.1.1から4.1.5で説明されているメカニズムを使用してローカルCEデバイスのIPアドレスを検出できない場合があります。そのような場合、手動設定が使用される場合があります。このドキュメントのすべての実装は、ローカルCEのIPv4アドレスの手動構成をサポートする必要があります。これは、PEがサポートする唯一の必須モードです。
The support for configuration of the IP address of the remote CE is OPTIONAL.
リモートCEのIPアドレスの構成のサポートはオプションです。
Once the local PE has received the IP address information of the remote CE from the remote PE, it will either initiate an address resolution request or respond to an outstanding request from the attached CE device.
ローカルPEは、リモートPEからリモートCEのIPアドレス情報を受信すると、アドレス解決要求を開始するか、接続されているCEデバイスからの未解決の要求に応答します。
In the event that the IPv4 address of the remote CE is manually configured, the address resolution can begin immediately as receipt of remote IP address of the CE becomes unnecessary.
リモートCEのIPv4アドレスが手動で構成されている場合、CEのリモートIPアドレスの受信が不要になるため、アドレス解決をすぐに開始できます。
When the PE learns the IP address of the remote CE as described in Section 5.1, it may or may not already know the IP address of the local CE. If the IP address is not known, the PE MUST wait until it is acquired through one of the methods described in Sections 4.1.1, 4.1.2, and 4.1.5. If the IP address of the local CE is known, the PE MAY choose to generate an unsolicited ARP message to notify the local CE about the binding of the IP address of the remote CE with the PE's own MAC address.
セクション5.1で説明されているように、PEがリモートCEのIPアドレスを学習するとき、PEはローカルCEのIPアドレスをすでに知っている場合と知らない場合があります。 IPアドレスが不明である場合、PEは、セクション4.1.1、4.1.2、および4.1.5で説明されている方法のいずれかによって取得されるまで待機する必要があります。ローカルCEのIPアドレスがわかっている場合、PEは非請求ARPメッセージを生成して、リモートCEのIPアドレスとPE自身のMACアドレスのバインディングについてローカルCEに通知することを選択できます（MAY）。
When the local CE generates an ARP request, the PE MUST proxy the ARP response [RFC925] using its own MAC address as the source hardware address and the IP address of the remote CE as the source protocol address. The PE MUST respond only to those ARP requests whose destination protocol address matches the IP address of the remote CE.
ローカルCEがARP要求を生成するとき、PEは自身のMACアドレスをソースハードウェアアドレスとして使用し、リモートCEのIPアドレスをソースプロトコルアドレスとして使用してARP応答[RFC925]をプロキシする必要があります。 PEは、宛先プロトコルアドレスがリモートCEのIPアドレスと一致するARP要求にのみ応答する必要があります。
When the PE learns the IP address of the remote CE, it SHOULD generate an Inverse ARP request. If the Attachment Circuit requires activation (e.g., Frame Relay), the PE SHOULD activate it first before the Inverse ARP request. It should be noted that the PE might never receive the response to its own request, nor see any Inverse ARP request from the CE, in cases where the CE is pre-configured with the IP address of the remote CE or where the use of Inverse ARP has not been enabled. In either case, the CE has used other means to learn the IP address of its neighbor.
PEがリモートCEのIPアドレスを学習すると、逆ARP要求を生成する必要があります。接続回線がアクティブ化を必要とする場合（フレームリレーなど）、PEは、逆ARP要求の前に最初にアクティブ化する必要があります（SHOULD）。 CEがリモートCEのIPアドレスで事前に構成されている場合、またはInverseの使用が行われている場合、PEはそれ自体の要求に対する応答を受信できず、CEからのInverse ARP要求も表示しない可能性があることに注意してください。 ARPが有効になっていません。どちらの場合も、CEは他の手段を使用して、そのネイバーのIPアドレスを学習しました。
When the PE learns the IP address of the remote CE, it SHOULD initiate a Configure-Request and set the IP-Address option to the IP address of the remote CE. This notifies the local CE of the IP address of the remote CE.
PEがリモートCEのIPアドレスを学習すると、構成要求を開始して、IPアドレスオプションをリモートCEのIPアドレスに設定する必要があります。これにより、リモートCEのIPアドレスがローカルCEに通知されます。
IPv4 uses ARP and Inverse ARP to resolve IP address and link-layer associations. Since these are dedicated address resolution protocols, and not IP packets, they cannot be carried on an IP pseudowire. They MUST be processed locally and the IPv4 address information they carry signaled between the PEs using the pseudowire control plane. IPv6 uses ICMPv6 extensions to resolve IP address and link address associations. As these are IPv6 packets, they can be carried on an IP pseudowire; therefore, no IPv6 address signaling is required.
IPv4はARPおよびInverse ARPを使用して、IPアドレスとリンク層の関連付けを解決します。これらは専用のアドレス解決プロトコルであり、IPパケットではないため、IP疑似配線では伝送できません。それらはローカルで処理されなければならず、それらが運ぶIPv4アドレス情報は、疑似配線コントロールプレーンを使用してPE間でシグナリングされます。 IPv6はICMPv6拡張を使用して、IPアドレスとリンクアドレスの関連付けを解決します。これらはIPv6パケットであるため、IP疑似配線で伝送できます。したがって、IPv6アドレスシグナリングは必要ありません。
A PE device that supports IPv6 MUST be capable of the following:
IPv6をサポートするPEデバイスは、次の機能を備えている必要があります。
o Intercepting ICMPv6 Neighbor Discovery [RFC4861] and Inverse Neighbor Discovery [RFC3122] packets received over the AC as well as over the PW,
o ACおよびPWを介して受信されたICMPv6ネイバー探索[RFC4861]およびインバースネイバー探索[RFC3122]パケットの傍受
o Recording the IPv6 interface addresses and CE link-layer addresses present in these packets,
o これらのパケットに存在するIPv6インターフェイスアドレスとCEリンク層アドレスを記録し、
o Possibly modifying these packets as dictated by the data link type of the egress AC (described in the following sections), and
o 出力ACのデータリンクタイプ（次のセクションで説明）の指示に従って、これらのパケットを変更する可能性があります。
o Forwarding them towards the original destination.
o 元の宛先に転送します。
The PE MUST also be capable of generating packets in order to interwork between Neighbor Discovery (ND) and Inverse Neighbor Discovery (IND). This is specified in Sections 4.3.3 to 4.3.6.
PEはまた、ネイバーディスカバリー（ND）とインバースネイバーディスカバリー（IND）の間で相互作用するためにパケットを生成できなければなりません（MUST）。これはセクション4.3.3から4.3.6で指定されています。
If an IP PW is used to interconnect CEs that use IPv6 Router Discovery [RFC4861], a PE device MUST also be capable of intercepting and processing those Router Discovery packets. This is required in order to translate between different link-layer addresses. If a Router Discovery message contains a link-layer address, then the PE MAY also use this message to discover the link-layer address and IPv6 interface address. This is described in more detail in Sections 4.3.7 and 4.3.8.
IP PWがIPv6ルーター発見[RFC4861]を使用するCEを相互接続するために使用される場合、PEデバイスはそれらのルーター発見パケットを傍受して処理することもできる必要があります。これは、異なるリンク層アドレス間で変換するために必要です。ルーター検出メッセージにリンク層アドレスが含まれている場合、PEはこのメッセージを使用してリンク層アドレスとIPv6インターフェイスアドレスを検出する場合があります。これについては、4.3.7項と4.3.8項で詳しく説明します。
The PE device MUST learn a list of CE IPv6 interface addresses for its directly attached CE and another list of CE IPv6 interface addresses for the far-end CE. The PE device MUST also learn the link-layer address of the local CE and be able to use it when forwarding traffic between the local and far-end 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.
PEデバイスは、直接接続されているCEのCE IPv6インターフェイスアドレスのリストと、遠端CEのCE IPv6インターフェイスアドレスの別のリストを学習する必要があります。 PEデバイスは、ローカルCEのリンク層アドレスも学習し、ローカルCEと遠端CEの間でトラフィックを転送するときにそれを使用できる必要があります。 PEは、CEから受信したデータパケットのソースリンク層アドレスを監視し、学習したCEリンク層アドレスに一致しないパケットを破棄することもできます（MAY）。
A Neighbor Solicitation received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address (if provided, this will not be the case for Duplicate Address Detection) and any link-layer address provided. The packet MUST then be forwarded over the pseudowire unmodified. A Neighbor Solicitation received over the pseudowire SHOULD be inspected to determine and learn an IPv6 interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute an appropriate link-layer address option, specifying the link-layer address of the PE interface attached to the local AC. Note that if the local AC is Ethernet, failure to substitute a link-layer address option may mean that the CE has no valid link-layer address with which to transmit data packets.
ローカルCEからACで受信した近隣要請は、IPv6インターフェースアドレス（提供されている場合、重複アドレス検出の場合は該当しません）および提供されているリンク層アドレスを決定および学習するために検査する必要があります（SHOULD）。その後、パケットは変更されずに疑似配線を介して転送される必要があります。疑似配線を介して受信された近隣要請は、遠端CEのIPv6インターフェイスアドレスを決定および学習するために検査する必要があります（SHOULD）。ソースリンク層アドレスオプションが存在する場合、PEはそれを削除する必要があります。 PEは、ローカルACに接続されたPEインターフェイスのリンク層アドレスを指定して、適切なリンク層アドレスオプションを代用してもよい（MAY）。ローカルACがイーサネットの場合、リンク層アドレスオプションの代用に失敗すると、CEにデータパケットを送信するための有効なリンク層アドレスがない可能性があります。
When a PE with a local AC, which is of the type point-to-point Layer 2 circuit, e.g., FR, ATM or PPP, receives a Neighbor Solicitation from a far-end PE over the pseudowire, after learning the IP address of the far-end CE, the PE MAY use one of the following procedures:
ポイントツーポイントレイヤ2回線タイプのローカルACを持つPE、たとえば、FR、ATM、またはPPPが、IPアドレスを学習した後、疑似配線を介して遠端PEから近隣要請を受信した場合遠端CEの場合、PEは次のいずれかの手順を使用できます。
1. Forward the Neighbor Solicitation to the local CE after replacing the source link-layer address with the link-layer address of the local AC.
1. ソースリンク層アドレスをローカルACのリンク層アドレスに置き換えた後、近隣要請をローカルCEに転送します。
2. Send an Inverse Neighbor Solicitation to the local CE, specifying the far-end CE's IP address and the link-layer address of the PE interface attached to local AC.
2. ローカルACに接続されているPEインターフェイスの遠端CEのIPアドレスとリンク層アドレスを指定して、逆近傍要請をローカルCEに送信します。
3. Reply to the far-end PE with a Neighbor Advertisement, using the IP address of the local CE as the source address and an appropriate link-layer address option that specifies the link-layer address of the PE interface attached to local AC. As described in Section 4.3.10, the IP address of the local CE is learned through IPv6 Control Protocol (IPv6CP) in the case of PPP and through Neighbor Solicitation in other cases.
3. 送信元アドレスとしてローカルCEのIPアドレスを使用し、ローカルACに接続されたPEインターフェイスのリンク層アドレスを指定する適切なリンク層アドレスオプションを使用して、ネイバーアドバタイズメントで遠端PEに返信します。 4.3.10項で説明したように、ローカルCEのIPアドレスは、PPPの場合はIPv6制御プロトコル（IPv6CP）を介して学習され、その他の場合は近隣要請を介して学習されます。
A Neighbor Advertisement received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 interface address and any link-layer address provided. The packet MUST then be forwarded over the IP pseudowire unmodified.
ローカルCEからACで受信されたネイバーアドバタイズメントを検査して、IPv6インターフェイスアドレスと提供されたリンク層アドレスを判別および学習する必要があります（SHOULD）。その後、パケットは変更されずにIP疑似配線を介して転送される必要があります。
A Neighbor Advertisement received over the pseudowire SHOULD be inspected to determine and learn an IPv6 interface address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute an appropriate link-layer address option, specifying the link-layer address of the PE interface attached to local AC. Note that if the local AC is Ethernet, failure to substitute a link-layer address option may mean that the local AC has no valid link-layer address with which to transmit data packets.
疑似配線を介して受信されたネイバーアドバタイズメントを検査して、遠端CEのIPv6インターフェイスアドレスを決定および学習する必要があります（SHOULD）。ソースリンク層アドレスオプションが存在する場合、PEはそれを削除する必要があります。 PEは、ローカルACに接続されたPEインターフェイスのリンク層アドレスを指定して、適切なリンク層アドレスオプションを代用してもよい（MAY）。ローカルACがイーサネットの場合、リンク層アドレスオプションの代替に失敗すると、ローカルACにデータパケットを送信するための有効なリンク層アドレスがない可能性があります。
When a PE with a local AC that is of the type point-to-point Layer 2 circuit, such as ATM, FR, or PPP, receives a Neighbor Advertisement over the pseudowire, in addition to learning the remote CE's IPv6 address, it SHOULD perform the following steps:
ATM、FR、またはPPPなどのポイントツーポイントレイヤー2回路タイプのローカルACを備えたPEが、リモートCEのIPv6アドレスを学習することに加えて、疑似配線を介してネイバーアドバタイズを受信する場合、SHOULD次の手順を実行します。
o If the AC supports Inverse Neighbor Discovery (IND) and the PE had already processed an Inverse Neighbor Solicitation (INS) from the local CE, it SHOULD send an Inverse Neighbor Advertisement (INA) on the local AC using source IP address information received in an ND advertisement (ND-ADV) and its own local AC link-layer information.
o ACがInverse Neighbor Discovery（IND）をサポートしていて、PEがローカルCEからのInverse Neighbor Solicitation（INS）をすでに処理している場合、PEはローカルACで受信したソースIPアドレス情報を使用して、Inverse Neighbor Advertisement（INA）を送信する必要があります。 NDアドバタイズメント（ND-ADV）および独自のローカルACリンク層情報。
o If the PE has not received any Inverse Neighbor Solicitation (INS) from the local CE and the AC supports Inverse Neighbor Discovery (IND), it SHOULD send an INS on the local AC using source IP address information received in the INA together with its own local AC link-layer information.
o PEがローカルCEからInverse Neighbor Solicitation（INS）を受信しておらず、ACがInverse Neighbor Discovery（IND）をサポートしている場合、PEはINAで受信したソースIPアドレス情報を自身と一緒に使用して、ローカルACでINSを送信する必要があります（SHOULD）。ローカルACリンク層情報。
An INS received on an AC from a local CE SHOULD be inspected to determine and learn the IPv6 addresses and the link-layer addresses. The packet MUST then be forwarded over the pseudowire unmodified.
ローカルCEからACで受信されたINSを検査して、IPv6アドレスとリンク層アドレスを決定および学習する必要があります（SHOULD）。その後、パケットは変更されずに疑似配線を介して転送される必要があります。
An INS received over the pseudowire SHOULD be inspected to determine and learn one or more IPv6 addresses for the far-end CE. If the local AC supports IND (e.g., a switched Frame Relay AC), the packet SHOULD be forwarded to the local CE after modifying the link-layer address options to match the type of the local AC.
疑似配線を介して受信したINSを検査して、遠端CEの1つ以上のIPv6アドレスを決定および学習する必要があります（SHOULD）。ローカルACがIND（たとえば、スイッチドフレームリレーAC）をサポートしている場合、パケットは、ローカルACのタイプと一致するようにリンク層アドレスオプションを変更した後、ローカルCEに転送する必要があります（SHOULD）。
If the local AC does not support IND, processing of the packet depends on whether the PE has learned at least one interface address for its directly attached CE.
ローカルACがINDをサポートしていない場合、パケットの処理は、PEが直接接続されたCEの少なくとも1つのインターフェイスアドレスを学習したかどうかによって異なります。
o If it has learned at least one IPv6 address for the CE, the PE MUST discard the Inverse Neighbor Solicitation (INS) and generate an Inverse Neighbor Advertisement (INA) back into the pseudowire. The destination address of the INA is the source address from the INS; the source address is one of the local CE's interface addresses; and all the local CE's interface addresses that have been learned so far SHOULD be included in the Target Address List. The Source and Target link-layer addresses are copied from the INS. In addition, the PE SHOULD generate ND advertisements on the local AC using the IPv6 address of the remote CE and the link-layer address of the local PE.
o CEのIPv6アドレスを少なくとも1つ学習した場合、PEは逆近傍要請（INS）を破棄し、逆隣接アドバタイズ（INA）を生成して疑似配線に戻す必要があります。 INAの宛先アドレスは、INSからの送信元アドレスです。送信元アドレスは、ローカルCEのインターフェイスアドレスの1つです。そして、これまでに学習されたすべてのローカルCEのインターフェイスアドレスは、ターゲットアドレスリストに含まれる必要があります。ソースおよびターゲットのリンク層アドレスは、INSからコピーされます。さらに、PEは、リモートCEのIPv6アドレスとローカルPEのリンク層アドレスを使用して、ローカルACでNDアドバタイズを生成する必要があります（SHOULD）。
o If it has not learned at least one IPv6 and link-layer address of its directly connected CE, the INS MUST continue to be discarded until the PE learns an IPv6 and link-layer address from the local CE (through receiving, for example, a Neighbor Solicitation). After this has occurred, the PE will be able to respond to INS messages received over the pseudowire as described above.
o 直接接続されているCEの少なくとも1つのIPv6およびリンク層アドレスを学習していない場合、PEがローカルCEからIPv6およびリンク層アドレスを学習するまで（たとえば、近隣要請）。これが発生した後、PEは上記のように疑似配線を介して受信したINSメッセージに応答できます。
An INA received on an AC from a local CE SHOULD be inspected to determine and learn one or more IPv6 addresses for the CE. It MUST then be forwarded unmodified over the pseudowire.
ローカルCEからACで受信したINAを検査して、CEの1つ以上のIPv6アドレスを決定および学習する必要があります（SHOULD）。その後、疑似配線を介して変更せずに転送する必要があります。
An INA received over the pseudowire SHOULD be inspected to determine and learn one or more IPv6 addresses for the far-end CE.
疑似配線を介して受信したINAを検査して、遠端CEの1つ以上のIPv6アドレスを決定および学習する必要があります（SHOULD）。
If the local AC supports IND (e.g., a Frame Relay AC), the packet MAY be forwarded to the local CE after modifying the link-layer address options to match the type of the local AC.
ローカルACがIND（フレームリレーACなど）をサポートしている場合、リンク層アドレスオプションをローカルACのタイプと一致するように変更した後、パケットをローカルCEに転送できます（MAY）。
If the local AC does not support IND, the PE MUST discard the INA and generate a Neighbor Advertisement (NA) towards its local CE. The source IPv6 address of the NA is the source IPv6 address from the INA; the destination IPv6 address is the destination IPv6 address from the INA; and the link-layer address is that of the local AC on the PE.
ローカルACがINDをサポートしていない場合、PEはINAを破棄し、ローカルCEに向けて近隣アドバタイズ（NA）を生成する必要があります。 NAのソースIPv6アドレスは、INAからのソースIPv6アドレスです。宛先IPv6アドレスは、INAからの宛先IPv6アドレスです。リンク層アドレスは、PEのローカルACのアドレスです。
A Router Solicitation received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 address for the CE and, if present, the link-layer address of the CE. It MUST then be forwarded unmodified over the pseudowire.
ローカルCEからACで受信されたルーター要請は、CEのIPv6アドレス、および存在する場合はCEのリンク層アドレスを決定および学習するために検査する必要があります（SHOULD）。その後、疑似配線を介して変更せずに転送する必要があります。
A Router Solicitation received over the pseudowire SHOULD be inspected to determine and learn an IPv6 address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute a source link-layer address option specifying the link-layer address of its local AC. The packet is then forwarded to the local CE.
疑似配線を介して受信されたルーター要請は、遠端CEのIPv6アドレスを決定および学習するために検査する必要があります（SHOULD）。ソースリンク層アドレスオプションが存在する場合、PEはそれを削除する必要があります。 PEは、ローカルACのリンク層アドレスを指定するソースリンク層アドレスオプションを代用してもよい（MAY）。その後、パケットはローカルCEに転送されます。
A Router Advertisement received on an AC from a local CE SHOULD be inspected to determine and learn an IPv6 address for the CE and, if present, the link-layer address of the CE. It MUST then be forwarded unmodified over the pseudowire.
ローカルCEからACで受信されたルーターアドバタイズメントを検査して、CEのIPv6アドレスと、存在する場合はCEのリンク層アドレスを決定して学習する必要があります（SHOULD）。その後、疑似配線を介して変更せずに転送する必要があります。
A Router Advertisement received over the pseudowire SHOULD be inspected to determine and learn an IPv6 address for the far-end CE. If a source link-layer address option is present, the PE MUST remove it. The PE MAY substitute a source link-layer address option specifying the link-layer address of its local AC. If an MTU option is present, the PE MAY reduce the specified MTU if the MTU of the pseudowire is less than the value specified in the option. The packet is then forwarded to the local CE.
疑似配線を介して受信されたルーターアドバタイズメントを検査して、遠端CEのIPv6アドレスを決定および学習する必要があります（SHOULD）。ソースリンク層アドレスオプションが存在する場合、PEはそれを削除する必要があります。 PEは、ローカルACのリンク層アドレスを指定するソースリンク層アドレスオプションを代用してもよい（MAY）。 MTUオプションが存在する場合、疑似配線のMTUがオプションで指定された値より小さい場合、PEは指定されたMTUを減らすことができます（MAY）。その後、パケットはローカルCEに転送されます。
Duplicate Address Detection [RFC4862] allows IPv6 hosts and routers to ensure that the addresses assigned to interfaces are unique on a link. As with all Neighbor Discovery packets, those used in Duplicate Address Detection will simply flow through the pseudowire, being inspected at the PEs at each end. Processing is performed as detailed in Sections 4.3.3 and 4.3.4. However, the source IPv6 address of Neighbor Solicitations used in Duplicate Address Detection is the unspecified address, so the PEs cannot learn the CE's IPv6 interface address (nor would it make sense to do so, given that at least one address is tentative at that time).
重複アドレス検出[RFC4862]により、IPv6ホストとルーターは、インターフェイスに割り当てられたアドレスがリンク上で一意であることを確認できます。すべての近隣探索パケットと同様に、重複アドレス検出で使用されるパケットは、疑似配線を通過するだけで、両端のPEで検査されます。処理は、セクション4.3.3および4.3.4で詳細に説明されているように実行されます。ただし、重複アドレス検出で使用される近隣要請の送信元IPv6アドレスは指定されていないアドレスであるため、PEはCEのIPv6インターフェイスアドレスを学習できません（その時点で少なくとも1つのアドレスが暫定的であるとすると、PEはCEのIPv6インターフェイスアドレスを学習できません） ）。
The IPv6 Control Protocol (IPv6CP) [RFC5072] describes a procedure for establishing and configuring IPv6 on a point-to-point connection, including the negotiation of a link-local interface identifier. As in the case of IPv4, when such an AC is configured for IP interworking, PPP negotiation is not performed end-to-end between CE devices. Instead, PPP negotiation takes place between the CE and its local PE. The PE performs proxy PPP negotiation and informs the attached CE of the link-local identifier of its local interface using the Interface-Identifier option (0x01). This local interface identifier is used by stateless address autoconfiguration [RFC4862].
IPv6制御プロトコル（IPv6CP）[RFC5072]は、リンクローカルインターフェイス識別子のネゴシエーションを含め、ポイントツーポイント接続でIPv6を確立および構成する手順を説明しています。 IPv4の場合と同様に、そのようなACがIPインターワーキング用に構成されている場合、PPPネゴシエーションはCEデバイス間でエンドツーエンドで実行されません。代わりに、PPPネゴシエーションはCEとそのローカルPEの間で行われます。 PEはプロキシPPPネゴシエーションを実行し、Interface-Identifierオプション（0x01）を使用して、接続されたCEにローカルインターフェイスのリンクローカル識別子を通知します。このローカルインターフェイス識別子は、ステートレスアドレス自動構成[RFC4862]によって使用されます。
When a PPP link completes IPv6CP negotiations and the PPP link is open, a PE MAY discover the IPv6 unicast address of the CE using any of the mechanisms described above.
PPPリンクがIPv6CPネゴシエーションを完了し、PPPリンクが開いている場合、PEは上記のメカニズムのいずれかを使用してCEのIPv6ユニキャストアドレスを検出できます（MAY）。
A PE device advertises the IPv4 address of the attached CE only when the encapsulation type of the pseudowire is IP Layer2 Transport (the value 0x000B, as defined in [RFC4446]). The IP Layer2 transport PW is also referred to as IP PW and is used interchangeably in this document. It is quite possible that the IPv4 address of a CE device is not available at the time the PW labels are signaled. For example, in Frame Relay, the CE device sends an Inverse ARP request only when the Data Link Connection Identifier (DLCI) is active. If the PE signals the DLCI to be active only when it has received the IPv4 address along with the PW Forwarding Equivalence Class (FEC) from the remote PE, a deadlock situation arises. In order to avoid such problems, the PE MUST be prepared to advertise the PW FEC before the IPv4 address of the CE is known; hence,the PE uses an IPv4 address value zero. When the IPv4 address of the CE device does become available, the PE re-advertises the PW FEC along with the IPv4 address of the CE.
PEデバイスは、疑似配線のカプセル化タイプがIPレイヤー2トランスポート（値0x000B、[RFC4446]で定義されている）である場合にのみ、接続されたCEのIPv4アドレスをアドバタイズします。 IP Layer2トランスポートPWはIP PWとも呼ばれ、このドキュメントでは同じ意味で使用されています。 PWラベルが通知されたときに、CEデバイスのIPv4アドレスが使用できない可能性があります。たとえば、フレームリレーでは、CEデバイスはデータリンク接続識別子（DLCI）がアクティブな場合にのみ、逆ARP要求を送信します。リモートPEからPW転送等価クラス（FEC）とともにIPv4アドレスを受信した場合にのみ、PEがDLCIをアクティブにするようにシグナル通知すると、デッドロック状態が発生します。このような問題を回避するには、CEのIPv4アドレスがわかる前に、PEがPW FECをアドバタイズする準備をしなければなりません。したがって、PEはIPv4アドレス値ゼロを使用します。 CEデバイスのIPv4アドレスが使用可能になると、PEはCEのIPv4アドレスとともにPW FECを再アドバタイズします。
Similarly, if the PE detects that an IP address of a CE is no longer valid (by methods described above), the PE MUST re-advertise the PW FEC with a null IP address to denote the withdrawal of the IP address of the CE. The receiving PE then waits for notification of the remote IP address. During this period, propagation of unicast IPv4 traffic is suspended, but multicast IPv4 traffic can continue to flow between the AC and the pseudowire.
同様に、PEがCEのIPアドレスが無効になったことを検出した場合（上記の方法で）、PEは、CEのIPアドレスの撤回を示すために、ヌルIPアドレスでPW FECを再アドバタイズする必要があります。次に、受信PEはリモートIPアドレスの通知を待ちます。この期間中、ユニキャストIPv4トラフィックの伝播は一時停止されますが、マルチキャストIPv4トラフィックはACと疑似配線の間を流れ続けることができます。
If two CE devices are locally attached to the PE on disparate AC types (for example, one CE connected to an Ethernet port and the other to a Frame Relay port), the IPv4 addresses are learned in the same manner as described above. However, since the CE devices are local, the distribution of IPv4 addresses for these CE devices is a local step.
2つのCEデバイスが異なるACタイプのPEにローカルに接続されている場合（たとえば、1つのCEがイーサネットポートに接続され、もう1つのCEがフレームリレーポートに接続されている）、IPv4アドレスは上記と同じ方法で学習されます。ただし、CEデバイスはローカルであるため、これらのCEデバイスのIPv4アドレスの配布はローカルステップです。
Note that the PEs discover the IPv6 addresses of the remote CE by intercepting Neighbor Discovery and Inverse Neighbor Discovery packets that have been passed in-band through the pseudowire. Hence, there is no need to communicate the IPv6 addresses of the CEs through LDP signaling.
PEは、疑似配線を通じて帯域内で渡された近隣探索パケットと逆近隣探索パケットをインターセプトすることにより、リモートCEのIPv6アドレスを検出することに注意してください。したがって、LDPシグナリングを介してCEのIPv6アドレスを通信する必要はありません。
If the pseudowire is carrying both IPv4 and IPv6 traffic, the mechanisms used for IPv6 and IPv4 SHOULD NOT interact. In particular, just because a PE has learned a link-layer address for IPv6 traffic by intercepting a Neighbor Advertisement from its directly connected CE, it SHOULD NOT assume that it can use that link-layer address for IPv4 traffic until that fact is confirmed by reception of, for example, an IPv4 ARP message from the CE.
疑似配線がIPv4とIPv6の両方のトラフィックを伝送している場合、IPv6とIPv4に使用されるメカニズムは相互作用してはなりません（SHOULD NOT）。特に、PEが直接接続されたCEからのネイバーアドバタイズを傍受することでIPv6トラフィックのリンク層アドレスを学習したからといって、その事実が確認されるまで、そのリンク層アドレスをIPv4トラフィックに使用できると想定してはなりません（SHOULD NOT）。たとえば、CEからのIPv4 ARPメッセージの受信。
[RFC4447] uses Label Distribution Protocol (LDP) transport to exchange PW FECs in the Label Mapping message in the Downstream Unsolicited (DU) mode. The PW FEC comes in two flavors, with some common fields between them: PWid and Generalized ID FEC elements. The discussions below refer to these common fields for IP L2 Interworking encapsulation.
[RFC4447]は、Label Distribution Protocol（LDP）トランスポートを使用して、Downstream Unsolicited（DU）モードのラベルマッピングメッセージでPW FECを交換します。 PW FECには2つのフレーバーがあり、PWidエレメントとGeneralized ID FECエレメントといういくつかの共通フィールドがあります。以下の説明では、IP L2インターワーキングカプセル化のこれらの一般的なフィールドを参照しています。
In addition to PW FEC, this document uses an IP Address List TLV (as defined in [RFC5036]) that is to be included in the optional parameter field of the Label Mapping message when advertising the PW FEC for the IP Layer2 Transport. The use of optional parameters in the Label Mapping message to extend the attributes of the PW FEC is specified in [RFC4447].
PW FECに加えて、このドキュメントでは、IPレイヤ2トランスポートのPW FECをアドバタイズするときに、ラベルマッピングメッセージのオプションパラメータフィールドに含まれるIPアドレスリストTLV（[RFC5036]で定義）を使用します。 PW FECの属性を拡張するためのラベルマッピングメッセージでのオプションのパラメーターの使用は、[RFC4447]で指定されています。
As defined in [RFC4447], when processing a received PW FEC, the PE matches the PW ID and PW type with the locally configured PW ID and PW Type. If there is a match and if the PW Type is IP Layer2 Transport, the PE further checks for the presence of an Address List TLV [RFC5036] in the optional parameter TLVs. The processing of the Address List TLV is as follows.
[RFC4447]で定義されているように、受信したPW FECを処理するとき、PEはPW IDおよびPWタイプをローカルに構成されたPW IDおよびPWタイプと照合します。一致があり、PWタイプがIPレイヤー2トランスポートである場合、PEはオプションのパラメーターTLVにアドレスリストTLV [RFC5036]が存在するかどうかをさらにチェックします。アドレスリストTLVの処理は以下の通りです。
o If a PE is configured for an AC to a CE enabled for IPv4 or dual-stack IPv4/IPv6, the PE SHOULD advertise an Address List TLV with address family type of IPv4 address. The PE SHOULD process the IPv4 Address List TLV as described in this document. The PE MUST advertise and process IPv6 capability using the procedures described in Section 6.
o PEがIPv4またはデュアルスタックIPv4 / IPv6に対応したCEへのACに対して構成されている場合、PEはIPv4アドレスのアドレスファミリタイプでアドレスリストTLVをアドバタイズする必要があります。このドキュメントで説明されているように、PEはIPv4アドレスリストTLVを処理する必要があります（SHOULD）。 PEは、セクション6で説明されている手順を使用してIPv6機能を通知および処理する必要があります。
o If a PE does not receive any IPv4 address in the Address List TLV, it MAY assume IPv4 behavior. The address resolution for IPv4 MUST then depend on local manual configuration. In the case of mismatched configuration whereby one PE has manual configuration while the other does not, the IP address to link-layer address mapping remains unresolved, resulting in unsuccessful propagation of IPv4 traffic to the local CE.
o PEがアドレスリストTLVでIPv4アドレスを受信しない場合、IPv4の動作を想定する場合があります。 IPv4のアドレス解決は、ローカルの手動構成に依存する必要があります。 1つのPEが手動で構成され、他のPEはそうではない不一致の構成の場合、IPアドレスからリンク層アドレスへのマッピングは未解決のままになり、IPv4トラフィックのローカルCEへの伝播が失敗します。
o If a PE is configured for an AC to a CE enabled for IPv6 only, the PE MUST advertise IPv6 capability using the procedures described in Section 6. In addition, by virtue of not setting the manual configuration for IPv4 support, IPv6-only support is realized.
o PEがIPv6のみが有効なCEへのACに対して構成されている場合、PEはセクション6で説明されている手順を使用してIPv6機能をアドバタイズする必要があります。さらに、IPv4サポートの手動構成を設定していないため、IPv6のみのサポートは実現した。
We use the Address List TLV [RFC5036] to signal the IPv4 address of the local CE. This IP Address List TLV is included in the optional parameter field of the Label Mapping message.
アドレスリストTLV [RFC5036]を使用して、ローカルCEのIPv4アドレスを通知します。このIPアドレスリストTLVは、ラベルマッピングメッセージのオプションのパラメーターフィールドに含まれています。
The Address List TLV is only used for IPv4 addresses.
アドレスリストTLVはIPv4アドレスにのみ使用されます。
The fields of the IP Address List TLV are set as follows:
IPアドレスリストTLVのフィールドは次のように設定されます。
Length Set to 6 to encompass 2 bytes of Address Family field and 4 bytes of Addresses field (because a single IPv4 address is used).
長さ6バイトに設定すると、2バイトのアドレスファミリフィールドと4バイトのアドレスフィールドが含まれます（単一のIPv4アドレスが使用されるため）。
Address Family Set to 1 to indicate IPv4 as defined in [RFC5036].
[RFC5036]で定義されているIPv4を示すには、アドレスファミリを1に設定します。
Addresses Contains a single IPv4 address that is the address of the CE attached to the advertising PE.
アドレスアドバタイジングPEに接続されたCEのアドレスである単一のIPv4アドレスが含まれます。
The address in the Addresses field is set to all zeros to denote that the advertising PE has not learned the IPv4 address of its local CE. Any non-zero address value denotes the IPv4 address of the advertising PE's attached CE device.
Addressesフィールドのアドレスはすべてゼロに設定され、アドバタイジングPEがローカルCEのIPv4アドレスを学習していないことを示します。ゼロ以外のアドレス値は、アドバタイジングPEに接続されたCEデバイスのIPv4アドレスを示します。
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アドレスのステータスの変更を通知するために使用されます。
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 field is 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 network protocol(s) they SHOULD be using. As discussed earlier, the use of the Address List TLV signifies support for IPv4 stack, so the Stack Capability Interface Parameter sub-TLV is used to indicate whether support for IPv6 stack is required on a given IP PW.
Stack Capability Interface ParameterサブTLVは2つのPEから通知されるため、2つのPEは、使用するネットワークプロトコルに同意する必要があります。前述のように、アドレスリストTLVの使用はIPv4スタックのサポートを意味するため、スタック機能インターフェイスパラメーターサブTLVは、特定のIP PWでIPv6スタックのサポートが必要かどうかを示すために使用されます。
The Stack Capability Interface Parameter sub-TLV is part of the interface parameters. The proposed format for the Stack Capability Interface Parameter sub-TLV is as follows:
スタック機能インターフェイスパラメーターサブTLVは、インターフェイスパラメーターの一部です。 Stack Capability Interface Parameterサブ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
The Stack Capability field is a bit field. Only one bit is defined in this document. When bit zero (the least significant bit with bitmask 0x0001) is set, it indicates IPv6 Stack Capability.
Stack Capabilityフィールドはビットフィールドです。このドキュメントでは1ビットのみが定義されています。ビット0（ビットマスク0x0001の最下位ビット）が設定されている場合、IPv6スタック機能を示します。
The presence of the Stack Capability Interface Parameter sub-TLV is relevant only when the PW type is IP PW. A PE that supports IPv6 on an IP PW MUST signal the Stack Capability Interface Parameter 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 supported by both.
Stack Capability Interface ParameterサブTLVの存在は、PWタイプがIP PWの場合にのみ関係します。 IP PWでIPv6をサポートするPEは、PWの初期ラベルマッピングメッセージでスタック機能インターフェイスパラメータサブTLVを通知する必要があります。 PEノードは、リモートPEによってアドバタイズされた値をローカル構成と比較し、両方でサポートされている機能のみを使用します。
The behavior of a PE that does not understand an Interface Parameter sub-TLV is specified in Section 5.5 of RFC 4447 [RFC4447].
インターフェイスパラメータサブTLVを理解しないPEの動作は、RFC 4447 [RFC4447]のセクション5.5で指定されています。
In some deployment scenarios, it may be desirable to take a PW operationally down if there is a mismatch of the Stack Capability between the PEs. In other deployment scenarios, an operator may wish the IP version supported by both PEs to fall back to IPv4 if one of the PEs does not support IPv6. The following procedures MUST be followed for each of these cases.
一部の導入シナリオでは、PE間にスタック機能の不一致がある場合、PWを運用上ダウンさせることが望ましい場合があります。他の展開シナリオでは、PEの1つがIPv6をサポートしていない場合、オペレーターは両方のPEでサポートされているIPバージョンがIPv4にフォールバックすることを望む場合があります。これらの各ケースについて、次の手順に従う必要があります。
If a PE that supports IPv6 and has not yet sent a Label Mapping message receives an initial Label Mapping message from the far-end PE that does not include the Stack Capability Interface Parameter sub-TLV, or one is received but it is not set to the 'IPv6 Stack Capability' value, then the PE supporting this procedure MUST NOT send a Label Mapping message for this PW.
IPv6をサポートし、まだラベルマッピングメッセージを送信していないPEが、スタック機能インターフェイスパラメータサブTLVが含まれていない遠端のPEから最初のラベルマッピングメッセージを受信した場合、または受信されたが、設定されていない場合「IPv6スタック機能」の値。この手順をサポートするPEは、このPWのラベルマッピングメッセージを送信してはならない（MUST NOT）。
If a PE that supports IPv6 has already sent an initial Label Mapping message for the PW and does not receive a Stack Capability Interface Parameter sub-TLV in the Label Mapping message from the far-end PE, or one is received but it is not set to 'IPv6 Stack Capability', the PE supporting this procedure MUST withdraw its PW label with the LDP status code meaning "IP Address type mismatch" (Status Code 0x0000004A). However, subsequently, if the configuration was to change at the far-end PE and a Stack Capability Interface Parameter sub-TLV in the Label Mapping message is received from the far-end PE, the local PE MUST re-advertise the Label Mapping message for the PW.
IPv6をサポートするPEがすでにPWの初期ラベルマッピングメッセージを送信していて、遠端PEからのラベルマッピングメッセージでスタック機能インターフェイスパラメータサブTLVを受信しない場合、または受信されたが設定されていない場合「IPv6スタック機能」に対して、この手順をサポートするPEは、「IPアドレスタイプの不一致」を意味するLDPステータスコード（ステータスコード0x0000004A）を含むPWラベルを取り消す必要があります。ただし、その後、遠端のPEで構成が変更され、ラベルマッピングメッセージのStack Capability Interface ParameterサブTLVが遠端のPEから受信された場合、ローカルPEはラベルマッピングメッセージを再アドバタイズする必要があります。 PWのために。
If a PE that supports IPv6 and has not yet sent a Label Mapping message receives an initial Label Mapping message from the far-end PE that does not include the Stack Capability Interface Parameter sub-TLV, or one is received but it is not set to the 'IPv6 Stack Capability' value, then it MAY send a Label Mapping message for this PW but MUST NOT include the Stack Capability Interface Parameter sub-TLV.
IPv6をサポートし、まだラベルマッピングメッセージを送信していないPEが、スタック機能インターフェイスパラメータサブTLVが含まれていない遠端のPEから最初のラベルマッピングメッセージを受信した場合、または受信されたが、設定されていない場合「IPv6スタック機能」の値の場合、このPWのラベルマッピングメッセージを送信できますが、スタック機能インターフェイスパラメータのサブTLVを含めることはできません。
If a PE that supports IPv6 and has already sent a Label Mapping message for the PW with the Stack Capability Interface Parameter sub-TLV but does not receive a Stack Capability Interface Parameter sub-TLV from the far-end PE in the initial Label Mapping message (or one is received but it is not set to the 'IPv6 Stack Capability' value), the PE following this procedure MUST send a Label Withdraw for its PW label with the LDP status code meaning "Wrong IP Address type" (Status Code 0x000004B) followed by a Label Mapping message that does not include the Stack Capability Interface Parameter sub-TLV. If a Label Withdraw message with the "Wrong IP Address Type" status code is received by a PE, it SHOULD treat this as a normal Label Withdraw but MUST NOT respond with a Label Release. It MUST continue to wait for the next control message for the PW as specified in Section 6.2 of RFC 4447 [RFC4447].
IPv6をサポートし、スタック機能インターフェイスパラメータサブTLVを使用してPWのラベルマッピングメッセージをすでに送信しているが、初期ラベルマッピングメッセージで遠端のPEからスタック機能インターフェイスパラメータサブTLVを受信していないPE （または1つは受信されますが、「IPv6スタック機能」の値に設定されていません）、この手順に従うPEは、「間違ったIPアドレスタイプ」を意味するLDPステータスコード（ステータスコード0x000004B）を含むPWラベルのラベル撤回を送信する必要があります）に続いて、Stack Capability Interface ParameterサブTLVを含まないラベルマッピングメッセージ。 「Wrong IP Address Type」ステータスコードのラベルウィズドローメッセージがPEで受信された場合、これを通常のラベルウィズドローとして扱う必要がありますが、ラベルリリースで応答してはなりません。 RFC 4447 [RFC4447]のセクション6.2で指定されているように、PWの次の制御メッセージを引き続き待機する必要があります。
This document uses new LDP status codes. IANA already maintains a registry of name "Status Code Name Space" defined by [RFC5036]. The following values have been assigned:
このドキュメントでは、新しいLDPステータスコードを使用しています。 IANAはすでに[RFC5036]で定義されている "Status Code Name Space"という名前のレジストリを維持しています。以下の値が割り当てられています。
0x0000002C "IP Address of CE" 0x0000004A "IP Address Type Mismatch" 0x0000004B "Wrong IP Address Type"
0x0000002C "CEのIPアドレス" 0x0000004A "IPアドレスタイプの不一致" 0x0000004B "間違ったIPアドレスタイプ"
This document proposes a new Interface Parameters sub-TLV, that has been assigned from the 'Pseudowire Interface Parameters Sub-TLV type Registry'. The following value has been assigned for the Parameter ID:
このドキュメントは、「Pseudowire Interface Parameters Sub-TLV type Registry」から割り当てられた新しいInterface ParametersサブTLVを提案します。パラメータIDには次の値が割り当てられています。
0x16 "Stack Capability"
0x16「スタック機能」
IANA has also set up a registry of "L2VPN PE stack Capabilities". This is a 16-bit field. Stack Capability bitmask 0x0001 is specified in Section 6 of this document. The remaining bitfield values (0x0002,..,0x8000) are to be assigned by IANA using the "IETF Review" policy defined in [RFC5226].
IANAは、「L2VPN PEスタック機能」のレジストリもセットアップしています。これは16ビットのフィールドです。スタック機能ビットマスク0x0001は、このドキュメントのセクション6で指定されています。残りのビットフィールド値（0x0002、..、0x8000）は、[RFC5226]で定義されている「IETFレビュー」ポリシーを使用してIANAによって割り当てられます。
L2VPN PE Stack Capabilities:
L2VPN PEスタック機能：
Bit (Value) Description
=============== ========================
Bit 0 (0x0001) - IPv6 stack capability
Bit 1 (0x0002) - Unassigned
Bit 2 (0x0004) - Unassigned
.
.
.
Bit 14 (0x4000) - Unassigned Bit 15 (0x8000) - Unassigned
ビット14（0x4000）-未割り当てビット15（0x8000）-未割り当て
The security aspect of this solution is addressed for two planes: the control plane and the data plane.
このソリューションのセキュリティ面は、コントロールプレーンとデータプレーンの2つのプレーンに対応しています。
Control plane security pertains to establishing the LDP connection and to pseudowire signaling and CE IP address distribution over that LDP connection. For greater security, the LDP connection between two trusted PEs MUST be secured by each PE verifying the incoming connection against the configured address of the peer and authenticating the LDP messages, as described in Section 2.9 of [RFC5036]. Pseudowire signaling between two secure LDP peers does not pose a security issue but mis-wiring could occur due to configuration error. However, the fact that the pseudowire will only be established if the two PEs have matching configurations (e.g., PW ID, PW type, and MTU) provides some protection against mis-wiring due to configuration errors.
コントロールプレーンのセキュリティは、LDP接続の確立と、そのLDP接続を介した疑似配線シグナリングおよびCE IPアドレス配布に関係しています。 [RFC5036]のセクション2.9で説明されているように、セキュリティを強化するために、2つの信頼できるPE間のLDP接続は、各PEがピアの構成アドレスに対して着信接続を検証し、LDPメッセージを認証することによって保護する必要があります。 2つのセキュアLDPピア間の疑似配線シグナリングはセキュリティ問題を引き起こしませんが、設定エラーが原因で誤配線が発生する可能性があります。ただし、2つのPEが一致する構成（PW ID、PWタイプ、MTUなど）を持っている場合にのみ疑似配線が確立されるという事実は、構成エラーによる誤配線に対する保護を提供します。
Learning the IP address of the appropriate CE can be a security issue. It is expected that the Attachment Circuit to the local CE will be physically secured. If this is a concern, the PE MUST be configured with the IP and MAC address of the CE when connected with Ethernet, IP and virtual circuit information (DLCI or VPI/VCI (Virtual Path Identifier / Virtual Circuit Identifier) when connected over Frame Relay or ATM, and IP address only when connected over PPP. During ARP/Inverse ARP frame processing, the PE MUST verify the received information against local configuration before forwarding the information to the remote PE to protect against hijacking of the connection.
適切なCEのIPアドレスを学習することは、セキュリティ上の問題になる可能性があります。ローカルCEへの接続回線が物理的に保護されることが期待されています。これが問題になる場合は、イーサネットに接続する場合、PEにCEのIPアドレスとMACアドレス、IPおよび仮想回線情報（DLCIまたはVPI / VCI（仮想パス識別子/仮想回路識別子））をフレームリレー経由で接続する場合、PEを構成する必要があります。またはATM、およびPPP経由で接続されている場合のみのIPアドレスARP /逆ARPフレーム処理中に、PEは、接続のハイジャックから保護するために、リモートPEに情報を転送する前に、ローカル構成に対して受信した情報を検証する必要があります。
For IPv6, the preferred means of security is Secure Neighbor Discovery (SEND) [RFC3971]. SEND provides a mechanism for securing Neighbor Discovery packets over media (such as wireless links) that may be insecure and open to packet interception and substitution. SEND is based upon cryptographic signatures of Neighbor Discovery packets. These signatures allow the receiving node to detect packet modification and confirm that a received packet originated from the claimed source node. SEND is incompatible with the Neighbor Discovery packet modifications described in this document. As such, SEND cannot be used for Neighbor Discovery across an ARP Mediation pseudowire. PEs taking part in IPv6 ARP Mediation MUST remove all SEND packet options from Neighbor Discovery packets before forwarding into the pseudowire. If the CE devices are configured to accept only SEND Neighbor Discovery packets, Neighbor Discovery will fail. Thus, the CE devices MUST be configured to accept non-SEND packets, even if they treat them with lower priority than SEND packets. Because SEND cannot be used in combination with IPv6 ARP Mediation, it is suggested that IPv6 ARP Mediation only be used with secure Attachment Circuits. An exception to this recommendation applies to an implementation that supports the SEND Proxy [RFC6496], which allows a device such as PE to act as an ND proxy as described in [RFC6496].
IPv6の場合、推奨されるセキュリティ手段はSecure Neighbor Discovery（SEND）[RFC3971]です。 SENDは、安全でない可能性があり、パケットの傍受と置換が可能なメディア（ワイヤレスリンクなど）経由で近隣探索パケットを保護するメカニズムを提供します。 SENDは、近隣探索パケットの暗号署名に基づいています。これらの署名により、受信ノードはパケットの変更を検出し、受信したパケットが要求されたソースノードから発信されたことを確認できます。 SENDは、このドキュメントで説明されている近隣探索パケットの変更と互換性がありません。そのため、SENDは、ARPメディエーション疑似配線を介した近隣探索には使用できません。 IPv6 ARPメディエーションに参加するPEは、疑似配線に転送する前に、近隣探索パケットからすべてのSENDパケットオプションを削除する必要があります。 CEデバイスがSEND近隣探索パケットのみを受け入れるように構成されている場合、近隣探索は失敗します。したがって、CEデバイスは、SENDパケットよりも低い優先度でそれらを処理する場合でも、非SENDパケットを受け入れるように構成する必要があります。 SENDはIPv6 ARPメディエーションと組み合わせて使用できないため、IPv6 ARPメディエーションは安全な接続回線でのみ使用することをお勧めします。この推奨事項の例外は、[RFC6496]で説明されているように、PEなどのデバイスがNDプロキシとして機能できるようにするSENDプロキシ[RFC6496]をサポートする実装に適用されます。
The data traffic between CE and PE is not encrypted, and it is possible that in an insecure environment, a malicious user may tap into the CE-to-PE connection and generate traffic using the spoofed destination MAC address on the Ethernet Attachment Circuit. 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アドレスを使用してトラフィックを生成する可能性があります。このようなハイジャックを回避するために、ローカルPEは、受信したフレームの送信元MACアドレスを、許可された接続のMACアドレスと照合して検証します。信頼性が確認された場合にのみ、フレームがPWに転送されます。スプーフィングが検出された場合、PEはローカルCEとの接続を切断し、PWを破棄して、最初からやり直す必要があります。
The authors would like to thank Yetik Serbest, Prabhu Kavi, Bruce Lasley, Mark Lewis, Carlos Pignataro, and others who participated in the discussions related to this document.
著者は、Yetik Serbest、Prabhu Kavi、Bruce Lasley、Mark Lewis、Carlos Pignataro、およびこのドキュメントに関連するディスカッションに参加した他の人々に感謝します。
This document is the combined effort of many who have contributed, carefully reviewed, and provided technical clarifications. This includes the individuals listed in this section and those listed in the Editors' Addresses.
このドキュメントは、技術的な説明を提供し、注意深く検討し、提供してきた多くの人々の力を合わせたものです。これには、このセクションに記載されている個人と編集者のアドレスに記載されている個人が含まれます。
Matthew Bocci Alcatel-Lucent EMail: Mathew.bocci@alcatel-lucent.com
マシューボッチアルカテルルーセントメール：Mathew.bocci@alcatel-lucent.com
Tiberiu Grigoriu Alcatel-Lucent EMail: Tiberiu.Grigoriu@alcatel-lucent.com
Tiberiu Grigoriuアルカテルルーセントメール：Tiberiu.Grigoriu@alcatel-lucent.com
Neil Hart Alcatel-Lucent EMail: Neil.Hart@alcatel-lucent.com
ニールハートアルカテルルーセントEメール：Neil.Hart@alcatel-lucent.com
Andrew Dolganow Alcatel-Lucent EMail: Andrew.Dolganow@alcatel-lucent.com
Andrew Dolganowアルカテルルーセントメール：Andrew.Dolganow@alcatel-lucent.com
Shane Amante Level 3 EMail: Shane@castlepoint.net
Shane Amanteレベル3メール：Shane@castlepoint.net
Toby Smith Google EMail: tob@google.com Andrew G. Malis Verizon EMail: Andy.g.Malis@verizon.com
Toby Smith Googleメール：tob@google.com Andrew G. Malis Verizonメール：Andy.g.Malis@verizon.com
Steven Wright Bell South Corp EMail: steven.wright@bellsouth.com
Steven Wright Bell South Corp Eメール：steven.wright@bellsouth.com
Waldemar Augustyn Consultant EMail: waldemar@wdmsys.com
Waldemar AugustynコンサルタントEメール：waldemar@wdmsys.com
Arun Vishwanathan Juniper Networks EMail: arunvn@juniper.net
Arun Vishwanathan Juniper Networksメール：Arunavan：Juniper.net
Ashwin Moranganti IneoQuest Technologies EMail: Ashwin.Moranganti@Ineoquest.com
Ashwin Moranganti IneoQuest Technologiesメール：Ashwin.Moranganti@Ineoquest.com
[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.
[RFC826]プラムマー、D。、「イーサネットアドレス解決プロトコル：またはネットワークプロトコルアドレスを48ビットイーサネットアドレスに変換してイーサネットハードウェアで送信する」、STD 37、RFC 826、1982年11月。
[RFC2390] Bradley, T., Brown, C., and A. Malis, "Inverse Address Resolution Protocol", RFC 2390, September 1998.
[RFC2390] Bradley、T.、Brown、C。、およびA. Malis、「Inverse Address Resolution Protocol」、RFC 2390、1998年9月。
[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.
[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月。
[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[RFC4446] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANA割り当て」、BCP 116、RFC 4446、2006年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、Ed。、Minei、I.、Ed。、and B. Thomas、Ed。、 "LDP Specification"、RFC 5036、October 2007。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC3122] Conta, A., "Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification", RFC 3122, June 2001.
[RFC3122] Conta、A。、「Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification」、RFC 3122、2001年6月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、2007年9月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Ed。、Kempf、J.、Zill、B.、and P. Nikander、 "SEcure Neighbor Discovery（SEND）"、RFC 3971、March 2005。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、2008年5月。
[RFC4664] Andersson, L., Ed., and E. Rosen, Ed., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC 4664, September 2006.
[RFC4664] Andersson、L.、Ed。およびE. Rosen、Ed。、 "Framework for Layer 2 Virtual Private Networks（L2VPNs）"、RFC 4664、2006年9月。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、G。、「PPPインターネットプロトコル制御プロトコル（IPCP）」、RFC 1332、1992年5月。
[RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072] Varada、S。、編、Haskins、D。、およびE. Allen、「IPバージョン6 over PPP」、RFC 5072、2007年9月。
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC925] Postel、J。、「Multi-LAN address resolution」、RFC 925、1984年10月。
[RFC1256] Deering, S., Ed., "ICMP Router Discovery Messages", RFC 1256, September 1991.
[RFC1256] Deering、S。、編、「ICMPルーター発見メッセージ」、RFC 1256、1991年9月。
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, October 2008.
[RFC5309] Shen、N.、Ed。、およびA. Zinin、Ed。、「Point-to-Point Operation over LAN in Link State Routing Protocols」、RFC 5309、2008年10月。
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-Martinez, "Secure Proxy ND Support for SEcure Neighbor Discovery (SEND)", RFC 6496, February 2012.
[RFC6496]クリシュナンS.、ラガニアJ.、ボノーラM.、およびA.ガルシアマルティネス、「SECur Neighbor Discovery（SEND）のセキュアプロキシNDサポート」、RFC 6496、2012年2月。
In an IP L2 interworking L2VPN, when an IGP on a CE connected to a broadcast link is cross-connected with an IGP on a CE connected to a point-to-point link, there are routing protocol related issues that MUST be addressed. The link state routing protocols are cognizant of the underlying link characteristics and behave accordingly when establishing neighbor adjacencies, representing the network topology, and passing protocol packets. The point-to-point operations of the routing protocols over a LAN are discussed in [RFC5309].
IP L2インターワーキングL2VPNでは、ブロードキャストリンクに接続されたCEのIGPがポイントツーポイントリンクに接続されたCEのIGPと相互接続されている場合、ルーティングプロトコル関連の問題に対処する必要があります。リンクステートルーティングプロトコルは、基礎となるリンク特性を認識しており、ネットワークトポロジを表し、プロトコルパケットを渡す隣接関係を確立するときにそれに応じて動作します。 LANを介したルーティングプロトコルのポイントツーポイント操作については、[RFC5309]で説明されています。
The OSPF protocol treats a broadcast link type with a special procedure that engages in Neighbor Discovery to elect a designated router and a backup designated router (DR and BDR, respectively), with which each other router on the link forms adjacencies. However, these procedures are neither applicable nor understood by OSPF running on a point-to-point link. By cross-connecting two neighbors with disparate link types, an IP L2 interworking L2VPN may experience connectivity issues.
OSPFプロトコルはブロードキャストリンクタイプを特別な手順で処理し、ネイバーディスカバリを実行して、指定ルータとバックアップ指定ルータ（それぞれDRとBDR）を選出し、リンク上の他のルータが隣接関係を形成します。ただし、これらの手順は、ポイントツーポイントリンクで実行されているOSPFでは適用されず、理解されません。リンクタイプが異なる2つのネイバーを相互接続することにより、IP L2インターワーキングL2VPNで接続の問題が発生する可能性があります。
Additionally, the link type specified in the router Link State Advertisement (LSA) will not match for the two cross-connected routers.
さらに、ルーターのLink State Advertisement（LSA）で指定されたリンクタイプは、2つの相互接続されたルーターと一致しません。
Finally, each OSPF router generates network LSAs when connected to a broadcast link such as Ethernet, receipt of which by an OSPF router that believes itself to be connected to a point-to-point link further adds to the confusion.
最後に、各OSPFルーターは、イーサネットなどのブロードキャストリンクに接続されたときにネットワークLSAを生成します。OSPFルーターがポイントツーポイントリンクに接続されていると信じているOSPFルーターがこれを受信すると、さらに混乱が生じます。
Fortunately, the OSPF protocol provides a configuration option (ospfIfType) whereby OSPF will treat the underlying physical broadcast link as a point-to-point link.
幸い、OSPFプロトコルは構成オプション（ospfIfType）を提供し、OSPFは基礎となる物理ブロードキャストリンクをポイントツーポイントリンクとして扱います。
It is strongly recommended that all OSPF protocols on CE devices connected to Ethernet interfaces use this configuration option when attached to a PE that is participating in an IP L2 Interworking VPN.
イーサネットインターフェイスに接続されているCEデバイス上のすべてのOSPFプロトコルは、IP L2インターワーキングVPNに参加しているPEに接続されている場合、この設定オプションを使用することを強くお勧めします。
The RIP protocol broadcasts RIP advertisements every 30 seconds. If the multicast/broadcast traffic snooping mechanism is used as described in Section 4.1, the attached PE can learn the local CE router's IP address from the IP header of its advertisements. No special configuration is required for RIP in this type of Layer 2 IP Interworking L2VPN.
RIPプロトコルは、30秒ごとにRIPアドバタイズをブロードキャストします。マルチキャスト/ブロードキャストトラフィックスヌーピングメカニズムがセクション4.1で説明されているように使用されている場合、接続されているPEは、アドバタイズのIPヘッダーからローカルCEルーターのIPアドレスを学習できます。このタイプのレイヤ2 IPインターワーキングL2VPNでは、RIPに特別な設定は必要ありません。
The IS-IS protocol does not encapsulate its PDUs in IP; hence, it cannot be supported in IP L2 Interworking L2VPNs.
IS-ISプロトコルは、PDUをIPにカプセル化しません。したがって、IP L2インターワーキングL2VPNではサポートできません。
Editors' Addresses
編集者のアドレス
Himanshu Shah (editor) Ciena EMail: hshah@ciena.com
Himanshu Shah（編集者）Ciena EMail：hshah@ciena.com
Eric Rosen (editor) Cisco Systems EMail: erosen@cisco.com
エリックローゼン（編集者）Cisco Systems EMail：erosen@cisco.com
Giles Heron (editor) Cisco Systems EMail: giheron@cisco.com
Giles Heron（編集者）Cisco Systems EMail：giheron@cisco.com
Vach Kompella (editor) Alcatel-Lucent EMail: vach.kompella@alcatel-lucent.com
Vach Kompella（編集者）Alcatel-Lucentメール：vach.kompella@alcatel-lucent.com