RFC4925 日本語訳
4925 Softwire Problem Statement. X. Li, Ed., S. Dawkins, Ed., D. Ward,Ed., A. Durand, Ed.. July 2007. (Format: TXT=49299 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
ワーキンググループのX.李、エドをネットワークでつないでください。コメントのために以下を要求してください。 4925年のCERNETカテゴリ: エドエドHuawei D.区、シスコシステムズA.ジュランドエド情報のS.ダウキンズ、コムキャスト2007年7月
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).
IETFが信じる著作権(C)(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.
このドキュメントはSoftwires作業部会のために問題声明を得ます。(それは、接続IPv4ネットワークのためにIPv4だけネットワークの向こう側のIPv6ネットワークと同様にIPv6だけネットワークの向こう側に発見、コントロール、およびカプセル化方法の規格を開発しています)。 そして、規格は特定と、必要であるところに広がることによって、複数の、そして、共同利用できる業者実現を奨励するでしょう、選択されたセットを決議する既存の標準プロトコル、「IPv4/IPv6"、「IPv6/IPv4"変遷問題このドキュメントが特定の問題について説明する、(「ハブとスポーク、」 「メッシュ」) それがSoftwires作業部会によって開発された規格によって解決される、」 また、いくつかの要件(そして、非要件)が、特定の問題範囲について、よりよく説明するために特定されます。
Li, et al. Informational [Page 1] RFC 4925 Softwire Problem Statement July 2007
李、他 [1ページ]情報のRFC4925Softwire問題声明2007年7月
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1。 用語. . . . . . . . . . . . . . . . . . . . . . . 4 2。 ハブとスポーク問題. . . . . . . . . . . . . . . . . . . 6 2.1 記述. . . . . . . . . . . . . . . . . . . . . . . 8 2.2。 非Upgradable CPEルータ. . . . . . . . . . . . . . . . 9 2.3。 アドレス変換(NAT)とポートアドレス翻訳(軽くたたくこと). . . . . . . . . . . . . . . . . . . . 10 2.4をネットワークでつないでください。 静的な接頭語代表団. . . . . . . . . . . . . . . . . 10 2.5。 Softwire創始者. . . . . . . . . . . . . . . . . . . . 11 2.6。 Softwire集中装置. . . . . . . . . . . . . . . . . . 11 2.7。 Softwire集中装置発見. . . . . . . . . . . . . 12 2.8。 スケーリング. . . . . . . . . . . . . . . . . . . . . . . . . 12 2.9。 ルート設定. . . . . . . . . . . . . . . . . . . . . . . . . 12 2.10。 マルチキャスト. . . . . . . . . . . . . . . . . . . . . . . . 12 2.11。 セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . . 12 2.11.1。 認証、認可、および会計(AAA). . . . . . . . . . . . . . . . . . . . . . . . 12 2.11.2。 プライバシー、保全、および反復操作による保護. . . . . . 13 2.12。 操作と管理(OAM。). . . . . . . . . . . . . 13 2.13 カプセル化. . . . . . . . . . . . . . . . . . . . . . 13 3。 問題. . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1を網の目にかけてください。 記述. . . . . . . . . . . . . . . . . . . . . . . 14 3.2。 スケーリング. . . . . . . . . . . . . . . . . . . . . . . . . 16 3.3。 固執、発見、および準備時間. . . . . . . . . . 16 3.4。 マルチキャスト. . . . . . . . . . . . . . . . . . . . . . . . 17 3.5。 Softwireカプセル化. . . . . . . . . . . . . . . . . . 17 3.6。 セキュリティ. . . . . . . . . . . . . . . . . . . . . . . . . 17 4。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 18 5。 校長は.186を書きます。 貢献者. . . . . . . . . . . . . . . . . . . . . . . . . 19 7。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.1。 引用規格. . . . . . . . . . . . . . . . . . . 20 7.2。 有益な参照. . . . . . . . . . . . . . . . . . 20
Li, et al. Informational [Page 2] RFC 4925 Softwire Problem Statement July 2007
李、他 [2ページ]情報のRFC4925Softwire問題声明2007年7月
1. Introduction
1. 序論
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の接続性を設立に要求します。 1つを支持する広域ネットワークかアドレス家族の両方がすべてのアドレス家族を養うというわけではない輸送網によって切り離されるかもしれません。 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).
o Softwiresは長命ですが、softwireの準備時間はCustomer Premise Equipment(CPE)/アドレスFamily Border Router(AFBR)の始動に必要である合計時の非常にわずかな部分であると予想されます。
o The nodes that actually initiate softwires should support dual-
stack (IPv4 and IPv6) functionality.
o 実際にsoftwiresを開始するノードは二元的なスタック(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 ネットワークスタックの同じ層の他のホストメカニズムへのsoftwireプロトコルの関係。 考えるメカニズムに関する例はトンネリングメカニズム、VPNs移動性、マルチホーミング(SHIM6(レベル3 IPv6のためのShim))です(仮想の兵士のNetworks)…
Li, et al. Informational [Page 3] RFC 4925 Softwire Problem Statement July 2007
李、他 [3ページ]情報のRFC4925Softwire問題声明2007年7月
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).
o 輸送へのsoftwiresの効果は層にされます。 QoS(Serviceの品質)のパケット損失、輻輳制御、および取り扱いのように、経路の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 IETF63「軽量の可到達性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月のパリのSoftwiresの当座のミーティングでは、関係者は全体的な問題スペースを解決するネットワーク形態に基づく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「島」によって管理されるかということです。 「ハブとSpokes」は1つの接続と関連静的なデフォルトルートで特徴付けられます、そして、「メッシュ」は複数の接続とルーティング接頭語によって特徴付けられます。 一般に、ホストかLANの接続性とネットワーク(または、VPN)接続性問題として2を分類できます。現在それらはネットワーク標準です、そして、マルチアドレス家族ネットワークの歴史を調べて、2つのシナリオのはっきりとした輪郭は明確に決して例証されませんでしたが、両方を解決しなければなりません。 その後、Work Group(WG)の解決策段階の間これらの問題は関係づけられるように扱われるでしょうが、分離してください、問題空間。 それぞれに関する必要条件を満たすのに必要であるときに、問題スペースを考えて、可能な、しかし、異なったプロトコルとメカニズムが選択されるとき、同様のプロトコルとメカニズムは使用されるでしょう。
1.1. Terminology
1.1. 用語
Address Family (AF) - IPv4 or IPv6. Presently defined values for this field are specified in
家族(AF)を記述してください--IPv4かIPv6。 この分野への現在定義された値では、指定されます。
Li, et al. Informational [Page 4] RFC 4925 Softwire Problem Statement July 2007
李、他 [4ページ]情報のRFC4925Softwire問題声明2007年7月
http://www.iana.org/assignments/address-family-numbers.
http://www.iana.org/assignments/address-family-numbers 。
Address Family Border Router (AFBR) - The router that interconnects two networks that use different address families.
Family Border Router(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.
このドキュメントの範囲の下の顧客Premise Equipment(CPE)、これは加入者の構内に位置していて、画定ポイントでキャリヤーの通信チャネルに接続された端末の、そして、関連している設備と内面の配線("「反-しぼりかす」")を示します。 「反-しぼりかす」は電話、ケーブル、または他のサービスプロバイダー設備と顧客設備を切り離すためにビルか複合体に確立されたポイントです。 アクセスネットワークの特定の特性によって、CPEはホストかルータであるかもしれません。 IPv4のための「反-しぼりかす」のポイントがIPv6のための「反-しぼりかす」のポイントと同じであるかもしれない、その結果、IPv4とIPv6の代理をする1個のCPE箱か2つの別々のものと、IPv4のためのものとIPv6のための1つがあることができます。
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終点の間の制御プロトコルセットアップに基づいて多点から共有されたポイントからポイントかポイントへの状態で作成される「トンネル。」 Softwiresは一般に現実にダイナミックですが(彼らは、要求に応じて開始されて、終えられるかもしれません)、非常に長命であるかもしれません。
Softwire Concentrator (SC) - The node terminating the softwire in the service provider network.
Softwire Concentrator(サウスカロライナ)--サービスプロバイダーネットワークでsoftwireを終えるノード。
Softwire Initiator (SI) - The node initiating the softwire within the customer network.
Softwire Initiator(SI)--顧客ネットワークの中でsoftwireを開始するノード。
Softwire Transport Header AF (STH AF) - the address family of the outermost IP header of a softwire.
Softwire Transport Header 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有効搭載量Header AF(SPH AF)--softwireの中で運ばれるIPヘッダーのアドレス家族。 (例えば)トンネルがsoftwireの上まで運ばれるなら追加「レベル」のIPヘッダーが出席しているかもしれないことに注意してください--SPH AFの主要な属性はそれがsoftwireの中で直接要約されて、パケットがsoftwireを出ているときsoftwire終点が推進決定をSPH AFに基礎づけるということです。
Subsequent Address Family (SAF) - Additional information about the type of Network Layer Reachability Information (e.g., unicast or multicast).
その後のAddress Family(SAF)--Network Layer Reachability情報(例えば、ユニキャストかマルチキャスト)のタイプに関する追加情報。
Li, et al. Informational [Page 5] RFC 4925 Softwire Problem Statement July 2007
李、他 [5ページ]情報のRFC4925Softwire問題声明2007年7月
2. Hubs and Spokes Problem
2. ハブとスポーク問題
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]で説明されるように)はいくつかの状況で十分な変遷メカニズムであるかもしれません。 他の解決法がしかしながら、Network Address Translation(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
+-------+ +------------+ +--------+ | | |Softwire| | IPv6| +---------+ | IPv4|--|集中装置|--| ネットワーク|=>インターネット|v4/v6|--| | +------------+ +--------+ |ホストCPE| | | +---------+ |ネットワーク| +-------+ _ _ _ _ _ _ __ ()_ _ _ _ _ _ __() IPv6 SPH "softwire" |--------------||-------------------------| IPv4だけIPv6かデュアルスタック
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創始者はホストCPE(直接モデムに接続される)です(デュアルスタックです)。 他のゲートウェイ装置は全くありません。 IPv4交通はsoftwireを横断するべきではありません。
Figure 1: Case 1
図1: ケース1
Li, et al. Informational [Page 6] RFC 4925 Softwire Problem Statement July 2007
李、他 [6ページ]情報のRFC4925Softwire問題声明2007年7月
+-------+ +-------------+ +--------+
| | | 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
+-------+ +-------------+ +--------+ | | | Softwire| | v6| +-----+ +------+ | v4|--| 集中装置|--| ネットワーク|=>インターネット|v4/v6|--|v4/v6|--| | +-------------+ +--------+ |ホスト| |ルータ| |ネットワーク| +-----+ |v4/v6| | | | CPE| +-------+ +------+ _ _ _ _ _ _ __ ()_ _ _ _ _ _ __() IPv6 SPH "softwire" |--------------||--------------||-------------------------| デュアルスタックIPv4だけIPv6かデュアルスタック
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です。(その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
+-------+ +-------------+ +--------+ | | | Softwire| | v6| +------+ +------+ | v4|--| 集中装置|--| ネットワーク|=>インターネット|v4/v6|--|v4|--| | +-------------+ +--------+ |ホスト| |ルータ| |ネットワーク| |v6 CPE| |v4 CPE| | | +------+ | | +-------+ +------+ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH "softwire" |-----------------------||-------------------------| IPv4、唯一のIPv6かデュアルスタック
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創始者はホストです。(IPv6としてのその行為はそのホストのためにCPEを接待します)。 IPv4交通はsoftwireを横断するべきではありません。
Figure 3: Case 3
図3: ケース3
Li, et al. Informational [Page 7] RFC 4925 Softwire Problem Statement July 2007
李、他 [7ページ]情報のRFC4925Softwire問題声明2007年7月
+-----+
|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
+-----+ |v4/v6| +-------+ +------------+ +-------+ |ホスト| | | |Softwire| | v6| +-----+ +------+ | v4|--|集中装置|--|ネットワーク|=>インターネット| |v4|--| | +------------+ +-------+ |---------|ルータ| |ネットワーク| | |v4 CPE| +-------+ +---------+ +------+ |Softwire| |創始者| |v6 Router| | CPE| +---------+ _ _ _ _ _ _ _ _ _ _ _ _ ()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH "softwire" |--------||-----------------------||----------------------| IPv6かデュアルスタックだけが積み重ねる二元的なIPv4
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創始者は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.
上図でIPv4をIPv6に逆もまた同様に取り替えて、逆ケースは存在しています。
2.1. Description
2.1. 記述
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
もう1アドレス家族(Softwire有効搭載量Header Address Family、またはSPH AF)に縛られたアプリケーションを支持するために、仮想のデュアルスタックインフラストラクチャを確立するのが必要です(終わるには、終わってください)、通常自動的に確立したトンネル(Softwires)による。 ネイティブのAFを通してネットワークを横断できる交通はやむを得ずsoftwire経路を取ってはいけません。 そうでなければAFミスマッチのため進めることができない唯一の交通はそうであるべきです。
Li, et al. Informational [Page 8] RFC 4925 Softwire Problem Statement July 2007
李、他 [8ページ]情報のRFC4925Softwire問題声明2007年7月
forwarded within the softwire. The goal is to avoid overwhelming the softwire concentrator (SC).
softwireの中で進めます。 目標はsoftwire集中装置(サウスカロライナ)を圧倒するのを避けることです。
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).
ネットワーク・オペレータは、方針理由(すなわち、ネットワークにおける交通がアドレス家族のひとりに優位である、単独のアドレス家族はOperationsとManagement(OAM)費用などを下ろすのに使用される)か技術的な理由で1かこのインフラストラクチャのいくつかの部分で単独のアドレス家族を可能にするのを選ぶかもしれません(すなわち、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) 家のゲートウェイ(「反-しぼりかす」のポイントでのCPEルータの、または、他の設備)、容易に、両方のアドレス家族を養うためにアップグレードできません。 この理由は、通常、アドレス家族のひとりの業者サポート、アップグレードを行わない商業の、または、操作上の理由の不足(すなわち、操作上の変化、そして/または、費用は、何百万ユニットにもターンできるすべての顧客のためにキャリヤーによってサポートされる必要があるかもしれない)、またはCPEルータを変えるか、またはアップグレードさせるという顧客不本意(費用、「壊れていなくて、そうはそれを変えない」)です。 また、CPEルータの系統的なアップグレードの実行不可能がIPv4ネットワークにおける、6to4のベースの解決策[RFC3056]の展開を妨げていることに注意してください。
2.2. Non-Upgradable CPE Router
2.2. 非Upgradable CPEルータ
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
CPEルータがデュアルスタックモードに立候補できないとき、softwireはそのCPEルータの後ろに位置するノードによって設立されなければならないでしょう。 softwireソフトウェアを動かす家のレギュラーのホスト(図1か図3)か「IPv6ルータ」として演じられるひたむきなハードウェア(図4)でこれを達成できます。 そのような装置は、デザインでかなり簡単であり、1つの物理ネットワークしか必要としません。
Li, et al. Informational [Page 9] RFC 4925 Softwire Problem Statement July 2007
李、他 [9ページ]情報のRFC4925Softwire問題声明2007年7月
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.
連結してください。 softwireを通してミスマッチしているAFの交通だけを進めるでしょう。 そうでなければsoftwireなしで進めることができる交通を要約するべきではありません。
2.3. Network Address Translation (NAT) and Port Address Translation
(PAT)
2.3. ネットワーク・アドレス翻訳(NAT)とポートアドレス翻訳(パット)
A typical case of non-upgradable CPE router is a pre-existing IPv4/ NAT home gateway, so the softwire solution must support NAT traversal.
非upgradable CPEルータの典型的なケースが先在のIPv4/NAT家のゲートウェイであるので、softwire解決策は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セットアップの間、明白な要件なしで"autodetect"NATかPAT存在にNATかPATを通してSoftwireを設立するのを支持しなければなりません。 単に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.
トンネリングプロトコルはNATsを横断できなければなりませんが、トンネリングプロトコルには、そうでなければNATを横断しながらUDPカプセル化を迂回させる任意の能力があるかもしれません。
2.4. Static Prefix Delegation
2.4. 静的な接頭語代表団
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での安定したアドレスの登録を考慮して、RFC3041[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]のためのDynamic Host Configuration Protocolは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
softwireリンク自体のIPアドレスは安定している必要はなくて、安定性に関する願望は代表として派遣された接頭語に適用されるだけです。 softwireの後ろで添付されたただ一つのノードがある場合
Li, et al. Informational [Page 10] RFC 4925 Softwire Problem Statement July 2007
李、他 [10ページ]情報のRFC4925Softwire問題声明2007年7月
link, nothing prevents a softwire concentrator to delegate it a /64 prefix.
リンクしてください、そして、何もそれを代表として派遣するsoftwire集中装置を防ぎません。/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 softwireの場合では、DHCP[RFC2131]によってアドレスを提供できました。 IPv4 softwireの場合では、メカニズムは、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に関して以下に注意してください。 これはSoftwiresと6to4の主な違いの1つです。 CPEルータが新しい外部アドレスを得るときはいつも、6to4アドレスは変化して、DHCPv6がどこでsoftwireリンクを通して接頭語を代表として派遣したかは、安定しているかもしれません。
2.5. Softwire Initiator
2.5. Softwire創始者
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創始者ノードは、時間がたつにつれて、変化できて、IPがsoftwire終点に扱う代表として派遣された同じくらいであるかもしれません。 特に、softwiresは遊牧民的な場合(例えば、様々なWi-Fiホットスポットで彼のラップトップを開けるユーザ)で働いているはずです。そこでは、softwire創始者は、潜在的に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接頭語と他のパラメタを変えるべきではありません。
2.6. Softwire Concentrator
2.6. Softwire集中装置
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.
キャリヤーはスケーラビリティ理由で、数個のsoftwire集中装置(例えば、1POPあたり1つ)を配布するかもしれません。
Softwire concentrators are usually not nomadic and have stable IP addresses.
Softwire集中装置は、通常、遊牧民的でなく、安定したIPアドレスを持っています。
Li, et al. Informational [Page 11] RFC 4925 Softwire Problem Statement July 2007
李、他 [11ページ]情報のRFC4925Softwire問題声明2007年7月
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集中装置アーキテクチャと相互作用を定義して、プロフィールを推薦しなければなりません。 これらの推薦はコアIPv6ネットワーク(: 例えば、接頭語集合)のプロバイダーネットワークと影響でSoftwires Concentratorの分配された自然を考慮に入れなければなりません。
2.7. Softwire Concentrator Discovery
2.7. Softwire集中装置発見
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集中装置のDNS名かIPアドレスを知らなければなりません。 自動化された発見フェーズは、集中装置のIPアドレスか名前を返すのに使用されるかもしれません。 あるいはまた、この情報はあらかじめ、ユーザ、またはsoftwire創始者のプロバイダーによって構成されるかもしれません。 このドキュメントの範囲の外にこの発見問題の詳細があって、しかしながら、考慮で前の仕事を取ることができました。 例は: [サービスしてけなします]、[RFC4891]、および[大酒樽AD。]
2.8. Scaling
2.8. スケーリング
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).
「ハブとSpokesモデル」では、キャリヤーは加えるのによるsoftwire創始者の何数百万も、より多くのハブ(すなわち、softwire集中装置)にソリューションについて合わせて調整することができなければなりません。
2.9. Routing
2.9. ルート設定
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.
顧客ネットワークが彼らのキャリヤーへの単一のリンクを通して通常付けられているとき、最小のルーティング要件はアドレスファミリーの各人のためのデフォルトルートです。
2.10. Multicast
2.10. マルチキャスト
Softwires must support multicast.
Softwiresはマルチキャストをサポートしなければなりません。
2.11. Security
2.11. セキュリティ
2.11.1. Authentication, Authorization, and Accounting (AAA)
2.11.1. 認証、承認、および会計(AAA)
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
softwireプロトコルは制御飛行機で顧客に認証をサポートしなければなりません、サービスへのアクセスを認可して、活動(会計)の適切な伐採を提供するために。 しかしながら、a
Li, et al. Informational [Page 12] RFC 4925 Softwire Problem Statement July 2007
李、他 [12ページ]情報のRFC4925Softwire問題声明2007年7月
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.
キャリヤーは、例えば、顧客がある他の手段で既に認証されるときいくつかの事情でそれをオフにすると決めるかもしれません、閉じているネットワーク、セルラー・ネットワークなどのように、不要なオーバーヘッドを避けるために。
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).
少なくとも「ハブとスポーク」において、softwireソリューションは一般的に配布しているAAAソリューションで積分可能であるに違いありません(それらのAAAソリューションへの拡大が必要であるかもしれませんが)。
2.11.2. Privacy, Integrity, and Replay Protection
2.11.2. プライバシー、保全、および反復操作による保護
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 Control、そして/または、Data飛行機は完全なペイロードセキュリティ(IPsecかSSL(Secure Socket Layer)などの)を提供できなければなりません。 この追加保護はsoftwireメカニズム自体のトンネリング局面から分離できるに違いありません。 IPsecに関しては、デフォルトプロフィールを定義しなければなりません。 [RFC4891]はこれに関するガイドラインを提供します。
2.12. Operations and Management (OAM)
2.12. 操作と管理(OAM)
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の向こう側に行かなければならないかもしれなくて、keepaliveメカニズムを定義しなければならないと思われるとき。 また、そのようなメカニズムも死んでいる同輩検出の役に立ちます。 しかしながら、いくつかの事情(すなわち、狭帯域アクセス、1トラフィックあたりの支払いなど)では、keepaliveメカニズムが不要な帯域幅を消費するかもしれないので、管理オプションであるとそれをつけたり消したりして、周期性を変更するのをサポートしなければなりません。
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)
- 経路失敗検出(検出メカニズムはトンネルの外で動作しなければなりません)
2.13. Encapsulations
2.13. カプセル化
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のためのクリティカルパスにあります。 この仕様で明らかに言及されたものを超えて追加カプセル化に限界を置くという意志が全くありません。
Li, et al. Informational [Page 13] RFC 4925 Softwire Problem Statement July 2007
李、他 [13ページ]情報のRFC4925Softwire問題声明2007年7月
3. Mesh Problem
3. メッシュ問題
3.1. Description
3.1. 記述
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.
以下の図は、AF2だけネットワークがAF1だけネットワーク、AF2だけネットワーク、およびデュアルスタックネットワークに接続したのを示します。 また、AF2だけコアを通した経路に加えて他の経路がAF1ネットワークの間に存在するかもしれないことに注意してください。 AF1をサポートするAFBRsは自分たちの間でAF1ルーティング情報を交換するのにBGPを使用するでしょうが、そのような情報は他のコアルータに分配されないでしょう。 また、AFBRsはコアノードによるAF2ルーティング情報の交換に参加するでしょう。
Li, et al. Informational [Page 14] RFC 4925 Softwire Problem Statement July 2007
李、他 [14ページ]情報のRFC4925Softwire問題声明2007年7月
+----------+ +----------+
|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 |
+--------+ +--------+
+----------+ +----------+ |AF1専用| |AF1専用| | | | | +----------+ +----------+ | | | | デュアルスタックデュアルスタック"AFBR""AFBR"| | | | +----------------------------+ | | +-------+ | | +-------+ |AF2| | AF2専用| |AF2| |唯一|-------| (また、提供しています|、-、-、-、-、-、--、| | +だけ、-、-、-、-、-、--、+| AF1のためにトランジットになってください) | +-------+ | | +----------------------------+ | / \ | | / \ | デュアルスタックデュアルスタック"AFBR""AFBR"| | | | | | +--------+ +--------+ |そしてAF1。| |そしてAF1。| |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".
1組の境界ルータがコアルータに知られていないルーティング情報を交換するのにBGPを使用する状況は時々いくらか誤解させて知られています、「無BGPのコア」として。 この種類のシナリオでは、解決するべき問題は(a) (b) 念のため、AF1のためのアップデートが与えられたAFBRを許容するBGPによって分配されたルーティング、AFBR1を言って、第2のAFBRを通して与えられたAF1アドレス接頭語のための経路があることを確認してください、AFBR2が言って、どの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
メッシュ問題の目標の1つはAFBRs以外のどんなルータでも釣り銭がいない解決法を提供することです。 これで、AF2だけバックボーンがあるキャリヤー(または、それらの社内資源のためのキャリヤーとして機能する大企業ネットワーク)はクライアントのためにトランジットサービスをAF1に供給できるでしょう、変化を必要としないで
Li, et al. Informational [Page 15] RFC 4925 Softwire Problem Statement July 2007
李、他 [15ページ]情報のRFC4925Softwire問題声明2007年7月
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はデュアルスタック操作を実行する唯一のデバイスと、softwiresでそれらを送る、そして/または、受けるためにAF1パケットをカプセル化する、そして/または、decapsulateする唯一のデバイスです。
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.
このシナリオがRFC4364[RFC4364]で説明されたLayer3Virtual兵士のNetwork(L3VPN)ソリューションによって扱われたシナリオと非常に同様であると認められるかもしれません。 AFBRsはRFC4364の「プロバイダー縁のルータ」(PE)に対応しています。 それらのL3VPNシナリオでは、PEsはアドレスファミリー(例えば、VPN-IPv4アドレスファミリー)でルーティング情報を交換しますが、彼らは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もコアネットワークに多重連結しているかもしれなくて、また、クライアントネットワークに多重連結しているかもしれないことに注意してください。 さらに、クライアントネットワークは私設のネットワークを通して、または、インターネットを通して「裏口の接続」を互いに持っているかもしれません。
3.2. Scaling
3.2. スケーリング
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は、それが接続する各ネットワークと共に「完全なインターネットのもの」のルーティング情報の価値を交換する必要があるかもしれません。 これらのネットワークがVPNsでないなら、ルーティング情報の量に関連しているスケーリング問題はただインターネットトランジットサービスを提供しているどんなネットワークの境界ルータによっても直面されていた普通のスケーリング問題です。 (また、AFBRsがVPNsに取り付けられるなら、普通のL3VPNスケーリング問題は適用されます、RFC4364[RFC4364]とRFC4365[RFC4365]で議論するように。) 普通のメソッドでBGPじっと見る接続の数を制御できて、例えば、ルートの使用は反射鏡です。
3.3. Persistence, Discovery, and Setup Time
3.3. 固執、発見、および準備時間
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は互いを発見して、互いに関するどんな必要事項も得るかもしれません、ルーティング情報の交換の副産物として(本質的には同じようにそのPEルータ発見、L3VPNsの互い) これは新しいプロトコル要素か属性の追加を既存のプロトコルに必要とするかもしれません。
Li, et al. Informational [Page 16] RFC 4925 Softwire Problem Statement July 2007
李、他 [16ページ]情報のRFC4925Softwire問題声明2007年7月
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.
パケットが1AFBRから別のものに送られるのを許容するのが必要であるsoftwiresは「いつも利用可能であるべきです」、すなわち、かなりの遅れをデータ・パケットに伝える少しの延ばされた準備時間も必要とするべきではありません。
3.4. Multicast
3.4. マルチキャスト
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クライアントネットワークの間のマルチキャストはまだ可能であるべきです、Softwiresを通した模写されたパケットのAFBRsとunicastingのときに模写を必要とするかもしれませんが。 ネイティブのマルチキャストサービスが可能にされるなら、マルチキャスト流動を最適化するのにこれらのサービスを利用するのは可能であるべきです。
3.5. Softwire Encapsulation
3.5. Softwireカプセル化
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.
メッシュ問題への解決はどんなカプセル化の使用も必要としてはいけません。 むしろ、それは、方針に基づくどんな特定の状況にも使用されるためにさまざまな異なったカプセル化メカニズムの使用、およびものを選ぶための手段に対応しなければなりません。
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.
特に、メッシュ問題への解決は、少なくとも以下のカプセル化が使用されるのを許容しなければなりません: 2Tunnelingプロトコルバージョン3(L2TPv3)、IPにおけるIP、MPLS(自由民主党ベースの、そして、RSVP-TEに基づいている)、Genericルート設定Encapsulation(GRE)、およびIPsecを層にしてください。 カプセル化の選択が方針に基づくことであり、方針自体はパケット、ルート、またはsoftwire終点の様々な特性自体に基づくかもしれません。
3.6. Security
3.6. セキュリティ
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ソリューションは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.
仕様の範囲の外に情報が交換した可到達性とルーティング・プロトコル自体のセキュリティを囲む問題の検証があります。
Li, et al. Informational [Page 17] RFC 4925 Softwire Problem Statement July 2007
李、他 [17ページ]情報のRFC4925Softwire問題声明2007年7月
4. Security Considerations
4. セキュリティ問題
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ヘッダーに適用されるだけであるので。
5. Principal Authors
5. 共著の中心となる著者
These are the principal authors for this document.
これらはこのドキュメントのための共著の中心となる著者です。
Xing Li
CERNET
Room 225 Main Building, Tsinghua University
Beijing 100084
China
Xing李CERNET Room225本館、Tsinghua大学中国北京100084
Phone: +86 10 62785983
Fax: +86 10 62785933
Email: xing@cernet.edu.cn
以下に電話をしてください。 +86 10 62785983、Fax: +86 10 62785933はメールされます: xing@cernet.edu.cn
Alain Durand
Comcast
1500 Market st
Philadelphia
PA 19102
USA
アランジュランドコムキャスト1500が売り出される、フィラデルフィアPA19102第米国
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
F、西-shinjuku、向こうずねのMiyakawa NTTコミュニケーション3-20-2TOC21東京日本新宿
Phone: +81-3-6800-3262
Fax: +81-3-5365-2990
Email: miyakawa@nttv6.jp
以下に電話をしてください。 +81-3-6800-3262 Fax: +81-3-5365-2990 メールしてください: miyakawa@nttv6.jp
Li, et al. Informational [Page 18] RFC 4925 Softwire Problem Statement July 2007
李、他 [18ページ]情報のRFC4925Softwire問題声明2007年7月
Jordi Palet Martinez
Consulintel
San Jose Artesano, 1
Alcobendas - Madrid
E-28108 - Spain
ジョルディ殻マルチネスConsulintel1アルコベンダス--マドリードE-28108--Artesano、サンノゼスペイン
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
以下に電話をしてください。 +34 91 151、81 99、Fax: +34 91 151 81 98はメールされます: jordi.palet@consulintel.es
Florent Parent
Hexago
2875 boul. Laurier, suite 300
Sainte-Foy, QC G1V 2M2
Canada
フローランParent Hexago2875boul。 ローリエ、スイート300サントフォア、QC G1V 2M2カナダ
Phone: +1 418 266 5533
Email: Florent.Parent@hexago.com
以下に電話をしてください。 +1 5533年の418 266メール: Florent.Parent@hexago.com
David Ward
Cisco Systems
170 W. Tasman Dr.
San Jose, CA 95134
USA
サンノゼ、デヴィッド区シスコシステムズ170w.タスマン博士カリフォルニア95134米国
Phone: +1-408-526-4000
Email: dward@cisco.com
以下に電話をしてください。 +1-408-526-4000 メールしてください: dward@cisco.com
Eric C. Rosen
Cisco Systems
1414 Massachusetts Avenue
Boxborough, MA, 01716
USA
エリックC.ローゼンシスコシステムズ1414マサチューセッツ通りBoxborough、MA01716米国
Email: erosen@cisco.com
メール: erosen@cisco.com
6. Contributors
6. 貢献者
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.
作者はこのドキュメントの以前のバージョンに関する有用な入力を提供した以下の貢献者を承認したがっています: アランBaudot(ホイ・?、フランシス・デュポン)はエヴァンスから略奪します、エドコーラーJr、エリックNordmark、SoohongダニエルPark、トムPusateri、ペッカSavola、ブルーノStevant、ローランTotain、ビルStorer、マリア・(アリス)のドス・サントス、ヤング・キュイ、クリス・メス、サイモン・バーバー、スキップブース、スコットWainner、およびカール・ウィリアムズ。
Li, et al. Informational [Page 19] RFC 4925 Softwire Problem Statement July 2007
李、他 [19ページ]情報のRFC4925Softwire問題声明2007年7月
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日)でのSoftwiresの当座のミーティングの関係者を承認したがっています(数分が 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に議論中であります。 RFC3053[RFC3053]でsoftwireに関連する初期の仕事は見つけることができます。 「V6トンネル構成」という先への妥当な指針が扱うBOF問題声明[GOALS-TUN]は、より初期です。
The authors would like to acknowledge the work and support of Dr Jianping Wu of Tsinghua university.
作者はTsinghua大学のJianpingウー博士の仕事とサポートを承諾したがっています。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6",
RFC 3041, January 2001.
[RFC3041] NartenとT.とR.Draves、「IPv6"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento,
"IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] ジュランドとA.とファザーノとP.とグァルディーニ、I.とレントのD.「IPv6トンネルのブローカー」、RFC3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6
Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses
(CGA)", RFC 3972, March 2005.
[RFC3972] 香気、T.、「アドレス(CGA)であると暗号で生成された」RFC3972、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ホストとルータのための基本的な変遷メカニズム」、RFC4213、2005年10月。
7.2. Informative References
7.2. 有益な参照
[GOALS-TUN] Palet, J., "Goals for Tunneling Configuration", Work
in Progress, February 2005.
[目標大酒樽] 殻、J.、「トンネリング構成の目標」が進歩、2005年2月に働いています。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2131] Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。
Li, et al. Informational [Page 20] RFC 4925 Softwire Problem Statement July 2007
李、他 [20ページ]情報のRFC4925Softwire問題声明2007年7月
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、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.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、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、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP
Virtual Private Networks (VPNs)", RFC 4365,
February 2006.
[RFC4365]ローゼン、E.、「BGP/MPLS IP仮想私設網(VPNs)のための適用性証明」、RFC4365、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、「IPv4のIPv6にトンネルを固定するのにIPsecを使用する」RFC4891)は2007がそうするかもしれません。
[SERVICE-DIS] Durand, A., "Service Discovery using NAPTR records in
DNS", Work in Progress, October 2004.
[SERVICE-DIS]ジュランド、A.、「DNSでのNAPTR記録を使用するサービスディスカバリー」、Progress、2004年10月のWork。
[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.
[大酒樽AD] 「IPv6トンネルエンドポイント発見メカニズムの分析」という殻、J.、およびMは進歩、2005年1月に働いています。
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of
IPsec", Work in Progress, February 2007.
S.、「IPsecの使用を強制するためのガイドライン」という[USEIPSEC]Bellovinは進歩、2007年2月に働いています。
Li, et al. Informational [Page 21] RFC 4925 Softwire Problem Statement July 2007
李、他 [21ページ]情報のRFC4925Softwire問題声明2007年7月
Authors' Addresses
作者のアドレス
Xing Li (editor) CERNET Room 225 Main Building, Tsinghua University Beijing, 100084 China
Xing李(エディタ)CERNET Room225本館、Tsinghua大学北京、100084中国
Phone: +86 10 62785983 Fax: +86 10 62785933 EMail: xing@cernet.edu.cn
以下に電話をしてください。 +86 10 62785983、Fax: +86 10 62785933はメールされます: xing@cernet.edu.cn
Spencer Dawkins (editor) Huawei Technologies (USA) 1700 Alma Drive, Suite 100
1700年のスペンサーダウキンズ(エディタ)Huawei Technologies(米国)アルマのドライブ、スイート100
Plano, TX 75075 US
プラノ、テキサス75075米国
Phone: +1 972 509 0309 Fax: +1 469 229 5397 EMail: spencer@mcsr-labs.org
以下に電話をしてください。 +1 972 509、0309Fax: +1 5397年の469 229メール: spencer@mcsr-labs.org
David Ward (editor) Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US
デヴィッド区(エディタ)シスコシステムズ170w.タスマンサンノゼカリフォルニア95134博士(米国)
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
アランジュランド(エディタ)コムキャスト1500市場St PA19102フィラデルフィア(米国)
EMail: alain_durand@cable.comcast.com
メール: alain_durand@cable.comcast.com
Li, et al. Informational [Page 22] RFC 4925 Softwire Problem Statement July 2007
李、他 [22ページ]情報のRFC4925Softwire問題声明2007年7月
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Li, et al. Informational [Page 23]
李、他 情報[23ページ]
一覧
スポンサーリンク
