[要約] RFC 4925は、IPv4とIPv6の間の接続を提供するソフトワイヤ技術の問題を説明しています。このRFCの目的は、ソフトワイヤ技術の課題を明確にし、解決策の開発を促進することです。
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
Softwireの問題ステートメント
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）The IETF Trust（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.
このドキュメントは、IPv6のみのネットワーク全体にIPv4ネットワークを接続するための発見、制御、およびカプセル化方法の標準を開発しているSoftwiresワーキンググループの問題ステートメントをキャプチャします。標準は、選択した「IPv4/IPv6」および「IPv6/IPv4」遷移問題のセットを解決するために、既存の標準プロトコルを特定し、必要に応じて拡張することにより、複数の運用可能なベンダーの実装を促進します。このドキュメントでは、ソフトウェアワーキンググループによって開発された基準によって解決される特定の問題（「ハブとスポーク」と「メッシュ」）について説明します。特定の問題の範囲をよりよく説明するために、いくつかの要件（および非追跡）も特定されています。
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:
ソフトワイヤワーキンググループは、IPv6のみのネットワークとIPv4のみのネットワーク全体でIPv4のみのネットワークを接続するための発見、制御、およびカプセル化方法の標準化を指定しており、複数の運用可能なベンダーの実装を促進する方法で指定しています。このドキュメントでは、ソフトウェアワーキンググループによって開発された基準によって解決される特定の問題（「ハブとスポーク」と「メッシュ」）について説明します。特定の問題の範囲をよりよく説明するために、いくつかの要件（および非追跡）も特定されています。いくつかの一般的な仮定が前にリストされています：
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のみのアプリケーションの両方に対応するために、両方のプロトコルファミリをサポートすることがよくあります。グローバルな到達可能性には、両方の住所ファミリをサポートしていないネットワークの一部を越えてトランジットするためのソフトワイヤ接続の確立が必要です。一方または両方の対処ファミリーをサポートする広いエリアネットワークは、すべての住所ファミリをサポートしていないトランジットネットワークによって分離される場合があります。両方の住所ファミリのグローバルな到達可能性を確立するには、ソフトワイヤーの接続が必要です。
o Softwires are to be used in IP-based networks to forward both unicast and multicast traffic.
o ソフトウェアは、IPベースのネットワークで使用され、ユニキャストとマルチキャストの両方のトラフィックを転送します。
o Softwires are assumed to be long-lived in nature.
o ソフトウェアは、本質的に長寿命であると想定されています。
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).
o ソフトウェアは長命ですが、ソフトワイヤのセットアップ時間は、顧客の施設機器（CPE）/アドレスファミリーボーダールーター（AFBR）のスタートアップに必要な合計時間のごくわずかな割合になると予想されます。
o The nodes that actually initiate softwires should support dual-stack (IPv4 and IPv6) functionality.
o ソフトウェアを実際に開始するノードは、デュアルスタック（IPv4およびIPv6）機能をサポートする必要があります。
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)),...
o ネットワークスタックの同じレイヤーにおけるソフトワイヤープロトコルと他のホストメカニズムとの関係。考慮すべきメカニズムの例は、トンネルメカニズム、VPN（仮想プライベートネットワーク）、モビリティ、マルチホミング（SHIM6（IPv6のレベル3 SHIM））、...です。
o Operational brittleness introduced by softwire, e.g., potential single point of failure or difficulties to deploy redundant systems.
o Softwireによって導入された運用上のbrittleness、たとえば、冗長システムを展開するための潜在的な単一の障害または困難の困難。
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).
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「軽量Reachability 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).
o 2005年10月のパリソフトウェア暫定会議では、参加者は全体的な問題スペースを2つの別々の「サブ問題」に分割して、ネットワークトポロジに基づいて解決しました。これらの2つの問題は、「ハブとスポーク」（セクション2で説明）および「メッシュ」（セクション3で説明）と呼ばれます。
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 "島"によって管理される接続と関連するルートの数です。「ハブとスポーク」は、1つの接続と関連する静的デフォルトルートで特徴付けられ、「メッシュ」は複数の接続とルーティングプレフィックスによって特徴付けられます。一般に、2つはホストまたはLAN接続およびネットワーク（またはVPN）接続の問題に分類できます。マルチアドレスファミリーネットワーキングの歴史を見ると、2つのシナリオの明確な描写は明確に示されることはありませんでしたが、現在はネットワークの規範であり、両方を解決する必要があります。その後、ワークグループ（WG）の溶液段階で、これらの問題は関連するが別々の問題スペースとして扱われます。可能な場合は、同様のプロトコルとメカニズムが使用されますが、必要に応じて、各特定の問題スペースの要件を満たすために必要な場合に選択できます。
Address Family (AF) - IPv4 or IPv6. Presently defined values for this field are specified in http://www.iana.org/assignments/address-family-numbers.
アドレスファミリー（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.
アドレスファミリーボーダールーター（AFBR） - 異なるアドレスファミリを使用する2つのネットワークを相互接続するルーター。
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） - このドキュメントの範囲の下で、これはサブスクライバーの施設にあるターミナルと関連する機器、および内部配線を指し、境界点（「DeMarc」）のキャリアの通信チャネルと接続されています。DEMARCは、電話、ケーブル、またはその他のサービスプロバイダー機器から顧客機器を分離するために、建物または複合施設に確立されたポイントです。CPEは、アクセスネットワークの特定の特性に応じて、ホストまたはルーターにすることができます。IPv4のDEMARCポイントは、IPv6のDEMARCポイントと同じである場合と同じである場合があります。したがって、IPv4とIPv6または2つの別々のCPEボックスが1つのCPEボックス、IPv4には1つ、IPv6用の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.
ホームゲートウェイ - ホームネットワークをプロバイダーネットワークに接続する既存の機器。通常、片方または両方の対処ファミリーの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 Concentrator (SC) - The node terminating the softwire in the service provider network.
Softwire concencorator（SC） - サービスプロバイダーネットワークのソフトワイヤーを終了するノード。
Softwire Initiator (SI) - The node initiating the softwire within the customer network.
Softwire Initiator（SI） - 顧客ネットワーク内でソフトワイヤーを開始するノード。
Softwire Transport Header AF (STH AF) - the address family of the outermost IP header of a softwire.
Softwire Transport Header AF（STH AF） - ソフトワイヤの最も外側の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 Payload Header AF（SPH AF） - ソフトワイヤ内で運ばれているIPヘッダーのアドレスファミリ。（たとえば）トンネルがソフトワイヤーに運ばれている場合、IPヘッダーの追加の「レベル」が存在する可能性があることに注意してください。SPHAFの重要な属性は、ソフトワイヤ内に直接カプセル化され、ソフトワイヤーのエンドポイントが決定の基盤を基にすることです。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のみのアクセスネットワーク（STH）を介したIPv6接続。Softwire Initiatorは、デュアルスタックであるホストCPE（モデムに直接接続されています）です。他のゲートウェイデバイスはありません。IPv4トラフィックは、ソフトワイヤーを横断してはなりません。
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のみのアクセスネットワーク（STH）を介したIPv6接続。Softwireイニシエーターは、デュアルスタックデバイスであるルーターCPEです。IPv4トラフィックは、ソフトワイヤーを横断してはなりません。
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のみのアクセスネットワーク（STH）を介したIPv6接続。CPEはIPv4のみです。Softwire Initiatorはホストであり、IPv6ホストCPEとして機能します。IPv4トラフィックは、ソフトワイヤーを横断してはなりません。
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のみのアクセスネットワーク（STH）を介したIPv6接続。ルーティングCPEはIPv4のみです。Softwire Initiatorは、ホームネットワーク内のIPv6 CPEルーターとして機能するデバイスです。IPv4トラフィックは、ソフトワイヤーを横断してはなりません。
Figure 4: Case 4
図4：ケース4
The converse cases exist, replacing IPv4 by IPv6 and vice versa in the above figures.
逆のケースが存在し、上記の数値ではIPv4をIPv6に置き換え、その逆も同様です。
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).
このシナリオでは、キャリア（または内部ネットワークのキャリアとして機能する大規模なエンタープライズネットワーク）には、特定のパス上の少なくとも1つのデバイスで1つのアドレスファミリのみをサポートするインフラストラクチャがあり、アドレスファミリにバインドされたアプリケーションをサポートしたいお客様がいます。エンドツーエンドをルーティングすることはできません。「交差」しなければならないアドレスファミリは、Softwire Transport HeaderまたはSTH AF（IPv4またはIPv6のいずれか）と呼ばれます。
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).
別のアドレスファミリ（ソフトワイヤーペイロードヘッダーアドレスファミリ、またはSPH AF）にバインドされたアプリケーションをサポートするには、通常、自動化されたトンネルを使用して、仮想デュアルスタックインフラストラクチャ（エンドツーエンド）を確立する必要があります。（ソフトワイヤ）。ネイティブAFを介してネットワークを横断できるトラフィックは、ソフトワイヤーパスを取得することを余儀なくされてはなりません。それ以外の場合は、AFミスマッチのために転送できないトラフィックのみをソフトワイヤー内で転送する必要があります。目標は、ソフトワイヤーコンセントレーター（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つのアドレスファミリのみをサポートするインフラストラクチャ（コア、アクセス）全体で使用されている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) ホームゲートウェイ（DEMARCポイントの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機器は、1つの住所ファミリのみをサポートするために制限される場合があります。多くの場合、それらはデュアルスタックモードで実行するためにそれらをアップグレードすることを嫌がっている、またはアップグレードできない顧客またはキャリアが所有しています（図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ルーターがデュアルスタックモードで実行できない場合、そのCPEルーターの後ろにあるノードによってソフトワイヤーを確立する必要があります。これは、Home Running Softwireソフトウェア（図1または図3）の通常のホストまたは「IPv6ルーター」として機能する専用のハードウェア（図4）によって達成できます。このようなデバイスの設計は非常にシンプルで、物理ネットワークインターフェイスが1つだけ必要です。繰り返しますが、不一致のAFのトラフィックのみが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.
アップグレード可能なCPEルーターの典型的なケースは、既存のIPv4/ NATホームゲートウェイであるため、ソフトワイヤーソリューションは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.
Softwireのセットアップ中にNATまたはPATの存在感を「自動化」するための明示的な要件なしに、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ルーターの背後にソフトワイヤーを確立するノードの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]の動的ホスト構成プロトコルは、ソフトワイヤーを介して実行できる必要があります。
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].
リンクトンネルの両端に割り当てられたローカルアドレスはパケット転送に十分ですが、Tracerouteのような管理目的のために、Globalアドレスは、Stateless Address Auto Configuration [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リンクの後ろに単一のノードが接続されている場合でも、Softwire Concencoratorを防止してA /64プレフィックスを委任するものはありません。
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ソフトワイヤーの場合、アドレスはDHCP [RFC2131]によって提供される可能性があります。IPv4ソフトワイヤーの場合、IPv4プレフィックス[subnet]を委任するためにメカニズムを利用できるようにする必要があります。
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：これは、ソフトウェアと6to4の主な違いの1つです。6to4アドレスは、CPEルーターが新しい外部アドレスを取得するたびに変更されます。ここで、Softwireリンクを介してDHCPV6委任されたプレフィックスが安定する可能性があります。
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.).
「ハブとスポーク」の問題では、ソフトウェアは常に顧客側によって開始されます。したがって、顧客ネットワーク内のソフトワイヤーの端をホストするノードは、Softwire Initiatorと呼ばれます。任意のデュアルスタックノードで実行できます。前述のように、これはCPEアクセスデバイス、元のCPEアクセスデバイスの背後にあるもう1つの専用の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 Initiatatorノードは時間とともに変更される可能性があり、ソフトワイヤーエンドポイントの同じIPアドレスを委任される場合と委任されない場合があります。特に、ソフトウェアは遊牧民の場合（たとえば、さまざまなWi-Fiホットスポットでラップトップを開くユーザー）で動作する必要があります。ここでは、ソフトワイヤーのイニシエーターが元のキャリアネットワークの外側の1つのアドレスファミリの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.
キャリア側では、ソフトワイヤがソフトワイヤーコンセントレーターで終了します。ソフトワイヤーコンセントレーターは、通常、キャリアのデュアルスタックコアに接続されたデュアルスタックルーターです。
A carrier may deploy several softwire concentrators (for example one per POP) for scalability reasons.
キャリアは、スケーラビリティの理由でいくつかのソフトワイヤーコンセントレーター（POPごとに1つ）を展開できます。
Softwire concentrators are usually not nomadic and have stable IP addresses.
ソフトワイヤーコンセントレーターは通常、遊牧民ではなく、安定した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.
住所ファミリの1つが、キャリアのコアに面したインターフェイスでネイティブにサポートされていない場合があります。その後、接続性は他のトンネルによって提供され、潜在的にソフトワイヤーメッシュモデルを使用する必要があります。
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 concencorator機能は、トンネル、プレフィックス、およびアドレスの割り当て、管理の既存の標準に基づいています。ワーキンググループは、これらのプロトコル間のソフトワイヤーコンセントレーターアーキテクチャと相互作用を定義し、プロファイルを推奨する必要があります。これらの推奨事項は、プロバイダーネットワークのソフトウェア濃縮器の分散性の性質と、Core 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イニシエーターは、Softwire ConcentoratorのDNS名または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).
「ハブアンドスポークモデル」では、キャリアは、ハブ（つまり、ソフトワイヤーコンセントレーター）を追加することで、何百万ものソフトワイヤーイニシエーターにソリューションをスケーリングできる必要があります。
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.
ソフトウェアはマルチキャストをサポートする必要があります。
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ソリューションと統合できる必要があります（ただし、これらの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.
ソフトワイヤーコントロールおよび/またはデータプレーンは、必要に応じて完全なペイロードセキュリティ（IPSECやSSL（セキュアソケットレイヤー）など）を提供できる必要があります。この追加の保護は、ソフトワイヤーメカニズム自体のトンネルの側面から分離可能でなければなりません。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.
ソフトワイヤーが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は、「ハブとスポーク」ソフトウェアの重要なパスにあります。この仕様で明示的に言及されているものを超えて、追加のカプセルに制限を設ける意図はありません。
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トランジットネットワークを使用しないIPv4パケットが取ることができる他のパスがあるかもしれません（またはそうでないかもしれません）。選択された実際のパスは、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をサポートするAFBRは、BGPを使用してAF1ルーティング情報を自分自身の間で交換しますが、そのような情報は他のコアルーターに配布されません。AFBRは、コアノードと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分配されたルーティングアップデートにより、特定のAFBR1たとえばAFBR1が、特定のAF1アドレスのプレフィックスのパスが2番目の状態であることを確認できるようにすることです。AFBR、AFBR2、および（b）AFBR1がAF2のみのコアを介してAFBR2にAF1パケットを送信できる方法を提供する。もちろん、AF2のみのコアを介してAF1パケットを送信するには、AF1パケットをカプセル化し、「トンネル」から送信する必要があります。これらのトンネルは、「ソフトワイヤ」として知られるエンティティです。
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.
メッシュの問題の目標の1つは、AFBR以外のルーターの変更を必要としないソリューションを提供することです。これにより、AF2のみのバックボーンを備えたキャリア（または内部リソースのキャリアとして機能する大規模なエンタープライズネットワーク）が、クライアントにAF1トランジットサービスを提供することができます。コアルーター。AFBRは、デュアルスタック操作を実行する唯一のデバイスであり、ソフトワイヤでそれらを送信および/または受信するために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は、RFC 4364の「プロバイダーエッジルーター」（PE）に対応しています。これらのL3VPNシナリオでは、PES交換ルーティング情報が住所ファミリー（例：VPN-IPV4アドレスファミリ）ですが、VPNデータパケットを送信します。VPNルーティング情報がないコア。ただし、ソフトワイヤーの問題は、ボーダールーターが複数のプライベートおよび/または重複するアドレススペースを維持する状況に焦点を合わせていません。複数のアドレススペースをサポートするために特に必要な技術は、ソフトウェアのドメインではなく、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でない場合、ルーティング情報の量に関連するスケーリングの問題は、インターネットトランジットサービスを提供しているネットワークのボーダールーターが直面する通常のスケーリングの問題にすぎません。（AFBRが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.
AFBRはお互いを発見し、ルーティング情報の交換の副産物として、お互いに関する必要な情報を取得する可能性があります（本質的には、PEルーターがL3VPNで互いに発見されるのと同じ方法で）。これには、既存のプロトコルに新しいプロトコル要素または属性を追加する必要がある場合があります。
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から別のAFBRに送信できるようにするために必要なソフトウェアは、「常に利用可能」である必要があります。つまり、データパケットにかなりの遅延を与える延長セットアップ時間は必要ありません。
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コアがネイティブマルチキャストサービスを提供していない場合、AFBRでの複製とソフトウェアを介した複製パケットのユニキャストが必要な場合でも、AF1クライアントネットワーク間のマルチキャストはまだ可能です。ネイティブマルチキャストサービスが有効になっている場合、これらのサービスを使用してマルチキャストフローを最適化することができるはずです。
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-in-IP、MPLS（LDPベース、RSVP-TEベース）、ジェネリックルーティングカプセル化（GRE）、およびIPSEC。カプセル化の選択はポリシーに基づいており、ポリシー自体は、パケット、ルート、またはソフトワイヤーのエンドポイント自体のさまざまな特性に基づいている可能性があります。
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ソリューションはIPSECをサポートする必要があり、IPSECプロファイルを定義する必要があります（[USEIPSEC]の推奨事項を参照）。
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
Xing Li Cernet Room 225本館、Tsinghua University Beijing 100084 China
Phone: +86 10 62785983
Fax: +86 10 62785933
Email: xing@cernet.edu.cn
Alain Durand Comcast 1500 Market st Philadelphia PA 19102 USA
Alain Durand Comcast 1500 Market St Philadelphia PA 19102 USA
Email: Alain_Durand@cable.comcast.com
Shin Miyakawa NTT Communications 3-20-2 TOC 21F, Nishi-shinjuku, Shinjuku Tokyo Japan
Shin Miyakawa NTT Communications 3-20-2 TOC 21F、西shinjuku、東京島日本
Phone: +81-3-6800-3262 Fax: +81-3-5365-2990 Email: miyakawa@nttv6.jp Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain
電話：81-3-6800-3262ファックス：81-3-5365-2990メール：miyakawa@nttv6.jp Jordi Palet Martinez Martinez Martinez San Jose Artesano、1 Alcobendas-Madrid E-28108-Spain
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
Florent Parent Hexago 2875 boul. Laurier, suite 300 Sainte-Foy, QC G1V 2M2 Canada
Florent Parent Hexago 2875 Boul。ローリエ、スイート300セントフォイ、QC G1V 2M2カナダ
Phone: +1 418 266 5533
Email: Florent.Parent@hexago.com
David Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA
David Ward Cisco Systems 170 W. Tasman Dr. San Jose、CA 95134 USA
Phone: +1-408-526-4000
Email: dward@cisco.com
Eric C. Rosen Cisco Systems 1414 Massachusetts Avenue Boxborough, MA, 01716 USA
エリックC.ローゼンシスコシステム1414マサチューセッツアベニューボックスボロー、マサチューセッツ州、01716 USA
Email: 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.
著者は、このドキュメントの以前のバージョンで有益な入力を提供した以下の貢献者に、Alain Baudot、Hui Deng、Francis Dupont、Rob Evans、Ed Koehler JR、Erik Nordmark、Soohong Daniel Park、Tom Pusateri、Pekka Savola、BrunoStevant、Laurent Totain、Bill Storer、Maria（Alice）Dos Santos、Yong Cui、Chris Metz、Simon Barber、Skip Booth、Scott Wainner、Carl Williams。
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).
著者はまた、フランスのパリで開催されたソフトワイヤの暫定会議の参加者（2005年10月11〜12日）に感謝したいと思います（議事録はhttp://bgp.nu/~dward/softwires/interimeetingminutes.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.
著者はまた、マーク・タウンズリーに特別な承認を表明したいと思います。彼のリーダーシップ、粘り強さ、編集スキル、およびドキュメントの徹底的な提案がなければ、私たちは成功していなかったでしょう。
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問題ステートメント[目標-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のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 3041、2001年1月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore、「IPv4 Cloudsを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[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. Gilligan、「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] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、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.、Ed。、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364] Rosen、E。およびY. Rekhter、「BGP/MPLS IP仮想プライベートネットワーク（VPNS）」、RFC 4364、2006年2月。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006.
[RFC4365] Rosen、E。、「BGP/MPLS IP仮想ネットワーク（VPNS）のアプリケーションステートメント」、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.、Parthasarathy、M.、Savola、P。、およびH. Tschofenig、「IPSECを使用してIPv6-in-IPV4トンネルを保護する」、RFC 4891、2007年5月。
[SERVICE-DIS] Durand, A., "Service Discovery using NAPTR records in DNS", Work in Progress, October 2004.
[Service-Dis] Durand、A。、「DNSでNAPTRレコードを使用したサービス発見」、2004年10月、進行中の作業。
[SUBNET] Johnson, R., "Subnet Allocation Option", Work in Progress, June 2007.
[Subnet] Johnson、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
Xing Li（編集者）Cernet Room 225本館、Tsinghua University Beijing、100084 China
Phone: +86 10 62785983
Fax: +86 10 62785933
EMail: xing@cernet.edu.cn
Spencer Dawkins (editor) Huawei Technologies (USA) 1700 Alma Drive, Suite 100
スペンサードーキンス（編集者）Huawei Technologies（USA）1700 Alma Drive、Suite100
Plano, TX 75075 US
テキサス州プラノ75075 US
Phone: +1 972 509 0309
Fax: +1 469 229 5397
EMail: spencer@mcsr-labs.org
David Ward (editor) Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US
David Ward（編集者）Cisco Systems 170 W. Tasman Dr. San Jose、CA 95134 US
Phone: 1-408-526-4000 EMail: dward@cisco.com
電話：1-408-526-4000メール：dward@cisco.com
Alain Durand (editor) Comcast 1500 Market St Philadelphia, PA 19102 US
Alain Durand（編集者）Comcast 1500 Market St Philadelphia、PA 19102 US
EMail: alain_durand@cable.comcast.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。