Network Working Group X. Li, Ed.
Request for Comments: 4925 CERNET
Category: Informational S. Dawkins, Ed.
Huawei
D. Ward, Ed.
Cisco Systems
A. Durand, Ed.
Comcast
July 2007
Softwire Problem Statement
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope.
この文書では、IPv4のみのネットワーク間でのIPv6のみのネットワーク全体でIPv4ネットワークだけでなく、IPv6ネットワークを接続するための発見、制御、およびカプセル化方法の標準を開発しているSoftwiresワーキンググループ、のための問題文をキャプチャします。規格は識別、および選択された「のIPv4 / IPv6の」のセットとの「IPv6 / IPv4の」遷移の問題を解決するために、必要に応じて既存の標準プロトコルを拡張することにより、複数の、相互操作可能なベンダの実装を促進します。この文書では、特定の問題Softwiresワーキンググループによって開発された標準によって解決されます（「ハブとスポーク」と「メッシュ」）を記述する。いくつかの要件（非要件）も、より良い特定の問題の範囲を記述するために識別されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Hubs and Spokes Problem . . . . . . . . . . . . . . . . . . . 6
2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Non-Upgradable CPE Router . . . . . . . . . . . . . . . . 9
2.3. Network Address Translation (NAT) and Port Address
Translation (PAT) . . . . . . . . . . . . . . . . . . . . 10
2.4. Static Prefix Delegation . . . . . . . . . . . . . . . . . 10
2.5. Softwire Initiator . . . . . . . . . . . . . . . . . . . . 11
2.6. Softwire Concentrator . . . . . . . . . . . . . . . . . . 11
2.7. Softwire Concentrator Discovery . . . . . . . . . . . . . 12
2.8. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11.1. Authentication, Authorization, and Accounting
(AAA) . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11.2. Privacy, Integrity, and Replay Protection . . . . . . 13
2.12. Operations and Management (OAM) . . . . . . . . . . . . . 13
2.13. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 13
3. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Persistence, Discovery, and Setup Time . . . . . . . . . . 16
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Softwire Encapsulation . . . . . . . . . . . . . . . . . . 17
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Principal Authors . . . . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 20
The Softwires Working Group is specifying the standardization of discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks and IPv6 networks across IPv4-only networks in a way that will encourage multiple, inter-operable vendor implementations. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. A few generic assumptions are listed up front:
Softwiresワーキンググループは、発見、制御、および複数の、相互操作可能なベンダの実装を促進するようにIPv4のみのネットワーク上でIPv6のみのネットワークとIPv6ネットワーク間のIPv4ネットワークを接続するためのカプセル化方法の標準化を指定されています。この文書では、特定の問題Softwiresワーキンググループによって開発された標準によって解決されます（「ハブとスポーク」と「メッシュ」）を記述する。いくつかの要件（非要件）も、より良い特定の問題の範囲を記述するために識別されます。いくつかの一般的な仮定は、フロントまで記載されています：
o Local Area Networks will often support both protocol families in order to accommodate both IPv4-only and IPv6-only applications, in addition to dual-stack applications. Global reachability requires the establishment of softwire connectivity to transit across portions of the network that do not support both address families. Wide area networks that support one or both address families may be separated by transit networks that do not support all address families. Softwire connectivity is necessary to establish global reachability of both address families.
Oローカル・エリア・ネットワークは、多くの場合、デュアルスタックのアプリケーションに加えて、両方のIPv4のみとIPv6のみのアプリケーションに対応するために、両方のプロトコルファミリをサポートします。グローバル到達可能性は、両方のアドレスファミリをサポートしていないネットワークの部分全体に遷移するsoftwire接続の確立を必要とします。一方または両方のアドレスファミリをサポートするワイドエリアネットワークは、すべてのアドレスファミリをサポートしていませんトランジットネットワークによって分離することができます。 Softwire接続は、両方のアドレスファミリのグローバルな到達可能性を確立する必要があります。
o Softwires are to be used in IP-based networks to forward both unicast and multicast traffic.
O Softwiresは、ユニキャストおよびマルチキャストトラフィックの両方を転送するためにIPベースのネットワークで使用されます。
o Softwires are assumed to be long-lived in nature.
O Softwiresは長命な性質であると想定されています。
o Although Softwires are long-lived, the setup time of a softwire is expected to be a very small fraction of the total time required for the startup of the Customer Premise Equipment (CPE)/Address Family Border Router (AFBR).
Softwiresは、長寿命ですが、softwireのセットアップ時間は、顧客宅内機器（CPE）の起動に必要な総時間のごく一部であることが期待されるO /ファミリー境界ルータ（AFBR）のアドレス。
o The nodes that actually initiate softwires should support dual-stack (IPv4 and IPv6) functionality.
実際にデュアルスタック（IPv4およびIPv6）機能をサポートする必要がありsoftwiresを開始ノードO。
o The goal of this effort is to reuse or extend existing technology. The 'time-to-market' requirement for solutions to the stated problems is very strict and existing, deployed technology must be very strongly considered in our solution selection.
Oこの取り組みの目的は、再利用したり、既存の技術を拡張することです。述べた問題の解決のための「タイム・ツー・マーケットの要件は非常に厳しいと既存の、展開の技術は非常に強く、当社のソリューションを選択する際に考慮しなければならないです。
The solution to the stated problem should address the following points:
述べた問題を解決するには、以下の点に対処する必要があります。
o Relation of the softwire protocols to other host mechanisms in the same layer of the network stack. Examples of mechanisms to consider are tunneling mechanisms, VPNs (Virtual Private Networks), mobility, multihoming (SHIM6 (Level 3 Shim for IPv6)),...
ネットワークスタックの同じ層内の他のホストのメカニズムsoftwireプロトコルの入出力関係。考慮すべき機構の例には、メカニズム、VPNの（仮想プライベートネットワーク）、モビリティ、マルチホーミング（SHIM6（レベルIPv6の3シムを））、トンネリングされています...
o Operational brittleness introduced by softwire, e.g., potential single point of failure or difficulties to deploy redundant systems.
O softwireによって導入された動作脆性は、例えば、障害または問題の潜在的なシングルポイントは、冗長システムを展開します。
o Effects of softwires on the transport layer. Issue like packet losses, congestion control, and handling of QoS (Quality of Service) reservation and usage of on-path protocols such as RSVP (Resource Reservation Protocol).
トランスポート層上softwiresの影響O。パケットロス、輻輳制御、およびQoSの取り扱い（サービス品質）の予約や、RSVP（リソース予約プロトコル）などのオンパスのプロトコルの使用方法などの問題。
The history of IPv4 and IPv6 transition strategies at the IETF is very long and complex. Here we list out some steps we have taken to further the effort and it has lead to the creation of this document and a few 'working rules' for us to accomplish our work:
IETFでIPv4とIPv6移行戦略の歴史は非常に長くて複雑です。ここでは、我々は努力を促進するために行ったいくつかのステップをリストアップし、それはこのドキュメントの作成と私たちの仕事を達成するために私たちのためにいくつかの「働くルール」につながるがあります。
o At the IETF 63 "LightWeight Reachability softWires" (LRW) BOF meeting, attendees from several operators requested a very tight timeframe for the delivery of a solution, based on time-to-market considerations. This problem statement is narrowly scoped to accommodate near-term deployment.
O IETF 63「軽量到達可能性softWires」（LRW）BOF会議では、いくつかの事業者からの参加者は、市場投入までの時間の考慮に基づいて、ソリューションの配信のために非常にタイトな時間枠を要求しました。この問題文は狭く短期的な展開に対応するためにスコープされます。
o At the Paris Softwires interim meeting in October, 2005, participants divided the overall problem space into two separate "sub-problems" to solve based on network topology. These two problems are referred to as "Hubs and Spokes" (described in Section 2) and "Mesh" (described in Section 3).
2005年10月にパリSoftwires暫定会議ではO、参加者は、ネットワークトポロジに基づいて解決するには、2つの別々の「サブ問題」に、全体的な問題空間を分割しました。この2つの問題は、（セクション3を参照）、「ハブとスポーク」（セクション2を参照）および「メッシュ」と呼ばれます。
As stated, there are two scenarios that emerged when discussing the traversal of networks composed of differing address families. The scenarios are quite common in today's network deployments. The primary difference between "Spokes and Hubs" and "Mesh" is how many connections and associated routes are managed by each IPv4 or IPv6 "island". "Hubs and Spokes" is characterized with one connection and associated static default route, and "Mesh" is characterized by multiple connections and routing prefixes. In general, the two can be categorized as host or LAN connectivity and network (or VPN) connectivity problems. Looking at the history of multi-address family networking, the clear delineation of the two scenarios was never clearly illustrated but they are now the network norm, and both must be solved. Later, during the solution phase of the Work Group (WG), these problems will be treated as related, but separate, problem spaces. Similar protocols and mechanisms will be used when possible, but different protocols and mechanisms may be selected when necessary to meet the requirements of each given problem space.
述べたように、アドレスファミリを異なる構成のネットワークの横断を議論する際に現れた2つのシナリオがあります。シナリオは、今日のネットワークの展開にはかなり共通しています。 「スポークとハブ」と「メッシュ」の主な違いは、それぞれのIPv4またはIPv6の「島」で管理されているどのように多くの接続および関連するルートです。 「ハブとスポーク」とは、一つの接続と関連する静的デフォルトルートで特徴付けられ、かつ複数の接続とルーティングプレフィックスを特徴とする「メッシュ」。一般に、二人は、ホストまたはLAN接続とネットワーク（またはVPN）接続の問題として分類することができます。マルチアドレスファミリのネットワーキングの歴史を見ると、2つのシナリオの明確な線引きが明確に示されなかったが、彼らは今、ネットワークノルムであり、両方を解決しなければなりません。その後、作業グループ（WG）の溶液相の間に、これらの問題は、関連するが、独立した、問題のスペースとして扱われます。可能な場合は同様のプロトコルおよびメカニズムが使用されるが、それぞれ与えられた問題空間の要件を満たすために必要な場合に、異なるプロトコル及びメカニズムが選択されてもよいです。
Address Family (AF) - IPv4 or IPv6. Presently defined values for this field are specified in
アドレスファミリ（AF） - IPv4またはIPv6。このフィールドの現在定義された値がで指定されています
http://www.iana.org/assignments/address-family-numbers.
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／あっｄれっｓーふぁみｌｙーぬｍべｒｓ。
Address Family Border Router (AFBR) - The router that interconnects two networks that use different address families.
別のアドレスファミリを使用する2つのネットワークを相互接続するルータ - ファミリー境界ルータ（AFBR）に対処。
Customer Premise Equipment (CPE) - Under the scope of this document, this refers to terminal and associated equipment and inside wiring located at a subscriber's premises and connected with a carrier's communication channel(s) at the demarcation point ("demarc"). The demarc is a point established in a building or complex to separate customer equipment from telephone, cable, or other service provider equipment. CPE can be a host or router, depending on the specific characteristics of the access network. The demarc point for IPv4 may or may not be the same as the demarc point for IPv6, thus there can be one CPE box acting for IPv4 and IPv6 or two separate ones, one for IPv4 and one for IPv6.
顧客宅内機器（CPE） - この文書の範囲の下では、これは端末と関連した装置及び加入者の構内に位置し、境界点（「分界点」）におけるキャリアの通信チャネル（複数可）に接続内部配線を指します。分界点は、電話、ケーブル、またはその他のサービスプロバイダーの機器とは別の顧客の機器に建物や複雑に設立されたポイントです。 CPEは、アクセスネットワークの特定の特性に応じて、ホストまたはルータとすることができます。 IPv4の分界点は、またはIPv6の分界点と同じであってもなくてもよく、したがって、IPv4とIPv6又は二つの別々のもの、のIPv4用とIPv6のいずれかに作用する1つのCPEボックスが存在し得ます。
Home gateway - Existing piece of equipment that connects the home network to the provider network. Usually act as CPE for one or both address families.
ホームゲートウェイ - プロバイダーネットワークにホームネットワークを接続している機器の既存の作品。通常、1つまたは両方のアドレスファミリのCPEとして動作します。
Softwire (SW) - A "tunnel" that is created on the basis of a control protocol setup between softwire endpoints with a shared point-to-point or multipoint-to-point state. Softwires are generally dynamic in nature (they may be initiated and terminated on demand), but may be very long-lived.
Softwire（SW） - とsoftwireエンドポイント間の制御プロトコルの設定に基づいて作成された「トンネル」の共有ポイントツーポイントまたはマルチポイントツーポイント状態。 Softwiresは（彼らが開始され、オンデマンドで終了することができる）自然の中で一般的に動的であるが、非常に長寿命かもしれません。
Softwire Concentrator (SC) - The node terminating the softwire in the service provider network.
Softwireコンセントレータ（SC） - サービスプロバイダネットワーク内softwire終端ノード。
Softwire Initiator (SI) - The node initiating the softwire within the customer network.
Softwireイニシエータ（SI） - 顧客のネットワーク内softwireを開始ノード。
Softwire Transport Header AF (STH AF) - the address family of the outermost IP header of a softwire.
Softwire転送ヘッダAF（STH AF） - softwireの最も外側IPヘッダのアドレスファミリー。
Softwire Payload Header AF (SPH AF) - the address family of the IP headers being carried within a softwire. Note that additional "levels" of IP headers may be present if (for example) a tunnel is carried over a softwire - the key attribute of SPH AF is that it is directly encapsulated within the softwire and the softwire endpoint will base forwarding decisions on the SPH AF when a packet is exiting the softwire.
SoftwireペイロードヘッダAF（SPH AF） - softwire内で運ばれるIPヘッダのアドレスファミリー。 SPH AFのキー属性は、それが直接softwire内に封入されsoftwireエンドポイントが上に転送決定の基礎であろうということである - （例えば）トンネルがsoftwire上に担持されている場合、IPヘッダーの追加の「レベル」が存在してもよいことに留意されたいですパケットがsoftwireから出ているSPH AF。
Subsequent Address Family (SAF) - Additional information about the type of Network Layer Reachability Information (e.g., unicast or multicast).
次のアドレスファミリー（SAF） - ネットワーク層到達可能性情報（例えば、ユニキャストまたはマルチキャスト）の種類に関する追加情報。
The "Hubs and Spokes" problem is named in reference to the airline industry where major companies have established a relatively small number of well connected hubs and then serve smaller airports from those hubs.
「ハブとスポーク」の問題は、大手企業がうまく接続されているハブの比較的小さな数を確立し、それらのハブから小さな空港にサービスを提供している航空業界への参照で指定されています。
Manually configured tunnels (as described in [RFC4213]) can be a sufficient transition mechanism in some situations. However, cases where Network Address Translation (NAT) traversal is a concern (see Section 2.3), or dynamic IP address configuration is required, another solution is necessary.
手動で設定されたトンネルは、（[RFC4213]に記載されているように）いくつかの状況において十分な遷移機構とすることができます。しかし、ネットワークアドレス変換（NAT）トラバーサル例（セクション2.3を参照）の関心事である、または動的IPアドレスの設定が必要とされ、別の解決策が必要です。
There are four variant cases of the "Hubs and Spokes" problem which are shown in the following figures.
次の図に示されている「ハブとスポーク」問題の4の変形例があります。
+-------+ +------------+ +--------+
| | |Softwire | | IPv6 |
+---------+ | IPv4 |--|concentrator|--| Network|=>Internet
|v4/v6 |--| | +------------+ +--------+
|Host CPE | | |
+---------+ |Network|
+-------+
_ _ _ _ _ _ __
()_ _ _ _ _ _ __() IPv6 SPH
"softwire"
|--------------||-------------------------|
IPv4-only IPv6 or dual-stack
Case 1: IPv6 connectivity across an IPv4-only access network (STH). Softwire initiator is the host CPE (directly connected to a modem), which is dual-stack. There is no other gateway device. The IPv4 traffic should not traverse the softwire.
ケース1：IPv4のみのアクセスネットワークを介したIPv6接続（STH）。 Softwire開始剤は、デュアルスタックであるホストCPE（直接モデムに接続されている）、です。他のゲートウェイデバイスはありません。 IPv4トラフィックはsoftwireを横断してはいけません。
Figure 1: Case 1
図1：ケース1
+-------+ +-------------+ +--------+
| | | Softwire | | v6 |
+-----+ +------+ | v4 |--| concentrator|--| Network|=>Internet
|v4/v6|--|v4/v6 |--| | +-------------+ +--------+
|Host | |Router| |Network|
+-----+ |v4/v6 | | |
| CPE | +-------+
+------+
_ _ _ _ _ _ __
()_ _ _ _ _ _ __() IPv6 SPH
"softwire"
|--------------||--------------||-------------------------|
Dual-stack IPv4-only IPv6 or dual-stack
Case 2: IPv6 connectivity across an IPv4-only access network (STH). Softwire initiator is the router CPE, which is a dual-stack device. The IPv4 traffic should not traverse the softwire.
ケース2：IPv4のみのアクセスネットワークを介したIPv6接続（STH）。 Softwire開始剤は、デュアルスタックデバイスであるルータCPE、です。 IPv4トラフィックはsoftwireを横断してはいけません。
Figure 2: Case 2
図2：ケース2
+-------+ +-------------+ +--------+
| | | Softwire | | v6 |
+------+ +------+ | v4 |--| concentrator|--| Network|=>Internet
|v4/v6 |--|v4 |--| | +-------------+ +--------+
|Host | |Router| |Network|
|v6 CPE| |v4 CPE| | |
+------+ | | +-------+
+------+
_ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH
"softwire"
|-----------------------||-------------------------|
IPv4 only IPv6 or dual-stack
Case 3: IPv6 connectivity across an IPv4-only access network (STH). The CPE is IPv4-only. Softwire initiator is a host, which act as an IPv6 host CPE. The IPv4 traffic should not traverse the softwire.
ケース3：IPv4のみのアクセスネットワークを介したIPv6接続（STH）。 CPEはIPv4のみです。 Softwireイニシエータは、IPv6ホストCPEとして動作するホスト、です。 IPv4トラフィックはsoftwireを横断してはいけません。
Figure 3: Case 3
図3：ケース3
+-----+
|v4/v6| +-------+ +------------+ +-------+
|Host | | | |Softwire | | v6 |
+-----+ +------+ | v4 |--|concentrator|--|Network|=>Internet
| |v4 |--| | +------------+ +-------+
|---------|Router| |Network|
| |v4 CPE| +-------+
+---------+ +------+
|Softwire |
|Initiator|
|v6 Router|
| CPE |
+---------+
_ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH
"softwire"
|--------||-----------------------||----------------------|
Dual IPv4 only IPv6 or dual-stack
stack
Case 4: IPv6 connectivity across an IPv4-only access network (STH). The routing CPE is IPv4-only. Softwire initiator is a device acting as an IPv6 CPE router inside the home network. The IPv4 traffic should not traverse the softwire.
ケース4：IPv4のみのアクセスネットワークを介したIPv6接続（STH）。ルーティングCPEは、IPv4のみです。 Softwireイニシエータは、ホームネットワーク内でのIPv6 CPEルータとして機能するデバイスです。 IPv4トラフィックはsoftwireを横断してはいけません。
Figure 4: Case 4
図4：ケース4
The converse cases exist, replacing IPv4 by IPv6 and vice versa in the above figures.
逆の場合は、上記の図にIPv6と逆にすることで、IPv4を置き換え、存在します。
In this scenario, carriers (or large enterprise networks acting as carriers for their internal networks) have an infrastructure that in at least one device on any given path supports only one address family, with customers who wish to support applications bound to an address family that cannot be routed end-to-end. The address family that must be "crossed" is called the Softwire Transport Header, or STH AF (which could be either IPv4 or IPv6).
このシナリオでは、（自分の内部ネットワークのためのキャリアとして機能するか、大規模な企業ネットワーク）キャリアは、任意のパス上の少なくとも一つの装置で、そのアドレスファミリにバインドされたアプリケーションをサポートするために、ご希望のお客様に、唯一のアドレスファミリをサポートするインフラストラクチャを持っていますエンドツーエンドをルーティングすることはできません。 「交差」しなければならないアドレスファミリーはSoftwire転送ヘッダ、または（IPv4またはIPv6のいずれかである）STH AFと呼ばれています。
In order to support applications bound to another address family (the Softwire Payload Header Address Family, or SPH AF), it is necessary to establish a virtual dual-stack infrastructure (end-to-end), typically by means of automatically-established tunnels (Softwires). The traffic that can traverse the network via its native AF must not be forced to take the softwire path. Only the traffic that otherwise would not be able to be forwarded due to the AF mismatch should be forwarded within the softwire. The goal is to avoid overwhelming the softwire concentrator (SC).
別のアドレスファミリ（Softwireペイロードヘッダーアドレスファミリ、またはSPH AF）にバインドされたアプリケーションをサポートするためには、通常、自動的に確立されたトンネルを介して仮想デュアルスタックインフラストラクチャを（エンド・ツー・エンド）を確立する必要があります（Softwires）。その本来のAFを介してネットワークを通過できるトラフィックはsoftwireパスを取ることを余儀なくされてはなりません。それ以外によるAFの不一致に転送することができないだろうトラフィックのみがsoftwire内に転送する必要があります。目標は、softwireコンセントレータ（SC）を圧倒しないようにすることです。
A network operator may choose to enable a single address family in one or several parts of this infrastructure for policy reasons (i.e., traffic on the network is dominant in one of the address families, a single address family is used to lower Operations and Management (OAM) cost, etc.) or for technical reasons (i.e., because one or more devices are not able to support both address families).
ネットワークオペレータは、政策上の理由のための1つまたはこのインフラストラクチャのいくつかの部分では、単一のアドレスファミリを有効にすることもできます（つまり、ネットワーク上のトラフィックは、アドレスファミリの一つ、家族が運用と管理を（下げるために使用される単一のアドレスが支配的ですOAM）コストなど）または技術的な理由（すなわち、1つのまたは複数のデバイスが両方のアドレスファミリをサポートすることができませんので）。
There are several obstacles that may preclude support for both address families:
両方のアドレスファミリのサポートを妨げることがあり、いくつかの障害があります。
a) One or more devices (routers or some other media-specific aggregation point device) being used across the infrastructure (core, access) that supports only one address family. Typically the reasons for this situation include a lack of vendor support for one of the address families, the (perceived) cost of upgrading them, the (perceived) complexity of running both address families natively, operation/management reasons to avoid upgrades (perhaps temporarily), or economic reasons (such as a commercially insignificant amount of traffic with the non-supported address family).
a）1種以上のデバイス（ルータまたは何らかの他のメディア特有の集約ポイント装置）のみアドレスファミリをサポートするインフラストラクチャ（コア、アクセス）を横切って使用されています。通常、このような状況の理由は、おそらく一時的にアドレスファミリのいずれかのベンダー・サポートの欠如、それらをアップグレードする（認知）コスト、ネイティブの両方のアドレスファミリを実行しているの（認知）の複雑さ、アップグレードを回避するための操作/管理上の理由を（含めます）、またはそのような非サポートされるアドレスファミリを持つトラフィックの商業的にわずかな量として、経済的な理由（）。
b) The home gateway (CPE router or other equipment at the demarc point), cannot be easily upgraded to support both address families. Typically the reason for this is the lack of vendor support for one of the address families, commercial or operational reasons for not carrying out the upgrade (i.e., operational changes and/or cost may need to be supported by the carrier for all the customers, which can turn into millions of units), or customer reluctance to change/ upgrade CPE router (cost, "not broken, so don't change it"). Note that the impracticality of systematic upgrades of the CPE routers is also hindering the deployment of 6to4 based solutions [RFC3056] in IPv4 networks.
b）はホームゲートウェイ（分界点でのCPEルータまたはその他の機器）は、簡単に両方のアドレスファミリをサポートするようにアップグレードすることはできません。通常、この理由は（すなわち、運用上の変更及び/またはコストはすべての顧客のためのキャリアによってサポートされる必要があり、アドレスファミリの一つ、アップグレードを行っていないため、商用または運用上の理由のためにベンダーのサポートの欠如でありますこれは数百万台になることができます）、または変更するには、顧客の不本意/アップグレードCPEルータ（コスト、「壊れていないので、それを変更しないでください」）。 CPEルータの体系的なアップグレードの非現実もIPv4ネットワーク内の6to4ベースのソリューション[RFC3056]の展開を妨げていることに注意してください。
Residential and small-office CPE equipment may be limited to support only one address family. Often, they are owned by a customer or carrier who is unwilling or unable to upgrade them to run in dual stack mode (as shown in Figure 3 and Figure 4).
住宅や小規模オフィスのCPE機器は、唯一のアドレスファミリをサポートするために制限することができます。多くの場合、彼らは不本意または（図3と図4に示すように）デュアルスタックモードで実行するためにそれらをアップグレードすることができない顧客やキャリアによって所有されています。
When the CPE router cannot run in dual-stack mode, a softwire will have to be established by a node located behind that CPE router. This can be accomplished either by a regular host in the home running softwire software (Figure 1 or Figure 3) or by a dedicated piece of hardware acting as the "IPv6 router" (Figure 4). Such a device is fairly simple in design and only requires one physical network interface. Again, only the traffic of the mismatched AF will be forwarded via the softwire. Traffic that can otherwise be forwarded without a softwire should not be encapsulated.
CPEルータがデュアルスタックモードで実行することができない場合は、softwireは、CPEルータの背後に配置ノードによって確立されなければなりません。これはsoftwireソフトウェアを実行して、家庭での通常のホスト（図1または図3）によって、または「IPv6ルータ」（図4）として動作する専用のハードウェアのいずれかによって達成することができます。このようなデバイスは、設計に非常に単純であり、唯一つの物理ネットワークインタフェースが必要です。ここでも、不一致AFのトラフィックのみがsoftwireを経由して転送されます。そうでない場合はsoftwireずに転送することができますトラフィックをカプセル化するべきではありません。
2.3. Network Address Translation (NAT) and Port Address Translation (PAT)
2.3. ネットワークアドレス変換（NAT）およびポートアドレス変換（PAT）
A typical case of non-upgradable CPE router is a pre-existing IPv4/ NAT home gateway, so the softwire solution must support NAT traversal.
softwireソリューションは、NATトラバーサルをサポートしなければならないので、非アップグレードCPEルータの典型的なケースでは、既存のIPv4 / NATホームゲートウェイです。
Establishing a Softwire through NAT or PAT must be supported without an explicit requirement to "autodetect" NAT or PAT presence during softwire setup. Simply enabling NAT traversal could be sufficient to meet this requirement.
NATまたはPATを通じてSoftwireを確立することsoftwireのセットアップ時にNATまたはPATの存在を「自動検出」するために、明示的な要求なしに支持されなければなりません。単純にNATトラバーサルを有効にすると、この要件を満たすのに十分である可能性があります。
Although the tunneling protocol must be able to traverse NATs, tunneling protocols may have an optional capability to bypass UDP encapsulation if not traversing a NAT.
トンネリングプロトコルのNATをトラバースすることができなければならないが、トンネリングプロトコルは、NATを横断しない場合はUDPカプセル化をバイパスするオプション機能を有していてもよいです。
An important characteristic of this problem in IPv4 networks is that the carrier-facing CPE IP address is typically dynamically assigned. (The IP address of the node establishing the softwire behind the CPE router can also be dynamically assigned.)
IPv4ネットワークでは、この問題の重要な特徴は、キャリアに面したCPEのIPアドレスは通常、動的に割り当てられていることです。 （CPEルータの背後softwireを確立するノードのIPアドレスが動的に割り当てることができます。）
Solutions like external dynamic DNS and dynamic NAT port forwarding have been deployed to deal with ever changing addresses, but it would be simpler if, in IPv6 networks, a static prefix was delegated to customers. Such a prefix would allow for the registration of stable addresses in the DNS and enable the use of solutions like RFC 3041 [RFC3041] privacy extension or cryptographically generated addresses (CGA) [RFC3972].
外部のダイナミックDNSおよびダイナミックNATポートフォワーディングのようなソリューションは、常に変化するアドレスに対処するために展開されてきたが、、IPv6ネットワークでは、静的プレフィックスが顧客に委任された場合は、それが簡単になります。そのようなプレフィックスがDNSに安定したアドレスの登録を可能にし、RFC 3041 [RFC3041]プライバシー拡張または暗号化生成アドレス（CGA）[RFC3972]のような溶液の使用を可能にします。
The softwire protocol does not need to define a new method for prefix delegation; however, the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) prefix delegation [RFC3633] must be able to run over a softwire.
softwireプロトコルはプレフィックス委任のための新しい方法を定義する必要はありません。しかし、IPv6の動的ホスト構成プロトコル（DHCPv6）プレフィックス委譲[RFC3633]はsoftwire上で実行できる必要があります。
Link local addresses allocated at both ends of the tunnel are enough for packet forwarding, but for management purpose like traceroute, global addresses can be allocated using existing protocols such as stateless address auto-configuration [RFC2462] or DHCPv6 [RFC3315].
トンネルの両端に割り当てられたリンクローカルアドレスは、パケット転送のために十分であるが、トレースルートのような管理目的のために、グローバルアドレスは、ステートレスアドレス自動構成[RFC2462]またはDHCPv6の[RFC3315]などの既存のプロトコルを使用して割り当てることができます。
The IP addresses of the softwire link itself do not need to be stable, the desire for stability only applies to the delegated prefix. Even if there is a single node attached behind a softwire link, nothing prevents a softwire concentrator to delegate it a /64 prefix.
softwireリンク自体のIPアドレスは、安定性のための欲求だけ委任プレフィックスに適用され、安定である必要はありません。 softwireリンクの後ろに接続された単一のノードが存在する場合であっても、何もそれに/ 64のプレフィックスを委任するsoftwireコンセントレータを防ぎません。
Similarly, in the case of an IPv4 softwire, the address could be provided by means of DHCP [RFC2131]. In the case of an IPv4 softwire, a mechanism should be available in order to delegate an IPv4 prefix [SUBNET].
同様に、IPv4のsoftwireの場合には、アドレスがDHCP [RFC2131]を用いて提供することができます。 IPv4 softwireの場合において、機構は、IPv4のプレフィックス[サブネット]を委任するために利用可能であるべきです。
Note about 6to4: This is one of the main differences between Softwires and 6to4. 6to4 addresses will change every time the CPE router gets a new external address, where a DHCPv6 delegated prefix through a softwire link could be stable.
6to4のについて注意：これはSoftwiresと6to4の主な違いの一つです。 6to4のアドレスは、DHCPv6のは、安定した可能性がsoftwireリンクを通じてプレフィックスを委任CPEルータが新しい外部アドレスを取得するたびに、変更されます。
In the "Hubs and Spokes" problem, softwires are always initiated by the customer side. Thus, the node hosting the end of the softwire within the customer network is called the softwire initiator. It can run on any dual-stack node. As noted earlier, this can be the CPE access device, another dedicated CPE router behind the original CPE access device, or actually any kind of node (host, appliance, sensor, etc.).
「ハブとスポーク」問題では、softwiresは常に顧客側によって開始されています。このように、顧客のネットワーク内softwireの終わりをホスティングしているノードがsoftwireイニシエータと呼ばれています。これは、任意のデュアルスタックノード上で実行することができます。先に述べたように、これはCPEアクセスデバイス、元のCPEアクセスデバイスの背後にある別の専用のCPEルータ、または実際のノード（ホスト、機器、センサー、等）の任意の種類であってもよいです。
The softwire initiator node can change over time and may or may not be delegated the same IP address for the softwire endpoint. In particular, softwires should work in the nomadic case (e.g., a user opening up his laptop in various Wi-Fi hot-spots), where the softwire initiator could potentially obtain an IP address of one address family outside its original carrier network and still want to obtain the other address family addresses from its carrier.
softwireイニシエータノードは、経時的に変化することができ、またはしないかもしれsoftwireエンドポイントに対して同じIPアドレスを委任することができます。特に、softwiresは遊牧民の場合には動作するはずです（例えば、アップユーザーの開口部の各種のWi-Fiホットスポットでの彼のラップトップ）softwireイニシエータは、潜在的に、まだ元のキャリア・ネットワークと外部の一つのアドレスファミリのIPアドレスを取得することができ、そのキャリアから他のアドレスファミリのアドレスを取得します。
If and when the IPv4 provider periodically changes the IPv4 address allocated to the gateway, the softwire initiator has to discover in a reasonable amount of time that the tunnel is down and restart it. This re-establishment should not change the IPv6 prefix and other parameters allocated to the site.
IPv4のプロバイダは、定期的にゲートウェイに割り当てられたIPv4アドレスを変更したときと、softwire開始剤は、トンネルがダウンしていると、それを再起動する妥当な時間内に発見しなければならない場合。この再確立がIPv6プレフィックスとサイトに割り当てられた他のパラメータを変更しないでください。
On the carrier side, softwires are terminated on a softwire concentrator. A softwire concentrator is usually a dual-stack router connected to the dual-stack core of the carrier.
キャリア側では、softwiresはsoftwireコンセントレータ上で終端されています。 softwire濃縮は、通常、担体のデュアルスタックコアに接続されたデュアルスタックルータです。
A carrier may deploy several softwire concentrators (for example one per POP) for scalability reasons.
キャリアは、スケーラビリティの理由から（例えばPOPあたりいずれかの）いくつかのsoftwireコンセントレータを展開することができます。
Softwire concentrators are usually not nomadic and have stable IP addresses.
Softwireコンセントレータは、通常は遊牧民ではなく、安定したIPアドレスを持っています。
It may be the case that one of the address families is not natively supported on the interface facing the core of the carrier. Connectivity must then be provided by other tunnels, potentially using the softwire mesh model.
これは、アドレスファミリの一つは、ネイティブのキャリアのコアが直面しているインターフェイスではサポートされていないこと場合があります。接続は、潜在的にsoftwireメッシュモデルを使用して、他のトンネルによって提供されなければなりません。
Softwire concentrator functionality will be based on existing standards for tunneling, prefixes, and addresses allocation, management. The working group must define a softwire concentrator architecture and interaction between these protocols and recommend profiles. These recommendations must take into account the distributed nature of the Softwires Concentrator in the provider network and the impact on core IPv6 networks (for instance: prefix aggregation).
Softwireコンセントレーター機能は、トンネリング、プレフィックス、およびアドレスの割り当て、管理のための既存の標準に基づいて行われます。ワーキンググループは、これらのプロトコル間のsoftwireコンセントレータアーキテクチャとの相互作用を定義し、プロファイルをお勧めしなければなりません。これらの推奨事項は考慮プロバイダネットワーク内Softwiresコンセントレータの分散性及び（：接頭集約例えば）コアIPv6ネットワークへの影響を取らなければなりません。
The softwire initiator must know the DNS name or IP address of the softwire concentrator. An automated discovery phase may be used to return the IP address(s) or name(s) of the concentrator. Alternatively, this information may be configured by the user, or by the provider of the softwire initiator in advance. The details of this discovery problem are outside the scope of this document, however previous work could be taken in consideration. Examples include: [SERVICE-DIS], [RFC4891], and [TUN-AD].
softwire開始剤は、DNS名またはsoftwireコンセントレータのIPアドレスを知っている必要があります。自動化された発見フェーズは、コンセントレータのIPアドレス（複数可）または名前（複数可）を返すために使用することができます。あるいは、この情報は、ユーザによって、又は予めsoftwire開始剤のプロバイダによって構成されていてもよいです。この発見の問題の詳細は、このドキュメントの範囲外で、しかし前作は考慮して取ることができるされています。例としては、[SERVICE-DIS]、[RFC4891]、および[TUN-AD]。
In a "Hubs and Spokes model", a carrier must be able to scale the solution to millions of softwire initiators by adding more hubs (i.e., softwire concentrators).
「ハブとスポークモデル」において、キャリアは、より多くのハブ（すなわち、softwireコンセントレータ）を加えることによってsoftwire開始の何百万もの解を拡張することができなければなりません。
As customer networks are typically attached via a single link to their carrier, the minimum routing requirement is a default route for each of the address families.
顧客ネットワークは、典型的には、そのキャリアに単一のリンクを介して結合されているように、最小のルーティング要件は、アドレスファミリーのそれぞれのデフォルトルートです。
Softwires must support multicast.
Softwiresは、マルチキャストをサポートしている必要があります。
The softwire protocol must support customer authentication in the control plane, in order to authorize access to the service, and provide adequate logging of activity (accounting). However, a carrier may decide to turn it off in some circumstances, for instance, when the customer is already authenticated by some other means, such as closed networks, cellular networks, etc., in order to avoid unnecessary overhead.
softwireプロトコルは、サービスへのアクセスを許可するためには、制御プレーンで顧客認証をサポートし、活動の十分なログ（会計）を提供しなければなりません。しかし、キャリアは、顧客が既に不要なオーバーヘッドを回避するために、等閉じネットワーク、セルラーネットワーク、のようないくつかの他の手段によって認証された場合、例えば、いくつかの状況でそれをオフにすることを決定してもよいです。
The protocol should offer mutual authentication in scenarios where the initiator requires identity proof from the concentrator.
プロトコルは、イニシエータは、コンセントレータからの身元証明を必要とするシナリオで相互認証を提供する必要があります。
The softwire solution, at least for "Hubs and Spokes", must be integrable with commonly deployed AAA solutions (although extensions to those AAA solutions may be needed).
（これらのAAAソリューションへの拡張が必要になるかもしれないが）softwire溶液は、少なくとも「ハブとスポーク」ため、一般的に展開AAAソリューションと統合可能でなければなりません。
The softwire Control and/or Data plane must be able to provide full payload security (such as IPsec or SSL (Secure Socket Layer)) when desired. This additional protection must be separable from the tunneling aspect of the softwire mechanism itself. For IPsec, default profiles must be defined. [RFC4891] provides guidelines on this.
softwire制御および/またはデータプレーンは、所望の場合（例えば、IPSecまたはSSL（セキュアソケットレイヤー）のような）完全なペイロード・セキュリティを提供することができなければなりません。この追加の保護はsoftwireメカニズム自体のトンネリング面から分離可能でなければなりません。 IPsecの場合、デフォルトのプロファイルを定義する必要があります。 [RFC4891]は、この上のガイドラインを提供します。
As it is assumed that the softwire may have to go across NAT or PAT, a keepalive mechanism must be defined. Such a mechanism is also useful for dead peer detection. However in some circumstances (i.e., narrowband access, billing per traffic, etc.) the keepalive mechanism may consume unnecessary bandwidth, so turning it on or off, and modifying the periodicity, must be supported administrative options.
それはsoftwireがNATまたはPAT越えて行かなければならないことが想定されるので、キープアライブメカニズムを定義する必要があります。このようなメカニズムは、死んだ仲間の検出に有用です。しかし、いくつかの状況において（すなわち、狭帯域アクセス、トラフィック当たりの課金、等）キープアライブ機構はそうオンまたはオフに回し、そして周期を変更する、不要な帯域幅を消費することができる、管理オプションをサポートしなければなりません。
Other needed OAM features include:
その他の必要なOAM機能は、次のとおりです。
- Logging
- ロギング
- Usage accounting
- 使用法会計
- End-point failure detection (the detection mechanism must operate within the tunnel)
- エンドポイントの障害検出（検出機構がトンネル内で動作しなければなりません）
- Path failure detection (the detection mechanism must operate outside the tunnel)
- パス障害検出（トンネル外で動作しなければならない検出機構）
IPv6/IPv4, IPv6/UDP/IPv4, and IPv4/IPv6 are on the critical path for "Hubs and Spokes" softwires. There is no intention to place limits on additional encapsulations beyond those explicitly mentioned in this specification.
IPv6の/ IPv4の、IPv6の/ UDP / IPv4の、とIPv4 / IPv6は、 "ハブとスポーク" softwiresのためのクリティカルパス上にあります。明示的に本明細書中で言及されたもの以外の追加のカプセル化に制限を配置する意図はありません。
We use the term "Mesh Problem" to describe the problem of supporting a general routed topology in which a backbone network that does not support a particular address family can be used as part of the path for packets that belong to that address family. For example, the path for an IPv4 packet might include a transit network that supports only IPv6. There might (or might not) be other paths that the IPv4 packet could take that do not use the IPv6 transit network; the actual path chosen will be determined by the IPv4 routing procedures.
私たちは、特定のアドレスファミリをサポートしていないバックボーンネットワークは、そのアドレスファミリーに属するパケットのためのパスの一部として使用することができる一般的なルーティングされたトポロジーをサポートする問題を記述するために用語「メッシュの問題」を使用します。たとえば、IPv4パケットのパスは、IPv6のみをサポートしているトランジットネットワークが含まれる場合があります。 （またはしない場合があります）IPv4パケットがIPv6トランジットネットワークを使用していないことを取ることができる他の経路があるかもしれません。選択された実際のパスは、IPv4ルーティング手順によって決定されるであろう。
By saying that the transit network supports only a single address family, we mean that the "core" routers of that network do not maintain routing information for other address families, and they may not even be able to understand the packet headers of other address families. We do suppose though that the core will have "edge routers" or "border routers", which maintain the routing information for both address families, and which can parse the headers of both address families. We refer to these as "Address Family Border Routers" (AFBRs).
トランジットネットワークは、単一のアドレスファミリをサポートしていることを言って、私たちは、そのネットワークの「コア」のルータが他のアドレスファミリーのためのルーティング情報を保持していない、と彼らも他のアドレスファミリのパケットヘッダを理解することができないかもしれないことを意味します。私たちは、コアは、両方のアドレスファミリのためのルーティング情報を維持する「エッジルータ」または「境界ルータ」を、持っていること、および両方のアドレスファミリのヘッダを解析することができたのにと思います。私たちは、「アドレスファミリー境界ルータ」（AFBRs）としてこれらを参照してください。
The following figure shows an AF2-only network connected to AF1-only networks, AF2-only networks, and dual stack networks. Note that in addition to paths through the AF2-only core, other paths may also exist between AF1 networks. The AFBRs that support AF1 would use BGP to exchange AF1 routing information between themselves, but such information would not be distributed to other core routers. The AFBRs would also participate in the exchange of AF2 routing information with the core nodes.
次の図は、AF1専用ネットワーク、AF2専用ネットワーク、およびデュアルスタックのネットワークに接続されたAF2専用ネットワークを示します。 AF2のみのコアを通る経路に加えて、他のパスはAF1ネットワークとの間にも存在し得ることに留意されたいです。 AF1をサポートAFBRs自体の間でAF1ルーティング情報を交換するためにBGPを使用することになり、そのような情報は、他のコアルータに分配されないであろう。 AFBRsは、コアノードとAF2ルーティング情報の交換に参加します。
+----------+ +----------+
|AF1 only | |AF1 only |
| | | |
+----------+ +----------+
| |
| |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| |
| |
+----------------------------+
| |
+-------+ | | +-------+
|AF2 | | AF2 only | |AF2 |
|only |-------| (but also providing |-------|only |
+-------+ | transit for AF1) | +-------+
| |
+----------------------------+
| / \ |
| / \ |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| | |
| | |
+--------+ +--------+
|AF1 and | |AF1 and |
|AF2 | |AF2 |
+--------+ +--------+
Figure 5: Mesh Topology
図5：メッシュトポロジー
The situation in which a pair of border routers use BGP to exchange routing information that is not known to the core routers is sometimes known, somewhat misleadingly, as a "BGP-free core". In this sort of scenario, the problems to be solved are (a) to make sure that the BGP-distributed routing updates for AF1 allow a given AFBR, say AFBR1, to see that the path for a given AF1 address prefix is through a second AFBR, say AFBR2, and (b) to provide a way in which AFBR1 can send AF1 packets through the AF2-only core to AFBR2. Of course, sending AF1 packets through an AF2-only core requires the AF1 packets to be encapsulated and sent through "tunnels"; these tunnels are the entities known as "softwires".
境界ルータ一対のコアルータに知られていないルーティング情報を交換するためにBGPを使用する状況は、時々、「BGP-フリーコア」として、幾分誤解を招く、知られています。シナリオのこの種では、問題は、（a）はAF1のためのBGP-分散ルーティングアップデートが与えられたAFBRが許可されていることを確認するためにされている解決すべき、与えられたAF1アドレスプレフィックスのパスが第2の貫通であることを確認するために、AFBR1を言いますAFBRは、AFBR2言うと、（b）AFBR1がAFBR2にAF2のみコアを通してAF1パケットを送信することができる方法を提供します。もちろん、AF2のみコアを通してAF1パケットを送信すると、カプセル化され、「トンネル」を介して送信されるAF1パケットを必要としますこれらのトンネルは「softwires」として知られているエンティティです。
One of the goals of the mesh problem is to provide a solution that does not require changes in any routers other than the AFBRs. This would allow a carrier (or large enterprise networks acting as carrier for their internal resources) with an AF2-only backbone to provide AF1 transit services for its clients, without requiring any changes whatsoever to the clients' routers, and without requiring any changes to the core routers. The AFBRs are the only devices that perform dual-stack operations, and the only devices that encapsulate and/or decapsulate the AF1 packets in order to send and/or receive them on softwires.
メッシュ問題の目標の一つは、AFBRs以外の任意のルータの変更を必要としない解決策を提供することにあります。これは、クライアントのルータへの一切の変更を必要とせず、およびへの変更を必要とせずに、そのクライアントのためAF1トランジットサービスを提供するために、AF2のみの骨格とキャリア（または大規模な企業ネットワークは、その内部リソースのためのキャリアとして作用する）ことが可能になりますコア・ルータ。 AFBRsは、デュアルスタック操作、および送信および/またはsoftwires上でそれらを受けるために、カプセル化、および/またはAF1パケットをデカプセル化デバイスのみを実行するだけの装置です。
It may be recognized that this scenario is very similar to the scenario handled by the Layer 3 Virtual Private Network (L3VPN) solution described in RFC 4364 [RFC4364]. The AFBRs correspond to the "Provider Edge Routers" (PE) of RFC 4364. In those L3VPN scenarios, the PEs exchange routing information in an address family (e.g., the VPN-IPv4 address family), but they send VPN data packets through a core which does not have the VPN routing information. However, the softwire problem is NOT focused on the situation in which the border routers maintain multiple private and/or overlapping address spaces. Techniques which are specifically needed to support multiple address spaces are in the domain of L3VPN, rather than in the domain of Softwires.
なお、このシナリオでは、RFC 4364 [RFC4364]に記載されたレイヤ3仮想プライベートネットワーク（L3VPN）溶液によって処理シナリオに非常に類似していることを認識することができます。 AFBRsアドレスファミリー（例えば、VPN-IPv4アドレスファミリー）にルーティング情報をそれらL3VPNシナリオでRFC 4364の「プロバイダ・エッジ・ルータ」（PE）、PEの交換に対応し、それらはを通じてVPNデータパケットを送信しますVPNルーティング情報を持っていないコア。しかし、softwireの問題は、境界ルータは、複数のプライベートおよび/または重複するアドレス空間を維持している状況に焦点を当てていません。特に複数のアドレス空間をサポートするために必要な技術は、むしろSoftwiresのドメインに比べ、L3VPNのドメインです。
Note that the AFBRs may be multiply connected to the core network, and also may be multiply connected to the client networks. Further, the client networks may have "backdoor connections" to each other, through private networks or through the Internet.
AFBRsが多重コアネットワークに接続することができ、また、多重クライアント・ネットワークに接続されてもよいことに留意されたいです。さらに、クライアントのネットワークは、プライベートネットワークを介して、またはインターネットを通じて、お互いに「バックドアの接続」を有していてもよいです。
In the mesh problem, the number of AFBRs that a backbone network supporting only AF2 will need is approximately on the order of the number of AF1 networks to which it connects. (This is really an upper limit, since a single AFBR can connect to many such networks).
メッシュの問題では、唯一のAF2を支えるバックボーンネットワークが必要になりますAFBRsの数は、それが接続するAF1ネットワークの数の順に約あります。 （単一AFBRは、多くのそのようなネットワークに接続することができるので、これは、実際の上限です）。
An AFBR may need to exchange a "full Internet's" worth of routing information with each network to which it connects. If these networks are not VPNs, the scaling issues associated with the amount of routing information are just the usual scaling issues faced by the border routers of any network which is providing Internet transit services. (If the AFBRs are also attached to VPNs, the usual L3VPN scaling issues apply, as discussed in RFC 4364 [RFC4364] and RFC 4365 [RFC4365].) The number of BGP peering connections can be controlled through the usual methods, e.g., use of route reflectors.
AFBRは、それが接続する各ネットワークにルーティング情報の「完全なインターネットの」価値を交換する必要があるかもしれません。これらのネットワークはVPNのない場合は、ルーティング情報の量に関連したスケーリングの問題は、インターネットトランジットサービスを提供している任意のネットワークの境界ルータが直面しているだけで、通常のスケーリングの問題です。 （AFBRsもVPNに接続されている場合、RFC 4364 [RFC4364]及びRFC 4365 [RFC4365]で説明したような問題は、適用スケーリング。通常L3VPN）BGPピアリング接続の数は、通常の方法によって制御することができ、例えば、使用ルートリフレクタの。
AFBRs may discover each other, and may obtain any necessary information about each other, as a byproduct of the exchange of routing information (essentially in the same way that PE routers discovery each other in L3VPNs). This may require the addition of new protocol elements or attributes to existing protocols.
AFBRsは互いを発見することができ、（本質的にL3VPNsにおいて互いにPEルータの発見と同じ方法で）ルーティング情報の交換の副産物として、互いに約必要な情報を得ることができます。これは、既存のプロトコルに新しいプロトコル要素や属性の追加が必要な場合があります。
The softwires needed to allow packets to be sent from one AFBR to another should be "always available", i.e., should not require any extended setup time that would impart an appreciable delay to the data packets.
パケットが別のAFBRから送信されることを可能にするために必要なsoftwires、すなわち、データパケットにかなりの遅延を与えるであろう任意の拡張セットアップ時間を必要とすべきではない、「常に利用可能」でなければなりません。
If the AF2 core does not provide native multicast services, multicast between AF1 client networks should still be possible, even though it may require replication at the AFBRs and unicasting of the replicated packets through Softwires. If native multicast services are enabled, it should be possible to use these services to optimize the multicast flow.
AF2コアは、ネイティブマルチキャストサービスを提供していない場合は、AF1クライアントネットワーク間のマルチキャストはまだそれがAFBRsとSoftwiresて複製されたパケットのユニキャストで複製が必要な場合であっても、可能でなければなりません。ネイティブマルチキャストサービスが有効になっている場合は、マルチキャストフローを最適化するために、これらのサービスを使用することが可能でなければなりません。
The solution to the mesh problem must not require the use of any one encapsulation. Rather, it must accommodate the use of a variety of different encapsulation mechanisms, and a means for choosing the one to be used in any particular circumstance based on policy.
メッシュの問題を解決するには、いずれかのカプセル化の使用を要求してはなりません。むしろ、異なるカプセル化メカニズムの様々な使用、およびポリシーに基づいて、任意の特定の状況で使用する1つを選択するための手段を収容しなければなりません。
In particular, the solution to the mesh problem must allow for at least the following encapsulations to be used: Layer 2 Tunneling Protocol version 3 (L2TPv3), IP-in-IP, MPLS (LDP-based and RSVP-TE-based), Generic Routing Encapsulation (GRE), and IPsec. The choice of encapsulation is to be based on policy, and the policies themselves may be based on various characteristics of the packets, of the routes, or of the softwire endpoints themselves.
具体的には、メッシュの問題に対する解決策は、使用されるべき、少なくとも以下のカプセル化を可能にしなければならない：レイヤ2トンネリングプロトコルバージョン3（L2TPv3の）、IPインIP、MPLSを（LDPベースおよびRSVP-TEをベース）汎用ルーティングカプセル化（GRE）、およびIPsec。カプセル化の選択は、ポリシーに基づくものであり、ポリシー自体はルートの、又はsoftwire端点自身のパケットの種々の特性に基づくことができます。
In the mesh problem, the routers are not advertising routes for individual users. So the mesh problem does not require the fine-grained authentication that is required by the "Hub and Spoke" problem. There should however be a way to provide various levels of security for the data packets being transmitted on a softwire. The softwire solution must support IPsec and an IPsec profile must be defined (see recommendations in [USEIPSEC]).
メッシュの問題では、ルータは、個々のユーザーのためのルートをアドバタイズしていません。だから、メッシュの問題がで必要とされる「ハブとスポーク」の問題をされてきめ細かい認証を必要としません。しかしsoftwire上で伝送されるデータパケットのセキュリティのさまざまなレベルを提供する方法があるはずです。 softwire溶液（[USEIPSEC]の推奨事項を参照）に定義されなければならないIPsecとのIPsecプロファイルをサポートしなければなりません。
Security mechanisms for the control protocols are also required. It must be possible to protect control data from being modified in flight by an attacker, and to prevent an attacker from masquerading as a legitimate control protocol participant.
制御プロトコルのためのセキュリティ・メカニズムも必要とされています。攻撃者が飛行中に変更されることから制御データを保護するために、正当な制御プロトコルの参加者になりすましからの攻撃を防ぐことが可能でなければなりません。
The verification of the reachability information exchanged and issues surrounding the security of routing protocols themselves is outside the scope of the specification.
到達可能性情報の検証を交換し、それ自体が仕様の範囲外であるルーティングプロトコルのセキュリティを取り巻く問題。
Security considerations specific to the "Hubs and Spokes" and "Mesh" models appear in those sections of the document.
「ハブとスポーク」と「メッシュ」のモデルに固有のセキュリティに関する注意事項は、文書のこれらのセクションに表示されます。
As with any tunneling protocol, using this protocol may introduce a security issue by circumventing a site security policy implemented as ingress filtering, since these filters will only be applied to STH AF IP headers.
これらのフィルタは唯一STH AFのIPヘッダーに適用されますので、任意のトンネリングプロトコルと同様に、このプロトコルを使用すると、イングレスフィルタリングとして実装され、サイトのセキュリティポリシーを回避することによって、セキュリティ上の問題を導入することができます。
These are the principal authors for this document.
これらは、この文書の主な著者です。
Xing Li CERNET Room 225 Main Building, Tsinghua University Beijing 100084 China
興李CERNETルーム225本館、清華大学、北京100084中国
Phone: +86 10 62785983 Fax: +86 10 62785933 Email: xing@cernet.edu.cn
電話：+86 10 62785983ファックス：+86 10 62785933 Eメール：xing@cernet.edu.cn
Alain Durand Comcast 1500 Market st Philadelphia PA 19102 USA
アラン・デュランComcastの1500年の市場STフィラデルフィアPA 19102 USA
Email: Alain_Durand@cable.comcast.com
メール：Alain_Durand@cable.comcast.com
Shin Miyakawa NTT Communications 3-20-2 TOC 21F, Nishi-shinjuku, Shinjuku Tokyo Japan
しん みやかわ んっｔ こっむにかちおんｓ ３ー２０ー２ とＣ ２１Ｆ、 にしーしんじゅく、 しんじゅく ときょ じゃぱん
Phone: +81-3-6800-3262 Fax: +81-3-5365-2990 Email: miyakawa@nttv6.jp
電話：+ 81-3-6800-3262ファックス：+ 81-3-5365-2990 Eメール：miyakawa@nttv6.jp
Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain
ジョルディPaletマルティネスConsulintelサンノゼArtesano 1アルコベンダス - マドリッドE-28108 - スペイン
Phone: +34 91 151 81 99 Fax: +34 91 151 81 98 Email: jordi.palet@consulintel.es
電話：+34 91 151 81 99ファックス：+34 91 151 81 98 Eメール：jordi.palet@consulintel.es
Florent Parent Hexago 2875 boul. Laurier, suite 300 Sainte-Foy, QC G1V 2M2 Canada
フロラン親Hexago 2875 BOUL。ローリエ、スイート300サント・フォワ、QC G1V 2M2カナダ
Phone: +1 418 266 5533 Email: Florent.Parent@hexago.com
電話：+1 418 266 5533 Eメール：Florent.Parent@hexago.com
David Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA
デビッド・ウォードシスコシステムズ170 W.タスマン博士はカリフォルニア州サンノゼ95134 USA
Phone: +1-408-526-4000 Email: dward@cisco.com
電話：+ 1-408-526-4000 Eメール：dward@cisco.com
Eric C. Rosen Cisco Systems 1414 Massachusetts Avenue Boxborough, MA, 01716 USA
エリックC.ローゼンシスコシステムズ1414年マサチューセッツアベニューボックスボロー、MA、01716 USA
Email: erosen@cisco.com
メール：erosen@cisco.com
The authors would like to acknowledge the following contributors who provided helpful inputs on earlier versions of this document: Alain Baudot, Hui Deng, Francis Dupont, Rob Evans, Ed Koehler Jr, Erik Nordmark, Soohong Daniel Park, Tom Pusateri, Pekka Savola, Bruno Stevant, Laurent Totain, Bill Storer, Maria (Alice) Dos Santos, Yong Cui, Chris Metz, Simon Barber, Skip Booth, Scott Wainner, and Carl Williams.
アランボドー、ホイ鄧小、フランシスデュポン、ロブ・エヴァンス、エド・ケーラージュニア、エリックNordmarkと、Soohongダニエル・パーク、トムPusateri、ペッカSavola、ブルーノ：作者はこのドキュメントの以前のバージョンで役立つ入力を提供し、次の貢献者を承認したいと思いますStevant、ローランTotain、ビル・ストアラー、マリア（アリス）ドス・サントス、龍崔、クリス・メッツ、サイモン・理容室、スキップブース、スコット・ワイナー、およびカール・ウィリアムズ。
The authors would also like to acknowledge the participants in the Softwires interim meeting in Paris, France (October 11-12, 2005) (minutes are at http://bgp.nu/~dward/softwires/InterimMeetingMinutes.htm).
著者らはまた、パリ、フランスのSoftwires中間会合（10月11-12、2005）（分http://bgp.nu/~dward/softwires/InterimMeetingMinutes.htmである）の参加を承認したいと思います。
The authors would also like to express a special acknowledgement and thanks to Mark Townsley. Without his leadership, persistence, editing skills, and thorough suggestions for the document, we would have not have been successful.
著者はまた、特別な承認とマークTownsleyに感謝を表したいと思います。彼のリーダーシップ、持続性、編集のスキル、および文書のための徹底した提案がなければ、我々は成功していないだろう。
Tunnel-based transition mechanisms have been under discussion in the IETF for more than a decade. Initial work related to softwire can be found in RFC 3053 [RFC3053]. The earlier "V6 Tunnel Configuration" BOF problem statement [GOALS-TUN] a reasonable pointer to prior work.
トンネルベースの移行メカニズムは、10年以上にわたりIETFで議論されています。 softwireに関連した初期の作品は、RFC 3053 [RFC3053]で見つけることができます。以前の「V6トンネルの設定」BOFの問題文[GOALS-TUN]前の仕事に合理的なポインタ。
The authors would like to acknowledge the work and support of Dr Jianping Wu of Tsinghua university.
著者は、清華大学の博士ジアンピング・ウの仕事と支援を承認したいと思います。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]デュラン、A.、ファザーノ、P.、Guardini、I.、およびD.レント、 "IPv6のトンネルブローカー"、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア、RFC 3056、2001年2月 "のIPv4クラウドを介したIPv6ドメインの接続"。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]オーラ、T.、 "暗号的に生成されたアドレス（CGA）"、RFC 3972、2005年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213] Nordmarkと、E.とR.ギリガン、 "IPv6ホストとルータのための基本的な変遷メカニズム"、RFC 4213、2005年10月。
[GOALS-TUN] Palet, J., "Goals for Tunneling Configuration", Work in Progress, February 2005.
[GOALS-TUN] Palet、J.、 "トンネリングの設定のための目標"、進歩、2005年2月に作業。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O.とR. Droms、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[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月。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006.
[RFC4365]ローゼン、E.、 "BGP / MPLS IP仮想プライベートネットワーク（VPN）のための適用性に関する声明"、RFC 4365、2006年2月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891] Graveman、R.、パルタサラティ、M.、Savola、P.、およびH. Tschofenig、RFC 4891、2007年5月の "IPv6インIPv4トンネルを保護するためにIPsecを使用します"。
[SERVICE-DIS] Durand, A., "Service Discovery using NAPTR records in DNS", Work in Progress, October 2004.
[SERVICE-DIS]デュラン、A.、 "DNSにNAPTRレコードを使用してサービスディスカバリー"、進歩、2004年10月に作業。
[SUBNET] Johnson, R., "Subnet Allocation Option", Work in Progress, June 2007.
[サブネット]ジョンソン、R.、「サブネット割り当てオプション」、進歩、2007年6月に作業。
[TUN-AD] Palet, J. and M, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005.
[TUN-AD] Palet、J.およびM、 "IPv6のトンネルエンドポイント発見メカニズムの解析"、進歩、2005年1月での作業。
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress, February 2007.
[USEIPSEC] Bellovin氏、S.、 "IPsecのの使用を義務付けるためのガイドライン"、進歩、2007年2月での作業。
Authors' Addresses
著者のアドレス
Xing Li (editor) CERNET Room 225 Main Building, Tsinghua University Beijing, 100084 China
興李（エディタ）CERNETルーム225本館、清華大学、北京、100084中国
Phone: +86 10 62785983 Fax: +86 10 62785933 EMail: xing@cernet.edu.cn
電話：+86 10 62785983ファックス：+86 10 62785933 Eメール：xing@cernet.edu.cn
Spencer Dawkins (editor) Huawei Technologies (USA) 1700 Alma Drive, Suite 100
スペンサー・ドーキンス（エディタ）華為技術（USA）1700アルマドライブ、スイート100
Plano, TX 75075 US
プラノ、TX 75075米国
Phone: +1 972 509 0309 Fax: +1 469 229 5397 EMail: spencer@mcsr-labs.org
電話：+1 972 509 0309ファックス：+1 469 229 5397 Eメール：spencer@mcsr-labs.org
David Ward (editor) Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US
デビッド・ウォード（編集者）、シスコシステムズ170 W.タスマン博士はカリフォルニア州サンノゼ95134米国
Phone: 1-408-526-4000 EMail: dward@cisco.com
電話：1-408-526-4000 Eメール：dward@cisco.com
Alain Durand (editor) Comcast 1500 Market St Philadelphia, PA 19102 US
アラン・デュラン（エディタ）Comcastの1500年の市場セント、フィラデルフィア、PA 19102米国
EMail: alain_durand@cable.comcast.com
メールアドレス：alain_durand@cable.comcast.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。