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.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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の両方のパケットを処理できるようにする必要があります。しかし、インターネットのいくつかの構成要素のネットワークは、「シングル・プロトコル」のネットワークであることが期待されます。単一プロトコル・ネットワークの一種は、IPv4パケットを解析することができ、IPv4のみルーティング情報を処理することができます。別の種類だけでIPv6パケットを解析することができますし、ルーティング情報をIPv6のみを処理することができます。それにもかかわらず、単一プロトコル・ネットワークのいずれかの種類が「その他」のプロトコルのためのトランジットサービスを提供できることが必要です。これは、他の単一プロトコルネットワークの一端からルーティング情報の「他の種類」を渡すことによって、および他の1つのエッジからのデータパケットの「他の種類を」トンネリングすることによって行われます。トンネルは「softwires」として知られています。このフレームワークドキュメントはルーティング情報とつのプロトコルのデータパケットが他のプロトコルの単一プロトコルネットワークを介して渡される方法について説明します。文書は、これは既存の技術で行うことができたときに、それが新規または変更技術の開発を必要とする場合に指定するように注意です。
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]は、外部ルーティング情報を配布するために使用され、インテリアゲートウェイプロトコル（IGP）は、OSPF [RFC2328]として、または[RFC1195]-IS ISは、内部ルーティング情報を配布するために使用されます。
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）ルータとして知られています。用語「入口」（または「入口PE」）は、パケットがバックボーンに入射するルータを指し、用語「出口」（又は「出口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は、それがインタフェースにための一つ。しかし、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つのアドレスファミリの一つだけをサポートするバックボーンは、他の中継サービスを提供するために必要とされます。バックボーンのエッジルータは、もちろん、両方のアドレスファミリをサポートしている必要があります。我々は、これらのPEルータを参照するために用語「アドレスファミリー境界ルータ」（AFBR）を使用します。転送に使用されるトンネルを「softwires」と呼ばれます。
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メッシュ問題」[SW-PROB]として知られており、この文書で指定されたフレームワークは、したがって「Softwireメッシュフレームワーク」として知られています。このフレームワークでは、唯一のAFBRsは、両方のアドレスファミリをサポートする必要があります。 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.
トンネリング技術の多種多様を経由して、これらのシナリオに対処することが可能です。このフレームワークは、特定のトンネリング技術の使用を強制しません。任意の展開では、トンネリング技術の選択は、政策の問題です。両方LDPベース（ラベル配布プロトコル、[RFC5036]）とRSVP-TEベース（リソース予約プロトコル - - トラヒックエンジニアリング、[RFC3209]のフレームワークは、少なくともMPLSの使用（[RFC3031]、[RFC3032]）を収容します） - のL2TPv3 [RFC3931]、GRE [RFC2784]、及びIPイン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を設定できるようにすることが望ましいです。次にルータは互いのクラスメンバーシップを広告することができ、およびカプセル化ポリシーは、として表すことができ、例えば、「クラスXのルータへのトンネルへのL2TPv3を使用して、クラスYのルータへのトンネルにGREを使用します」。 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メッシュの枠組みで対応する必要があります。
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.
トンネリングされた転送の使用は、多くの場合、シグナリングプロトコルのいくつかの並べ替えがトンネルを設定および/または維持するために使用されている必要があります。このフレームワークが収容するトンネリング技術の多くはすでに、独自のシグナリングプロトコルを持っています。しかし、いくつかはない、場合によっては特定のトンネリング技術のための標準的なシグナリングプロトコルは、対象のシナリオで（一つまたは別の理由のために）適切ではないかもしれません。 （そのような場合にのみ）、このような場合には、新たなシグナリング方法が定義され、標準化される必要があります。
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.
このフレームワークでは、softwiresは、ルーティングに表示されるオーバレイ・トポロジーを形成しません。ルーティング隣接はsoftwiresにわたって維持されず、経路制御パケットはsoftwiresを介して送信されていません。 （エッジノードを含む）バックボーンノード間ルーティング隣接バックボーンのネイティブ技術を介して維持されます。
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].
すなわち、AFBRs間BGPを外部ルーティング情報を配信するための標準的なルーティング方法が既に存在します。しかし、関心のあるシナリオでは、我々は、IPv4にルーティング情報を渡すためにIPv6ベースのBGPセッションを使用してもよい、と我々は、IPv6ルーティング情報を渡すためにIPv4ベースのBGPセッションを使用してもよいです。 IPv4トラフィックは、IPv6バックボーン上でトンネリングする場合また、IPv6アドレスとIPv4ルートは、「BGPネクストホップ」、およびその逆を符号化することが必要です。で指定された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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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オーバーIPv4のシナリオ
The IPv4 transit core may or may not run MPLS. If it does, MPLS may be used as part of the solution.
IPv4のトランジットコアは、またはMPLSを実行しない場合があります。それがない場合は、MPLSは、ソリューションの一部として使用することができます。
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仮想プライベートネットワーク）技術は、バックボーン[V6NLRI-V4NH]で、必要に応じて、AFBRsにMPLSを使用して、IPv6接続を提供するために拡張されています。この枠組みの中で説明するソリューションは、トンネリング（softwire）技術を選択するためのより一般的な方式で、[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オーバ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を実行しない場合があります。それがない場合は、MPLSは、ソリューションの一部として使用することができます。
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のオーバーのIPv4の問題は、過去にかなりの注目を受けているが、IPv4のオーバーのIPv6のシナリオはしていません。サービスプロバイダーの数は、IPv6バックボーンネットワークを構築しているし、自社のコア・ルータにネイティブのIPv4サポートを提供したくないようだが、それは、重要な新興の要件です。これらのサービスプロバイダは、そのIPv6のバックボーンにわたって動作する必要が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.
以下のセクションでは、我々は、トランジットネットワークによってサポートされているIP（すなわち、IPv4またはIPv6のいずれか）の形を指すために、用語「I-IP」（内部IP）を使用します。私たちは、クライアントのネットワークによってサポートされているIPのフォームを参照するために用語「E-IP」（外部IP）を使用します。興味のあるシナリオでは、E-IPがIPv4の場合とI-IPは、IPv6であり、E-IPは、IPv6同値-IPが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.
AFBRsは、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ルータと中継網のAFBRsは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.
AFBRsは、互いにE-IPルーティング情報を交換するための内部BGP（IBGP）を使用します。どちらかがAFBRs間のIBGP接続のフルメッシュであるか、あるいはAFBRsの一部または全部がBGPルートリフレクタのクライアントです。これらのIBGP接続は（すなわち、BGPアップデートのネットワーク層到達可能性情報（NLRI）はE-IPアドレスファミリである）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、退出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へのトンネル（すなわち、softwire介して）を介してパケットを転送しなければなりません。これは、Pルータが処理することができ、それはPルータは出力AFBRにパケットを送信しますカプセル化ヘッダを使用して、パケットをカプセル化することによって行われます。出口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].
softwire介してパケットを送信することは常にカプセル化ヘッダを元のパケットに付加されることを必要とします。結果のパケットは、そのためのカプセル化ペイロードよりも常に長いです。 （a）は、パケットがカプセル化される前にフラグメント化する必要はないだろう、と、（b）は、カプセル化されたパケットは、それながら、断片化する必要はありませんように運用問題として、softwireのパスの最大転送単位（MTU）が十分大きくなければなりませんsoftwireに沿って転送されています。トンネリング転送の文脈における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は、互いにE-IPルーティング情報を配布するためにBGPを使用します。これはIBGPセッションのAFBR-AFBRメッシュによって行うことができるが、より可能性の高い各AFBR 1つのまたは2つのルートリフレクタにではなく、他のAFBRsにIBGPセッションを有している、すなわち、BGPルートリフレクタを介して行われます。
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間、またはAFBRsとルートリフレクタ間のBGPセッションは、I-IPアドレスファミリの上で実行されます。トランジットコアはIPv6のみ、IPv6を上で実行するクライアント・ネットワークからのIPv4ルーティング情報を配布するために使用IBGPセッションをサポートしている場合つまり、。トランジットコアはIPv4のみをサポートしている場合、IBGPセッションは、IPv4上で実行されるクライアントネットワークからIPv6のルーティング情報を配布するために使用します。 BGPセッションは、このようにコアのネイティブネットワーク層を使用します。 BGPメッセージはsoftwiresを介して、または任意の他のメカニズムを介してトンネリングされません。
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は、ルーティング更新はBGPネクストホップ（NH）のアドレスを（より一般的に、NLRI）アドレスプレフィックスを関連付けます。 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.
I-IPトランスポートを使用するBGPセッション上で搬送されるE-IPアドレスプレフィックスに関する情報が含まれていて、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.
人のBGPピアが特定のBGP能力をアドバタイズしていない限り、いくつかの場合（例えば、[V4NLRI-V6NH]を用いた場合）において、一方がこの規則に従うことができません。これは、次のsoftwire展開制限につながる：BGP機能はE-IP NLRIはI-IP NHを持って、与えられたトランジットコア内のすべての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アドレスを持っている場合は、ネットワーク管理者は、通常、1つAFBRは、BGPアップデートでネクストホップとして自分自身を識別するために使用する選択する際にかなりの柔軟性を持っています。 AFBRは、特定のトンネリング技術のsoftwire介してパケットを受信することを期待し、そして場合AFBRは、特定のIPアドレスを介して、そのトンネリング技術が知られている場合は、その同一のIPアドレスを次のホップにAFBRを識別するために使用されなければなりませんBGPアップデートのフィールド。 L2TPv3のトンネリングが使用される場合、例えば、その後のL2TPv3シグナリングに係合するときAFBRが使用する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アドレスファミリを使用して分配されます。これは、各IPv6アドレスのプレフィックスでMPLSラベルを関連付ける出口AFBRすることができます。入口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 softwiresのメッシュは場所になければなりません。与えられた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
トランジットコアはレイヤ3中継サービスを提供しているので、ポイントツーポイントトンネルはこのフレームワークによって必要とされません。マルチポイントツーポイントトンネルはすべてのことが必要とされています。パケットがトンネルから出たときに、マルチポイントツーポイントトンネルでは、トンネルにパケットを入れたルータ伝える方法がありません。このモデルの出口ルータは、与えられたパケットの入口ルータを決定することはできませんここでネイティブIPフォワーディングパラダイム、。もちろん、ポイントツーポイントトンネルは、この文書で説明する基本的な要件を超えた何らかの理由で必要になる場合があります。の例については、品質
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.
サービス（QoS）のか、セキュリティ上の考慮事項は、ポイントツーポイントトンネルを使用する必要があります。だから、ポイントツーポイントトンネルは、このフレームワークによって、許可されるが、必須ではありません。
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.
softwiresために、特定のトンネリング技術を用いることが望ましい、とされている場合は、その技術は、独自の「ネイティブ」のシグナリング方法論を持っている場合、推定はネイティブのシグナリングが使用されるということです。これは確かにLDPまたはRSVP-TEを使用されるMPLSベースのsoftwiresに適用されます。それはsoftwireのセキュリティプロパティを保証するために必要であるとして、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ベースsoftwireは、又は様々な任意のGREヘッダフィールドが使用されるかどうかに応じて、シグナリングを必要としない場合があります。このような場合のために、シグナリング手順はsoftwiresをサポートするために開発する必要がありますので、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.
別の可能softwire技術がL2TPv3のです。 L2TPv3のは、独自のネイティブシグナルを持っていないが、そのシグナリングはポイントツーポイントトンネルを設定します。 softwiresのためには、マルチポイント・ツー・ポイント・モードでの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（生存時間）フィールド、DSCP（Diffservのサービスクラス）ビット、等であってもよいです
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.
すべての必要なsoftwiresが完全にsoftwiresを通過する必要があります任意のパケットの到着前に設定されることが望ましいです。つまり、softwiresは、「常にオン」にする必要があります。任意の特定のAFBRの観点から、softwireエンドポイントは常にAFBRがインストールされているルートのBGPネクストホップです。これは、任意の必要softwireシグナリングは通常のシステム起動の一部として実行されなければならないのいずれか（LDPベースMPLSと、例えば、起こるような）あるいは（例えば、[RFC5512]に記載されているようなBGPルーティング情報の受信によってトリガされることを示唆しています）;トリガーとなる経路情報の配信を優先する場合にも有用です。
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.
softwireを通じて転送するのではなく、ネイティブに転送するように、決定は、入口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コアとコアに面したインターフェイスを送り出さなければならないことを言うならば、softwireを介してパケットを送信します。
- 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パケットをサポートしているインターフェイスから送信されなければならないことを言うならば、softwireを通じて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-分散経路であれば、softwire（即ち、トンネルのすべての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".
例えば、「常にLDPベースのMPLSを使用する」または「いつものL2TPv3を使用する」 - ほとんどの場合、ポリシーは非常にシンプルなものになり、与えられたトランジットコアのすべてAFBRsで同じになる、ことが想定されます。
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
しかし、他の展開は言う、サポートのいくつかは、ルータ、GREとL2TPv3の両方の混合物があるかもしれませんが、他のは、それらの技術の一つだけをサポートしています。これは、ネットワーク管理、クラスの小さなセットを作成し、これらのクラスのうちの1つまたは複数のメンバーである各AFBRを設定できるようにすることが望ましいです。次にルータは互いのクラスメンバーシップを広告することができ、およびカプセル化ポリシーは、として表すことができ、例えば、「クラスXのルータに話をするのL2TPv3を使用して、クラス内のルータと通信するためにGREを使用します
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).
Y」。AFBRsは、それらのクラスのメンバーシップを宣伝できるようにするため、このようなポリシーをサポートするために、それが必要である。[RFC5512]他AFBRSに、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.
ポリシーは、サービスの一定の品質を受信するトラフィックの特定のクラスが必要な場合があり、これは、そのクラス内のパケットのために使用されるトンネルおよび/またはトンネリング技術の選択に影響を与える可能性があります。このフレームワークは、トンネリング技術の様々なsoftwiresをインスタンス化するために使用することができます。第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.
多くの場合、ポリシーは無条件になりますが、例えば、他の例では、ポリシーが選択は、例えばsoftwireリモートエンドポイントの詳細については、を条件であることを指定することができ、「常にsoftwires用のL2TPv3を使用する」、「使用L2TPv3のは内のルータに話をしますクラスX、Yクラス内のルータと通信するためにGREを使用します」。これは、ネットワーク管理、クラスの小さなセットを作成し、これらのクラスのうちの1つまたは複数のメンバーである各AFBRを設定できるようにすることが望ましいです。そのような各クラスがコミュニティまたは拡張コミュニティとして表される場合、[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やセキュリティ上の考慮事項に依存してもよい任意の複雑さのポリシーを可能にします。しかし、そのような政策の仕様は、このドキュメントの範囲内ではありません。
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ネクストホップの、トランスポートネットワークのアドレスファミリでは、アドレスを提供します。パケットは、そのリモートエンドポイントアドレスは、BGPネクストホップアドレスと同じであるsoftwireを介して送信されなければなりません。
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.
softwire介してパケットを送信する第一のトランジットネットワークで処理し、次いでsoftwireのリモートエンドポイントアドレスに向けて送信することができるカプセル化ヘッダでパケットをカプセル化の問題です。
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.
一つはリモートエンドポイントのアドレスを知ると、多くの場合において、1は、1つのカプセル化ヘッダを形成するために必要なすべての情報を有しています。 softwireをインスタンストンネル技術がある場合、これは、オプションヘッダフィールドせず、例えば、LDPベースのIPインIP MPLS、または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-TEベース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パケットとしてsoftwireを介して送信されなければなりません。この文書に記載されたトンネリング技術のほとんどは、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.
Softwiresは、基本的にルータを接続するトンネルです。彼らは消えや性能に劣化している場合、それらのトンネル経由の接続は影響を受けます。トンネルエンドポイント（AFBRs）ならびにトンネル自身のステータスを監視するために利用可能ないくつかの技術があります。これらの技術は、softwireパストレース、リモートsoftwireエンドポイントのpingなどの操作、およびリモートエンドポイントsoftwireライブネス故障検出を可能にします。
Examples of techniques applicable to softwire OAM include:
softwire OAMに適用可能な技術の例としては、
o BGP/TCP timeouts between AFBRs
O BGP / TCPはAFBRs間のタイムアウト
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
AFBRルータ間BFD（双方向フォワーディング検出）O [BFD】パケット交換
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
softwire OAMのためのもう一つの可能性は、要求/応答パケット[RFC4378]のようなものを構築したり、他の言葉で、作成して生成することsoftwireエコーすることです。周知のUDPポートに送信されたエコー要求は、MPLS転送等価と同様ペイロードとして出力AFBR IPアドレスとsoftwire識別子（含むであろう
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.
LSPエコー要求に含まれるクラス）。 softwireエコーパケットがカプセル化ヘッダでカプセル化し、softwire自体のと同じパス（帯域内）を介して転送されることになります。
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にsoftwireアプリケーションに通知されると、定期的に遠隔softwireエンドポイント到達可能性を検証するために自動化することができます。考慮すべきことは、このような自動化メカニズムのエンドポイント到達可能性の損失の検出に要する時間に対するそのようなメカニズムのスケーラビリティとの間のトレードオフに与えられなければなりません。
In general, a framework for softwire OAM can, for a large part, be based on the [RFC4176] framework.
一般に、softwireの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.
特定のMIBはSoftwireメッシュフレームワークの要素を管理するために存在します。しかし、これらのMIBを拡張したりsoftwireネットワーク内でSNMPで管理することが可能な機能要素を反映した新しいものを作成するために、いずれかの必要があるでしょう。
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マルチキャストアプリケーションを実行したい場合があります。トランジットコアを横切って延びるIPマルチキャスト接続は、特性の異なるセットを有する方法、各々の数で行うことができます。可能性の（全てではないが）大部分は[L3VPN-MCAST]でL3VPNsために定義された手順のわずかな変化のいずれかです。
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-SSM（PIMソース固有モード） - サポートは、PIM-SM（スパースモードプロトコル独立マルチキャスト）するために設けられています。これらの機能は、通常のプロバイダ間の境界を越えて使用されていないよう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マッピング」方式では、各クライアントのマルチキャストツリーは、中継芯を介して延長されます。
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]で使用されていません。状態の量は無限とサービスプロバイダの制御の外にあるため、VPNコンテキストでは、これは望ましくないと考えられます。しかし、1対1の方式モデルクライアントネットワークとトランジットコアは両方のIPv4またはIPv6の両方のある典型的な「インターネットマルチキャスト」シナリオ。それはそのような場合のために十分に拡張した場合、それはまた、クライアントのネットワークとトランジットコアは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がCEのいずれかからE-IP PIM制御メッセージを受信すると、I-IPにE-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は、E-IP PIMは（S、G）ツリーまたは（*、G）木のいずれかのためにCEから/プルーンメッセージを受信すると仮定しよう。 AFBRは、I-IP PIMメッセージに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アドレスになりますので注意してください。 （AFBRs以外）トランジットコア内のルータはE-IPアドレスへのルートを持っていないので、Aは、その上流の隣人に送信するjoin / pruneメッセージをPIMでRPFベクトル[RFC5496]を入れなければなりません。 RPFベクトルは、I-IPアドレス、マルチキャストツリーのルートへの経路に沿って中継網内の出口点であるAFBR Bとして、識別されます。 AFBR Bは、ツリーのルートへのルートのAFBR AのBGPネクストホップです。 RPFベクトルは、コアルータは、彼らはE-IPのルートを維持していないにもかかわらず、PIMは、上流の木の根元に向けて/プルーンJoinメッセージを転送することができます。
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.
I-IP PIMメッセージにE-IP PIMメッセージを翻訳するために、AFBR Aは、（（S、G）群の場合）SのアドレスまたはE-からGのRPのアドレスを変換する必要がありますI-IPアドレスファミリへの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である場合には、アルゴリズムこの変換を行うことも可能です。対応するIPv4マップIPv6アドレス[RFC4291]にはIPv4 Sを翻訳することができ、その後、Bはバックそれを翻訳することができます。これを書いている時点で、IPv4マップIPv6マルチキャストアドレスのようなものは存在しないが、そのようなものは標準化した場合、その後もIPv6の内のIPv4 Gを変換でき、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 AFBRsの間の追加のシグナリングを必要とします。各下流AFBRは、（S、G）マルチキャストトンネルを必要と上流AFBRをシグナリングする必要があります。上流AFBRは、その後トンネルにマルチキャストアドレスG」を割り当てて使用するP-G値の下流に通知しなければなりません。下流AFBRは、次にS 『が上流ASBR（自律システム境界ルータ）のIPv4アドレスである（S」、G』）ツリーを、参加するPIM /の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のいずれかのクライアントのマルチキャストをサポートするために使用することができます。それはクライアント（S「G」）ツリーの操作に操作「（*、G）ツリーオフソースを剪定」をマッピングするための方法を提供しないので、クライアントのマルチキャストは、SSMである場合しかし、それだけで動作します。この方法はまた、追加のシグナリングを必要とします。 [L3VPN-MCAST-BGP]のBGPベースのシグナリングを使用することができる一つのシグナリング方法です。他のシグナリング方法も同様に定義することができます。
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.
【MLDP]で指定されたポイントツーマルチポイントおよびマルチポイント・ツー・マルチポイントのLSPのためのLDPの拡張。我々は、これらのLDP拡張子を参照するために用語「MLDP」を使用します。トランジットコアは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が受信したときにE-IP PIMは、Gは、SSM基であり、それはP2MP LSPに参加するMLDPを使用してCEのいずれかからの（S、G）のために/プルーンメッセージに参加します。 P2MP LSPのルートは、P2MP LSPを一意にそのルートの組み合わせと「FEC（転送等価クラス）識別子」によって識別されるMLDPにおいてS.へのルート上のAのBGPネクストホップであるAFBRのBであろう。以下のためのP2MP LSP（S、G）に参加するために必要なすべてのAFBRsが同じFEC識別子を生成するように、元の（S、G）は、アルゴリズム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).
FEC識別子に（S、G）をコードする方法が標準化される必要があります。 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それはもはや（S、G）のための任意の下流の受信機を有すること（PIM手順を介して）決定していない場合、例えば、AFBR対応するP2MP LSPオフ自体を整理するための適切なMLDPプロシージャを呼び出す必要があります。
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のソースツリーの両方を下るかもしれない）トランジットコアを通過してしまう可能性があり、重複。あるいは、LSPのルートにP2MP LSPオフ源をプルーニングするAFBRツーAFBRプロトコルを考案することができました。クライアントの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-双方向によって設定MLDP [MLDP]によって設定MP2MP（多対多）のLSPに上記の技術を用いてマッピングすることができます。インタープロバイダ双方向グループはどこにも使用されていないよう私たちは、さらにこれを考慮していません。
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]のような）そのコンパニオン文書に記載されているものです。 softwire環境にそれらのスキームを適用するには、それは彼らがすべてであるかのようにマルチキャスト目的のために、所定の通過コアの全てAFBRsを治療するためにのみ必要であり、PEルータは、同じVPNに取り付けられました。
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環境では、コア内の樹木の数が直線的にクライアントの木の数よりも少ないスケール要件があります。この要件はsoftwireシナリオで保持しない場合があります。
The MVPN-like schemes can support SM, SSM, and Bidir groups. They provide a number of options for the control plane:
MVPNのようなスキームは、SM、SSM、および双方向のグループをサポートすることができます。彼らは、制御プレーンのためのオプションの数を提供します。
- LAN-like
- LANのような
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（Local Area Network）をエミュレートし、その「LAN」を超えるクライアント側のPIMプロトコルを実行するために、コアにマルチキャストツリーのセットを使用してください。 「LAN」とは、全てAFBRs又はSSMツリーのセット、各AFBRをルートいずれかを含有し、受信機としての他のすべてのAFBRsを含む単一の双方向ツリーから構成することができます。
- 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は、すべてのクライアントのマルチキャストパケットを受信しなければならないとして、この特定のオプションは、softwireシナリオのために、しかし、非常に魅力的ではありません。
- 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.
- それを受信する必要はありません「あまりにも多くの」AFBRsに行くために、そのグループのトラフィックを発生させるという意味で、そのグループのために適切であると考えられる木にマッピングされたすべてのマルチキャストグループ。
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）で構成された場合を検討しています。トランジットコアが複数のASで構成されている場合、そのエンドポイントであるAFBRs異なる自律システムに取り付けsoftwiresを使用する必要があるかもしれません。この場合、softwireのリモートエンドポイントでAFBRはsoftwire上で送信する必要があるパケットのBGPネクストホップではありません。上記の手順は、BGPネクストホップのアドレスと同じになるように、リモートsoftwireエンドポイントのアドレスを必要とするので、これらの手順は、トランジットコアが複数の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.はそれをしないでください。それぞれのエッジでAFBRsがほどトランジットコアは複数の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はabfrsとが同じまたは隣接のASに含まれていない場合でも、AFBRsが互いに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.
例えば、D.は、それが進入AFBRのA1に到着し、DのためにベストマッチであるルートがBGPネクストホップB1を持っていると仮定し、宛先IPアドレスを持つパケットPを考えます。だから、A1はB1に配信するためのパケットをカプセル化します。 B1はA1のAS内にない場合、A1は、そのルートの、B2、それを呼び出す、B1までのルートを検索して、BGPネクストホップを見つける必要があります。 A1のASの内部ルータはB1へのルートを持っていない場合は、A1は、パケット二時間、B2に配信するために、この時間をカプセル化する必要があります。
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メッシュフレームワークでは、カプセル化されたデータパケットは、インターネットを介して移動されているE-IPデータパケットです。これらのデータ・パケット（softwire「ペイロード」）や認証、完全性、機密性、または再生保護などのセキュリティ機能を必要としない場合があります。しかし、ペイロードパケットのセキュリティニーズは、これらのパケットはsoftwiresを横断しているかどうかとは無関係です。特定のペイロードパケットがsoftwireて走行しているという事実は、どのような方法でそのセキュリティニーズには影響を与えません。
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".
カプセル化ヘッダーがsoftwiresを通過するパケットのルーティングを決定しているので、彼らは「平文で」が表示されなければなりません。
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.
SoftwireメッシュFrameworkでは、トンネルの各受信エンドポイントに対して、有効な送信エンドポイントが受信エンドポイントにトンネルパケットに許可されているものである1つ以上の「有効」を送信するエンドポイントがあります。カプセル化ヘッダは、認証や整合性の保証を持っていない場合、受信を与え、不正なノードが受信エンドポイントにカプセル化されたパケットを送信する、スプーフィング攻撃を持つことが可能であるカプセル化されたパケットが本当にsoftwireを旅した無効な印象をエンドポイント。リプレイ攻撃も可能です。
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.
このような攻撃の効果は、しかし、やや限られています。 softwireの受信エンドポイントは、ペイロードのカプセル化を解除し、さらにルーティングは、ペイロードの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.
しかし、この種の攻撃は、ポリシー違反につながることができます。 softwireの許可された送信エンドポイント（複数可）のみ、特定のペイロード・パケットがsoftwire介して送信されます応じたポリシーを次のことができます。不正ノードは、彼らが認可ノードから到着したかのように見ている受信側のエンドポイントに到着するようにペイロードパケットをカプセル化することができます場合は、適切に承認ポリシーは、サイドステップとなっています。
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.)
我々が検討している種類の攻撃も受けトンネルエンドポイント上のサービス拒否攻撃に使用することができます。しかし、このような攻撃は、偽装されたパケット上で暗号化を行う必要として、暗号認証/インテグリティ技術の使用によって防ぐことができないだけでサービス拒否問題悪化させます。 （仮定は暗号化メカニズムは、脱カプセル化/転送メカニズムよりも高価である可能性が高いということである。1は、暗号の完全性試験に合格しないパケットを破棄することにより一端を脱カプセル化/転送メカニズムのフラッディング攻撃を排除しようとするのであればちょうど別のために攻撃の一種の取引まで。）
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.
- トンネルの送信エンドポイントは、アドレスの異なるセットを与えることができ、それらのアドレスが境界ルータへとトンネルの受信側エンドポイントに知られているとすることができます。境界ルータはこのセットにある送信元アドレスとドメイン外から到着するすべてのパケットをフィルタリングすることができ、および受信エンドポイントは、しかし、送信元アドレスこのセットではありませんsoftwireの一部であるように表示されるすべてのパケットを破棄することができます。
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ビットの「クッキー」は、時々このように使用されます。ドメインに由来し、それはドメインを残していないパケットをスパイするために、攻撃者のために実行不可能とみなされる場合、これは管理ドメイン内に役立ちます。その後、攻撃者は、パスワードを発見することはできません。攻撃者は、もちろん、パスワードを推測しようとすることができますが、パスワードは任意の64ビットのバイナリシーケンスである場合、すべての可能なパスワードを介して実行ブルートフォース攻撃は実行不可能になります。この手法は、入力フィルタリングがあるよりも管理が容易であり得ると仮定が保持している場合、同じように効果的です。イングレスフィルタリングのように、しかし、それはドメインの境界を越えるトンネルに適用できない場合があります。
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トンネルモードを使用することができるだけでなく、1は、セキュリティアソシエーションのエンドポイントとしてトンネルヘッドとトンネルテールを治療するための、および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アドレスとして使用されるであろう。この技術は、最初のIPsecトランスポート・モードを適用し、次いでMPLSインIPまたはMPLSインGRE [RFC4023]でMPLSパケットをカプセル化によって、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はsoftwiresを確保するために使用される場合、IPsecは認証と完全性を提供しなければなりません。したがって、実装はnull暗号化[RFC4303]または他のAH（IP認証ヘッダー）[RFC4302]でESP（IPカプセル化セキュリティペイロード）のいずれかをサポートしなければなりません。 ESP暗号化をサポートすることができます。 ESPを使用する場合、トンネルテールは、任意のパケットの送信元IPアドレスが指定されたSA（IPsecのセキュリティアソシエーション）で受信されたことを確認しなければならない[RFC4301]のセクション5.2、ステップ4で指定されるように、予想されるものです。
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.
softwiresがルーティング情報を渡すの副産物として動的に設定されているので、鍵配布はのIKEv2 [RFC4306]を用いて自動的に行われなければなりません。 PKI（公開鍵基盤）が利用できない場合、IPsecトンネル認証サブTLVは、[RFC5566]で説明SAを設定する前に使用され、検証されなければなりません。
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]パーキンス、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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ファリナッチ、D.、李、T.、ハンクス、S.、マイヤー、D.、およびP. Trainaの、 "総称ルーティングカプセル化（GRE）"、RFC 2784、2000年3月。
[RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001.
[RFC3031]ローゼン、E.、Viswanathanの、A.、およびR. Callon、 "マルチプロトコルラベルスイッチングアーキテクチャ"、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]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、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.、バーガー、L.、ガン、D.、李、T.、スリニヴァサン、V.、およびG.ツバメ、 "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]ラウ、J.、エド、Townsley、M.、エド、およびI. Goyret、エド、 "レイヤ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.ローゼン、編、 "IP又は総称ルーティングカプセル化（GRE）でMPLSカプセル化"、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.ローゼン、 "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]バーガー、L.、ホワイト、R.とE.ローゼン、 "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]ルFaucheur、F.とE.ローゼン、 "IPv6のネクストホップと広告のIPv4ネットワーク層到達可能性情報"、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]デClercq、J.、Ooms、D.、プレボ、S.、およびF.ルFaucheur、 "IPv6のプロバイダエッジルータを使用したIPv4 MPLS上のIPv6諸島接続（6PE）"、RFC 4798、2007年2月。
[BFD] Katz, D. and D. Ward, "Bidirectional Forwarding Detection", Work in Progress, February 2009.
[BFD]カッツ、D.とD.ウォード、 "双方向フォワーディング検出"、進歩、2009年2月に作業。
[L3VPN-MCAST] Rosen, E., Ed., and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", Work in Progress, March 2009.
[L3VPN-MCAST]ローゼン、E.、エド。、およびR.アガルワル、エド。、 "MPLS / BGP VPNのIPマルチキャストで"、進歩、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]アガルワル、R.、ローゼン、E.、モリン、T.およびY. Rekhter、 "BGPエンコーディング及びMPLS / IP VPNの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] Minei、I.、エド。、Kompella、K.、Wijnands、IJ。、エド。、およびB.トーマス、「ポイント・ツー・マルチポイントおよびマルチポイント・ツー・マルチポイントラベルは、パスのスイッチのためのラベル配布プロトコルの拡張機能」 、進捗状況、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.は、RFC 1195、1990年12月 "OSIの使用は、TCP / IPやデュアル環境でのルーティングのためIS-IS"。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]モイ、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]エルMghazli、Y.、エド。、ナドー、T.、Boucadair、M.、チャン、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.、エド。、李、T.、エド。、およびS.野兎、編、 "ボーダーゲートウェイプロトコル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.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302]ケント、S.、 "IP認証ヘッダー"、RFC 4302、2005年12月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、エド。、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼン、E.およびY. Rekhter、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）"、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]アラン、D.、エド。、およびT.ナドー、エド。、 "（MPLS）操作と管理（OAM）をマルチプロトコルラベルスイッチングのためのフレームワーク"、RFC 4378、2006年2月。
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006.
[RFC4459]、RFC 4459 Savola、P.、 "イン・ネットワークのトンネリングを使用したMTUと断片化の問題"、2006年4月。
[RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, October 2007.
[RFC5036]アンデション、L.、エド。、Minei、I.、エド。、およびB.トーマス、エド。、 "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。、ボーア人、A.、およびE.ローゼン、 "リバースパス転送（RPF）のベクトル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]李、X.、エド。、ドーキンス、S.、エド。、ウォード、D.、エド。、およびA.デュラン、エド。、 "Softwire問題文"、RFC 4925、2007年7月。
Xing Li Tsinghua University Department of Electronic Engineering, Tsinghua University Beijing 100084 P.R.China
電子工学の興李清華大学学部、清華大学、北京100084 P.R.China
Phone: +86-10-6278-5983 EMail: xing@cernet.edu.cn
電話：+ 86-10-6278-5983 Eメール：xing@cernet.edu.cn
Simon Barber Cisco Systems, Inc. 250 Longwater Avenue Reading, ENGLAND, RG2 6GB United Kingdom
サイモン・バーバーシスコシステムズ社250 Longwaterアベニュー読書、ENGLAND、RG2 6ギガバイトイギリス
EMail: sbarber@cisco.com
メールアドレス：sbarber@cisco.com
Pradosh Mohapatra Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA
Pradosh Mohapatraシスコシステムズ株式会社3700シスコウェイサンノゼ、CA 95134 USA
EMail: pmohapat@cisco.com
メールアドレス：pmohapat@cisco.com
John Scudder Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089 USA
ジョン・スカダージュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089 USA
EMail: jgs@juniper.net
メールアドレス：jgs@juniper.net
David Ward, Chris Cassar, Gargi Nalawade, Ruchi Kapoor, Pranav Mehta, Mingwei Xu, and Ke Xu provided useful input into this document.
デビッド・ウォード、クリス・カサール、Gargi Nalawade、Ruchiカプール、Pranavメータ、Mingwei徐、および柯徐は、この文書に便利な入力を提供します。
Authors' Addresses
著者のアドレス
Jianping Wu Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China
コンピュータサイエンスのジアンピング・ウ清華大学学部、清華大学、北京100084 P.R.China
Phone: +86-10-6278-5983 EMail: jianping@cernet.edu.cn
電話：+ 86-10-6278-5983 Eメール：jianping@cernet.edu.cn
Yong Cui Tsinghua University Department of Computer Science, Tsinghua University Beijing 100084 P.R.China
コンピュータサイエンスの龍崔清華大学学部、清華大学、北京100084 P.R.China
Phone: +86-10-6278-5822 EMail: yong@csnet1.cs.tsinghua.edu.cn
電話：+ 86-10-6278-5822 Eメール：yong@csnet1.cs.tsinghua.edu.cn
Chris Metz Cisco Systems, Inc. 3700 Cisco Way San Jose, CA 95134 USA
クリス・メッツシスコシステムズ株式会社3700シスコウェイサンノゼ、CA 95134 USA
EMail: chmetz@cisco.com
メールアドレス：chmetz@cisco.com
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
エリックC.ローゼンシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: erosen@cisco.com
メールアドレス：erosen@cisco.com