[要約] RFC 5565は、ソフトワイヤメッシュフレームワークに関する技術仕様です。その目的は、IPv4とIPv6のネットワーク間での通信を容易にするためのソリューションを提供することです。
Network Working Group J. Wu
Request for Comments: 5565 Y. Cui
Category: Standards Track Tsinghua University
C. Metz
E. Rosen
Cisco Systems, Inc.
June 2009
Softwire Mesh Framework
ソフトワイヤーメッシュフレームワーク
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの貢献からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得しないと、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版または英語以外の言語に翻訳する。
Abstract
概要
The Internet needs to be able to handle both IPv4 and IPv6 packets. However, it is expected that some constituent networks of the Internet will be "single-protocol" networks. One kind of single-protocol network can parse only IPv4 packets and can process only IPv4 routing information; another kind can parse only IPv6 packets and can process only IPv6 routing information. It is nevertheless required that either kind of single-protocol network be able to provide transit service for the "other" protocol. This is done by passing the "other kind" of routing information from one edge of the single-protocol network to the other, and by tunneling the "other kind" of data packet from one edge to the other. The tunnels are known as "softwires". This framework document explains how the routing information and the data packets of one protocol are passed through a single-protocol network of the other protocol. The document is careful to specify when this can be done with existing technology and when it requires the development of new or modified technology.
インターネットは、IPv4パケットとIPv6パケットの両方を処理できる必要があります。ただし、インターネットの一部の構成ネットワークは「単一プロトコル」ネットワークになると予想されます。1つの種類の単一プロトコルネットワークは、IPv4パケットのみを解析でき、IPv4ルーティング情報のみを処理できます。別の種類は、IPv6パケットのみを解析でき、IPv6ルーティング情報のみを処理できます。それにもかかわらず、どちらの種類の単一プロトコルネットワークが「他の」プロトコルにトランジットサービスを提供できることが必要です。これは、単一プロトコルネットワークの1つの端からもう一方のエッジに「他の種類」のルーティング情報を渡し、「他の種類」のデータパケットを一方のエッジからもう一方の端にトンネル化することによって行われます。トンネルは「ソフトウェア」として知られています。このフレームワークドキュメントでは、1つのプロトコルのルーティング情報とデータパケットが他のプロトコルの単一プロトコルネットワークを介してどのように渡されるかを説明しています。このドキュメントは、これを既存のテクノロジーでいつ実行できるか、そして新しいテクノロジーまたは修正されたテクノロジーの開発が必要な時期を指定するように注意しています。
Table of Contents
目次
1. Introduction ....................................................3
2. Specification of Requirements ...................................6
3. Scenarios of Interest ...........................................7
3.1. IPv6-over-IPv4 Scenario ....................................7
3.2. IPv4-over-IPv6 Scenario ....................................9
4. General Principles of the Solution .............................10
4.1. E-IP and I-IP .............................................10
4.2. Routing ...................................................10
4.3. Tunneled Forwarding .......................................11
5. Distribution of Inter-AFBR Routing Information .................11
6. Softwire Signaling .............................................13
7. Choosing to Forward through a Softwire .........................15
8. Selecting a Tunneling Technology ...............................15
9. Selecting the Softwire for a Given Packet ......................16
10. Softwire OAM and MIBs .........................................17
10.1. Operations and Maintenance (OAM) .........................17
10.2. MIBs .....................................................18
11. Softwire Multicast ............................................18
11.1. One-to-One Mappings ......................................18
11.1.1. Using PIM in the Core .............................19
11.1.2. Using mLDP and Multicast MPLS in the Core .........20
11.2. MVPN-Like Schemes ........................................21
12. Inter-AS Considerations .......................................22
13. Security Considerations .......................................23
13.1. Problem Analysis .........................................23
13.2. Non-Cryptographic Techniques .............................24
13.3. Cryptographic Techniques .................................26
14. References ....................................................27
14.1. Normative References .....................................27
14.2. Informative References ...................................28
15. Contributors ..................................................30
16. Acknowledgments ...............................................30
The routing information in any IP backbone network can be thought of as being in one of two categories: "internal routing information" or "external routing information". The internal routing information consists of routes to the nodes that belong to the backbone, and to the interfaces of those nodes. External routing information consists of routes to destinations beyond the backbone, especially destinations to which the backbone is not directly attached. In general, BGP [RFC4271] is used to distribute external routing information, and an Interior Gateway Protocol (IGP) such as OSPF [RFC2328] or IS-IS [RFC1195] is used to distribute internal routing information.
任意のIPバックボーンネットワークのルーティング情報は、「内部ルーティング情報」または「外部ルーティング情報」の2つのカテゴリのいずれかにあると考えることができます。内部ルーティング情報は、バックボーンに属するノードとそれらのノードのインターフェイスへのルートで構成されています。外部ルーティング情報は、バックボーンを越えた目的地へのルート、特にバックボーンが直接接続されていない目的地で構成されています。一般に、BGP [RFC4271]は外部ルーティング情報の配布に使用され、OSPF [RFC2328]やIS-IS [RFC1195]などのインテリアゲートウェイプロトコル（IGP）は、内部ルーティング情報を配布するために使用されます。
Often an IP backbone will provide transit routing services for packets that originate outside the backbone and whose destinations are outside the backbone. These packets enter the backbone at one of its "edge routers". They are routed through the backbone to another edge router, after which they leave the backbone and continue on their way. The edge nodes of the backbone are often known as "Provider Edge" (PE) routers. The term "ingress" (or "ingress PE") refers to the router at which a packet enters the backbone, and the term "egress" (or "egress PE") refers to the router at which it leaves the backbone. Interior nodes are often known as "P routers". Routers that are outside the backbone but directly attached to it are known as "Customer Edge" (CE) routers. (This terminology is taken from [RFC4364].)
多くの場合、IPバックボーンは、バックボーンの外で発生し、その目的地がバックボーンの外側にあるパケットにトランジットルーティングサービスを提供します。これらのパケットは、「エッジルーター」の1つにバックボーンに入ります。彼らはバックボーンを通って別のエッジルーターにルーティングされ、その後バックボーンを離れて進みます。バックボーンのエッジノードは、しばしば「プロバイダーエッジ」（PE）ルーターとして知られています。「Ingress」（または「Ingress PE」）という用語は、パケットがバックボーンに入るルーターを指し、「出口」という用語（または「Egress PE」）は、バックボーンを離れるルーターを指します。インテリアノードは、しばしば「Pルーター」として知られています。バックボーンの外側にあるが、それに直接接続されているルーターは、「顧客エッジ」（CE）ルーターとして知られています。（この用語は[RFC4364]から取られています。）
When a packet's destination is outside the backbone, the routing information that is needed within the backbone in order to route the packet to the proper egress is, by definition, external routing information.
パケットの宛先がバックボーンの外側にある場合、パケットを適切な出口にルーティングするためにバックボーン内で必要なルーティング情報は、定義上、外部ルーティング情報です。
Traditionally, the external routing information has been distributed by BGP to all the routers in the backbone, not just to the edge routers (i.e., not just to the ingress and egress points). Each of the interior nodes has been expected to look up the packet's destination address and route it towards the egress point. This is known as "native forwarding": the interior nodes look into each packet's header in order to match the information in the header with the external routing information.
従来、外部ルーティング情報は、BGPによってバックボーン内のすべてのルーターに分配されており、エッジルーターだけでなく（つまり、侵入ポイントと出口だけでなく）。各インテリアノードは、パケットの宛先アドレスを検索し、出口ポイントに向かってルーティングすることが期待されています。これは「ネイティブ転送」と呼ばれます。インテリアノードは、ヘッダーの情報を外部ルーティング情報と一致させるために、各パケットのヘッダーを調べます。
It is, however, possible to provide transit services without requiring that all the backbone routers have the external routing information. The routing information that BGP distributes to each ingress router specifies the egress router for each route. The ingress router can therefore "tunnel" the packet directly to the egress router. "Tunneling the packet" means putting on some sort of encapsulation header that will force the interior routers to forward the packet to the egress router. The original packet is known as the "encapsulation payload". The P routers do not look at the packet header of the payload but only at the encapsulation header. Since the path to the egress router is part of the internal routing information of the backbone, the interior routers then do not need to know the external routing information. This is known as "tunneled forwarding". Of course, before the packet can leave the egress, it has to be decapsulated.
ただし、すべてのバックボーンルーターに外部ルーティング情報があることを要求することなく、トランジットサービスを提供することが可能です。BGPが各イングレスルーターに分配するルーティング情報は、各ルートの出力ルーターを指定します。したがって、イングレスルーターは、パケットを出力ルーターに直接「トンネル」することができます。「パケットのトンネル」とは、内部ルーターにパケットを出口ルーターに転送させるために、何らかのカプセル化ヘッダーを着用することを意味します。元のパケットは、「カプセル化ペイロード」と呼ばれます。Pルーターは、ペイロードのパケットヘッダーではなく、カプセル化ヘッダーでのみ見られます。出力ルーターへのパスはバックボーンの内部ルーティング情報の一部であるため、内部ルーターは外部ルーティング情報を知る必要はありません。これは「トンネル転送」として知られています。もちろん、パケットが出口を離れる前に、脱カプセル化する必要があります。
The scenario where the P routers do not have external routes is sometimes known as a "BGP-free core". That is something of a misnomer, though, since the crucial aspect of this scenario is not that the interior nodes don't run BGP, but that they don't maintain the external routing information.
Pルーターに外部ルートがないシナリオは、「BGPフリーコア」として知られている場合があります。ただし、このシナリオの重要な側面は、インテリアノードがBGPを実行しないことではなく、外部ルーティング情報を維持していないということであるため、それは誤った呼び名です。
In recent years, we have seen this scenario deployed to support VPN services, as specified in [RFC4364]. An edge router maintains multiple independent routing/addressing spaces, one for each VPN to which it interfaces. However, the routing information for the VPNs is not maintained by the interior routers. In most of these scenarios, MPLS is used as the encapsulation mechanism for getting the packets from ingress to egress. There are some deployments in which an IP-based encapsulation, such as L2TPv3 (Layer 2 Transport Protocol) [RFC3931] or GRE (Generic Routing Encapsulation) [RFC2784] is used.
近年、[RFC4364]で指定されているように、VPNサービスをサポートするためにこのシナリオが展開されています。エッジルーターは、複数の独立したルーティング/アドレス指定スペースを維持します。ただし、VPNのルーティング情報は、内部ルーターによって維持されません。これらのシナリオのほとんどで、MPLSは、イングレスから出口にパケットを取得するためのカプセル化メカニズムとして使用されます。L2TPV3（レイヤー2輸送プロトコル）[RFC3931]またはGRE（汎用ルーティングカプセル化）[RFC2784]などのIPベースのカプセル化が使用される展開がいくつかあります。
This same technique can also be useful when the external routing information consists not of VPN routes, but of "ordinary" Internet routes. It can be used any time it is desired to keep external routing information out of a backbone's interior nodes, or in fact any time it is desired for any reason to avoid the native forwarding of certain kinds of packets.
この同じ手法は、外部ルーティング情報がVPNルートではなく、「通常の」インターネットルートで構成されている場合にも役立ちます。バックボーンの内部ノードから外部ルーティング情報を維持することが望ましいとき、または実際には、特定の種類のパケットのネイティブ転送を避けるために何らかの理由でいつでも望まれるときはいつでも使用できます。
This framework focuses on two such scenarios.
このフレームワークは、このような2つのシナリオに焦点を当てています。
1. In this scenario, the backbone's interior nodes support only IPv6. They do not maintain IPv4 routes at all, and are not expected to parse IPv4 packet headers. Yet, it is desired to use such a backbone to provide transit services for IPv4 packets. Therefore, tunneled forwarding of IPv4 packets is required. Of course, the edge nodes must have the IPv4 routes, but the ingress must perform an encapsulation in order to get an IPv4 packet forwarded to the egress.
1. このシナリオでは、バックボーンの内部ノードはIPv6のみをサポートしています。IPv4ルートをまったく維持せず、IPv4パケットヘッダーを解析することは期待されていません。しかし、IPv4パケットにトランジットサービスを提供するために、このようなバックボーンを使用することが望まれます。したがって、IPv4パケットのトンネル転送が必要です。もちろん、エッジノードにはIPv4ルートが必要ですが、IPv4パケットを出口に転送するために、イングレスはカプセル化を実行する必要があります。
2. This scenario is the reverse of scenario 1, i.e., the backbone's interior nodes support only IPv4, but it is desired to use the backbone for IPv6 transit.
2. このシナリオはシナリオ1の逆です。つまり、バックボーンの内部ノードはIPv4のみをサポートしますが、IPv6トランジットにはバックボーンを使用することが望まれます。
In these scenarios, a backbone whose interior nodes support only one of the two address families is required to provide transit services for the other. The backbone's edge routers must, of course, support both address families. We use the term "Address Family Border Router" (AFBR) to refer to these PE routers. The tunnels that are used for forwarding are referred to as "softwires".
これらのシナリオでは、インテリアノードが2つのアドレスファミリのうちの1つだけをサポートするバックボーンは、他方に輸送サービスを提供するために必要です。もちろん、バックボーンのエッジルーターは、両方のアドレスファミリをサポートする必要があります。これらのPEルーターを参照するには、「Address Family Border Router」（AFBR）という用語を使用します。転送に使用されるトンネルは、「ソフトウェア」と呼ばれます。
These two scenarios are known as the "Softwire Mesh Problem" [SW-PROB], and the framework specified in this document is therefore known as the "Softwire Mesh Framework". In this framework, only the AFBRs need to support both address families. The CE routers support only a single address family, and the P routers support only the other address family.
これらの2つのシナリオは「Softwire Meshの問題」[SW-Prob]として知られており、このドキュメントで指定されているフレームワークは「Softwire Mesh Framework」として知られています。このフレームワークでは、AFBRのみが両方のアドレスファミリをサポートする必要があります。CEルーターは単一のアドレスファミリのみをサポートし、Pルーターは他のアドレスファミリのみをサポートします。
It is possible to address these scenarios via a large variety of tunneling technologies. This framework does not mandate the use of any particular tunneling technology. In any given deployment, the choice of tunneling technology is a matter of policy. The framework accommodates at least the use of MPLS ([RFC3031], [RFC3032]) -- both LDP-based (Label Distribution Protocol, [RFC5036]) and RSVP-TE-based (Resource Reservation Protocol - Traffic Engineering, [RFC3209]) -- L2TPv3 [RFC3931], GRE [RFC2784], and IP-in-IP [RFC2003]. The framework will also accommodate the use of IPsec tunneling, when that is necessary in order to meet security requirements.
多種多様なトンネリング技術を介してこれらのシナリオに対処することができます。このフレームワークは、特定のトンネル技術の使用を義務付けていません。任意の展開において、トンネル技術の選択は政策の問題です。フレームワークは、少なくともMPLS（[RFC3031]、[RFC3032]）の使用に対応します。） - L2TPV3 [RFC3931]、GRE [RFC2784]、およびIP-in-IP [RFC2003]。フレームワークは、セキュリティ要件を満たすために必要な場合、IPSECトンネルの使用にも対応します。
It is expected that, in many deployments, the choice of tunneling technology will be made by a simple expression of policy, such as "always use IP-IP tunnels", or "always use LDP-based MPLS", or "always use L2TPv3".
多くの展開において、「IP-IPトンネルを常に使用する」、「常にLDPベースのMPLSを使用する」、「常にL2TPV3を使用する」など、トンネル技術の選択は、ポリシーの単純な表現によって行われることが期待されています。「。
However, other deployments may have a mixture of routers, some of which support, say, both GRE and L2TPv3, but others of which support only one of those techniques. It is desirable therefore to allow the network administration to create a small set of classes, and to configure each AFBR to be a member of one or more of these classes. Then the routers can advertise their class memberships to each other, and the encapsulation policies can be expressed as, e.g., "use L2TPv3 to tunnel to routers in class X; use GRE to tunnel to routers in class Y". To support such policies, it is necessary for the AFBRs to be able to advertise their class memberships; a standard way of doing this must be developed.
ただし、他の展開にはルーターが混在している場合がありますが、その一部はGREとL2TPV3の両方をサポートしていますが、それらはそれらのテクニックの1つだけをサポートしています。したがって、ネットワーク管理が小さなクラスのセットを作成できるようにし、各AFBRをこれらのクラスの1つ以上のメンバーに設定できるようにすることが望ましいです。その後、ルーターはクラスのメンバーシップを互いに宣伝できます。例えば、カプセル化ポリシーは「L2TPV3を使用してクラスXのルーターにトンネルにトンネルにトンネルにトンネルにトンネルにトンネルにトンネルにトンネルを付けます。クラスYのルーターにトンネルを使用してください」このようなポリシーをサポートするには、AFBRSがクラスメンバーシップを宣伝できるようにする必要があります。これを行う標準的な方法を開発する必要があります。
Policy may also require a certain class of traffic to receive a certain quality of service, and this may impact the choice of tunnel and/or tunneling technology used for packets in that class. This needs to be accommodated by the Softwire Mesh Framework.
ポリシーは、特定のサービスを受けるために特定のクラスのトラフィックを必要とする場合があり、これはそのクラスのパケットに使用されるトンネルおよび/またはトンネリングテクノロジーの選択に影響を与える可能性があります。これは、Softwire Meshフレームワークに対応する必要があります。
The use of tunneled forwarding often requires that some sort of signaling protocol be used to set up and/or maintain the tunnels. Many of the tunneling technologies accommodated by this framework already have their own signaling protocols. However, some do not, and in some cases the standard signaling protocol for a particular tunneling technology may not be appropriate (for one or another reason) in the scenarios of interest. In such cases (and in such cases only), new signaling methodologies need to be defined and standardized.
トンネル転送を使用するには、多くの場合、何らかのシグナル伝達プロトコルを使用してトンネルのセットアップおよび/または維持が必要です。このフレームワークに対応するトンネル技術の多くには、すでに独自のシグナリングプロトコルがあります。ただし、一部の場合は、特定のトンネルテクノロジーの標準的なシグナル伝達プロトコルが関心のシナリオでは適切ではない（1つまたは別の理由で）適切ではない場合があります。そのような場合（およびそのような場合のみ）、新しいシグナル伝達方法論を定義し、標準化する必要があります。
In this framework, the softwires do not form an overlay topology that is visible to routing; routing adjacencies are not maintained over the softwires, and routing control packets are not sent through the softwires. Routing adjacencies among backbone nodes (including the edge nodes) are maintained via the native technology of the backbone.
このフレームワークでは、ソフトウェアはルーティングに見えるオーバーレイトポロジを形成しません。ルーティングの隣接はソフトウェア上に維持されておらず、ルーティング制御パケットはソフトウェアを介して送信されません。バックボーンノード（エッジノードを含む）間の隣接するルーティングは、バックボーンのネイティブテクノロジーを介して維持されます。
There is already a standard routing method for distributing external routing information among AFBRs, namely BGP. However, in the scenarios of interest, we may be using IPv6-based BGP sessions to pass IPv4 routing information, and we may be using IPv4-based BGP sessions to pass IPv6 routing information. Furthermore, when IPv4 traffic is to be tunneled over an IPv6 backbone, it is necessary to encode the "BGP next hop" for an IPv4 route as an IPv6 address, and vice versa. The method for encoding an IPv4 address as the next hop for an IPv6 route is specified in [V6NLRI-V4NH]; the method for encoding an IPv6 address as the next hop for an IPv4 route is specified in [V4NLRI-V6NH].
AFBRに外部ルーティング情報を配布するための標準的なルーティング方法、つまりBGPがすでにあります。ただし、関心のあるシナリオでは、IPv6ベースのBGPセッションを使用してIPv4ルーティング情報に合格する可能性があり、IPv4ベースのBGPセッションを使用してIPv6ルーティング情報に合格する可能性があります。さらに、IPv4のトラフィックをIPv6バックボーン上でトンネル化する場合、IPv6アドレスとしてIPv4ルートの「BGP Next Hop」をエンコードする必要があります。IPv6ルートの次のホップとしてIPv4アドレスをエンコードする方法は、[v6nlri-v4nh]で指定されています。IPv4ルートの次のホップとしてIPv6アドレスをエンコードする方法は、[V4NLRI-V6NH]で指定されています。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
In this scenario, the client networks run IPv6 but the backbone network runs IPv4. This is illustrated in Figure 1.
このシナリオでは、クライアントネットワークはIPv6を実行しますが、バックボーンネットワークはIPv4を実行します。これを図1に示します。
+--------+ +--------+
| IPv6 | | IPv6 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFBR | | AFBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv4 | | | | IPv4 |
| Client | | | | Client |
| Network|------| IPv4 |-------| Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFBR |---| AFBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv6 | | IPv6 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 1: IPv6-over-IPv4 Scenario
図1：IPv6-Over-IPV4シナリオ
The IPv4 transit core may or may not run MPLS. If it does, MPLS may be used as part of the solution.
IPv4 Transit Coreは、MPLSを実行する場合と実行できない場合があります。もしそうなら、MPLはソリューションの一部として使用できます。
While Figure 1 does not show any "backdoor" connections among the client networks, this framework assumes that there will be such connections. That is, there is no assumption that the only path between two client networks is via the pictured transit-core network. Hence, the routing solution must be robust in any kind of topology.
図1はクライアントネットワーク間の「バックドア」接続を示していませんが、このフレームワークはそのような接続があることを前提としています。つまり、2つのクライアントネットワーク間の唯一のパスは、写真のトランジットコアネットワークを介してであるという仮定はありません。したがって、ルーティングソリューションは、あらゆる種類のトポロジで堅牢でなければなりません。
Many mechanisms for providing IPv6 connectivity across IPv4 networks have been devised over the past ten years. A number of different tunneling mechanisms have been used, some provisioned manually, and others based on special addressing. More recently, L3VPN (Layer 3 Virtual Private Network) techniques from [RFC4364] have been extended to provide IPv6 connectivity, using MPLS in the AFBRs and, optionally, in the backbone [V6NLRI-V4NH]. The solution described in this framework can be thought of as a superset of [V6NLRI-V4NH], with a more generalized scheme for choosing the tunneling (softwire) technology. In this framework, MPLS is allowed -- but not required -- even at the AFBRs. As in [V6NLRI-V4NH], there is no manual provisioning of tunnels, and no special addressing is required.
IPv4ネットワーク全体でIPv6接続を提供するための多くのメカニズムは、過去10年間に考案されてきました。多くの異なるトンネルメカニズムが使用されており、一部は手動でプロビジョニングされ、その他は特別なアドレス指定に基づいています。最近では、[RFC4364]のL3VPN（レイヤー3仮想プライベートネットワーク）手法が拡張され、AFBRSのMPLSを使用し、オプションではバックボーン[V6NLRI-V4NH]を使用してIPv6接続を提供しています。このフレームワークで説明されているソリューションは、[V6NLRI-V4NH]のスーパーセットと考えることができ、トンネリング（ソフトワイヤ）テクノロジーを選択するためのより一般化されたスキームを使用します。このフレームワークでは、AFBRSでもMPLSが許可されていますが、必須ではありません。[v6nlri-v4nh]のように、トンネルの手動プロビジョニングはなく、特別なアドレス指定は必要ありません。
In this scenario, the client networks run IPv4 but the backbone network runs IPv6. This is illustrated in Figure 2.
このシナリオでは、クライアントネットワークはIPv4を実行しますが、バックボーンネットワークはIPv6を実行します。これを図2に示します。
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFBR | | AFBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client | | | | Client |
| Network|------| IPv6 |-------| Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFBR |---| AFBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 2: IPv4-over-IPv6 Scenario
図2：IPv4-Over-IPV6シナリオ
The IPv6 transit core may or may not run MPLS. If it does, MPLS may be used as part of the solution.
IPv6トランジットコアは、MPLSを実行する場合と実行できない場合があります。もしそうなら、MPLはソリューションの一部として使用できます。
While Figure 2 does not show any "backdoor" connections among the client networks, this framework assumes that there will be such connections. That is, there is no assumption that the only path between two client networks is via the pictured transit-core network. Hence, the routing solution must be robust in any kind of topology.
図2では、クライアントネットワーク間の「バックドア」接続を示していませんが、このフレームワークはそのような接続があると想定しています。つまり、2つのクライアントネットワーク間の唯一のパスは、写真のトランジットコアネットワークを介してであるという仮定はありません。したがって、ルーティングソリューションは、あらゆる種類のトポロジで堅牢でなければなりません。
While the issue of IPv6-over-IPv4 has received considerable attention in the past, the scenario of IPv4-over-IPv6 has not. Yet, it is a significant emerging requirement, as a number of service providers are building IPv6 backbone networks and do not wish to provide native IPv4 support in their core routers. These service providers have a large legacy of IPv4 networks and applications that need to operate across their IPv6 backbone. Solutions for this do not exist yet because it had always been assumed that the backbone networks of the foreseeable future would be dual stack.
IPv6-over-IPV4の問題は過去にかなりの注目を集めていますが、IPv4-over-IPV6のシナリオにはそうではありません。しかし、多くのサービスプロバイダーがIPv6バックボーンネットワークを構築しており、コアルーターでネイティブIPv4サポートを提供することを望んでいないため、それは重要な新しい要件です。これらのサービスプロバイダーには、IPv4バックボーン全体で動作する必要があるIPv4ネットワークとアプリケーションの大きな遺産があります。これのソリューションは、予見可能な将来のバックボーンネットワークがデュアルスタックになると常に想定されていたため、まだ存在していません。
This section gives a very brief overview of the procedures. The subsequent sections provide more detail.
このセクションでは、手順の非常に簡単な概要を説明します。後続のセクションでは、より詳細な詳細を提供します。
In the following sections, we use the term "I-IP" (Internal IP) to refer to the form of IP (i.e., either IPv4 or IPv6) that is supported by the transit network. We use the term "E-IP" (External IP) to refer to the form of IP that is supported by the client networks. In the scenarios of interest, E-IP is IPv4 if and only if I-IP is IPv6, and E-IP is IPv6 if and only if I-IP is IPv4.
次のセクションでは、「I-IP」（内部IP）という用語を使用して、TransitネットワークでサポートされているIP（つまり、IPv4またはIPv6のいずれか）を参照します。「E-IP」（外部IP）という用語を使用して、クライアントネットワークによってサポートされているIPの形式を参照します。関心のあるシナリオでは、i-IPがi-IPがIPv6である場合にのみ、i-IPがIPv6である場合にのみ、I-IPがIPv4である場合にのみIPv4です。
We assume that the P routers support only I-IP. That is, they are expected to have only I-IP routing information, and they are not expected to be able to parse E-IP headers. We similarly assume that the CE routers support only E-IP.
PルーターはI-IPのみをサポートしていると仮定します。つまり、I-IPルーティング情報のみを持っていると予想されており、E-IPヘッダーを解析できることは期待されていません。同様に、CEルーターはE-IPのみをサポートしていると想定しています。
The AFBRs handle both I-IP and E-IP. However, only I-IP is used on AFBR's "core-facing interfaces", and E-IP is only used on its client-facing interfaces.
AFBRは、I-IPとE-IPの両方を処理します。ただし、I-IPのみがAFBRの「コア向けインターフェイス」で使用され、E-IPはクライアント向けインターフェイスでのみ使用されます。
The P routers and the AFBRs of the transit network participate in an IGP for the purposes of distributing I-IP routing information.
PルーターとトランジットネットワークのAFBRは、I-IPルーティング情報を配布する目的でIGPに参加します。
The AFBRs use Internal BGP (IBGP) to exchange E-IP routing information with each other. Either there is a full mesh of IBGP connections among the AFBRs, or else some or all of the AFBRs are clients of a BGP Route Reflector. Although these IBGP connections are used to pass E-IP routing information (i.e., the Network Layer Reachability Information (NLRI) of the BGP updates is in the E-IP address family), the IBGP connections run over I-IP, and the BGP next hop for each E-IP NLRI is in the I-IP address family.
AFBRは、内部BGP（IBGP）を使用して、e-IPルーティング情報を互いに交換します。AFBRの間にIBGP接続の完全なメッシュがあるか、AFBRの一部またはすべてがBGPルートリフレクターのクライアントです。これらのIBGP接続は、E-IPルーティング情報（つまり、BGPの更新のネットワークレイヤーリーチビリティ情報（NLRI）がE-IPアドレスファミリにある）に渡すために使用されますが、IBGP接続はI-IPで実行され、BGP各E-IP NLRIの次のホップは、I-IPアドレスファミリにあります。
When an ingress AFBR receives an E-IP packet from a client-facing interface, it looks up the packet's destination IP address. In the scenarios of interest, the best match for that address will be a BGP-distributed route whose next hop is the I-IP address of another AFBR, the egress AFBR.
イングレスAFBRがクライアント向けインターフェイスからE-IPパケットを受信すると、パケットの宛先IPアドレスを調べます。関心のあるシナリオでは、そのアドレスに最適なマッチは、次のホップが別のAFBRのI-IPアドレスである出口AFBRのI-IPアドレスであるBGP分配ルートです。
The ingress AFBR must forward the packet through a tunnel (i.e, through a softwire) to the egress AFBR. This is done by encapsulating the packet, using an encapsulation header that the P routers can process and that will cause the P routers to send the packet to the egress AFBR. The egress AFBR then extracts the payload, i.e., the original E-IP packet, and forwards it further by looking up its IP destination address.
イングレスAFBRは、トンネル（つまり、ソフトワイヤを介して）を介して出力AFBRにパケットを転送する必要があります。これは、Pルーターが処理できるカプセル化ヘッダーを使用してパケットをカプセル化することによって行われ、PルーターがPacketをEgress AFBRに送信します。Engress AFBRは、ペイロード、つまり元のE-IPパケットを抽出し、IP宛先アドレスを検索してさらに転送します。
Several kinds of tunneling technologies are supported. Some of those technologies require explicit AFBR-to-AFBR signaling before the tunnel can be used, others do not.
いくつかの種類のトンネル技術がサポートされています。これらのテクノロジーの一部は、トンネルを使用する前に明示的なAFBRからAFBRへのシグナル伝達を必要としますが、他のテクノロジーは使用できません。
Transmitting a packet through a softwire always requires that an encapsulation header be added to the original packet. The resulting packet is therefore always longer than the encapsulation payload. As an operational matter, the Maximum Transmission Unit (MTU) of the softwire's path SHOULD be large enough so that (a) no packet will need to be fragmented before being encapsulated, and (b) no encapsulated packet will need to be fragmented while it is being forwarded along a softwire. A general discussion of MTU issues in the context of tunneled forwarding may be found in [RFC4459].
ソフトワイヤーを介してパケットを送信するには、常にカプセル化ヘッダーを元のパケットに追加する必要があります。したがって、結果のパケットは、カプセル化ペイロードよりも常に長くなります。動作問題として、ソフトワイヤーのパスの最大透過ユニット（MTU）は十分に大きくする必要があります。ソフトワイヤに沿って転送されています。トンネル転送のコンテキストでのMTUの問題に関する一般的な議論は、[RFC4459]に記載されている場合があります。
AFBRs peer with routers in the client networks to exchange routing information for the E-IP family.
AFBRSは、クライアントネットワーク内のルーターを使用して、E-IPファミリーのルーティング情報を交換します。
AFBRs use BGP to distribute the E-IP routing information to each other. This can be done by an AFBR-AFBR mesh of IBGP sessions, but more likely is done through a BGP Route Reflector, i.e., where each AFBR has an IBGP session to one or two Route Reflectors rather than to other AFBRs.
AFBRSはBGPを使用して、e-IPルーティング情報を相互に配布します。これは、IBGPセッションのAFBR-AFBRメッシュで行うことができますが、BGPルートリフレクター、つまり、各AFBRが他のAFBRではなく1つまたは2つのルートリフレクターにIBGPセッションを持っている可能性が高いです。
The BGP sessions between the AFBRs, or between the AFBRs and the Route Reflector, will run on top of the I-IP address family. That is, if the transit core supports only IPv6, the IBGP sessions used to distribute IPv4 routing information from the client networks will run over IPv6; if the transit core supports only IPv4, the IBGP sessions used to distribute IPv6 routing information from the client networks will run over IPv4. The BGP sessions thus use the native networking layer of the core; BGP messages are NOT tunneled through softwires or through any other mechanism.
AFBRS間のBGPセッション、またはAFBRSとルートリフレクター間のセッションは、I-IPアドレスファミリの上で実行されます。つまり、Transit CoreがIPv6のみをサポートする場合、クライアントネットワークからIPv4ルーティング情報を配布するために使用されるIBGPセッションはIPv6を超えて実行されます。Transit CoreがIPv4のみをサポートする場合、IPv6ルーティング情報をクライアントネットワークから配布するために使用されるIBGPセッションは、IPv4を超えて実行されます。したがって、BGPセッションは、コアのネイティブネットワーキングレイヤーを使用します。BGPメッセージは、ソフトワイヤや他のメカニズムを介してトンネル化されていません。
In BGP, a routing update associates an address prefix (or more generally, NLRI) with the address of a BGP next hop (NH). The NLRI is associated with a particular address family. The NH address is also associated with a particular address family, which may be the same as or different than the address family associated with the NLRI. Generally, the NH address belongs to the address family that is used to communicate with the BGP speaker to whom the NH address belongs.
BGPでは、ルーティングアップデートがアドレスプレフィックス（より一般的には、NLRI）をBGP Next Hop（NH）のアドレスに関連付けます。NLRIは特定の住所ファミリに関連付けられています。NHアドレスは、特定のアドレスファミリにも関連付けられています。これは、NLRIに関連するアドレスファミリーと同じまたは異なる場合があります。一般に、NHアドレスは、NHアドレスが属するBGPスピーカーと通信するために使用されるアドレスファミリに属します。
Since routing updates that contain information about E-IP address prefixes are carried over BGP sessions that use I-IP transport, and since the BGP messages are not tunneled, a BGP update providing information about an E-IP address prefix will need to specify a next hop address in the I-IP family.
E-IPアドレスのプレフィックスに関する情報を含むルーティングアップデートは、I-IPトランスポートを使用するBGPセッションに掲載されているため、BGPメッセージはトンネル化されていないため、E-IPアドレスのプレフィックスに関する情報を提供するBGPアップデートでは、I-IPファミリーの次のホップアドレス。
Due to a variety of historical circumstances, when the NLRI and the NH in a given BGP update are of different address families, it is not always obvious how the NH should be encoded. There is a different encoding procedure for each pair of address families.
さまざまな歴史的状況により、特定のBGPアップデートのNLRIとNHが住所ファミリが異なる場合、NHをエンコードする方法は必ずしも明らかではありません。アドレスファミリのペアごとに異なるエンコーディング手順があります。
In the case where the NLRI is in the IPv6 address family, and the NH is in the IPv4 address family, [V6NLRI-V4NH] explains how to encode the NH.
NLRIがIPv6アドレスファミリーにあり、NHがIPv4アドレスファミリーにある場合、[V6NLRI-V4NH]はNHをエンコードする方法を説明します。
In the case where the NLRI is in the IPv4 address family, and the NH is in the IPv6 address family, [V4NLRI-V6NH] explains how to encode the NH.
NLRIがIPv4アドレスファミリーにあり、NHがIPv6アドレスファミリーにある場合、[V4NLRI-V6NH]はNHをエンコードする方法を説明します。
If a BGP speaker sends an update for an NLRI in the E-IP family, and the update is being sent over a BGP session that is running on top of the I-IP network layer, and the BGP speaker is advertising itself as the NH for that NLRI, then the BGP speaker MUST, unless explicitly overridden by policy, specify the NH address in the I-IP family. The address family of the NH MUST NOT be changed by a Route Reflector.
BGPスピーカーがE-IPファミリーのNLRIのアップデートを送信し、I-IPネットワークレイヤーの上で実行されているBGPセッションで更新が送信され、BGPスピーカーはNHとして宣伝されています。そのNLRIについては、BGPスピーカーは、ポリシーによって明示的に上書きされない限り、I-IPファミリーのNHアドレスを指定しなければなりません。NHの住所ファミリは、ルートリフレクターによって変更されてはなりません。
In some cases (e.g., when [V4NLRI-V6NH] is used), one cannot follow this rule unless one's BGP peers have advertised a particular BGP capability. This leads to the following softwire deployment restriction: if a BGP capability is defined for the case in which an E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST advertise that capability.
場合によっては（たとえば、[v4nlri-v6nh]を使用する場合）、BGPピアが特定のBGP機能を宣伝していない限り、このルールに従うことはできません。これにより、次のソフトワイヤーの展開制限につながります。E-IP NLRIがI-IP NHを持っている場合に対してBGP機能が定義されている場合、特定のトランジットコアのすべてのAFBRSはその機能を宣伝する必要があります。
If an AFBR has multiple IP addresses, the network administrators usually have considerable flexibility in choosing which one the AFBR uses to identify itself as the next hop in a BGP update. However, if the AFBR expects to receive packets through a softwire of a particular tunneling technology, and if the AFBR is known to that tunneling technology via a specific IP address, then that same IP address must be used to identify the AFBR in the next hop field of the BGP updates. For example, if L2TPv3 tunneling is used, then the IP address that the AFBR uses when engaging in L2TPv3 signaling must be the same as the IP address it uses to identify itself in the next hop field of a BGP update.
AFBRに複数のIPアドレスがある場合、ネットワーク管理者は通常、AFBRがBGPアップデートの次のホップとして自分自身を識別するために使用するものを選択する際にかなりの柔軟性を持っています。ただし、AFBRが特定のトンネルテクノロジーのソフトワイヤを介してパケットを受信することを期待している場合、およびAFBRが特定のIPアドレスを介してそのトンネルテクノロジーに知られている場合、その同じIPアドレスを使用して次のホップでAFBRを識別する必要があります。BGP更新のフィールド。たとえば、L2TPV3トンネリングを使用する場合、AFBRが使用するIPアドレスは、L2TPV3シグナル伝達に従事するときに使用するIPアドレスは、BGPアップデートの次のホップフィールドで自らを識別するために使用するIPアドレスと同じでなければなりません。
In [V6NLRI-V4NH], IPv6 routing information is distributed using the labeled IPv6 address family. This allows the egress AFBR to associate an MPLS label with each IPv6 address prefix. If an ingress AFBR forwards packets through a softwire that can carry MPLS packets, each data packet can carry the MPLS label corresponding to the IPv6 route that it matched. This may be useful at the egress AFBR, for demultiplexing and/or enhanced performance. It is also possible to do the same for the IPv4 address family, i.e., to use the labeled IPv4 address family instead of the IPv4 address family. The use of the labeled IP address families in this manner is OPTIONAL.
[v6nlri-v4nh]では、IPv6ルーティング情報は、ラベル付きIPv6アドレスファミリを使用して配布されます。これにより、出力AFBRはMPLSラベルを各IPv6アドレスプレフィックスに関連付けることができます。Ingress AFBRがMPLSパケットを運ぶことができるSoftwireを介してパケットを転送する場合、各データパケットは、一致したIPv6ルートに対応するMPLSラベルを運ぶことができます。これは、脱出AFBRでは、パフォーマンスの強化に役立つ場合があります。また、IPv4アドレスファミリ、つまり、IPv4アドレスファミリの代わりにラベル付けされたIPv4アドレスファミリを使用することもできます。この方法でラベル付けされたIPアドレスファミリの使用はオプションです。
A mesh of inter-AFBR softwires spanning the transit core must be in place before packets can flow between client networks. Given N dual-stack AFBRs, this requires N^2 "point-to-point IP" or "label switched path" (LSP) tunnels. While in theory these could be configured manually, that would result in a very undesirable O(N^2) provisioning problem. Therefore, manual configuration of point-to-point tunnels is not considered part of this framework.
パケットがクライアントネットワーク間で流れる前に、トランジットコアにまたがるAFBR間ソフトウェアのメッシュが配置されている必要があります。nデュアルスタックAFBRSを考えると、これにはn^2 "ポイントツーポイントIP"または「ラベルスイッチ付きパス」（LSP）トンネルが必要です。理論的には、これらは手動で構成できますが、非常に望ましくないO（n^2）プロビジョニング問題になります。したがって、ポイントツーポイントトンネルの手動構成は、このフレームワークの一部とは見なされません。
Because the transit core is providing layer 3 transit services, point-to-point tunnels are not required by this framework; multipoint-to-point tunnels are all that is needed. In a multipoint-to-point tunnel, when a packet emerges from the tunnel there is no way to tell which router put the packet into the tunnel. This models the native IP forwarding paradigm, wherein the egress router cannot determine a given packet's ingress router. Of course, point-to-point tunnels might be required for some reason beyond the basic requirements described in this document. For example, Quality of Service (QoS) or security considerations might require the use of point-to-point tunnels. So point-to-point tunnels are allowed, but not required, by this framework.
トランジットコアはレイヤー3トランジットサービスを提供しているため、このフレームワークではポイントツーポイントトンネルは必要ありません。マルチポイントからポイントへのトンネルだけが必要です。マルチポイント間トンネルでは、トンネルからパケットが出現すると、どのルーターがパケットをトンネルに入れたかを伝える方法がありません。これにより、出力ルーターが特定のパケットのイングレスルーターを決定できないネイティブIP転送パラダイムをモデル化します。もちろん、このドキュメントで説明されている基本的な要件を超えて、何らかの理由でポイントツーポイントトンネルが必要になる場合があります。たとえば、サービス品質（QO）またはセキュリティ上の考慮事項には、ポイントツーポイントトンネルの使用が必要になる場合があります。したがって、このフレームワークによっては、ポイントツーポイントトンネルが許可されていますが、必須ではありません。
If it is desired to use a particular tunneling technology for the softwires, and if that technology has its own "native" signaling methodology, the presumption is that the native signaling will be used. This would certainly apply to MPLS-based softwires, where LDP or RSVP-TE would be used. An IPsec-based softwire would use standard IKEv2 (Internet Key Exchange) [RFC4306] and IPsec [RFC4301] signaling, as that is necessary in order to guarantee the softwire's security properties.
ソフトウェアに特定のトンネリングテクノロジーを使用することが望ましい場合、およびその技術に独自の「ネイティブ」シグナル伝達方法がある場合、ネイティブシグナル伝達が使用されると推定されます。これは、LDPまたはRSVP-TEが使用されるMPLSベースのソフトウェアに確実に適用されます。IPSECベースのソフトワイヤーは、Softwireのセキュリティプロパティを保証するために必要なため、標準のIKEV2（インターネットキーエクスチェンジ）[RFC4306]およびIPSEC [RFC4301]シグナリングを使用します。
A GRE-based softwire might or might not require signaling, depending on whether various optional GRE header fields are to be used. GRE does not have any "native" signaling, so for those cases, a signaling procedure needs to be developed to support softwires.
GREベースのソフトワイヤは、さまざまなオプションのGREヘッダーフィールドを使用するかどうかに応じて、信号を必要とする場合とそうでない場合があります。GREには「ネイティブ」シグナリングはないため、これらの場合には、ソフトウェアをサポートするためにシグナリング手順を開発する必要があります。
Another possible softwire technology is L2TPv3. While L2TPv3 does have its own native signaling, that signaling sets up point-to-point tunnels. For the purpose of softwires, it is better to use L2TPv3 in a multipoint-to-point mode, and this requires a different kind of signaling.
別の可能なソフトワイヤーテクノロジーはL2TPV3です。L2TPV3には独自のネイティブシグナル伝達がありますが、そのシグナリングはポイントツーポイントトンネルを設定します。ソフトウェアの目的のために、L2TPV3をマルチポイントツーポイントモードで使用することをお勧めします。これには、異なる種類のシグナル伝達が必要です。
The signaling to be used for GRE and L2TPv3 to cover these scenarios is BGP-based, and is described in [RFC5512].
これらのシナリオをカバーするためにGREおよびL2TPV3に使用されるシグナル伝達はBGPベースであり、[RFC5512]で説明されています。
If IP-IP tunneling is used, or if GRE tunneling is used without options, no signaling is required, as the only information needed by the ingress AFBR to create the encapsulation header is the IP address of the egress AFBR, and that is distributed by BGP.
IP-IPトンネリングが使用されている場合、またはGREトンネルがオプションなしで使用されている場合、シグナリングは必要ありません。イングレスAFBRがカプセル化ヘッダーを作成するために必要な唯一の情報は、出口AFBRのIPアドレスであり、BGP。
When the encapsulation IP header is constructed, there may be fields in the IP whose value is determined neither by whatever signaling has been done nor by the distributed routing information. The values of these fields are determined by policy in the ingress AFBR. Examples of such fields may be the TTL (Time to Live) field, the DSCP (Diffserv Service Classes) bits, etc.
カプセル化IPヘッダーが構築されると、IPにフィールドがある場合があります。その値は、信号が行われたものでも、分散ルーティング情報によっても決定されません。これらのフィールドの値は、イングレスAFBRのポリシーによって決定されます。このようなフィールドの例は、TTL（Live to Live）フィールド、DSCP（Diffserv Serviceクラス）ビットなどです。
It is desirable for all necessary softwires to be fully set up before the arrival of any packets that need to go through the softwires. That is, the softwires should be "always on". From the perspective of any particular AFBR, the softwire endpoints are always BGP next hops of routes that the AFBR has installed. This suggests that any necessary softwire signaling should either be done as part of normal system startup (as would happen, e.g., with LDP-based MPLS) or else be triggered by the reception of BGP routing information (such as is described in [RFC5512]); it is also helpful if distribution of the routing information that serves as the trigger is prioritized.
ソフトワイヤを通過する必要があるパケットが到着する前に、必要なすべてのソフトウェアを完全にセットアップすることが望ましいです。つまり、ソフトワイヤは「常にオン」でなければなりません。特定のAFBRの観点から見ると、Softwireエンドポイントは常にBGP次のルートの次のホップです。これは、必要なソフトワイヤーシグナリングは、通常のシステムスタートアップの一部として（LDPベースのMPLSなど）、BGPルーティング情報の受信（[RFC5512]に記載されているなど）によってトリガーされることを示唆しています。）;トリガーとして機能するルーティング情報の配布が優先順位付けされている場合にも役立ちます。
The decision to forward through a softwire, instead of to forward natively, is made by the ingress AFBR. This decision is a matter of policy.
ソフトワイヤーを介して転送するという決定は、ネイティブに転送するのではなく、侵入AFBRによって行われます。この決定は政策の問題です。
In many cases, the policy will be very simple. Some useful policies are:
多くの場合、ポリシーは非常に簡単です。いくつかの有用なポリシーは次のとおりです。
- If routing says that an E-IP packet has to be sent out a core-facing interface to an I-IP core, then send the packet through a softwire.
- ルーティングがE-IPパケットをI-IPコアにコア向けインターフェイスを送信する必要があると言っている場合は、ソフトワイヤーからパケットを送信します。
- If routing says that an E-IP packet has to be sent out an interface that only supports I-IP packets, then send the E-IP packet through a softwire.
- ルーティングが、e-ipパケットをi-ipパケットのみをサポートするインターフェイスを送信する必要があると言われている場合は、e-ipパケットをソフトワイヤーから送信します。
- If routing says that the BGP next hop address for an E-IP packet is an I-IP address, then send the E-IP packet through a softwire.
- ルーティングが、e-IPパケットのBGP次のホップアドレスがI-IPアドレスであると言っている場合は、Softwireを介してE-IPパケットを送信します。
- If the route that is the best match for a particular packet's destination address is a BGP-distributed route, then send the packet through a softwire (i.e., tunnel all BGP-routed packets).
- 特定のパケットの宛先アドレスに最適なルートがBGPで配置されたルートである場合は、ソフトワイヤ（つまり、すべてのBGPルーティングパケット）を通してパケットを送信します。
More complicated policies are also possible, but a consideration of those policies is outside the scope of this document.
より複雑なポリシーも可能ですが、これらのポリシーの検討は、このドキュメントの範囲外です。
The choice of tunneling technology is a matter of policy configured at the ingress AFBR.
トンネル技術の選択は、イングレスAFBRで構成されたポリシーの問題です。
It is envisioned that, in most cases, the policy will be a very simple one, and will be the same at all the AFBRs of a given transit core -- e.g., "always use LDP-based MPLS" or "always use L2TPv3".
ほとんどの場合、ポリシーは非常に単純なものであり、特定のトランジットコアのすべてのAFBRで同じであることを想定しています。。
However, other deployments may have a mixture of routers, some of which support, say, both GRE and L2TPv3, but others of which support only one of those techniques. It is desirable therefore to allow the network administration to create a small set of classes and to configure each AFBR to be a member of one or more of these classes. Then the routers can advertise their class memberships to each other, and the encapsulation policies can be expressed as, e.g., "use L2TPv3 to talk to routers in class X; use GRE to talk to routers in class Y". To support such policies, it is necessary for the AFBRs to be able to advertise their class memberships. [RFC5512] specifies a way in which an AFBR may advertise, to other AFBRS, various characteristics that may be relevant to the policy (e.g., "I belong to class Y"). In many cases, these characteristics can be represented by arbitrarily selected communities or extended communities, and the policies at the ingress can be expressed in terms of these classes (i.e., communities).
ただし、他の展開にはルーターが混在している場合がありますが、その一部はGREとL2TPV3の両方をサポートしていますが、それらはそれらのテクニックの1つだけをサポートしています。したがって、ネットワーク管理が小さなクラスのセットを作成し、各AFBRをこれらのクラスの1つ以上のメンバーに設定できるようにすることが望ましいです。その後、ルーターはクラスのメンバーシップを互いに宣伝でき、カプセル化ポリシーは、「L2TPV3を使用してクラスXのルーターと通信します。GREを使用してクラスYのルーターと話す」として表現できます。このようなポリシーをサポートするには、AFBRがクラスメンバーシップを宣伝できるようにする必要があります。[RFC5512]は、AFBRがポリシーに関連する可能性のあるさまざまな特性を他のAFBRに宣伝する方法を指定します（たとえば、「私はクラスYに属します」）。多くの場合、これらの特性は、任意に選択されたコミュニティまたは拡張コミュニティによって表現でき、イングレスの政策はこれらのクラス（つまり、コミュニティ）の観点から表現できます。
Policy may also require a certain class of traffic to receive a certain quality of service, and this may impact the choice of tunnel and/or tunneling technology used for packets in that class. This framework allows a variety of tunneling technologies to be used for instantiating softwires. The choice of tunneling technology is a matter of policy, as discussed in Section 1.
ポリシーは、特定のサービスを受けるために特定のクラスのトラフィックを必要とする場合があり、これはそのクラスのパケットに使用されるトンネルおよび/またはトンネリングテクノロジーの選択に影響を与える可能性があります。このフレームワークにより、さまざまなトンネリング技術を使用して、ソフトウェアの即興に使用できます。セクション1で説明したように、トンネル技術の選択は政策の問題です。
While in many cases the policy will be unconditional, e.g., "always use L2TPv3 for softwires", in other cases the policy may specify that the choice is conditional upon information about the softwire remote endpoint, e.g., "use L2TPv3 to talk to routers in class X; use GRE to talk to routers in class Y". It is desirable therefore to allow the network administration to create a small set of classes, and to configure each AFBR to be a member of one or more of these classes. If each such class is represented as a community or extended community, then [RFC5512] specifies a method that AFBRs can use to advertise their class memberships to each other.
多くの場合、ポリシーは無条件になりますが、たとえば「常にソフトウェアにL2TPV3を使用する」。他の場合は、ポリシーは、選択がソフトワイヤーのリモートエンドポイントに関する情報を条件とすることを指定する場合があります。クラスX; GREを使用して、クラスYのルーターと話をします。したがって、ネットワーク管理が小さなクラスのセットを作成できるようにし、各AFBRをこれらのクラスの1つ以上のメンバーに設定できるようにすることが望ましいです。そのような各クラスがコミュニティまたは拡張コミュニティとして表されている場合、[RFC5512]は、AFBRSがクラスメンバーシップを互いに宣伝するために使用できる方法を指定します。
This framework also allows for policies of arbitrary complexity, which may depend on characteristics or attributes of individual address prefixes as well as on QoS or security considerations. However, the specification of such policies is not within the scope of this document.
また、このフレームワークは、個々のアドレスプレフィックスの特性または属性、およびQoSまたはセキュリティ上の考慮事項に依存する可能性があるarbitrary意的な複雑さのポリシーも可能にします。ただし、このようなポリシーの仕様は、このドキュメントの範囲内ではありません。
Suppose it has been decided to send a given packet through a softwire. Routing provides the address, in the address family of the transport network, of the BGP next hop. The packet MUST be sent through a softwire whose remote endpoint address is the same as the BGP next hop address.
Softwireを介して特定のパケットを送信することが決定されたとします。ルーティングは、輸送ネットワークの住所ファミリで、BGP Next Hopのアドレスを提供します。パケットは、リモートエンドポイントアドレスがBGP次のホップアドレスと同じソフトワイヤを介して送信する必要があります。
Sending a packet through a softwire is a matter of first encapsulating the packet with an encapsulation header that can be processed by the transit network and then transmitting towards the softwire's remote endpoint address.
ソフトワイヤーを介してパケットを送信することは、最初にパケットをトランジットネットワークによって処理できるカプセル化ヘッダーでパケットをカプセル化し、その後ソフトワイヤーのリモートエンドポイントアドレスに送信できる問題です。
In many cases, once one knows the remote endpoint address, one has all the information one needs in order to form the encapsulation header. This will be the case if the tunnel technology instantiating the softwire is, e.g., LDP-based MPLS, IP-in-IP, or GRE without optional header fields.
多くの場合、リモートエンドポイントアドレスを知っていれば、カプセル化ヘッダーを形成するために必要なすべての情報があります。これは、ソフトワイヤーをインスタンス化するトンネル技術が、たとえば、LDPベースのMPL、IP-in-IP、またはオプションのヘッダーフィールドのないGREである場合に当てはまります。
If the tunnel technology being used is L2TPv3 or GRE with optional header fields, additional information from the remote endpoint is needed in order to form the encapsulation header. The procedures for sending and receiving this information are described in [RFC5512].
使用されているトンネル技術がオプションのヘッダーフィールドを備えたL2TPV3またはGREである場合、カプセル化ヘッダーを形成するためにリモートエンドポイントからの追加情報が必要です。この情報を送信および受信する手順は、[RFC5512]で説明されています。
If the tunnel technology being used is RSVP-TE-based MPLS or IPsec, the native signaling procedures of those technologies will need to be used.
使用されているトンネル技術がRSVPベースのMPLSまたはIPSECである場合、これらのテクノロジーのネイティブシグナル伝達手順を使用する必要があります。
If the packet being sent through the softwire matches a route in the labeled IPv4 or labeled IPv6 address families, it should be sent through the softwire as an MPLS packet with the corresponding label. Note that most of the tunneling technologies mentioned in this document are capable of carrying MPLS packets, so this does not presuppose support for MPLS in the core routers.
Softwireを介して送信されるパケットがラベル付きのIPv4のルートと一致する場合、またはラベル付きIPv6アドレスファミリと一致する場合は、対応するラベルを持つMPLSパケットとしてソフトワイヤーを介して送信する必要があります。このドキュメントに記載されているトンネル技術のほとんどは、MPLSパケットを運ぶことができるため、これはコアルーターのMPLSのサポートを前提としていないことに注意してください。
Softwires are essentially tunnels connecting routers. If they disappear or degrade in performance, then connectivity through those tunnels will be impacted. There are several techniques available to monitor the status of the tunnel endpoints (AFBRs) as well as the tunnels themselves. These techniques allow operations such as softwire path tracing, remote softwire endpoint pinging, and remote softwire endpoint liveness failure detection.
ソフトウェアは、ルーターを接続する本質的にトンネルです。パフォーマンスが消えたり低下したりすると、これらのトンネルを介した接続が影響を受けます。トンネルエンドポイント（AFBR）とトンネル自体のステータスを監視するためのいくつかの手法があります。これらの手法により、ソフトワイヤーパストレース、リモートソフトワイヤーエンドポイントピンング、リモートソフトワイヤーエンドポイントの描写障害検出などの操作が可能になります。
Examples of techniques applicable to softwire OAM include:
Softwire OAMに適用可能なテクニックの例は次のとおりです。
o BGP/TCP timeouts between AFBRs
o AFBR間のBGP/TCPタイムアウト
o ICMP or LSP echo request and reply addressed to a particular AFBR
o ICMPまたはLSPエコーリクエストと特定のAFBRに宛てた返信
o BFD (Bidirectional Forwarding Detection) [BFD] packet exchange between AFBR routers
o BFD（双方向転送検出）[BFD] AFBRルーター間のパケット交換
Another possibility for softwire OAM is to build something similar to [RFC4378] or, in other words, to create and generate softwire echo request/reply packets. The echo request sent to a well-known UDP port would contain the egress AFBR IP address and the softwire identifier as the payload (similar to the MPLS Forwarding Equivalence Class contained in the LSP echo request). The softwire echo packet would be encapsulated with the encapsulation header and forwarded across the same path (inband) as that of the softwire itself.
Softwire OAMのもう1つの可能性は、[RFC4378]に似たものを構築するか、言い換えれば、Softwireエコーリクエスト/返信パケットを作成および生成することです。よく知られているUDPポートに送信されたエコー要求には、出生者AFBR IPアドレスとペイロードとしてのSoftwire Identifierが含まれます（LSPエコーリクエストに含まれるMPLS転送等価クラスと同様）。Softwire Echoパケットは、カプセル化ヘッダーでカプセル化され、ソフトワイヤー自体と同じパス（インバンド）を越えて転送されます。
This mechanism can also be automated to periodically verify remote softwire endpoint reachability, with the loss of reachability being signaled to the softwire application on the local AFBR, thus enabling suitable actions to be taken. Consideration must be given to the trade-offs between the scalability of such mechanisms versus the time required for detection of loss of endpoint reachability for such automated mechanisms.
また、このメカニズムは、リモートソフトワイヤーのエンドポイントの到達可能性を定期的に検証するために自動化することもできます。これにより、地元のAFBRのソフトワイヤーアプリケーションに到達可能性の損失が合図されるため、適切なアクションを実行できます。そのようなメカニズムのスケーラビリティと、そのような自動化されたメカニズムのエンドポイントリーチ性の喪失性の検出に必要な時間との間のトレードオフを考慮する必要があります。
In general, a framework for softwire OAM can, for a large part, be based on the [RFC4176] framework.
一般に、ソフトワイヤーOAMのフレームワークは、大部分が[RFC4176]フレームワークに基づくことができます。
Specific MIBs do exist to manage elements of the Softwire Mesh Framework. However, there will be a need to either extend these MIBs or create new ones that reflect the functional elements that can be SNMP-managed within the softwire network.
Softwire Meshフレームワークの要素を管理するために、特定のMIBSが存在します。ただし、これらのMIBを拡張するか、Softwireネットワーク内でSNMPに管理できる機能的要素を反映する新しいMIBを作成する必要があります。
A set of client networks, running E-IP, that are connected to a provider's I-IP transit core may wish to run IP multicast applications. Extending IP multicast connectivity across the transit core can be done in a number of ways, each with a different set of characteristics. Most (though not all) of the possibilities are either slight variations of the procedures defined for L3VPNs in [L3VPN-MCAST].
プロバイダーのI-IPトランジットコアに接続されているe-IPを実行しているクライアントネットワークのセットは、IPマルチキャストアプリケーションを実行したい場合があります。Transitコア全体にIPマルチキャスト接続を拡張することは、さまざまな方法で実行でき、それぞれ異なる特性セットがあります。可能性のほとんど（すべてではありませんが）は、[l3vpn-mcast]のL3VPNに対して定義された手順のわずかなバリエーションです。
We will focus on supporting those multicast features and protocols that are typically used across inter-provider boundaries. Support is provided for PIM-SM (Protocol Independent Multicast - Sparse Mode) and PIM-SSM (PIM Source-Specific Mode). Support for BIDIR-PIM (Bidirectional PIM), BSR (Bootstrap Router Mechanism for PIM), and AutoRP (Automatic Rendezvous Point Determination) is not provided as these features are not typically used across inter-provider boundaries.
一般的にプロバイダー間の境界を越えて使用されるマルチキャスト機能とプロトコルのサポートに焦点を当てます。PIM-SM（プロトコル独立マルチキャスト - スパースモード）およびPIM-SSM（PIMソース固有モード）のサポートが提供されます。Bidir-PIM（双方向PIM）、BSR（PIMのブートストラップルーターメカニズム）、およびAutorp（自動ランデブーポイント決定）のサポートは、これらの機能が通常、プロバイダー間境界全体で使用されないため、提供されません。
In the "one-to-one mapping" scheme, each client multicast tree is extended through the transit core so that for each client tree there is exactly one tree through the core.
「1対1のマッピング」スキームでは、各クライアントのマルチキャストツリーがトランジットコアを介して拡張されるため、各クライアントツリーにコアに1つのツリーが1つあります。
The one-to-one scheme is not used in [L3VPN-MCAST] because it requires an amount of state in the core routers that is proportional to the number of client multicast trees passing through the core. In the VPN context, this is considered undesirable because the amount of state is unbounded and out of the control of the service provider. However, the one-to-one scheme models the typical "Internet multicast" scenario where the client network and the transit core are both IPv4 or both IPv6. If it scales satisfactorily for that case, it should also scale satisfactorily for the case where the client network and the transit core support different versions of IP.
[L3VPN-Mcast]では、1対1のスキームは使用されていません。これは、コアを通るクライアントマルチキャストツリーの数に比例するコアルーターの状態の量を必要とするためです。VPNのコンテキストでは、これは、状態の量が無制限であり、サービスプロバイダーの制御不能であるため、望ましくないと見なされます。ただし、1対1のスキームにより、クライアントネットワークとトランジットコアがIPv4または両方のIPv6の両方である典型的な「インターネットマルチキャスト」シナリオをモデル化します。その場合、それが十分にスケーリングする場合、クライアントネットワークとTransit CoreがIPのさまざまなバージョンをサポートする場合にも十分にスケーリングする必要があります。
When an AFBR receives an E-IP PIM control message from one of its CEs, it translates it from E-IP to I-IP, and forwards it towards the source of the tree. Since the routers in the transit core will not generally have a route to the source of the tree, the AFBR must include an "RPF (Reverse Path Forwarding) Vector" [RFC5496] in the PIM message.
AFBRがCESの1つからE-IP PIMコントロールメッセージを受信すると、E-IPからI-IPに翻訳し、ツリーのソースに転送します。トランジットコアのルーターには一般にツリーのソースへのルートがないため、AFBRにはPIMメッセージに「RPF（逆パス転送）ベクトル」[RFC5496]を含める必要があります。
Suppose an AFBR A receives an E-IP PIM Join/Prune message from a CE for either an (S,G) tree or a (*,G) tree. The AFBR would have to "translate" the PIM message into an I-IP PIM message. It would then send it to the neighbor that is the next hop along the route to the root of the (S,G) or (*,G) tree. In the case of an (S,G) tree, the root of the tree is S; in the case of a (*,G) tree, the root of the tree is the Rendezvous Point (RP) for the group G.
AFBR Aが、（s、g）ツリーまたは（*、g）ツリーのCEからe-ip pim結合/プルーンメッセージを受信するとします。AFBRは、PIMメッセージをI-IP PIMメッセージに「翻訳」する必要があります。その後、（s、g）または（*、g）ツリーのルートへのルートに沿った次のホップである隣人に送信します。（s、g）ツリーの場合、ツリーの根はsです。（*、g）ツリーの場合、ツリーの根はグループGのランデブーポイント（RP）です。
Note that the address of the root of the tree will be an E-IP address. Since the routers within the transit core (other than the AFBRs) do not have routes to E-IP addresses, A must put an RPF Vector [RFC5496] in the PIM Join/Prune message that it sends to its upstream neighbor. The RPF Vector will identify, as an I-IP address, the AFBR B that is the egress point in the transit network along the route to the root of the multicast tree. AFBR B is AFBR A's BGP next hop for the route to the root of the tree. The RPF Vector allows the core routers to forward PIM Join/Prune messages upstream towards the root of the tree, even though they do not maintain E-IP routes.
ツリーのルートのアドレスはE-IPアドレスになることに注意してください。Transit Core内のルーター（AFBR以外）にはE-IPアドレスへのルートがないため、上流の隣人に送信するPIM結合/PruneメッセージにRPFベクター[RFC5496]を配置する必要があります。RPFベクトルは、I-IPアドレスとして、マルチキャストツリーのルートへのルートに沿ったトランジットネットワークの出力ポイントであるAFBR Bを識別します。AFBR Bは、ツリーのルートへのルートのAFBR AのBGPの次のホップです。RPFベクトルにより、コアルーターは、E-IPルートを維持していなくても、ツリーのルートに向かって上流にメッセージを接合/プルンすることができます。
In order to translate an E-IP PIM message into an I-IP PIM message, the AFBR A must translate the address of S (in the case of an (S,G) group) or the address of G's RP from the E-IP address family to the I-IP address family, and the AFBR B must translate them back.
e-ip pimメッセージをi-ip pimメッセージに翻訳するために、afbr aは、s（s、g）グループの場合）またはe-からのgのrpのアドレスを翻訳する必要があります。IPアドレスファミリはI-IPアドレスファミリーになり、AFBR Bはそれらを翻訳する必要があります。
In the case where E-IP is IPv4 and I-IP is IPv6, it may be possible to do this translation algorithmically. A can translate the IPv4 S into the corresponding IPv4-mapped IPv6 address [RFC4291], and then B can translate it back. At the time of this writing, there is no such thing as an IPv4-mapped IPv6 multicast address, but if such a thing were to be standardized, then A could also translate the IPv4 G into IPv6, and B could translate it back. The precise circumstances under which these translations are to be done would be a matter of policy.
E-IPがIPv4で、I-IPがIPv6である場合、この翻訳をアルゴリズム的に行うことが可能かもしれません。A CANは、IPv4Sを対応するIPv4-Mapped IPv6アドレス[RFC4291]に変換し、Bがバックバックすることができます。この執筆時点では、IPv4-Mapped IPv6マルチキャストアドレスのようなものはありませんが、そのようなことを標準化する場合、AはIPv4 GをIPv6に翻訳することもでき、Bはそれを翻訳することもできます。これらの翻訳が行われる正確な状況は、政策の問題になるでしょう。
Obviously, this translation procedure does not generalize to the case where the client multicast is IPv6 but the core is IPv4. To handle that case, one needs additional signaling between the two AFBRs. Each downstream AFBR needs to signal the upstream AFBR that it needs a multicast tunnel for (S,G). The upstream AFBR must then assign a multicast address G' to the tunnel and inform the downstream of the P-G value to use. The downstream AFBR then uses PIM/IPv4 to join the (S',G') tree, where S' is the IPv4 address of the upstream ASBR (Autonomous System Border Router).
明らかに、この翻訳手順は、クライアントマルチキャストがIPv6であるが、コアはIPv4である場合に一般化するものではありません。そのケースを処理するには、2つのAFBR間の追加のシグナル伝達が必要です。各下流のAFBRは、上流のAFBRにマルチキャストトンネルが必要であることを示す必要があります（s、g）。上流のAFBRは、マルチキャストアドレスg 'をトンネルに割り当て、使用するP-g値を下流に通知する必要があります。その後、下流のAFBRはPIM/IPv4を使用して（S '、g'）ツリーを結合します。ここで、S 'はアップストリームASBR（自律システムボーダールーター）のIPv4アドレスです。
The (S',G') trees should be SSM trees.
（s '、g'）木はSSMツリーでなければなりません。
This procedure can be used to support client multicasts of either IPv4 or IPv6 over a transit core of the opposite protocol. However, it only works when the client multicasts are SSM, since it provides no method for mapping a client "prune a source off the (*,G) tree" operation into an operation on the (S',G') tree. This method also requires additional signaling. The BGP-based signaling of [L3VPN-MCAST-BGP] is one signaling method that could be used. Other signaling methods could be defined as well.
この手順は、反対のプロトコルのトランジットコアを介して、IPv4またはIPv6のいずれかのクライアントマルチキャストをサポートするために使用できます。ただし、クライアントのマルチキャストがSSMである場合にのみ機能します。クライアントが（*、g）ツリーからソースをプルーン化する」操作を（s '、g'）ツリーの操作にマッピングする方法を提供しないためです。この方法には、追加のシグナル伝達も必要です。[L3VPN-MCAST-BGP]のBGPベースのシグナル伝達は、使用できるシグナル伝達方法の1つです。他のシグナル伝達方法も定義できます。
LDP extensions for point-to-multipoint and multipoint-to-multipoint LSPs are specified in [MLDP]; we will use the term "mLDP" to refer to those LDP extensions. If the transit core implements mLDP and supports multicast MPLS, then client Source-Specific Multicast (SSM) trees can be mapped one-to-one onto P2MP (Point-to-Multipoint) LSPs.
Point-to-MultiPointおよびMultipoint-to-MultiPoint LSPのLDP拡張機能は、[MLDP]で指定されています。「MLDP」という用語を使用して、これらのLDP拡張機能を参照します。Transit CoreがMLDPを実装し、マルチキャストMPLSをサポートする場合、クライアントソース固有のマルチキャスト（SSM）ツリーをP2MP（ポイントツーマルチポイント）LSPに1対1でマッピングできます。
When an AFBR A receives an E-IP PIM Join/Prune message for (S,G) from one of its CEs, where G is an SSM group, it would use mLDP to join a P2MP LSP. The root of the P2MP LSP would be the AFBR B that is A's BGP next hop on the route to S. In mLDP, a P2MP LSP is uniquely identified by a combination of its root and an "FEC (Forwarding Equivalence Class) identifier". The original (S,G) can be algorithmically encoded into the FEC identifier so that all AFBRs that need to join the P2MP LSP for (S,G) will generate the same FEC identifier. When the root of the P2MP LSP (AFBR B) receives such an mLDP message, it extracts the original (S,G) from the FEC identifier, creates an "ordinary" E-IP PIM Join/Prune message, and sends it to the CE that is its next hop on the route to S.
AFBR AがCESの1つから（S、G）のE-IP PIM結合/プルーンメッセージを受信すると、GはSSMグループである場合、MLDPを使用してP2MP LSPに参加します。P2MP LSPのルートは、AのBGP次のAFBR Bであり、MLDPでのルートに次にホップします。P2MPLSPは、そのルートと「FEC（転送等価クラス）識別子」の組み合わせによって一意に識別されます。元の（s、g）は、FEC識別子にアルゴリズム的にエンコードできるため、（s、g）のP2MP LSPを結合する必要があるすべてのAFBRが同じFEC識別子を生成します。P2MP LSPのルート（AFBR B）がそのようなMLDPメッセージを受信すると、FEC識別子から元の（s、g）を抽出し、「通常の」e-ip pim結合メッセージを作成し、それを送信します。S.へのルートの次のホップであるCE
The method of encoding the (S,G) into the FEC identifier needs to be standardized. The encoding must be self-identifying so that a node that is the root of a P2MP LSP can determine whether a FEC identifier is the result of having encoded a PIM (S,G).
（s、g）をFEC識別子にエンコードする方法を標準化する必要があります。エンコードは、P2MP LSPのルートであるノードがFEC識別子がPIM（S、G）をエンコードした結果であるかどうかを判断できるように、自己識別でなければなりません。
The appropriate state machinery must be standardized so that PIM events at the AFBRs result in the proper mLDP events. For example, if at some point an AFBR determines (via PIM procedures) that it no longer has any downstream receivers for (S,G), the AFBR should invoke the proper mLDP procedures to prune itself off the corresponding P2MP LSP.
AFBRSでのPIMイベントにより、適切なMLDPイベントが発生するように、適切な状態機械を標準化する必要があります。たとえば、ある時点でAFBRが（PIM手順を介して）（S、G）の下流レシーバーがなくなっていないことを（PIM手順を介して）決定した場合、AFBRは適切なMLDP手順を呼び出して、対応するP2MP LSPを整理する必要があります。
Note that this method cannot be used when the G is a Sparse Mode group. The reason this method cannot be used is that mLDP does not have any function corresponding to the PIM "prune this source off the shared tree" function. So if a P2MP LSP were mapped one-to-one with a P2MP LSP, duplicate traffic could end up traversing the transit core (i.e., traffic from S might travel down both the shared tree and S's source tree). Alternatively, one could devise an AFBR-to-AFBR protocol to prune sources off the P2MP LSP at the root of the LSP. It is recommended, though, that client SM multicast groups be supported by other methods, such as those discussed below.
Gがスパースモードグループの場合、この方法は使用できないことに注意してください。この方法を使用できない理由は、MLDPがPIM「このソースを共有ツリーからプルネ」に対応する関数を持っていないためです。したがって、P2MP LSPがP2MP LSPを使用して1対1でマッピングされた場合、重複するトラフィックがトランジットコアを通過する可能性があります（つまり、Sからのトラフィックは共有ツリーとSのソースツリーの両方を下に移動する可能性があります）。あるいは、AFBRからAFBRプロトコルを考案して、LSPの根元にあるP2MP LSPからソースをプルネートすることもできます。ただし、クライアントSMマルチキャストグループは、以下で説明するような他の方法でサポートされることをお勧めします。
Client-side bidirectional multicast groups set up by PIM-bidir could be mapped using the above technique to MP2MP (Multipoint-to-Multipoint) LSPs set up by mLDP [MLDP]. We do not consider this further, as inter-provider bidirectional groups are not in use anywhere.
PIM-Bidirによって設定されたクライアント側の双方向マルチキャストグループは、上記の手法をMP2MP（Multipoint-to-Multipoint）LSPにMLDP [MLDP]によって設定してマッピングできます。プロバイダー間の双方向グループはどこにも使用されていないため、これをさらに考慮しません。
The "MVPN (Multicast VPN)-like schemes" are those described in [L3VPN-MCAST] and its companion documents (such as [L3VPN-MCAST-BGP]). To apply those schemes to the softwire environment, it is necessary only to treat all the AFBRs of a given transit core as if they were all, for multicast purposes, PE routers attached to the same VPN.
「MVPN（マルチキャストVPN）のようなスキーム」は、[l3vpn-mcast]とそのコンパニオンドキュメント（[l3vpn-mcast-bgp]など）に記載されているものです。これらのスキームをソフトワイヤー環境に適用するには、特定のトランジットコアのすべてのAFBRを、まるでそれらがすべてであるかのように、マルチキャストの目的で、同じVPNに接続されたPEルーターを処理する必要があります。
The MVPN-like schemes do not require a one-to-one mapping between client multicast trees and transit-core multicast trees. In the MVPN environment, it is a requirement that the number of trees in the core scales less than linearly with the number of client trees. This requirement may not hold in the softwire scenarios.
MVPNのようなスキームでは、クライアントマルチキャストツリーとトランジットコアマルチキャストツリーの間の1対1のマッピングを必要としません。MVPN環境では、コア内の木の数がクライアントツリーの数で直線的にスケーリングしないことが要件です。この要件は、ソフトワイヤーのシナリオでは保持されない場合があります。
The MVPN-like schemes can support SM, SSM, and Bidir groups. They provide a number of options for the control plane:
MVPNのようなスキームは、SM、SSM、およびBidirグループをサポートできます。コントロールプレーンの多くのオプションを提供します。
- LAN-like
- LAN-like
Use a set of multicast trees in the core to emulate a LAN (Local Area Network) and run the client-side PIM protocol over that "LAN". The "LAN" can consist of a single Bidir tree containing all the AFBRs or a set of SSM trees, one rooted at each AFBR and containing all the other AFBRs as receivers.
コア内のマルチキャストツリーのセットを使用して、LAN（ローカルエリアネットワーク）をエミュレートし、その「LAN」の上でクライアント側のPIMプロトコルを実行します。「LAN」は、すべてのAFBRまたはSSMツリーのセットを含む単一のビディールツリーで構成でき、1つは各AFBRに根を張り、他のすべてのAFBRを受信機として含めています。
- NBMA (Non-Broadcast Multiple Access), using BGP
- NBMA（非放送マルチアクセス）、BGPを使用
The client-side PIM signaling can be translated into BGP-based signaling, with a BGP Route Reflector mediating the signaling.
クライアント側のPIMシグナル伝達は、BGPベースのシグナル伝達に変換でき、BGPルートリフレクターがシグナリングを媒介します。
These two basic options admit of many variations; a comprehensive discussion is in [L3VPN-MCAST].
これらの2つの基本的なオプションは、多くのバリエーションを認めています。包括的な議論は[l3vpn-mcast]にあります。
For the data plane, there are also a number of options:
データプレーンには、多くのオプションもあります。
- All multicast data sent over the emulated LAN. This particular option is not very attractive, though, for the softwire scenarios, as every AFBR would have to receive every client multicast packet.
- エミュレートされたLANを介して送信されるすべてのマルチキャストデータ。ただし、すべてのAFBRがすべてのクライアントマルチキャストパケットを受信する必要があるため、この特定のオプションはそれほど魅力的ではありません。
- Every multicast group mapped to a tree that is considered appropriate for that group, in the sense of causing the traffic of that group to go to "too many" AFBRs that don't need to receive it.
- すべてのマルチキャストグループは、そのグループのトラフィックがそれを受け取る必要のない「多すぎる」AFBRに移動するという意味で、そのグループに適していると見なされるツリーにマッピングされました。
Again, a comprehensive discussion of the issues can be found in [L3VPN-MCAST].
繰り返しますが、問題の包括的な議論は[L3VPN-Mcast]に記載されています。
We have so far only considered the case where a "transit core" consists of a single Autonomous System (AS). If the transit core consists of multiple ASes, then it may be necessary to use softwires whose endpoints are AFBRs attached to different Autonomous Systems. In this case, the AFBR at the remote endpoint of a softwire is not the BGP next hop for packets that need to be sent on the softwire. Since the procedures described above require the address of a remote softwire endpoint to be the same as the address of the BGP next hop, those procedures do not work as specified when the transit core consists of multiple ASes.
これまでのところ、「トランジットコア」が単一の自律システム（AS）で構成されている場合のみを考慮しました。トランジットコアが複数のASEで構成されている場合、エンドポイントが異なる自律システムに接続されているAFBRであるソフトウェアを使用する必要がある場合があります。この場合、ソフトワイヤのリモートエンドポイントにあるAFBRは、ソフトワイヤで送信する必要があるパケットのBGP次のホップではありません。上記の手順では、リモートソフトワイヤーエンドポイントのアドレスがBGP Next Hopのアドレスと同じであることが必要なため、これらの手順は、トランジットコアが複数のASで構成されている場合に指定されたとおりに機能しません。
There are several ways to deal with this situation.
この状況に対処する方法はいくつかあります。
1. Don't do it; require that there be AFBRs at the edge of each AS so that a transit core does not extend more than one AS.
1. それをしないでください。それぞれの端にAFBRがあることを要求して、トランジットコアが複数のASを拡張しないようにします。
2. Use multi-hop EBGP to allow AFBRs to send BGP routes to each other, even if the ABFRs are not in the same or in neighboring ASes.
2. マルチホップEBGPを使用して、ABFRが同じまたは隣接するASEにない場合でも、AFBRがBGPルートを相互に送信できるようにします。
3. Ensure that an ASBR that is not an AFBR does not change the next hop field of the routes for which encapsulation is needed.
3. AFBRではないASBRが、カプセル化が必要なルートの次のホップフィールドを変更しないことを確認してください。
In the latter two cases, BGP recursive next hop resolution needs to be done, and encapsulations may need to be "stacked" (i.e., multiple layers of encapsulation may need to be used).
後者の2つのケースでは、BGPの再帰的な次のホップ解像度を行う必要があり、カプセルを「積み重ねる」必要がある場合があります（つまり、複数のカプセル化の層を使用する必要がある場合があります）。
For instance, consider packet P with destination IP address D. Suppose it arrives at ingress AFBR A1 and that the route that is the best match for D has BGP next hop B1. So A1 will encapsulate the packet for delivery to B1. If B1 is not within A1's AS, A1 will need to look up the route to B1 and then find the BGP next hop, call it B2, of that route. If the interior routers of A1's AS do not have routes to B1, then A1 needs to encapsulate the packet a second time, this time for delivery to B2.
たとえば、宛先IPアドレスDのパケットPを検討してください。IngressAFBRA1に到着し、Dに最適なルートにはBGP Next Hop B1があるとします。したがって、A1はB1への配信のためにパケットをカプセル化します。B1がA1のAS内にない場合、A1はB1へのルートを検索してからBGP次のホップを見つける必要があります。そのルートのB2と呼びます。A1の内部ルーターがB1へのルートがない場合、A1は2回目のパケットをカプセル化する必要があります。
In the Softwire Mesh Framework, the data packets that are encapsulated are E-IP data packets that are traveling through the Internet. These data packets (the softwire "payload") may or may not need such security features as authentication, integrity, confidentiality, or replay protection. However, the security needs of the payload packets are independent of whether or not those packets are traversing softwires. The fact that a particular payload packet is traveling through a softwire does not in any way affect its security needs.
Softwire Meshフレームワークでは、カプセル化されたデータパケットは、インターネットを走行しているE-IPデータパケットです。これらのデータパケット（Softwire "Payload"）は、認証、整合性、機密性、リプレイ保護などのセキュリティ機能が必要になる場合と必要な場合があります。ただし、ペイロードパケットのセキュリティニーズは、これらのパケットがソフトウェアを横断しているかどうかに依存しません。特定のペイロードパケットがソフトワイヤを通過しているという事実は、セキュリティのニーズには決して影響しません。
Thus, the only security issues we need to consider are those that affect the I-IP encapsulation headers, rather than those that affect the E-IP payload.
したがって、私たちが考慮する必要があるセキュリティの問題は、E-IPペイロードに影響を与えるものではなく、I-IPカプセル化ヘッダーに影響を与えるセキュリティの問題です。
Since the encapsulation headers determine the routing of packets traveling through softwires, they must appear "in the clear".
カプセル化ヘッダーは、ソフトワイヤを走行するパケットのルーティングを決定するため、「クリア」に表示されなければなりません。
In the Softwire Mesh Framework, for each receiving endpoint of a tunnel, there are one or more "valid" transmitting endpoints, where the valid transmitting endpoints are those that are authorized to tunnel packets to the receiving endpoint. If the encapsulation header has no guarantee of authentication or integrity, then it is possible to have spoofing attacks, in which unauthorized nodes send encapsulated packets to the receiving endpoint, giving the receiving endpoint the invalid impression the encapsulated packets have really traveled through the softwire. Replay attacks are also possible.
ソフトワイヤーメッシュフレームワークでは、トンネルの受信エンドポイントごとに、1つ以上の「有効な」送信エンドポイントがあります。ここでは、有効な送信エンドポイントは、受信エンドポイントまでトンネルパケットをトンネルすることを許可されたエンドポイントです。カプセル化ヘッダーに認証または整合性の保証がない場合、不正なノードがカプセル化されたパケットを受信エンドポイントに送信するスプーフィング攻撃を行うことができます。リプレイ攻撃も可能です。
The effect of such attacks is somewhat limited, though. The receiving endpoint of a softwire decapsulates the payload and does further routing based on the IP destination address of the payload. Since the payload packets are traveling through the Internet, they have addresses from the globally unique address space (rather than, e.g., from a private address space of some sort). Therefore, these attacks cannot cause payload packets to be delivered to an address other than the one appearing in the destination IP address field of the payload packet.
ただし、そのような攻撃の効果はやや制限されています。ソフトワイヤの受信エンドポイントはペイロードを脱カプセル化し、ペイロードのIP宛先アドレスに基づいてさらにルーティングを行います。ペイロードパケットはインターネットを通過しているため、グローバルに一意のアドレススペースからのアドレスがあります（たとえば、ある種のプライベートアドレススペースからではなく）。したがって、これらの攻撃により、ペイロードパケットは、ペイロードパケットの宛先IPアドレスフィールドに表示されるもの以外のアドレスに配信されません。
However, attacks of this sort can result in policy violations. The authorized transmitting endpoint(s) of a softwire may be following a policy according to which only certain payload packets get sent through the softwire. If unauthorized nodes are able to encapsulate the payload packets so that they arrive at the receiving endpoint looking as if they arrived from authorized nodes, then the properly authorized policies have been side-stepped.
ただし、この種の攻撃により、政策違反が発生する可能性があります。ソフトワイヤの承認された送信エンドポイントは、特定のペイロードパケットのみがソフトワイヤを介して送信されるというポリシーに従っている可能性があります。許可されていないノードがペイロードパケットをカプセル化して、認定ノードから到着したかのように見える受信エンドポイントに到着できるようにすると、適切に認可されたポリシーがサイドステップされています。
Attacks of the sort we are considering can also be used in denial-of-service attacks on the receiving tunnel endpoints. However, such attacks cannot be prevented by use of cryptographic authentication/integrity techniques, as the need to do cryptography on spoofed packets only makes the denial-of-service problem worse. (The assumption is that the cryptography mechanisms are likely to be more costly than the decapsulation/forwarding mechanisms. So if one tries to eliminate a flooding attack on the decapsulation/forwarding mechanisms by discarding packets that do not pass a cryptographic integrity test, one ends up just trading one kind of attack for another.)
私たちが検討している種類の攻撃は、受信トンネルのエンドポイントに対するサービス拒否攻撃でも使用できます。ただし、そのような攻撃は、暗号化されたパケットで暗号化を行う必要があるため、サービス拒否の問題を悪化させるため、暗号化認証/整合性技術を使用してもそのような攻撃を防ぐことはできません。（仮定は、暗号化メカニズムは脱カプセル化/転送メカニズムよりもコストがかかる可能性が高いということです。したがって、暗号化の整合性テストに合格しないパケットを破棄することにより、脱カプセル化/転送メカニズムに対する洪水攻撃を排除しようとすると、ある種の攻撃を別の攻撃と交換するだけです。）
This section is largely based on the security considerations section of RFC 4023, which also deals with encapsulations and tunnels.
このセクションは、主にRFC 4023のセキュリティに関する考慮事項セクションに基づいており、カプセルとトンネルも扱っています。
If a tunnel lies entirely within a single administrative domain, then, to a certain extent, there are certain non-cryptographic techniques one can use to prevent spoofed packets from reaching a tunnel's receiving endpoint. For example, when the tunnel encapsulation is IP-based:
トンネルが完全に単一の管理ドメイン内にある場合、ある程度まで、スプーフィングされたパケットがトンネルの受信エンドポイントに到達するのを防ぐために使用できる特定の非暗号化技術があります。たとえば、トンネルのカプセル化がIPベースの場合：
- The receiving endpoints of the tunnels can be given a distinct set of addresses, and those addresses can be made known to the border routers. The border routers can then filter out packets, destined to those addresses, that arrive from outside the domain.
- トンネルの受信エンドポイントには、明確なアドレスのセットを与えることができ、これらのアドレスはボーダールーターに知られるようにすることができます。ボーダールーターは、ドメインの外側から到着するアドレスに運命づけられたパケットを除外できます。
- The transmitting endpoints of the tunnels can be given a distinct set of addresses, and those addresses can be made known to the border routers and to the receiving endpoints of the tunnels. The border routers can filter out all packets arriving from outside the domain with source addresses that are in this set, and the receiving endpoints can discard all packets that appear to be part of a softwire, but whose source addresses are not in this set.
- トンネルの送信エンドポイントには、明確なアドレスのセットを与えることができ、これらのアドレスは、境界線ルーターとトンネルの受信エンドポイントに知られることができます。ボーダールーターは、このセットにあるソースアドレスを使用してドメインの外から到着するすべてのパケットを除外でき、受信エンドポイントはソフトワイヤの一部であるように見えるすべてのパケットを破棄できますが、そのソースアドレスはこのセットにありません。
If an MPLS-based encapsulation is used, the border routers can refuse to accept MPLS packets from outside the domain, or they can refuse to accept such MPLS packets whenever the top label corresponds to the address of a tunnel receiving endpoint.
MPLSベースのカプセル化が使用されている場合、ボーダールーターはドメインの外部からMPLSパケットを受け入れることを拒否できます。または、トップラベルがトンネルを受け取るエンドポイントのアドレスに対応する場合はいつでも、そのようなMPLSパケットを受け入れることを拒否できます。
These techniques assume that, within a domain, the network is secure enough to prevent the introduction of spoofed packets from within the domain itself. That may not always be the case. Also, these techniques can be difficult or impossible to use effectively for tunnels that are not in the same administrative domain.
これらの手法は、ドメイン内で、ネットワークがドメイン自体内からスプーフィングされたパケットの導入を防ぐのに十分なほど安全であると仮定しています。それは必ずしもそうではないかもしれません。また、これらの手法は、同じ管理ドメインにないトンネルに効果的に使用することが困難または不可能です。
A different technique is to have the encapsulation header contain a cleartext password. The 64-bit "cookie" of L2TPv3 [RFC3931] is sometimes used in this way. This can be useful within an administrative domain if it is regarded as infeasible for an attacker to spy on packets that originate in the domain and that do not leave the domain. An attacker would then not be able to discover the password. An attacker could, of course, try to guess the password, but if the password is an arbitrary 64-bit binary sequence, brute force attacks that run through all the possible passwords would be infeasible. This technique may be easier to manage than ingress filtering is, and may be just as effective if the assumptions hold. Like ingress filtering, though, it may not be applicable for tunnels that cross domain boundaries.
別の手法は、カプセル化ヘッダーにクリアテキストパスワードを含めることです。L2TPV3 [RFC3931]の64ビット「Cookie」は、この方法で時々使用されます。これは、攻撃者がドメインに由来し、ドメインを離れないパケットをスパイすることが実行不可能であると見なされる場合、管理ドメイン内で役立ちます。攻撃者はパスワードを発見できません。もちろん、攻撃者はパスワードを推測することができますが、パスワードが任意の64ビットのバイナリシーケンスである場合、可能なすべてのパスワードを実行するブルートフォース攻撃は実行不可能です。この手法は、イングレスフィルタリングがISよりも管理しやすい場合があり、仮定が当てはまる場合と同じように効果的かもしれません。ただし、イングレスフィルタリングと同様に、ドメインの境界を横断するトンネルには適用できない場合があります。
Therefore, it is necessary to also consider the use of cryptographic techniques for setting up the tunnels and for passing data through them.
したがって、トンネルをセットアップし、データを渡すための暗号化技術の使用も考慮する必要があります。
If the path between the two endpoints of a tunnel is not adequately secure, then:
トンネルの2つのエンドポイント間のパスが適切に保護されていない場合、次のとおりです。
- If a control protocol is used to set up the tunnels (e.g., to inform one tunnel endpoint of the IP address of the other), the control protocol MUST have an authentication mechanism, and this MUST be used when the tunnel is set up. If the tunnel is set up automatically as the result of, for example, information distributed by BGP, then the use of BGP's MD5-based authentication mechanism [RFC2385] is satisfactory.
- コントロールプロトコルを使用してトンネルをセットアップする場合（たとえば、他方のIPアドレスの1つのトンネルエンドポイントを通知するため）、コントロールプロトコルには認証メカニズムが必要であり、これを使用する必要があります。たとえば、BGPによって配布された情報の結果としてトンネルが自動的にセットアップされる場合、BGPのMD5ベースの認証メカニズム[RFC2385]の使用は満足のいくものです。
- Data transmission through the tunnel should be secured with IPsec. In the remainder of this section, we specify the way IPsec may be used, and the implementation requirements we mention are meant to be applicable whenever IPsec is being used.
- トンネルを介したデータ送信は、IPSECで固定する必要があります。このセクションの残りの部分では、IPSECの使用方法を指定し、IPSECが使用されている場合はいつでも適用できるように言及する実装要件を指定します。
We consider only the case where IPsec is used together with an IP-based tunneling mechanism. Use of IPsec with an MPLS-based tunneling mechanism is for further study.
IPSECがIPベースのトンネルメカニズムと一緒に使用される場合のみを検討します。MPLSベースのトンネルメカニズムを使用したIPSECの使用は、さらなる研究のためのものです。
If it is deemed necessary to use tunnels that are protected by IPsec, the tunnel type SHOULD be negotiated by the tunnel endpoints using the procedures specified in [RFC5566]. That document allows the use of IPsec tunnel mode but also allows one to treat the tunnel head and the tunnel tail as the endpoints of a Security Association, and to use IPsec transport mode.
IPSECによって保護されているトンネルを使用する必要があるとみなされる場合、[RFC5566]で指定された手順を使用して、トンネルのエンドポイントによってトンネルの種類を交渉する必要があります。このドキュメントにより、IPSECトンネルモードの使用が可能になりますが、トンネルヘッドとトンネルテールをセキュリティ協会のエンドポイントとして処理し、IPSECトランスポートモードを使用することもできます。
In order to use IPsec transport mode, encapsulated packets should be viewed as originating at the tunnel head and as being destined for the tunnel tail. A single IP address of the tunnel head will be used as the source IP address, and a single IP address of the tunnel tail will be used as the destination IP address. This technique can be used to carry MPLS packets through an IPsec Security Association, by first encapsulating the MPLS packets in MPLS-in-IP or MPLS-in-GRE [RFC4023] and then applying IPsec transport mode.
IPSECトランスポートモードを使用するには、カプセル化されたパケットは、トンネルヘッドに由来し、トンネルテールに向けて運命づけられていると見なす必要があります。トンネルヘッドの単一のIPアドレスがソースIPアドレスとして使用され、トンネルテールの単一のIPアドレスが宛先IPアドレスとして使用されます。この手法は、最初にMPLS-in-IPまたはMPLS-in-Gre [RFC4023]のMPLSパケットをカプセル化し、次にIPSECトランスポートモードを適用することにより、IPSECセキュリティ協会を介してMPLSパケットを運ぶために使用できます。
When IPsec is used to secure softwires, IPsec MUST provide authentication and integrity. Thus, the implementation MUST support either ESP (IP Encapsulating Security Payload) with null encryption [RFC4303] or else AH (IP Authentication Header) [RFC4302]. ESP with encryption MAY be supported. If ESP is used, the tunnel tail MUST check that the source IP address of any packet received on a given SA (IPsec Security Association) is the one expected, as specified in Section 5.2, step 4, of [RFC4301].
IPSECがソフトウェアのセキュリティに使用される場合、IPSECは認証と整合性を提供する必要があります。したがって、実装は、null暗号化[RFC4303]またはAH（IP認証ヘッダー）[RFC4302]を使用して、ESP（セキュリティペイロードをカプセル化するIP）のいずれかをサポートする必要があります。暗号化付きESPがサポートされる場合があります。ESPを使用する場合、トンネルテールは、[RFC4301]のセクション5.2、ステップ4で指定されているように、特定のSA（IPSECセキュリティアソシエーション）で受信したパケットのソースIPアドレスが予想されるものであることを確認する必要があります。
Since the softwires are set up dynamically as a byproduct of passing routing information, key distribution MUST be done automatically by means of IKEv2 [RFC4306]. If a PKI (Public Key Infrastructure) is not available, the IPsec Tunnel Authenticator sub-TLV described in [RFC5566] MUST be used and validated before setting up an SA.
ソフトウェアは、ルーティング情報を渡すことの副産物として動的にセットアップされるため、IKEV2 [RFC4306]によってキー分布を自動的に実行する必要があります。PKI（公開キーインフラストラクチャ）が利用できない場合、[RFC5566]に記載されているIPSECトンネルAuthenticator Sub-TLVを使用して検証する必要があります。
The selectors associated with the SA are the source and destination addresses of the encapsulation header, along with the IP protocol number representing the encapsulation protocol being used.
SAに関連付けられたセレクターは、使用されているカプセル化プロトコルを表すIPプロトコル番号とともに、カプセル化ヘッダーのソースおよび宛先アドレスです。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003] Perkins、C。、「IP内のIPカプセル化」、RFC 2003、1996年10月。
[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月。
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000.
[RFC2784] Farinacci、D.、Li、T.、Hanks、S.、Meyer、D。、およびP. Traina、「Generic Routing Cancapstulation（GRE）」、RFC 2784、2000年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031] Rosen、E.、Viswanathan、A。、およびR. Callon、「Multiprotocolラベルスイッチングアーキテクチャ」、RFC 3031、2001年1月。
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
[RFC3032] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. conta、「Mpls Label Stack ending」、RFC 3032、2001年1月。
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
[RFC3209] Awduche、D.、Berger、L.、Gan、D.、Li、T.、Srinivasan、V。、およびG. Swallow、「RSVP-TE：LSPトンネルのRSVPへの拡張」、RFC 3209、12月2001年。
[RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[RFC3931] Lau、J.、ed。、Ed。、Townsley、M.、ed。、およびI. Goyret、ed。、「レイヤー2トンネリングプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005.
[RFC4023] Worster、T.、Rekhter、Y.、およびE. Rosen、ed。、「IPまたは汎用ルーティングカプセル化（GRE）のMPLのカプセル化」、RFC 4023、2005年3月。
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation Subsequent Address Family Identifier (SAFI) and the BGP Tunnel Encapsulation Attribute", RFC 5512, April 2009.
[RFC5512] Mohapatra、P。およびE. Rosen、「BGPカプセル化後のアドレスファミリー識別子（SAFI）およびBGPトンネルカプセル化属性」、RFC 5512、2009年4月。
[RFC5566] Berger, L., White, R. and E. Rosen, "BGP IPsec Tunnel Encapsulation Attribute", RFC 5566, June 2009.
[RFC5566] Berger、L.、White、R。、およびE. Rosen、「BGP IPSECトンネルカプセル化属性」、RFC 5566、2009年6月。
[V4NLRI-V6NH] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next Hop", RFC 5549, May 2009.
[V4NLRI-V6NH] Le Faucheur、F。およびE. Rosen、「IPV4ネットワークレイヤーの到達可能性情報をIPv6 Next Hopで広告」、RFC 5549、2009年5月。
[V6NLRI-V4NH] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 Provider Edge Routers (6PE)", RFC 4798, February 2007.
[v6nlri-v4nh] de clercq、J.、ooms、D.、Prevost、S。、およびF. le Faucheur、「IPv6プロバイダーエッジルーター（6PE）を使用してIPv6島をIPv4 MPLSで接続する」、2007年2月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, February 2009.
[BFD] Katz、D。およびD. Ward、「双方向転送検出」、2009年2月、進行中の作業。
[L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, March 2009.
[L3VPN-Mcast] Rosen、E.、ed。、およびR. Aggarwal、ed。、「MPLS/BGP IP VPNSのマルチキャスト」、2009年3月、進行中の作業。
[L3VPN-MCAST-BGP] Aggarwal, R., Rosen, E., Morin, T. and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", Work in Progress, April 2009.
[L3VPN-MCAST-BGP] Aggarwal、R.、Rosen、E.、Morin、T。、およびY. Rekhter、「MPLS/BGP IP VPNSのマルチキャストのBGPエンコーディングと手順」、2009年4月の作業。
[MLDP] Minei, I., Ed., Kompella, K., Wijnands, IJ., Ed., and B. Thomas, "Label Distribution Protocol Extensions for Point-to-Multipoint and Multipoint-to-Multipoint Label Switched Paths", Work in Progress, April 2009.
[MLDP] Misei、I.、ed。、Kompella、K.、Wijnands、IJ。、ed。、およびB. Thomas、「ポイントツーマルチポイントおよびマルチポイントツーマルチポイントラベルスイッチ付きパスのラベル分布プロトコル拡張」、作業中の2009年4月。
[RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[RFC1195] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] Heffernan、A。、「TCP MD5署名オプションによるBGPセッションの保護」、RFC 2385、1998年8月。
[RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, October 2005.
[RFC4176] El Mghazli、Y.、ed。、Nadeau、T.、Boucadair、M.、Chan、K.、およびA. Gonguet、「レイヤー3仮想プライベートネットワーク（L3VPN）運用と管理のフレームワーク」、RFC 4176、2005年10月。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Ed。、Li、T.、ed。、およびS. Hares、ed。、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. SEO、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303] Kent、S。、「セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C.、ed。、「Internet Key Exchange（IKEV2）Protocol」、RFC 4306、2005年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4378] Allan, D., Ed., and T. Nadeau, Ed., "A Framework for Multi-Protocol Label Switching (MPLS) Operations and Management (OAM)", RFC 4378, February 2006.
[RFC4378] Allan、D.、ed。、およびT. Nadeau、ed。、「マルチプロトコルラベルスイッチング（MPLS）オペレーションおよび管理（OAM）のフレームワーク」、RFC 4378、2006年2月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459] Savola、P。、「ネットワーク内トンネルに関するMTUおよび断片化の問題」、RFC 4459、2006年4月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036] Andersson、L.、ed。、Minei、I.、ed。、およびB. Thomas、ed。、「LDP仕様」、RFC 5036、2007年10月。
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5496] Wijnands、IJ。、Boers、A。、およびE. Rosen、「The Reverse Path Forwarding（RPF）Vector TLV」、RFC 5496、2009年3月。
[SW-PROB] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. Durand, Ed., "Softwire Problem Statement", RFC 4925, July 2007.
[SW-Prob] Li、X.、ed。、Dawkins、S.、ed。、Ward、D.、ed。、およびA. Durand、ed。、「Softwire Problem Statement」、RFC 4925、2007年7月。
Xing Li Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R.China
Xing Li Tsinghua大学電子工学部、Tsinghua University Beijing 100084 P.R. China
Phone: +86-10-6278-5983
EMail: xing@cernet.edu.cn
Simon Barber Cisco Systems, Inc. 250 Longwater Avenue Reading, ENGLAND, RG2 6GB United Kingdom
Simon Barber Cisco Systems、Inc。250 Longwater Avenue Reading、イングランド、RG2 6GBイギリス
EMail: sbarber@cisco.com
Pradosh Mohapatra Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA
Pradosh Mohapatra Cisco Systems、Inc。3700 Cisco Way San Jose、CA 95134 USA
EMail: pmohapat@cisco.com
John Scudder Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
John Scudder Juniper Networks 1194 North Mathilda Avenue Sunnyvale、CA 94089 USA
EMail: jgs@juniper.net
David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, Mingwei Xu, and Ke Xu provided useful input into this document.
デイビッド・ウォード、クリス・カッサー、ガルギ・ナラワデ、ルチ・カプール、プラナブ・メタ、ミンヴァイXu、およびKe Xuは、このドキュメントに有用な入力を提供しました。
Authors' Addresses
著者のアドレス
Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China
Jianping Wu Tsinghua University of Computer Science、Tsinghua University Beijing 100084 P.R. China
Phone: +86-10-6278-5983
EMail: jianping@cernet.edu.cn
Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China
Yong Cui Tsinghua University of Computer Science、Tsinghua University Beijing 100084 P.R. China
Phone: +86-10-6278-5822
EMail: yong@csnet1.cs.tsinghua.edu.cn
Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA
Chris Metz Cisco Systems、Inc。3700 Cisco Way San Jose、CA 95134 USA
EMail: chmetz@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
エリックC.ローゼンシスコシステムズ、1414マサチューセッツアベニューボックスボロー、マサチューセッツ州01719 USA
EMail: erosen@cisco.com