RFC3102 日本語訳
3102 Realm Specific IP: Framework. M. Borella, J. Lo, D. Grabelsky, G.Montenegro. October 2001. (Format: TXT=73856 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Editors:
Request for Comments: 3102 M. Borella
Category: Experimental CommWorks
J. Lo
Candlestick Networks
Contributors:
D. Grabelsky
CommWorks
G. Montenegro
Sun Microsystems
October 2001
ワーキンググループエディターズをネットワークでつないでください: コメントのために以下を要求してください。 3102年のM.Borellaカテゴリ: 実験用CommWorks J.最低気温燭台は貢献者をネットワークでつなぎます: D。 Grabelsky CommWorks G.モンテネグロサン・マイクロシステムズ2001年10月
Realm Specific IP: Framework
分野の特定のIP: 枠組み
Status of this Memo
このMemoの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
IESG Note
IESG注意
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of RFC 3102, as well as in the Appendices of RFC 3104. Accordingly, the costs and benefits of using RSIP should be carefully weighed against other means of relieving address shortage.
IESGは、RSIP技術を説明するドキュメントのセットが完全な実現のために重要なホストとゲートウェイ変化を含意することに注意します。 さらに、ポートナンバーの浮動はいくつかのアプリケーションのために問題を起こすことができます、いくつかの場合(例えば、IPsec)、RSIPによって可能にされたホストが既存のアプリケーションで透明に共同利用するのを防いで。 最終的に、RSIPを使用すると関連している重要な操作上の複雑さがあるかもしれません。 これらと他のいくつかの複雑さがRFC3102のセクション6、およびRFC3104のAppendicesに概説されています。 それに従って、RSIPを使用するコストと利益は慎重にアドレス不足を救う他の手段に比較考量されるべきです。
Abstract
要約
This document examines the general framework of Realm Specific IP (RSIP). RSIP is intended as a alternative to NAT in which the end- to-end integrity of packets is maintained. We focus on implementation issues, deployment scenarios, and interaction with other layer-three protocols.
このドキュメントはRealm Specific IP(RSIP)の一般的な枠組みを調べます。 RSIPは終わりへのパケットの終わりの保全が維持されるNATへの代替手段として意図します。 私たちは他の層-3つのプロトコルとの導入問題、展開シナリオ、および相互作用に焦点を合わせます。
Borella, et al. Experimental [Page 1] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[1ページ]RFC3102RSIP: 枠組み2001年10月
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Document Scope . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Specification of Requirements . . . . . . . . . . . . . . . 5 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Host and Gateway Requirements . . . . . . . . . . . . . . . 7 3.2. Processing of Demultiplexing Fields . . . . . . . . . . . . 8 3.3. RSIP Protocol Requirements and Recommendations . . . . . . 9 3.4. Interaction with DNS . . . . . . . . . . . . . . . . . . . 10 3.5. Locating RSIP Gateways . . . . . . . . . . . . . . . . . . 11 3.6. Implementation Considerations . . . . . . . . . . . . . . . 11 4. Deployment . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Possible Deployment Scenarios . . . . . . . . . . . . . . . 12 4.2. Cascaded RSIP and NAT . . . . . . . . . . . . . . . . . . . 14 5. Interaction with Layer-Three Protocols . . . . . . . . . . . 17 5.1. IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2. Mobile IP . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3. Differentiated and Integrated Services . . . . . . . . . . 18 5.4. IP Multicast . . . . . . . . . . . . . . . . . . . . . . . 21 6. RSIP Complications . . . . . . . . . . . . . . . . . . . . . 23 6.1. Unnecessary TCP TIME_WAIT . . . . . . . . . . . . . . . . . 23 6.2. ICMP State in RSIP Gateway . . . . . . . . . . . . . . . . 23 6.3. Fragmentation and IP Identification Field Collision . . . . 24 6.4. Application Servers on RSAP-IP Hosts . . . . . . . . . . . 24 6.5. Determining Locality of Destinations from an RSIP Host. . . 25 6.6. Implementing RSIP Host Deallocation . . . . . . . . . . . . 26 6.7. Multi-Party Applications . . . . . . . . . . . . . . . . . 26 6.8. Scalability . . . . . . . . . . . . . . . . . . . . . . . . 27 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29 11. Full Copyright Statement . . . . . . . . . . . . . . . . . . 30
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 範囲. . . . . . . . . . . . . . . . . . . . . . 4 1.2を記録してください。 用語. . . . . . . . . . . . . . . . . . . . . . . . 4 1.3。 要件. . . . . . . . . . . . . . . 5 2の仕様。 構造. . . . . . . . . . . . . . . . . . . . . . . . 6 3。 要件. . . . . . . . . . . . . . . . . . . . . . . . 7 3.1。 ホストとゲートウェイ要件. . . . . . . . . . . . . . . 7 3.2。 逆多重化分野. . . . . . . . . . . . 8 3.3の処理。 RSIPは要件と推薦. . . . . . 9 3.4について議定書の中で述べます。 DNS. . . . . . . . . . . . . . . . . . . 10 3.5との相互作用。 RSIPゲートウェイ. . . . . . . . . . . . . . . . . . 11 3.6の場所を見つけます。 実現問題. . . . . . . . . . . . . . . 11 4。 展開. . . . . . . . . . . . . . . . . . . . . . . . . 12 4.1。 可能な展開シナリオ. . . . . . . . . . . . . . . 12 4.2。 どっと落しているRSIPとNAT. . . . . . . . . . . . . . . . . . . 14 5。 層-3つのプロトコル. . . . . . . . . . . 17 5.1との相互作用。 IPSEC. . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.2。 モバイルIP. . . . . . . . . . . . . . . . . . . . . . . . . 18 5.3。 微分されて統合しているサービス. . . . . . . . . . 18 5.4。 IPマルチキャスト. . . . . . . . . . . . . . . . . . . . . . . 21 6。 RSIP複雑さ. . . . . . . . . . . . . . . . . . . . . 23 6.1。 不要なTCPタイム誌_は.236.2を待っています。 ICMPはRSIPにゲートウェイ. . . . . . . . . . . . . . . . 23 6.3を述べます。 断片化とIP識別は衝突. . . . 24 6.4をさばきます。 RSAP-IPホスト. . . . . . . . . . . 24 6.5の上のアプリケーション・サーバー。 RSIPホストから目的地の場所を決定します。 . . 25 6.6. RSIPホストDeallocation. . . . . . . . . . . . 26 6.7を実行します。 マルチパーティアプリケーション. . . . . . . . . . . . . . . . . 26 6.8。 スケーラビリティ. . . . . . . . . . . . . . . . . . . . . . . . 27 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 27 8。 承認. . . . . . . . . . . . . . . . . . . . . . 27 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 28 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 29 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 30
1. Introduction
1. 序論
Network Address Translation (NAT) has become a popular mechanism of enabling the separation of addressing spaces. A NAT router must examine and change the network layer, and possibly the transport layer, header of each packet crossing the addressing domains that the NAT router is connecting. This causes the mechanism of NAT to violate the end-to-end nature of the Internet connectivity, and disrupts protocols requiring or enforcing end-to-end integrity of packets.
ネットワークAddress Translation(NAT)はアドレシング空間の分離を可能にするポピュラーなメカニズムになりました。 NATルータは、ネットワーク層、およびことによるとトランスポート層(NATルータがつなげているアドレス指定領域を越えるそれぞれのパケットのヘッダー)を調べて、変えなければなりません。 これは、NATのメカニズムが終わりから終わりへのインターネットの性質接続性に違反することを引き起こして、終わりから終わりへのパケットの保全を必要である、または実施するプロトコルを混乱させます。
Borella, et al. Experimental [Page 2] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[2ページ]RFC3102RSIP: 枠組み2001年10月
While NAT does not require a host to be aware of its presence, it requires the presence of an application layer gateway (ALG) within the NAT router for each application that embeds addressing information within the packet payload. For example, most NATs ship with an ALG for FTP, which transmits IP addresses and port numbers on its control channel. RSIP (Realm Specific IP) provides an alternative to remedy these limitations.
NATは、ホストが存在を意識しているのを必要としませんが、それはパケットペイロードの中にアドレス指定情報を埋め込む各アプリケーションのために、NATルータの中で応用層ゲートウェイ(ALG)を存在に要求します。 例えば、ほとんどのNATsがALGと共にFTPに出荷します。(それは、制御チャンネルのIPアドレスとポートナンバーを伝えます)。 RSIP(分野Specific IP)は、これらの制限を改善するために代替手段を提供します。
RSIP is based on the concept of granting a host from one addressing realm a presence in another addressing realm by allowing it to use resources (e.g., addresses and other routing parameters) from the second addressing realm. An RSIP gateway replaces the NAT router, and RSIP-aware hosts on the private network are referred to as RSIP hosts. RSIP requires ability of the RSIP gateway to grant such resources to RSIP hosts. ALGs are not required on the RSIP gateway for communications between an RSIP host and a host in a different addressing realm.
RSIPはリソース(例えば、アドレスと他のルーティングパラメタ)を使用するのを許容することによって別のアドレシング分野での存在を2番目のアドレシング分野から1つのアドレシング分野からのホストに与える概念に基づいています。 RSIPゲートウェイはNATルータを取り替えます、そして、私設のネットワークのRSIP意識しているホストはRSIPホストと呼ばれます。 RSIPはRSIPゲートウェイがそのようなリソースをRSIPホストに与える能力を必要とします。 ALGsはコミュニケーションに異なったアドレシング分野でRSIPホストとホストの間でRSIPゲートウェイの上で必要ではありません。
RSIP can be viewed as a "fix", of sorts, to NAT. It may ameliorate some IP address shortage problems in some scenarios without some of the limitations of NAT. However, it is not a long-term solution to the IP address shortage problem. RSIP allows a degree of address realm transparency to be achieve between two differently-scoped, or completely different addressing realms. This makes it a useful architecture for enabling end-to-end packet transparency between addressing realms. RSIP is expected to be deployed on privately addresses IPv4 networks and used to grant access to publically addressed IPv4 networks. However, in place of the private IPv4 network, there may be an IPv6 network, or a non-IP network. Thus, RSIP allows IP connectivity to a host with an IP stack and IP applications but no native IP access. As such, RSIP can be used, in conjunction with DNS and tunneling, to bridge IPv4 and IPv6 networks, such that dual-stack hosts can communicate with local or remote IPv4 or IPv6 hosts.
種類の「フィックス」としてNATにRSIPを見なすことができます。 それはNATの制限のいくつかなしでいくつかのシナリオのいくつかのIPアドレス不足問題を改善するかもしれません。 しかしながら、それはIPアドレス不足問題の長期的な解決法ではありません。 RSIPは、1段階のアドレス分野透明が2の間で異なって見られたか、完全に異なったアドレシング分野を達成することであることを許容します。これは、終わりから終わりへの個人的に配備される分野RSIPを記述することの間の透明が予想されるpublicallyするようにアクセスを承諾するのにおいてIPv4ネットワークの、そして、中古のアドレスが記述したIPv4がネットワークでつなぐパケットを可能にするためにそれを役に立つ構造にします。 しかしながら、私設のIPv4ネットワークに代わって、IPv6ネットワーク、または非IPネットワークがいるかもしれません。 したがって、RSIPはIPスタックとIPアプリケーションにもかかわらず、どんなネイティブのIPアクセサリーでもIPの接続性をホストに許容しません。 そういうものとして、RSIPを使用できます、DNSとトンネリングに関連して、橋のIPv4とIPv6ネットワークに、デュアルスタックホストが地元の、または、リモートなIPv4かIPv6ホストとコミュニケートできるように。
It is important to note that, as it is defined here, RSIP does NOT require modification of applications. All RSIP-related modifications to an RSIP host can occur at layers 3 and 4. However, while RSIP does allow end-to-end packet transparency, it may not be transparent to all applications. More details can be found in the section "RSIP complications", below.
それがここで定義されるときRSIPがアプリケーションの変更を必要としないことに注意するのは重要です。 RSIPホストへのすべてのRSIP関連の変更が層3と4に起こることができます。 しかしながら、RSIPは終わりから終わりへのパケット透明を許容しますが、それはすべてのアプリケーションに透明でないかもしれません。 下の「RSIP複雑さ」というセクションでその他の詳細を見つけることができます。
Borella, et al. Experimental [Page 3] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[3ページ]RFC3102RSIP: 枠組み2001年10月
1.1. Document Scope
1.1. ドキュメント範囲
This document provides a framework for RSIP by focusing on four particular areas:
このドキュメントは4つの特定の領域に焦点を合わせることによって、枠組みをRSIPに供給します:
- Requirements of an RSIP host and RSIP gateway.
- RSIPホストとRSIPゲートウェイの要件。
- Likely initial deployment scenarios.
- おそらく展開シナリオに頭文字をつけてください。
- Interaction with other layer-three protocols.
- 他の層-3つのプロトコルとの相互作用。
- Complications that RSIP may introduce.
- RSIPが導入するかもしれない複雑さ。
The interaction sections will be at an overview level. Detailed modifications that would need to be made to RSIP and/or the interacting protocol are left for separate documents to discuss in detail.
相互作用セクションが概観レベルにあるでしょう。 RSIPに作られている必要がある詳細な変更、そして/または、相互作用しているプロトコルが詳細に議論するのが別々のドキュメントに残されます。
Beyond the scope of this document is discussion of RSIP in large, multiple-gateway networks, or in environments where RSIP state would need to be distributed and maintained across multiple redundant entities.
向こうでは、このドキュメントの範囲は大きくて、複数のゲートウェイのネットワーク、またはRSIP州が複数の余分な実体の向こう側に分配されて、維持される必要がある環境で、RSIPの議論です。
Discussion of RSIP solutions that do not use some form of tunnel between the RSIP host and RSIP gateway are also not considered in this document.
また、RSIPホストとRSIPゲートウェイの間の何らかの形式のトンネルを使用しないRSIP解決策の議論は本書では考えられません。
This document focuses on scenarios that allow privately-addressed IPv4 hosts or IPv6 hosts access to publically-addressed IPv4 networks.
このドキュメントは個人的に記述されたIPv4にホストを許容するか、またはpublicallyによって記述されたIPv4ネットワークへのアクセスをIPv6ホストに許すシナリオに焦点を合わせます。
1.2. Terminology
1.2. 用語
Private Realm
私設の分野
A routing realm that uses private IP addresses from the ranges
(10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) specified in
[RFC1918], or addresses that are non-routable from the Internet.
範囲からのプライベートIPアドレスを使用するルーティング分野、(10.0 .0 16が)中で指定した8、.0/172.16.0 12、.0/192.168.0.0/[RFC1918]、またはインターネットから非発送可能であるアドレス。
Public Realm
公共部門
A routing realm with globally unique network addresses.
グローバルにユニークなネットワーク・アドレスがあるルーティング分野。
RSIP Host
RSIPホスト
A host within an addressing realm that uses RSIP to acquire
addressing parameters from another addressing realm via an RSIP
gateway.
RSIPゲートウェイを通して別のアドレシング分野からアドレシングパラメタを取得するのにRSIPを使用するアドレシング分野の中のホスト。
Borella, et al. Experimental [Page 4] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[4ページ]RFC3102RSIP: 枠組み2001年10月
RSIP Gateway
RSIPゲートウェイ
A router or gateway situated on the boundary between two
addressing realms that is assigned one or more IP addresses in at
least one of the realms. An RSIP gateway is responsible for
parameter management and assignment from one realm to RSIP hosts
in the other realm. An RSIP gateway may act as a normal NAT
router for hosts within the a realm that are not RSIP enabled.
ルータかゲートウェイが2つのアドレシング分野の間の少なくとも分野の1つの1つ以上のIPアドレスが割り当てられる境界に位置しました。RSIPゲートウェイはもう片方の分野で1つの分野からRSIPホストまでのパラメタ管理と課題に原因となります。 RSIPゲートウェイはa分野の中のRSIPでないホストにとって、正常なNATルータとして可能にされるのに作動するかもしれません。
RSIP Client
RSIPクライアント
An application program that performs the client portion of the
RSIP client/server protocol. An RSIP client application MUST
exist on all RSIP hosts, and MAY exist on RSIP gateways.
RSIPクライアント/サーバプロトコルのクライアント部分を実行するアプリケーション・プログラム。 RSIPクライアント利用は、すべてのRSIPホストの上に存在しなければならなくて、RSIPゲートウェイの上に存在するかもしれません。
RSIP Server
RSIPサーバ
An application program that performs the server portion of the
RSIP client/server protocol. An RSIP server application MUST
exist on all RSIP gateways.
RSIPクライアント/サーバプロトコルのサーバ部分を実行するアプリケーション・プログラム。 RSIPサーバ・アプリケーションはすべてのRSIPゲートウェイの上に存在しなければなりません。
RSA-IP: Realm Specific Address IP
RSA-IP: 分野の特定のアドレスIP
An RSIP method in which each RSIP host is allocated a unique IP
address from the public realm.
固有のIPアドレスが公共部門からそれぞれのRSIPホストに割り当てられるRSIP方法。
RSAP-IP: Realm Specific Address and Port IP
RSAP-IP: 分野の特定のアドレスとポートIP
An RSIP method in which each RSIP host is allocated an IP address
(possibly shared with other RSIP hosts) and some number of per-
address unique ports from the public realm.
中のIPアドレス(ことによると他のRSIPホストと共有される)と何らかの数がそれぞれのRSIPホストに割り当てられるRSIP方法、-、公共部門からユニークなポートを記述してください。
Demultiplexing Fields
逆多重化分野
Any set of packet header or payload fields that an RSIP gateway
uses to route an incoming packet to an RSIP host.
RSIPゲートウェイが入って来るパケットをRSIPホストに発送するのに使用するどんなセットのパケットのヘッダーかペイロード分野。
All other terminology found in this document is consistent with that of [RFC2663].
本書では見つけられた他のすべての用語が[RFC2663]のものと一致しています。
1.3. Specification of Requirements
1.3. 要件の仕様
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this documents are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」 「5月」、「推薦され」て、およびこれが記録する「任意」のコネは[RFC2119]で説明されるように解釈しないべきであることですか?
Borella, et al. Experimental [Page 5] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[5ページ]RFC3102RSIP: 枠組み2001年10月
2. Architecture
2. 構造
In a typical scenario where RSIP is deployed, there are some number of hosts within one addressing realm connected to another addressing realm by an RSIP gateway. This model is diagrammatically represented as follows:
RSIPが配備される典型的なシナリオには、何らかの数のホストがRSIPゲートウェイによって別のアドレシング分野に接続された1つのアドレシング分野の中にいます。 このモデルは以下の通り図式的に代理をされます:
RSIP Host RSIP Gateway Host
RSIPホストRSIPゲートウェイホスト
Xa Na Nb Yb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
( Network ) ( Network )
Xa Na Nb Yb[X]------( Addr sp. A)----[N]-----( Addr sp. B)-------[Y](ネットワーク)(ネットワーク)
Hosts X and Y belong to different addressing realms A and B, respectively, and N is an RSIP gateway (which may also perform NAT functions). N has two interfaces: Na on address space A, and Nb on address space B. N may have a pool of addresses in address space B which it can assign to or lend to X and other hosts in address space A. These addresses are not shown above, but they can be denoted as Nb1, Nb2, Nb3 and so on.
ホストXとYはそれぞれ異なったアドレシング分野AとBに属します、そして、NはRSIPゲートウェイ(また、NAT機能を実行するかもしれない)です。 Nには、2つのインタフェースがあります: アドレス空間Aに関するNa、およびNb1、Nb2、Nb3などとして指示されて、Nがしかし、アドレスが上に示されないThese、それらがアドレス空間A.であることができるでそれが割り当てることができるアドレス空間Bにおけるアドレスのプールを持っているか、またはXと他のホストを与えるかもしれないアドレス空間B.のNb。
As is often the case, the hosts within address space A are likely to use private addresses while the RSIP gateway is multi-homed with one or more private addresses from address space A in addition to its public addresses from address space B. Thus, we typically refer to the realm in which the RSIP host resides as "private" and the realm from which the RSIP host borrows addressing parameters as the "public" realm. However, these realms may both be public or private - our notation is for convenience. In fact, address space A may be an IPv6 realm or a non-IP address space.
RSIPゲートウェイが使用しそうですが、よくあるように、アドレス空間Aの中のホストがプライベート・アドレスを使用しそうである、マルチ、家へ帰り、アドレス空間Aからのアドレス空間B.Thusからの1つ以上のプライベート・アドレスが場内放送に加えてある状態で、私たちはRSIPホストが「個人的である」として住んでいる分野とRSIPホストが「公共」の分野としてパラメタを記述しながら借りる分野について通常言及します。 しかしながら、これらの分野は、ともに公設であるか、または私設であるかもしれません--私たちの記法は便宜のためのものです。 事実上、アドレス空間Aは、IPv6分野か非IPアドレス空間であるかもしれません。
Host X, wishing to establish an end-to-end connection to a network entity Y situated within address space B, first negotiates and obtains assignment of the resources (e.g., addresses and other routing parameters of address space B) from the RSIP gateway. Upon assignment of these parameters, the RSIP gateway creates a mapping, referred as a "bind", of X's addressing information and the assigned resources. This binding enables the RSIP gateway to correctly de- multiplex and forward inbound traffic generated by Y for X. If permitted by the RSIP gateway, X may create multiple such bindings on the same RSIP gateway, or across several RSIP gateways. A lease time SHOULD be associated with each bind.
アドレス空間Bの中に位置したネットワーク実体Yに終わりから終わりとの接続を確立することを願っていて、ホストXは、最初に、RSIPゲートウェイからリソース(アドレス空間Bの例えば、アドレスと他のルーティングパラメタ)の課題を交渉して、得ます。 これらのパラメタの課題のときに、RSIPゲートウェイはXのアドレス指定情報と割り当てられたリソースの「ひも」として参照されたマッピングを作成します。 この結合は反-正しく多重送信するRSIPゲートウェイとRSIPゲートウェイによって受入れられたX.IfのためにYで発生する前進のインバウンドトラフィックを可能にして、Xは同じRSIPゲートウェイの上、または、いくつかのRSIPゲートウェイの向こう側に複数のそのような結合を作成するかもしれません。 Aは時間SHOULDを賃貸します。各ひもに関連してください。
Using the public parameters assigned by the RSIP gateway, RSIP hosts tunnel data packets across address space A to the RSIP gateway. The RSIP gateway acts as the end point of such tunnels, stripping off the outer headers and routing the inner packets onto the public realm. As mentioned above, an RSIP gateway maintains a mapping of the
RSIPゲートウェイによって割り当てられた公共のパラメタを使用して、RSIPはアドレス空間Aの向こう側にトンネルデータ・パケットをRSIPゲートウェイに接待します。 RSIPゲートウェイはそのようなトンネル、外側のヘッダーを全部はぎ取って、およびルーティングのエンドポイントとして内側のパケットに公共部門に作用します。 以上のように、RSIPゲートウェイはマッピングを維持します。
Borella, et al. Experimental [Page 6] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[6ページ]RFC3102RSIP: 枠組み2001年10月
assigned public parameters as demultiplexing fields for uniquely mapping them to RSIP host private addresses. When a packet from the public realm arrives at the RSIP gateway and it matches a given set of demultiplexing fields, then the RSIP gateway will tunnel it to the appropriate RSIP host. The tunnel headers of outbound packets from X to Y, given that X has been assigned Nb, are as follows:
唯一RSIPホストにそれらを写像するための逆多重化分野としての公共のパラメタに個人的なアドレスを割り当てました。 公共部門からのパケットがRSIPゲートウェイに到着して、与えられたセットの逆多重化分野を合わせると、RSIPゲートウェイは適切なRSIPホストにそれにトンネルを堀るでしょう。 NbがXに割り当てられたなら、外国行きのXからYまでのパケットのトンネルヘッダーは以下の通りです:
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+
+---------+---------+---------+ | X->Na| Nb->Y| ペイロード| +---------+---------+---------+
There are two basic flavors of RSIP: RSA-IP and RSAP-IP. RSIP hosts and gateways MAY support RSA-IP, RSAP-IP, or both.
RSIPの2つの基本的な風味があります: RSA-IPとRSAP-IP。 RSIPホストとゲートウェイはRSA-IP、RSAP-IP、または両方を支持するかもしれません。
When using RSA-IP, an RSIP gateway maintains a pool of IP addresses to be leased by RSIP hosts. Upon host request, the RSIP gateway allocates an IP address to the host. Once an address is allocated to a particular host, only that host may use the address until the address is returned to the pool. Hosts MAY NOT use addresses that have not been specifically assigned to them. The hosts may use any TCP/UDP port in combination with their assigned address. Hosts may also run gateway applications at any port and these applications will be available to the public network without assistance from the RSIP gateway. A host MAY lease more than one address from the same or different RSIP gateways. The demultiplexing fields of an RSA-IP session MUST include the IP address leased to the host.
RSA-IPを使用するとき、RSIPホストによって賃貸されるように、RSIPゲートウェイはIPアドレスのプールを維持します。 ホスト要求のときに、RSIPゲートウェイはIPアドレスをホストに割り当てます。 いったん特定のホストにアドレスを割り当てると、そのホストだけがアドレスをプールに返すまでアドレスを使用するかもしれません。 ホストは明確にそれらに割り当てられていないアドレスを使用しないかもしれません。 ホストは彼らの割り当てられたアドレスと組み合わせてどんなTCP/UDPポートも使用するかもしれません。 また、ホストはどんなポートでもゲートウェイアプリケーションを実行するかもしれません、そして、これらのアプリケーションはRSIPゲートウェイからの支援なしで公衆通信回線に利用可能になるでしょう。 ホストは同じであるか異なったRSIPゲートウェイからの1つ以上のアドレスを賃貸するかもしれません。 RSA-IPセッションの逆多重化分野はホストに賃貸されたIPアドレスを含まなければなりません。
When using RSAP-IP, an RSIP gateway maintains a pool of IP addresses as well as pools of port numbers per address. RSIP hosts lease an IP address and one or more ports to use with it. Once an address / port tuple has been allocated to a particular host, only that host may use the tuple until it is returned to the pool(s). Hosts MAY NOT use address / port combinations that have not been specifically assigned to them. Hosts may run gateway applications bound to an allocated tuple, but their applications will not be available to the public network unless the RSIP gateway has agreed to route all traffic destined to the tuple to the host. A host MAY lease more than one tuple from the same or different RSIP gateways. The demultiplexing fields of an RSAP-IP session MUST include the tuple(s) leased to the host.
RSAP-IPを使用するとき、RSIPゲートウェイはポートナンバーのプールと同様に1アドレスあたりのIPアドレスのプールを維持します。 RSIPホストはそれと共に使用するIPアドレスと1つ以上のポートを賃貸します。 いったんアドレス/ポートtupleを特定のホストに割り当てると、そのホストだけがそれをプールに返すまでtupleを使用するかもしれません。 ホストは明確にそれらに割り当てられていないアドレス/ポート組み合わせを使用しないかもしれません。 ホストは割り当てられたtupleに縛られたゲートウェイアプリケーションを実行するかもしれませんが、tupleに運命づけられたすべての交通をホストに発送するために同意されて、RSIPゲートウェイが利用可能でない場合、彼らのアプリケーションは公衆通信回線に利用可能にならないでしょう。 ホストは同じであるか異なったRSIPゲートウェイから1tupleを賃貸するかもしれません。 RSAP-IPセッションの逆多重化分野はホストに賃貸されたtuple(s)を含まなければなりません。
3. Requirements
3. 要件
3.1. Host and Gateway Requirements
3.1. ホストとゲートウェイ要件
An RSIP host MUST be able to maintain one or more virtual interfaces for the IP address(es) that it leases from an RSIP gateway. The host MUST also support tunneling and be able to serve as an end-point for
RSIPホストはそれがRSIPゲートウェイから賃貸するIPアドレス(es)のために1つ以上の仮想インターフェースを維持できなければなりません。 ホストは、また、トンネルを堀るのを支持して、エンドポイントとして機能できなければなりません。
Borella, et al. Experimental [Page 7] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[7ページ]RFC3102RSIP: 枠組み2001年10月
one or more tunnels to RSIP gateways. An RSIP host MUST NOT respond to ARPs for a public realm address that it leases.
1つか以上がRSIPゲートウェイにトンネルを堀ります。 RSIPホストはそれが賃貸する公共部門アドレスのためにARPsに応じてはいけません。
An RSIP host supporting RSAP-IP MUST be able to maintain a set of one or more ports assigned by an RSIP gateway from which choose ephemeral source ports. If the host's pool does not have any free ports and the host needs to open a new communication session with a public host, it MUST be able to dynamically request one or more additional ports via its RSIP mechanism.
RSAP-IPを支持しているRSIPホストはどれがはかないソース港を選ぶかからRSIPゲートウェイによって割り当てられた1つ以上のポートのセットを維持できなければなりません。 ホストのプールには少しの自由港もなくて、ホストが、公共のホストとの新しいコミュニケーションセッションを開く必要があるなら、RSIPメカニズムでダイナミックに1つ以上の追加ポートを要求できなければなりません。
An RSIP gateway is a multi-homed host that routes packets between two or more realms. Often, an RSIP gateway is a boundary router between two or more administrative domains. It MUST also support tunneling and be able to serve as an end-point for tunnels to RSIP hosts. The RSIP gateway MAY be a policy enforcement point, which in turn may require it to perform firewall and packet filtering duties in addition to RSIP. The RSIP gateway MUST reassemble all incoming packet fragments from the public network in order to be able to route and tunnel them to the proper host. As is necessary for fragment reassembly, an RSIP gateway MUST timeout fragments that are never fully reassembled.
2つ以上の分野の間のそのルートパケットを接待してください。RSIPゲートウェイがaである、マルチ、家へ帰り、しばしば、RSIPゲートウェイは2つ以上の管理ドメインの間の境界ルータです。 それは、また、トンネルを堀るのを支持して、トンネルへのエンドポイントとしてRSIPホストにサービスできなければなりません。 RSIPゲートウェイは方針実施ポイントであるかもしれません。(そのポイントは、RSIPに加えてファイアウォールとパケットフィルタリング義務を実行するために順番にそれを必要とするかもしれません)。 RSIPゲートウェイは、適切なホストにそれらを発送して、トンネルを堀ることができるように公衆通信回線からすべての入って来るパケット断片を組み立て直さなければなりません。 そのままで、断片再アセンブリに必要であることで、RSIPゲートウェイは完全に決して組み立て直されるというわけではないタイムアウト断片がそうしなければなりません。
An RSIP gateway MAY include NAT functionality so that hosts on the private network that are not RSIP-enabled can still communicate with the public network. An RSIP gateway MUST manage all resources that are assigned to RSIP hosts. This management MAY be done according to local policy.
RSIPゲートウェイは、RSIPによって可能にされなかった私設のネットワークのホストが公衆通信回線でまだ交信できるように、NATの機能性を含むかもしれません。 RSIPゲートウェイはRSIPホストに割り当てられるすべてのリソースを管理しなければなりません。 ローカルの方針によると、この管理をするかもしれません。
3.2. Processing of Demultiplexing Fields
3.2. 逆多重化分野の処理
Each active RSIP host must have a unique set of demultiplexing fields assigned to it so that an RSIP gateway can route incoming packets appropriately. Depending on the type of mapping used by the RSIP gateway, demultiplexing fields have been defined to be one or more of the following:
それぞれの活発なRSIPホストは、RSIPゲートウェイが適切に入って来るパケットを発送できるように、ユニークなセットの逆多重化分野をそれに割り当てさせなければなりません。 RSIPゲートウェイによって使用されるマッピングのタイプに頼っていて、逆多重化分野は以下の1つ以上になるように定義されました:
- destination IP address
- 送付先IPアドレス
- IP protocol
- IPプロトコル
- destination TCP or UDP port
- 目的地TCPかUDPポート
- IPSEC SPI present in ESP or AH header (see [RFC3104])
- 超能力で出席しているIPSEC SPIかAHヘッダー([RFC3104]を見ます)
- others
- 他のもの
Note that these fields may be augmented by source IP address and source TCP or UDP port.
これらの分野はソースIPアドレスとソースTCPかUDPポートによって増大させられるかもしれないことに注意してください。
Borella, et al. Experimental [Page 8] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[8ページ]RFC3102RSIP: 枠組み2001年10月
Demultiplexing of incoming traffic can be based on a decision tree. The process begins with the examination of the IP header of the incoming packet, and proceeds to subsequent headers and then the payload.
入って来る交通の逆多重化は意思決定の樹状図に基づくことができます。 過程は、入って来るパケットのIPヘッダーの試験で始まって、その後のヘッダーと次に、ペイロードに続きます。
- In the case where a public IP address is assigned for each
host, a unique public IP address is mapped to each RSIP host.
- 公共のIPアドレスが各ホストのために割り当てられる場合では、ユニークな公共のIPアドレスはそれぞれのRSIPホストに写像されます。
- If the same IP address is used for more than one RSIP host,
then subsequent headers must have at least one field that will
be assigned a unique value per host so that it is usable as a
demultiplexing field. The IP protocol field SHOULD be used to
determine what in the subsequent headers these demultiplexing
fields ought to be.
- 同じIPアドレスが1人以上のRSIPホストに使用されるなら、その後のヘッダーには、1ホストあたり1つのユニークな値がそれが逆多重化分野として使用可能であるように割り当てられる少なくとも1つの分野がなければなりません。 IPは分野SHOULDについて議定書の中で述べます。その後のヘッダーのこれらの逆多重化分野が何であるべきであるかを決定するために、使用されます。
- If the subsequent header is TCP or UDP, then destination port
number can be used. However, if the TCP/UDP port number is the
same for more than one RSIP host, the payload section of the
packet must contain a demultiplexing field that is guaranteed
to be different for each RSIP host. Typically this requires
negotiation of said fields between the RSIP host and gateway so
that the RSIP gateway can guarantee that the fields are unique
per-host
- その後のヘッダーがTCPかUDPであるなら、目的地ポートナンバーを使用できます。 しかしながら、1人以上のRSIPホストにとって、TCP/UDPポートナンバーが同じであるなら、パケットのペイロード部分はそれぞれのRSIPホストにとって異なるように保証される逆多重化分野を含まなければなりません。 通常、これは、RSIPゲートウェイが、分野がユニークなホストであることを保証できるように、RSIPホストとゲートウェイの間の前述の分野の交渉を必要とします。
- If the subsequent header is anything other than TCP or UDP,
there must exist other fields within the IP payload usable as
demultiplexing fields. In other words, these fields must be
able to be set such that they are guaranteed to be unique per-
host. Typically this requires negotiation of said fields
between the RSIP host and gateway so that the RSIP gateway can
guarantee that the fields are unique per-host.
- その後のヘッダーがTCP以外の何かかUDPであるならでも、他の分野は逆多重化分野としてIPペイロードの中に使用可能な状態で存在しなければなりません。 言い換えれば、これらの分野が設定できなければならないのでそれらが特有になるように保証される、-、ホスト。 通常、これは、RSIPゲートウェイが、分野がユニークなホストであることを保証できるように、RSIPホストとゲートウェイの間の前述の分野の交渉を必要とします。
It is desirable for all demultiplexing fields to occur in well-known fixed locations so that an RSIP gateway can mask out and examine the appropriate fields on incoming packets. Demultiplexing fields that are encrypted MUST NOT be used for routing.
すべての逆多重化分野が周知の固定ロケーションに起こるのは、RSIPゲートウェイが入って来るパケットの適切な分野を覆い隠して、調べることができるくらい望ましいです。 ルーティングにコード化された逆多重化分野を使用してはいけません。
3.3. RSIP Protocol Requirements and Recommendations
3.3. RSIPプロトコル要件と推薦
RSIP gateways and hosts MUST be able to negotiate IP addresses when using RSA-IP, IP address / port tuples when using RSAP-IP, and possibly other demultiplexing fields for use in other modes.
他のモードにおける使用にRSAP-IP、およびことによると他の逆多重化分野を使用するとき、RSA-IP、IPアドレス/ポートtuplesを使用すると、RSIPゲートウェイとホストはIPアドレスを交渉できなければなりません。
In this section we discuss the requirements and implementation issues of an RSIP negotiation protocol.
このセクションで、私たちはRSIP交渉プロトコルの要件と導入問題について議論します。
For each required demultiplexing field, an RSIP protocol MUST, at the very least, allow for:
それぞれの必要な逆多重化分野に、RSIPプロトコルは以下を少なくとも考慮しなければなりません。
Borella, et al. Experimental [Page 9] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[9ページ]RFC3102RSIP: 枠組み2001年10月
- RSIP hosts to request assignments of demultiplexing fields
- 逆多重化分野の課題を要求するRSIPホスト
- RSIP gateways to assign demultiplexing fields with an
associated lease time
- 関連リース時間で逆多重化分野を割り当てるRSIPゲートウェイ
- RSIP gateways to reclaim assigned demultiplexing fields
- 開墾するRSIPゲートウェイは逆多重化分野を割り当てました。
Additionally, it is desirable, though not mandatory, for an RSIP protocol to negotiate an RSIP method (RSA-IP or RSAP-IP) and the type of tunnel to be used across the private network. The protocol SHOULD be extensible and facilitate vendor-specific extensions.
さらに、私設のネットワークの向こう側に使用されるためにRSIP方法(RSA-IPかRSAP-IP)とトンネルのタイプを交渉するのは、RSIPプロトコルに望ましくて、もっとも、義務的ではありません。 プロトコルSHOULDは広げることができて、業者特有の拡大を容易にします。
If an RSIP negotiation protocol is implemented at the application layer, a choice of transport protocol MUST be made. RSIP hosts and gateways may communicate via TCP or UDP. TCP support is required in all RSIP gateways, while UDP support is optional. In RSIP hosts, TCP, UDP, or both may be supported. However, once an RSIP host and gateway have begun communicating using either TCP or UDP, they MAY NOT switch to the other transport protocol. For RSIP implementations and deployments considered in this document, TCP is the recommended transport protocol, because TCP is known to be robust across a wide range of physical media types and traffic loads.
応用層でRSIP交渉プロトコルを実行するなら、トランスポート・プロトコルの選択をしなければなりません。 RSIPホストとゲートウェイはTCPかUDPを通って交信するかもしれません。 TCPサポートがすべてのRSIPゲートウェイで必要ですが、UDPサポートは任意です。 RSIPホストでは、TCP、UDP、または両方が支持されるかもしれません。 しかしながら、RSIPホストとゲートウェイがTCPかUDPのどちらかを使用することでいったん交信し始めたと、彼らはもう片方のトランスポート・プロトコルに切り替わらないかもしれません。 本書では考えられたRSIP実現と展開のために、TCPはお勧めのトランスポート・プロトコルです、TCPがさまざまな物理的なメディアタイプとトラヒック負荷の向こう側に強健であることが知られているので。
It is recommended that all communication between an RSIP host and gateway be authenticated. Authentication, in the form of a message hash appended to the end of each RSIP protocol packet, can serve to authenticate the RSIP host and gateway to one another, provide message integrity, and (with an anti-replay counter) avoid replay attacks. In order for authentication to be supported, each RSIP host and the RSIP gateway MUST either share a secret key (distributed, for example, by Kerberos) or have a private/public key pair. In the latter case, an entity's public key can be computed over each message and a hash function applied to the result to form the message hash.
RSIPホストとゲートウェイとのすべてのコミュニケーションが認証されるのは、お勧めです。 それぞれのRSIPプロトコルパケットの端まで追加されたメッセージ細切れ肉料理の形では、認証はお互いにRSIPホストとゲートウェイを認証して、メッセージの保全を提供して、反射攻撃を避けるのに(反再生カウンタで)役立つことができます。 認証が支持されるために、それぞれのRSIPホストとRSIPゲートウェイには、秘密鍵(例えば、ケルベロスで、分配される)を共有しなければならないか、または私設の/公開鍵組がなければなりません。 後者の場合では、各メッセージに関して実体の公開鍵を計算できました、そして、ハッシュ関数はメッセージ細切れ肉料理を形成するのを結果に適用しました。
3.4. Interaction with DNS
3.4. DNSとの相互作用
An RSIP-enabled network has three uses for DNS: (1) public DNS services to map its static public IP addresses (i.e., the public address of the RSIP gateway) and for lookups of public hosts, (2) private DNS services for use only on the private network, and (3) dynamic DNS services for RSIP hosts.
RSIPによって可能にされたネットワークには、DNSへの3つの用途があります: (1) 公共のDNSは静的な公立のIPが記述する地図(すなわち、RSIPゲートウェイの場内放送)と公共のホスト、私設のネットワークだけにおける使用のための(2)の個人的なDNSサービス、および(3)のルックアップのためにRSIPホストのためのダイナミックなDNSサービスを修理します。
With respect to (1), public DNS information MUST be propagated onto the private network. With respect to (2), private DNS information MUST NOT be propagated into the public network.
(1)に関して、公共のDNS情報を私設のネットワークに伝播しなければなりません。 (2)に関して、個人的なDNS情報を公衆通信回線に伝播してはいけません。
Borella, et al. Experimental [Page 10] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[10ページ]RFC3102RSIP: 枠組み2001年10月
With respect to (3), an RSIP-enabled network MAY allow for RSIP hosts with FQDNs to have their A and PTR records updated in the public DNS. These updates are based on address assignment facilitated by RSIP, and should be performed in a fashion similar to DHCP updates to dynamic DNS [DHCP-DNS]. In particular, RSIP hosts should be allowed to update their A records but not PTR records, while RSIP gateways can update both. In order for the RSIP gateway to update DNS records on behalf on an RSIP host, the host must provide the gateway with its FQDN.
(3)に関して、RSIPによって可能にされたネットワークは、FQDNsのRSIPホストが公共のDNSで彼らのAとPTR記録をアップデートさせるのを許容するかもしれません。 これらのアップデートは、RSIPによって容易にされたアドレス課題に基づいていて、DHCPアップデートと同様のファッションでダイナミックなDNS[DHCP-DNS]に実行されるべきです。 特に、RSIPホストはPTR記録ではなく、彼らのA記録をアップデートできるべきです、RSIPゲートウェイが両方をアップデートできますが。 RSIPゲートウェイが利益としてRSIPホストでDNS記録をアップデートするように、ホストはFQDNをゲートウェイに提供しなければなりません。
Note that when using RSA-IP, the interaction with DNS is completely analogous to that of DHCP because the RSIP host "owns" an IP address for a period of time. In the case of RSAP-IP, the claim that an RSIP host has to an address is only with respect to the port(s) that it has leased along with an address. Thus, two or more RSIP hosts' FQDNs may map to the same IP address. However, a public host may expect that all of the applications running at a particular address are owned by the same logical host, which would not be the case. It is recommended that RSAP-IP and dynamic DNS be integrated with some caution, if at all.
RSA-IPを使用するとき、RSIPホストがしばらくIPアドレスを「所有している」ので、DNSとの相互作用がDHCPのものに完全に類似していることに注意してください。 RSAP-IPの場合には、それがアドレスと共に賃貸したポートだけに関してRSIPホストがアドレスに持っているクレームがあります。 その結果RSIPホストのFQDNsが同じIPアドレスに写像するかもしれない2以上。 しかしながら、公共のホストは、特定のアドレスで稼働するアプリケーションのすべてが同じ論理的なホストによって所有されていると予想するかもしれません(ケースでないでしょう)。 RSAP-IPとダイナミックなDNSが何らかの警告について統合しているのは、せいぜいお勧めです。
3.5. Locating RSIP Gateways
3.5. RSIPゲートウェイの場所を見つけます。
When an RSIP host initializes, it requires (among other things) two critical pieces of information. One is a local (private) IP address to use as its own, and the other is the private IP address of an RSIP gateway. This information can be statically configured or dynamically assigned.
いつ、RSIPホストが初期化するか、それは2つの批評的な記事の情報を必要とします(特に)。 1つはそれ自身のものとして使用するローカル(個人的な)のIPアドレスです、そして、もう片方がRSIPゲートウェイのプライベートIPアドレスです。 この情報を静的に構成するか、またはダイナミックに割り当てることができます。
In the dynamic case, the host's private address is typically supplied by DHCP. A DHCP option could provide the IP address of an RSIP gateway in DHCPOFFER messages. Thus, the host's startup procedure would be as follows: (1) perform DHCP, (2) if an RSIP gateway option is present in the DHCPOFFER, record the IP address therein as the RSIP gateway.
ダイナミックな場合では、ホストのプライベート・アドレスはDHCPによって通常供給されます。 DHCPオプションはRSIPゲートウェイのIPアドレスをDHCPOFFERメッセージに提供するかもしれません。 したがって、ホストの始動手順は以下の通りでしょう: (1) DHCPを実行してください、(2) RSIPゲートウェイオプションがDHCPOFFERに存在しているならRSIPゲートウェイとしてそこにIPアドレスを記録してください。
Alternatively, the RSIP gateway can be discovered via SLP (Service Location Protocol) as specified in [SLP-RSIP]. The SLP template defined allows for RSIP service provisioning and load balancing.
あるいはまた、[SLP-RSIP]の指定されるとしてのSLP(サービスLocationプロトコル)を通してRSIPゲートウェイを発見できます。 定義されたSLPテンプレートはRSIPサービスの食糧を供給するのとロードバランシングを考慮します。
3.6. Implementation Considerations
3.6. 実装問題
RSIP can be accomplished by any one of a wide range of implementation schemes. For example, it can be built into an existing configuration protocol such as DHCP or SOCKS, or it can exist as a separate protocol. This section discusses implementation issues of RSIP in general, regardless of how the RSIP mechanism is implemented.
さまざまな実現体系のいずれもRSIPを達成できます。 例えば、DHCPかSOCKSなどの既存の構成プロトコルをそれに組み込むことができますか、またはそれは別々のプロトコルとして存在できます。 RSIPメカニズムがどう実装されるかにかかわらずこのセクションは一般に、RSIPの導入問題について論じます。
Borella, et al. Experimental [Page 11] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[11ページ]RFC3102RSIP: フレームワーク2001年10月
Note that on a host, RSIP is associated with a TCP/IP stack implementation. Modifications to IP tunneling and routing code, as well as driver interfaces may need to be made to support RSA-IP. Support for RSAP-IP requires modifications to ephemeral port selection code as well. If a host has multiple TCP/IP stacks or TCP/IP stacks and other communication stacks, RSIP will only operate on the packets / sessions that are associated with the TCP/IP stack(s) that use RSIP. RSIP is not application specific, and if it is implemented in a stack, it will operate beneath all applications that use the stack.
ホストでは、RSIPがTCP/IPスタック実装に関連していることに注意してください。 コード、およびドライバーインタフェースがそうするIPトンネリングとルーティングへの変更は、RSA-IPがサポートさせられる必要があります。 RSAP-IPのサポートはまた、エフェメラルポート選択コードへの変更を必要とします。 ホストが複数のTCP/IPスタックかTCP/IPスタックと他のコミュニケーションスタックを持っていると、RSIPはRSIPを使用するTCP/IPスタックに関連しているパケット/セッションを作動させるだけでしょう。 RSIPはアプリケーション特有ではありません、そして、スタックで実装されると、それはスタックを使用するすべてのアプリケーションの下で作動するでしょう。
4. Deployment
4. 展開
When RSIP is deployed in certain scenarios, the network characteristics of these scenarios will determine the scope of the RSIP solution, and therefore impact the requirements of RSIP. In this section, we examine deployment scenarios, and the impact that RSIP may have on existing networks.
RSIPが、あるシナリオで配布されるとき、これらのシナリオのネットワークの特性は、RSIPソリューションの範囲を決定して、したがって、RSIPの要件に影響を与えるでしょう。 このセクションで、私たちは展開シナリオ、およびRSIPが既存のネットワークに持っているかもしれない影響力を調べます。
4.1. Possible Deployment Scenarios
4.1. 可能な展開シナリオ
In this section we discuss a number of potential RSIP deployment scenarios. The selection below are not comprehensive and other scenarios may emerge.
このセクションで、私たちは多くの潜在的RSIP展開シナリオについて議論します。 以下での選択は包括的ではありません、そして、他のシナリオは現れるかもしれません。
4.1.1. Small / Medium Enterprise
4.1.1. 小さいか中型のエンタープライズ
Up to several hundred hosts will reside behind an RSIP-enabled router. It is likely that there will be only one gateway to the public network and therefore only one RSIP gateway. This RSIP gateway may control only one, or perhaps several, public IP addresses. The RSIP gateway may also perform firewall functions, as well as routing inbound traffic to particular destination ports on to a small number of dedicated gateways on the private network.
数100まで、ホストはRSIPによって可能にされたルータの後ろに住むでしょう。 公衆通信回線への1門としたがって、1RSIP門だけしかありそうにないでしょう。 このRSIPゲートウェイは1、または恐らく数個、公共のIPアドレスだけを制御するかもしれません。 また、RSIPゲートウェイはファイアウォール機能を実行するかもしれません、私設のネットワークの少ない数の専用ゲートウェイへの特定の仕向港へのルーティングインバウンドトラフィックと同様に。
4.1.2. Residential Networks
4.1.2. 住宅のネットワーク
This category includes both networking within just one residence, as well as within multiple-dwelling units. At most several hundred hosts will share the gateway's resources. In particular, many of these devices may be thin hosts or so-called "network appliances" and therefore not require access to the public Internet frequently. The RSIP gateway is likely to be implemented as part of a residential firewall, and it may be called upon to route traffic to particular destination ports on to a small number of dedicated gateways on the private network. It is likely that only one gateway to the public
このカテゴリは、ちょうど1つの住居以内と複数の住戸の中でともにネットワークでつなぐのを含んでいます。 高々、数100人のホストがゲートウェイのリソースを共有するでしょう。 これらのデバイスの多くが、特に、細いホストかいわゆる「ネットワーク器具」であり、したがって、公共のインターネットへのアクセスを頻繁に必要としないかもしれません。 RSIPゲートウェイは住宅のファイアウォールの一部として実装されそうです、そして、私設のネットワークで少ない数の専用ゲートウェイへの特定の仕向港にトラフィックを発送するのが要求されるかもしれません。 それがありそうである、公衆へのその唯一の1門
Borella, et al. Experimental [Page 12] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[12ページ]RFC3102RSIP: フレームワーク2001年10月
network will be present and that this gateway's RSIP gateway will control only one IP address. Support for secure end-to-end VPN access to corporate intranets will be important.
ネットワークは存在するでしょう、そして、このゲートウェイのRSIPゲートウェイは1つのIPアドレスだけを制御するでしょう。 終わりから終わりへのVPN企業イントラネットへの安全なアクセスのサポートは重要になるでしょう。
4.1.3. Hospitality Networks
4.1.3. 歓待ネットワーク
A hospitality network is a general type of "hosting" network that a traveler will use for a short period of time (a few minutes or a few hours). Examples scenarios include hotels, conference centers and airports and train stations. At most several hundred hosts will share the gateway's resources. The RSIP gateway may be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP gateway will control only one IP address. Support for secure end-to-end VPN access to corporate intranets will be important.
歓待ネットワークは旅行者が短期間の間に使用するネットワーク(数分か数時間)が一般型の「接待」です。 例のシナリオはホテル、会議センター、空港、および鉄道駅を含んでいます。 高々、数100人のホストがゲートウェイのリソースを共有するでしょう。 RSIPゲートウェイはファイアウォールの一部として実装されるかもしれません、そして、それは、私設のネットワークで専用ゲートウェイへの特定の仕向港にトラフィックを発送するのにたぶん使用されないでしょう。 公衆通信回線への1つの門だけが存在するでしょう、そして、このゲートウェイのRSIPゲートウェイは1つのIPアドレスだけを制御しそうでしょう。 終わりから終わりへのVPN企業イントラネットへの安全なアクセスのサポートは重要になるでしょう。
4.1.4. Dialup Remote Access
4.1.4. ダイアルアップ遠隔アクセス
RSIP gateways may be placed in dialup remote access concentrators in order to multiplex IP addresses across dialup users. At most several hundred hosts will share the gateway's resources. The RSIP gateway may or may not be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. Only one gateway to the public network will be present (the remote access concentrator itself) and that this gateway's RSIP gateway will control a small number of IP addresses. Support for secure end-to-end VPN access to corporate intranets will be important.
RSIPゲートウェイは、ダイアルアップユーザの向こう側にIPアドレスを多重送信するためにダイアルアップ遠隔アクセス集中装置に置かれるかもしれません。 高々、数100人のホストがゲートウェイのリソースを共有するでしょう。 RSIPゲートウェイはファイアウォールの一部として実装されるかもしれません、そして、それは、私設のネットワークで専用ゲートウェイへの特定の仕向港にトラフィックを発送するのにたぶん使用されないでしょう。 公衆通信回線への1つの門は存在するでしょう、そして、(遠隔アクセスの集中装置自体)このゲートウェイのRSIPゲートウェイは少ない数のIPアドレスを制御するだけでしょう。 終わりから終わりへのVPN企業イントラネットへの安全なアクセスのサポートは重要になるでしょう。
4.1.5. Wireless Remote Access Networks
4.1.5. ワイヤレスの遠隔アクセスのネットワーク
Wireless remote access will become very prevalent as more PDA and IP / cellular devices are deployed. In these scenarios, hosts may be changing physical location very rapidly - therefore Mobile IP will play a role. Hosts typically will register with an RSIP gateway for a short period of time. At most several hundred hosts will share the gateway's resources. The RSIP gateway may be implemented as part of a firewall, and it will probably not be used to route traffic to particular destination ports on to dedicated gateways on the private network. It is likely that only one gateway to the public network will be present and that this gateway's RSIP gateway will control a small number of IP addresses. Support for secure end-to-end VPN access to corporate intranets will be important.
より多くのPDAとIP/セルのデバイスが配布されるとき、ワイヤレスの遠隔アクセスは非常に一般的になるでしょう。 これらのシナリオでは、ホストは非常に急速に物理的な位置を変えているかもしれません--したがって、モバイルIPは役割を果たすでしょう。 ホストは短期間の間、RSIPゲートウェイと通常ともに記名するでしょう。 高々、数100人のホストがゲートウェイのリソースを共有するでしょう。 RSIPゲートウェイはファイアウォールの一部として実装されるかもしれません、そして、それは、私設のネットワークで専用ゲートウェイへの特定の仕向港にトラフィックを発送するのにたぶん使用されないでしょう。 公衆通信回線への1つの門だけが存在するでしょう、そして、このゲートウェイのRSIPゲートウェイは少ない数のIPアドレスを制御しそうでしょう。 終わりから終わりへのVPN企業イントラネットへの安全なアクセスのサポートは重要になるでしょう。
Borella, et al. Experimental [Page 13] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[13ページ]RFC3102RSIP: フレームワーク2001年10月
4.2. Cascaded RSIP and NAT
4.2. どっと落しているRSIPとNAT
It is possible for RSIP to allow for cascading of RSIP gateways as well as cascading of RSIP gateways with NAT boxes. For example, consider an ISP that uses RSIP for address sharing amongst its customers. It might assign resources (e.g., IP addresses and ports) to a particular customer. This customer may use RSIP to further subdivide the port ranges and address(es) amongst individual end hosts. No matter how many levels of RSIP assignment exists, RSIP MUST only assign public IP addresses.
RSIPがRSIPゲートウェイをどっと落させていて、NAT箱でRSIPゲートウェイをどっと落させると考慮するのは、可能です。 例えば、顧客の中で共有されるアドレスにRSIPを使用するISPを考えてください。 それはリソース(例えば、IPアドレスとポート)をうるさい顧客に割り当てるかもしれません。 この顧客は、個々の終わりのホストの中でさらに、ポート範囲とアドレス(es)を分筆するのにRSIPを使用するかもしれません。 いくつのレベルのRSIP課題が存在していても、RSIP MUSTは公共のIPアドレスを割り当てるだけです。
Note that some of the architectures discussed below may not be useful or desirable. The goal of this section is to explore the interactions between NAT and RSIP as RSIP is incrementally deployed on systems that already support NAT.
以下で議論したアーキテクチャのいくつかが役に立つか、または望ましくないかもしれないことに注意してください。 このセクションの目標はRSIPが既にNATをサポートするシステムの上で増加して配布されるときNATとRSIPとの相互作用を探検することです。
4.2.1. RSIP Behind RSIP
4.2.1. RSIPの後ろのRSIP
A reference architecture is depicted below.
参照アーキテクチャは以下に表現されます。
+-----------+
| |
| RSIP |
| gateway +---- 10.0.0.0/8
| B |
| |
+-----+-----+
|
| 10.0.1.0/24
+-----------+ | (149.112.240.0/25)
| | |
149.112.240.0/24| RSIP +--+
----------------+ gateway |
| A +--+
| | |
+-----------+ | 10.0.2.0/24
| (149.112.240.128/25)
|
+-----+-----+
| |
| RSIP |
| gateway +---- 10.0.0.0/8
| C |
| |
+-----------+
+-----------+ | | | RSIP| | ゲートウェイ+---- 10.0.0.0/8 | B| | | +-----+-----+ | | 10.0.1.0/24 +-----------+ | (149.112.240.0/25) | | | 149.112.240.0/24| RSIP+--+----------------+ ゲートウェイ| | +--+| | | +-----------+ | 10.0.2.0/24 | (149.112.240.128/25) | +-----+-----+ | | | RSIP| | ゲートウェイ+---- 10.0.0.0/8 | C| | | +-----------+
Borella, et al. Experimental [Page 14] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[14ページ]RFC3102RSIP: フレームワーク2001年10月
RSIP gateway A is in charge of the IP addresses of subnet 149.112.240.0/24. It distributes these addresses to RSIP hosts and RSIP gateways. In the given configuration, it distributes addresses 149.112.240.0 - 149.112.240.127 to RSIP gateway B, and addresses 149.112.240.128 - 149.112.240.254 to RSIP gateway C. Note that the subnet broadcast address, 149.112.240.255, must remain unclaimed, so that broadcast packets can be distributed to arbitrary hosts behind RSIP gateway A. Also, the subnets between RSIP gateway A and RSIP gateways B and C will use private addresses.
RSIPゲートウェイAがサブネット149.112.240のIPアドレスを担当して.0/24にあります。 それはRSIPホストとRSIPゲートウェイにこれらのアドレスを配布します。 サブネットはアドレスを放送しました、149.112。与えられた構成では、アドレスを配布する、149.112、.240、.0、--149.112 .240 .127 RSIPゲートウェイBにアドレス、149.112、.240、.128、149.112、.240、RSIPゲートウェイC.Noteへの.254、それ、.240 .255 RSIPゲートウェイA.Also、RSIPゲートウェイAとRSIPゲートウェイBの間のサブネットの後ろで任意のホストに放送パケットを分配できて、Cがプライベート・アドレスを使用するくらい要求されないままで残らなければなりません。
Due to the tree-like fashion in which addresses will be cascaded, we will refer to RSIP gateways A as the 'parent' of RSIP gateways B and C, and RSIP gateways B and C as 'children' of RSIP gateways A. An arbitrary number of levels of children may exist under a parent RSIP gateway.
アドレスがどっと落す木のようなファッションのため、私たちはRSIPゲートウェイBとCの'親'とRSIPゲートウェイAを呼ぶつもりです、そして、子供のレベルのRSIPゲートウェイA.An特殊活字の数字の'子供'としてのRSIPゲートウェイBとCは親RSIPゲートウェイの下に存在するかもしれません。
A parent RSIP gateway will not necessarily be aware that the address(es) and port blocks that it distributes to a child RSIP gateway will be further distributed. Thus, the RSIP hosts MUST tunnel their outgoing packets to the nearest RSIP gateway. This gateway will then verify that the sending host has used the proper address and port block, and then tunnel the packet on to its parent RSIP gateway.
親RSIPゲートウェイはそれが子供RSIPゲートウェイに配布するアドレス(es)とポートブロックがさらに配布されるのを必ず意識するというわけではないでしょう。 したがって、RSIPホストは最も近いRSIPゲートウェイに彼らの出発しているパケットにトンネルを堀らなければなりません。 このゲートウェイは、次に、送付ホストが適切なアドレスとポートブロックを使用したことを確かめて、次に、親RSIPゲートウェイにパケットにトンネルを堀るでしょう。
For example, in the context of the diagram above, host 10.0.0.1, behind RSIP gateway C will use its assigned external IP address (say, 149.112.240.130) and tunnel its packets over the 10.0.0.0/8 subnet to RSIP gateway C. RSIP gateway C strips off the outer IP header. After verifying that the source public IP address and source port number is valid, RSIP gateway C will tunnel the packets over the 10.0.2.0/8 subnet to RSIP gateway A. RSIP gateway A strips off the outer IP header. After verifying that the source public IP address and source port number is valid, RSIP gateway A transmits the packet on the public network.
例えば、上のダイヤグラムの文脈で接待する、10.0、.0、.1、RSIPの後ろでは、ゲートウェイCが割り当てられた外部のIPアドレスを使用する、(149.112の.240の言いたい事、.130、)およびトンネル、パケット、終わっている、10.0に、RSIPゲートウェイC. RSIPゲートウェイCへの.0.0/8サブネットは外側のIPヘッダーを下に裸にします。 ソースの公共のIPアドレスとソースポート番号が有効であることを確かめるCがパケットにトンネルを堀るRSIPゲートウェイの後に、10.0に、RSIPゲートウェイA. RSIPゲートウェイAへの.2.0/8サブネットは外側のIPヘッダーを全部はぎ取ります。 ソースの公共のIPアドレスとソースポート番号が有効なRSIPゲートウェイであることを確かめた後に、Aは公衆通信回線でパケットを伝えます。
While it may be more efficient in terms of computation to have a RSIP host tunnel directly to the overall parent of an RSIP gateway tree, this would introduce significant state and administrative difficulties.
計算で直接RSIPゲートウェイ木の総合的な親にRSIPホストトンネルを持っているのが、より効率的であるかもしれない間、これは重要な状態と管理困難を導入するでしょう。
A RSIP gateway that is a child MUST take into consideration the parameter assignment constraints that it inherits from its parent when it assigns parameters to its children. For example, if a child RSIP gateway is given a lease time of 3600 seconds on an IP address, it MUST compare the current time to the lease time and the time that the lease was assigned to compute the maximum allowable lease time on the address if it is to assign the address to a RSIP host or child RSIP gateway.
子供であるRSIPゲートウェイはパラメタを子供に割り当てるとき、親から世襲するというパラメタ課題規制を考慮に入れなければなりません。 例えば、IPアドレスの3600秒のリース時間を子供RSIPゲートウェイに与えるなら、RSIPホストか子供RSIPゲートウェイにアドレスを割り当てるつもりであるなら、それは、アドレスの最大の許容できるリース時間を計算するために現在の時間からリース時間とリースが割り当てられた時間を比較しなければなりません。
Borella, et al. Experimental [Page 15] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[15ページ]RFC3102RSIP: フレームワーク2001年10月
4.2.2. NAT Behind RSIP
4.2.2. RSIPの後ろのNAT
+--------+ +--------+
| NAT w/ | | RSIP |
hosts ------+ RSIP +------+ gate- +----- public network
| host | | way |
+--------+ +--------+
+--------+ +--------+ | NAT| | RSIP| ホスト------+ RSIP+------+ ゲート+----- 公衆通信回線| ホスト| | 道| +--------+ +--------+
In this architecture, an RSIP gateway is between a NAT box and the public network. The NAT is also equipped with an RSIP host. The NAT dynamically requests resources from the RSIP gateway as the hosts establish sessions to the public network. The hosts are not aware of the RSIP manipulation. This configuration does not enable the hosts to have end-to-end transparency and thus the NAT still requires ALGs and the architecture cannot support IPSEC.
このアーキテクチャには、NAT箱と公衆通信回線の間には、RSIPゲートウェイがあります。 また、NATはRSIPホストに持たせます。 ホストがセッションを公衆通信回線に確立するとき、NATはRSIPゲートウェイからリソースをダイナミックに要求します。 ホストはRSIP操作を意識していません。 この構成は、ホストには終わりから終わりへの透明があるのを有効にしません、そして、その結果、NATはまだALGsを必要としています、そして、アーキテクチャはIPSECをサポートすることができません。
4.2.3. RSIP Behind NAT
4.2.3. NATの後ろのRSIP
+--------+ +--------+
RSIP | RSIP | | |
hosts ------+ gate- +------+ NAT +----- public network
| way | | |
+--------+ +--------+
+--------+ +--------+ RSIP| RSIP| | | ホスト------+ ゲート+------+ NAT+----- 公衆通信回線| 道| | | +--------+ +--------+
In this architecture, the RSIP hosts and gateway reside behind a NAT. This configuration does not enable the hosts to have end-to-end transparency and thus the NAT still requires ALGs and the architecture cannot support IPSEC. The hosts may have transparency if there is another gateway to the public network besides the NAT box, and this gateway supports cascaded RSIP behind RSIP.
このアーキテクチャでは、RSIPホストとゲートウェイはNATの後ろに住んでいます。 この構成は、ホストには終わりから終わりへの透明があるのを有効にしません、そして、その結果、NATはまだALGsを必要としています、そして、アーキテクチャはIPSECをサポートすることができません。 ホストには、公衆通信回線へのもう1門がNAT箱以外にあれば、透明があるかもしれません、そして、このゲートウェイはRSIPの後ろでどっと落しているRSIPをサポートします。
4.2.4. RSIP Through NAT
4.2.4. NATを通したRSIP
+--------+ +--------+
RSIP | | | RSIP |
hosts ------+ NAT +------+ gate- +----- public network
| | | way |
+--------+ +--------+
+--------+ +--------+ RSIP| | | RSIP| ホスト------+ NAT+------+ ゲート+----- 公衆通信回線| | | 道| +--------+ +--------+
In this architecture, the RSIP hosts are separated from the RSIP gateway by a NAT. RSIP signaling may be able to pass through the NAT if an RSIP ALG is installed. The RSIP data flow, however, will have its outer IP address translated by the NAT. The NAT must not translate the port numbers in order for RSIP to work properly. Therefore, only traditional NAT will make sense in this context.
このアーキテクチャでは、RSIPホストはNATによってRSIPゲートウェイと切り離されます。 RSIP ALGがインストールされるなら、RSIPシグナリングはNATを通り抜けることができるかもしれません。 しかしながら、RSIPデータフローで、NATは外側のIPアドレスを翻訳するでしょう。 RSIPが適切に扱うように、NATはポートナンバーを翻訳してはいけません。 伝統的なNATだけがこのような関係においては理解できるでしょう。
Borella, et al. Experimental [Page 16] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[16ページ]RFC3102RSIP: フレームワーク2001年10月
5. Interaction with Layer-Three Protocols
5. 層-3つのプロトコルとの相互作用
Since RSIP affects layer-three objects, it has an impact on other layer three protocols. In this section, we outline the impact of RSIP on these protocols, and in each case, how RSIP, the protocol, or both, can be extended to support interaction.
RSIPが層-3個のオブジェクトに影響するので、それは他の層threeのプロトコルに影響を与えます。 このセクションで、私たちはこれらのプロトコルに、その都度RSIPの影響について概説します、どう、RSIP(プロトコル、または両方)を金属・担体相互作用に広げることができるか。
Each of these sections is an overview and not a complete technical specification. If a full technical specification of how RSIP interacts with a layer-three protocol is necessary, a separate document will contain it.
それぞれのこれらのセクションは完全な技術仕様書ではなく、概要です。 RSIPがどう層-3プロトコルと対話するかに関する完全な技術仕様書が必要であるなら、別々のドキュメントはそれを含むでしょう。
5.1. IPSEC
5.1. IPSEC
RSIP is a mechanism for allowing end-to-end IPSEC with sharing of IP addresses. Full specification of RSIP/IPSEC details are in [RSIP- IPSEC]. This section provides a brief summary. Since IPSEC may encrypt TCP/UDP port numbers, these objects cannot be used as demultiplexing fields. However, IPSEC inserts an AH or ESP header following the IP header in all IPSEC-protected packets (packets that are transmitted on an IPSEC Security Association (SA)). These headers contain a 32-bit Security Parameter Index (SPI) field, the value of which is determined by the receiving side. The SPI field is always in the clear. Thus, during SA negotiation, an RSIP host can instruct their public peer to use a particular SPI value. This SPI value, along with the assigned IP address, can be used by an RSIP gateway to uniquely identify and route packets to an RSIP host. In order to guarantee that RSIP hosts use SPIs that are unique per address, it is necessary for the RSIP gateway to allocate unique SPIs to hosts along with their address/port tuple.
RSIPは、IPアドレスを共有する終わりから終わりへのIPSECを許容するためのメカニズムです。 詳細があるRSIP/IPSECの完全な仕様[RSIP- IPSEC]。 このセクションは簡潔な概要を提供します。 IPSECがTCP/UDPポートナンバーを暗号化するかもしれないので、逆多重化分野としてこれらのオブジェクトを使用できません。 しかしながら、すべてのIPSECによって保護されたパケット(IPSEC Security Association(SA)で伝えられるパケット)でIPヘッダーに続いて、IPSECはAHか超能力ヘッダーを挿入します。 これらのヘッダーは32ビットのSecurity Parameter Index(SPI)分野を含んでいます。その値は受信側で決定しています。 SPI分野がいつも明確にあります。 したがって、SA交渉の間、RSIPホストは、特定のSPI値を使用するよう彼らの公共の同輩に命令できます。 唯一特定するRSIPゲートウェイとルートパケットは割り当てられたIPアドレスと共にこのSPI値をRSIPホストに使用できます。 RSIPホストがアドレス単位でユニークなSPIsを使用するのを保証するために、RSIPゲートウェイが彼らのアドレス/ポートtupleに伴うホストにユニークなSPIsを割り当てるのが必要です。
IPSEC SA negotiation takes place using the Internet Key Exchange (IKE) protocol. IKE is designated to use port 500 on at least the destination side. Some host IKE implementations will use source port 500 as well, but this behavior is not mandatory. If two or more RSIP hosts are running IKE at source port 500, they MUST use different initiator cookies (the first eight bytes of the IKE payload) per assigned IP address. The RSIP gateway will be able to route incoming IKE packets to the proper host based on initiator cookie value. Initiator cookies can be negotiated, like ports and SPIs. However, since the likelihood of two hosts assigned the same IP address attempting to simultaneously use the same initiator cookie is very small, the RSIP gateway can guarantee cookie uniqueness by dropping IKE packets with a cookie value that is already in use.
IPSEC SA交渉は、インターネット・キー・エクスチェンジ(IKE)プロトコルを使用することで行われます。 IKEは、少なくとも目的地の側の上のポート500を使用するために指定されます。 いくつかのホストIKE実装がまた、ソースポート500を使用するでしょうが、この振舞いは義務的ではありません。 2人以上のRSIPホストがソースポート500でIKEを実行しているなら、彼らは割り当てられたIPアドレスあたりの異なった創始者クッキー(IKEペイロードの最初の8バイト)を使用しなければなりません。 RSIPゲートウェイは創始者クッキー価値に基づく適切なホストに入って来るIKEパケットを発送できるでしょう。 ポートとSPIsのように創始者クッキーを交渉できます。 しかしながら、同時に同じ創始者クッキーを使用するのを試みる同じIPアドレスが割り当てられた2人のホストの見込みが非常に小さいので、RSIPゲートウェイは既に使用中のクッキー値に応じてIKEパケットを下げることによって、クッキーのユニークさを保証できます。
Borella, et al. Experimental [Page 17] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[17ページ]RFC3102RSIP: フレームワーク2001年10月
5.2. Mobile IP
5.2. モバイルIP
Mobile IP allows a mobile host to maintain an IP address as it moves from network to network. For Mobile IP foreign networks that use private IP addresses, RSIP may be applicable. In particular, RSIP would allow a mobile host to bind to a local private address, while maintaining a global home address and a global care-of address. The global care-of address could, in principle, be shared with other mobile nodes.
モバイルIPで、ネットワークからネットワークまで移行するとき、モバイルホストはIPアドレスを維持できます。 プライベートIPアドレスを使用するモバイルIP外国ネットワークにおいて、RSIPは適切であるかもしれません。 aグローバルなホームアドレスとaをグローバルに維持している間、特に、RSIPがローカルのプライベート・アドレスにモバイルホストを縛らせるだろう、注意、-、アドレス。 グローバルである、注意、-、原則として他のモバイルノードとアドレスを共有できました。
The exact behavior of Mobile IP with respect to private IP addresses has not be settled. Until it is, a proposal to adapt RSIP to such a scenario is premature. Also, such an adaptation may be considerably complex. Thus, integration of RSIP and Mobile IP is a topic of ongoing consideration.
プライベートIPアドレスに関するモバイルIPの正確な振舞いは決着していません。 そのようなシナリオにRSIPを適合させるという提案はそれがそうまで時期尚早です。 また、そのような適合もかなり複雑であるかもしれません。 したがって、RSIPとモバイルIPの統合は進行中の考慮の話題です。
5.3. Differentiated and Integrated Services
5.3. 差別化されて統合しているサービス
To attain the capability of providing quality of service between two communicating hosts in different realms, it is important to consider the interaction of RSIP with different quality of service provisioning models and mechanisms. In the section, RSIP interaction with the integrated service and differentiated service frameworks is discussed.
2の間の異なった分野でホストを伝えるサービスの質を提供する能力に達するように、異なったサービスの質がモデルとメカニズムに食糧を供給しているRSIPの相互作用を考えるのは重要です。セクションで、統合サービスと差別化されたサービスフレームワークとのRSIP相互作用について議論します。
5.3.1. Differentiated Services
5.3.1. 差別化されたサービス
The differentiated services architecture defined in [RFC2475] allows networks to support multiple levels of best-effort service through the use of "markings" of the IP Type-of-Service (now DS) byte. Each value of the DS byte is termed a differentiated services code point (DSCP) and represents a particular per-hop behavior. This behavior may not be the same in all administrative domains. No explicit signaling is necessary to support differentiated services.
[RFC2475]で定義された差別化されたサービスアーキテクチャで、ネットワークはサービスのIP Type(現在のDS)バイトの「印」の使用で複数のレベルのベストエフォート型サービスをサポートすることができます。 DSバイトの各値は、差別化されたサービスコード・ポイント(DSCP)と呼ばれて、1ホップあたり1つの特定の振舞いを表します。 この振舞いはすべての管理ドメインで同じでないかもしれません。 どんな明白なシグナリングも、差別化されたサービスをサポートするのに必要ではありません。
For outbound packets from an edge network, DSCP marking is typically performed and/or enforced on a boundary router. The marked packet is then forwarded onto the public network. In an RSIP-enabled network, a natural place for DSCP marking is the RSIP gateway. In the case of RSAP-IP, the RSIP gateway can apply its micro-flow (address/port tuple) knowledge of RSIP assignments in order to provide different service levels to different RSIP host. For RSA-IP, the RSIP gateway will not necessarily have knowledge of micro-flows, so it must rely on markings made by the RSIP hosts (if any) or apply a default policy to the packets.
縁のネットワークからの外国行きのパケットに関しては、DSCPマークは、境界ルータで通常実行される、そして/または、実施されます。 そして、著しいパケットを公衆通信回線に送ります。 RSIPによって可能にされたネットワークでは、DSCPマークのための自然な場所はRSIPゲートウェイです。 RSAP-IPの場合では、RSIPゲートウェイは、異なったRSIPホストに異なったサービスレベルを提供するためにRSIP課題に関するマイクロ流れ(アドレス/ポートtuple)知識を適用できます。 RSA-IPに関しては、RSIPゲートウェイにはマイクロ流れに関する知識が必ずあるというわけではないので、それは、RSIPホスト(もしあれば)によって作られた印を当てにしなければならないか、またはデフォルト方針をパケットに適用しなければなりません。
Borella, et al. Experimental [Page 18] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[18ページ]RFC3102RSIP: フレームワーク2001年10月
When differentiated services is to be performed between RSIP hosts and gateways, it must be done over the tunnel between these entities. Differentiated services over a tunnel is considered in detail in [DS-TUNN], the key points that need to be addressed here are the behaviors of tunnel ingress and egress for both incoming and going packets.
差別化されたサービスがRSIPホストとゲートウェイの間で実行することであるときに、これらの実体の間のトンネルの上にそれをしなければなりません。 トンネルの上の差別化されたサービスは[DS-TUNN]で詳細に考えられて、ここで扱われる必要がある要所は入って来るものと同様に行っているパケットのためのトンネルイングレスと出口の振舞いです。
For incoming packets arriving at an RSIP gateway tunnel ingress, the RSIP gateway may either copy the DSCP from the inner header to the outer header, leave the inner header DSCP untouched, but place a different DSCP in the outer header, or change the inner header DSCP while applying either the same or a different DSCP to the outer header.
RSIPゲートウェイトンネルイングレスに到着する入って来るパケットに関しては、RSIPゲートウェイは、同じくらいか異なったDSCPのどちらかを外側のヘッダーに適用している間、内側のヘッダーから外側のヘッダーまでDSCPをコピーするか、異なったDSCPを外側のヘッダーに置くのを除いて、触れない状態で内側のヘッダーDSCPを残すか、または内側のヘッダーDSCPを変えるかもしれません。
For incoming packets arriving at an RSIP host tunnel egress, behavior with respect to the DSCP is not necessarily important if the RSIP host not only terminates the tunnel, but consumes the packet as well. If this is not the case, as per some cascaded RSIP scenarios, the RSIP host must apply local policy to determine whether to leave the inner header DSCP as is, overwrite it with the outer header DSCP, or overwrite it with a different value.
RSIPホストトンネル出口に到着する入って来るパケットに関しては、RSIPホストがトンネルを終えるだけではなく、また、パケットを消費するなら、DSCPに関する振舞いは必ず重要であるというわけではありません。 これがそうでないなら、いくつかのどっと落しているRSIPシナリオに従って、RSIPホストは、そのままで内側のヘッダーをDSCPに置き去りにするか、外側のヘッダーDSCPと共にそれを上書きするか、または異価でそれを上書きするかを決定するためにローカルの方針を適用しなければなりません。
For outgoing packets arriving at an RSIP host tunnel ingress, the host may either copy the DSCP from the inner header to the outer header, leave the inner header DSCP untouched, but place a different DSCP in the outer header, or change the inner header DSCP while applying either the same or a different DSCP to the outer header.
RSIPホストトンネルイングレスに到着する出発しているパケットに関しては、ホストは、同じくらいか異なったDSCPのどちらかを外側のヘッダーに適用している間、内側のヘッダーから外側のヘッダーまでDSCPをコピーするか、異なったDSCPを外側のヘッダーに置くのを除いて、触れない状態で内側のヘッダーDSCPを残すか、または内側のヘッダーDSCPを変えるかもしれません。
For outgoing packets arriving at an RSIP gateway tunnel egress, the RSIP gateway must apply local policy to determine whether to leave the inner header DSCP as is, overwrite it with the outer header DSCP, or overwrite it with a different value.
RSIPゲートウェイトンネル出口に到着する出発しているパケットに関しては、RSIPゲートウェイは、そのままで内側のヘッダーをDSCPに置き去りにするか、外側のヘッダーDSCPと共にそれを上書きするか、または異価でそれを上書きするかを決定するためにローカルの方針を適用しなければなりません。
It is reasonable to assume that in most cases, the diffserv policy applicable on a site will be the same for RSIP and non-RSIP hosts. For this reason, a likely policy is that the DSCP will always be copied between the outer and inner headers in all of the above cases. However, implementations should allow for the more general case.
多くの場合、サイトで適切なdiffserv方針がRSIPと非RSIPホストにとって同じになると仮定するのは妥当です。 この理由で、ありそうな方針はDSCPが上のケースのすべての外側の、そして、内側のヘッダーの間にいつもコピーされるということです。 しかしながら、実装は、より一般的なケースを考慮するべきです。
5.3.2. Integrated Services
5.3.2. 統合サービス
The integrated services model as defined by [RFC2205] requires signalling using RSVP to setup a resource reservation in intermediate nodes between the communicating endpoints. In the most common scenario in which RSIP is deployed, receivers located within the private realm initiate communication sessions with senders located within the public realm. In this section, we discuss the interaction of RSIP architecture and RSVP in such a scenario. The less common
[RFC2205]によって定義される統合サービスモデルは、交信終点の間の中間的ノードにおける資源予約をセットアップするのにRSVPを使用することで合図するのを必要とします。 RSIPが配布される最も一般的なシナリオでは、私設の分野の中に位置した受信機は公共部門の中に位置している送付者とのコミュニケーションセッションを開始します。 このセクションで、私たちはそのようなシナリオでRSIPアーキテクチャとRSVPの相互作用について議論します。 それほど一般的でない
Borella, et al. Experimental [Page 19] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[19ページ]RFC3102RSIP: フレームワーク2001年10月
case of having senders within the private realm and receivers within the public realm is not discussed although concepts mentioned here may be applicable.
ここに言及された概念は適切であるかもしれませんが、送付者が公共部門の中に私設の分野と受信機の中にいるケースについて議論しません。
With senders in the public realm, RSVP PATH messages flow downstream from sender to receiver, inbound with respect to the RSIP gateway, while RSVP RESV messages flow in the opposite direction. Since RSIP uses tunneling between the RSIP host and gateway within the private realm, how the RSVP messages are handled within the RSIP tunnel depends on situations elaborated in [RFC2746].
公共部門の送付者と共に、RSVP PATHメッセージは川下を送付者から受信機まで流れます、RSIPゲートウェイに関して本国行きです、RSVP RESVメッセージが逆方向に流れますが。 RSIPが私設の分野の中でRSIPホストとゲートウェイの間のトンネリングを使用するので、RSVPメッセージがRSIPトンネルの中でどう扱われるかは[RFC2746]に詳しく説明された状況に依存します。
Following the terminology of [RFC2476], if Type 1 tunnels exist between the RSIP host and gateway, all intermediate nodes inclusive of the RSIP gateway will be treated as a non-RSVP aware cloud without QoS reserved on these nodes. The tunnel will be viewed as a single (logical) link on the path between the source and destination. End- to-end RSVP messages will be forwarded through the tunnel encapsulated in the same way as normal IP packets. We see this as the most common and applicable deployment scenario.
Type1トンネルがRSIPホストとゲートウェイの間に存在しているなら[RFC2476]の用語に従って、RSIPゲートウェイを包含すべての中間的ノードがこれらのノードの上で予約されたQoSなしで非RSVPの意識している雲として扱われるでしょう。 トンネルはソースと目的地の間の経路の単一(論理的な)のリンクとして見なされるでしょう。 正常なIPパケットと同様に、カプセル化されたトンネルを通して終わりまでの終わりのRSVPメッセージを転送するでしょう。 私たちは最も一般的で適切な展開シナリオであるとこれをみなします。
However, should Type 2 or 3 tunnels be deployed between the tunneling endpoints , end-to-end RSVP session has to be statically mapped (Type 2) or dynamically mapped (Type 3) into the tunnel sessions. While the end-to-end RSVP messages will be forwarded through the tunnel encapsulated in the same way as normal IP packets, a tunnel session is established between the tunnel endpoints to ensure QoS reservation within the tunnel for the end-to-end session. Data traffic needing special QoS assurance will be encapsulated in a UDP/IP header while normal traffic will be encapsulated using the normal IP-IP encapsulation. In the type 2 deployment scenario where all data traffic flowing to the RSIP host receiver are given QoS treatment, UDP/IP encapsulation will be rendered in the RSIP gateway for all data flows. The tunnel between the RSIP host and gateway could be seen as a "hard pipe". Traffic exceeding the QoS guarantee of the "hard pipe" would fall back to the best effort IP-IP tunneling.
しかしながら、終わりから終わりへのRSVPセッションは、Type2か3トンネルがトンネリング終点の間で配布されるなら静的に写像されなければならないか(2をタイプします)、またはトンネルセッションまでダイナミックに写像されなければなりません(3をタイプします)。 正常なIPパケットと同様に、カプセル化されたトンネルを通して終わりから終わりへのRSVPメッセージを転送するでしょうが、終わりから終わりへのセッションのためにトンネルの中でQoSの予約を確実にするためにトンネル終点の間でトンネルセッションを確立します。 正常なトラフィックが正常なIP-IPカプセル化を使用することでカプセル化されている間、特別なQoS保証を必要とするデータ通信量がUDP/IPヘッダーでカプセル化されるでしょう。 すべてのデータトラフィック流動がQoS処理をRSIPホスト受信機に与えられているタイプ2展開シナリオでは、UDP/IPカプセル化はすべてのデータフローのためにRSIPゲートウェイにされるでしょう。 「固いパイプ」とRSIPホストとゲートウェイの間のトンネルを見ることができました。 「固いパイプ」のQoS保証を超えているトラフィックがベストエフォート型IP-IPトンネリングへ後ろへ下がるでしょう。
In the type 2 deployment scenario where data traffic could be selectively channeled into the UDP/IP or normal IP-IP tunnel, or for type 3 deployment where end-to-end sessions could be dynamically mapped into tunnel sessions, integration with the RSIP model could be complicated and tricky. (Note that these are the cases where the tunnel link could be seen as a expandable soft pipe.) Two main issues are worth considering.
タイプ3展開に、RSIPモデルによる統合は、トンネルセッションまでダイナミックに終わりから終わりへのセッションを写像できたところでタイプの選択的にUDP/IPにデータ通信量を向けることができた2展開シナリオか正常なIP-IPでは、トンネルを堀ってください。さもないと、複雑であって、扱いにくいかもしれません。 (これらがトンネルのリンクを拡張可能な軟質のパイプと考えることができたケースであることに注意してください。) 2つの本題は考える価値があります。
- For RSIP gateway implementations that does encapsulation of the
incoming stream before passing to the IP layer for forwarding,
the RSVP daemon has to be explicitly signaled upon reception of
incoming RSVP PATH messages. The RSIP implementation has to
- RSIPゲートウェイ実装のために、それは推進のためにIP層に通る前に入って来るストリームのカプセル化をして、RSVPデーモンは入って来るRSVP PATHメッセージのレセプションで明らかに合図されなければなりません。 RSIP実装はそうしなければなりません。
Borella, et al. Experimental [Page 20] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[20ページ]RFC3102RSIP: フレームワーク2001年10月
recognize RSVP PATH messages and pass them to the RSVP daemon
instead of doing the default tunneling. Handling of other RSVP
messages would be as described in [RFC2746].
RSVP PATHメッセージを認識してください、そして、デフォルトトンネリングをすることの代わりにRSVPデーモンにそれらを通過してください。 他のRSVPメッセージの取り扱いが[RFC2746]で説明されるようにあるでしょう。
- RSIP enables an RSIP host to have a temporary presence at the
RSIP gateway by assuming one of the RSIP gateway's global
interfaces. As a result, the RSVP PATH messages would be
addressed to the RSIP gateway. Also, the RSVP SESSION object
within an incoming RSVP PATH would carry the global destination
address, destination port (and protocol) tuples that were
leased by the RSIP gateway to the RSIP host. Hence the realm
unaware RSVP daemon running on the RSIP gateway has to be
presented with a translated version of the RSVP messages.
Other approaches are possible, for example making the RSVP
daemon realm aware.
- RSIPは、RSIPホストがRSIPゲートウェイにRSIPゲートウェイのグローバルなインタフェースの1つを仮定することによって一時的な存在を飼っているのを可能にします。 その結果、RSVP PATHメッセージはRSIPゲートウェイに扱われるでしょう。 また、入って来るRSVP PATHの中のRSVP SESSIONオブジェクトはグローバルな送付先アドレス(RSIPホストへのRSIPゲートウェイによって賃貸された仕向港(議定書を作る)tuples)を運ぶでしょう。 したがって、RSIPゲートウェイで動く分野の気づかないRSVPデーモンにRSVPメッセージの翻訳されたバージョンを与えなければなりません。 例えば、RSVPデーモン分野を意識するようにして、他のアプローチは可能です。
A simple mechanism would be to have the RSIP module handle the necessary RSVP message translation. For an incoming RSVP signalling flow, the RSIP module does a packet translation of the IP header and RSVP SESSION object before handling the packet over to RSVP. The global address leased to the host is translated to the true private address of the host. (Note that this mechanism works with both RSA- IP and RSAP-IP.) The RSIP module also has to do an opposite translation from private to global parameter (plus tunneling) for end-to-end PATH messages generated by the RSVP daemon towards the RSIP host receiver. A translation on the SESSION object also has to be done for RSVP outbound control messages. Once the RSVP daemon gets the message, it maps them to an appropriate tunnel sessions.
簡単なメカニズムはRSIPモジュールに必要なRSVPメッセージ翻訳を扱わせるだろうことです。 入って来るRSVP合図流動のために、RSVPにパケットを扱う前に、RSIPモジュールはIPヘッダーとRSVP SESSIONオブジェクトに関するパケット翻訳をします。 ホストに賃貸されたグローバルアドレスはホストの正しいプライベート・アドレスに翻訳されます。 (このメカニズムがRSA IPとRSAP-IPの両方で働くことに注意してください。) RSIPモジュールも終わりから終わりへのPATH RSVPデーモンによってRSIPホスト受信機に向かって生成されたメッセージのために反対の個人的なパラメタからグローバルなパラメタ(プラストンネリング)までの翻訳をしなければなりません。RSVPの外国行きのコントロールメッセージのためにSESSIONオブジェクトに関する翻訳もしなければなりません。 RSVPデーモンがいったん意味を了解すると、それは適切なトンネルセッションまでそれらを写像します。
Encapsulation of the inbound data traffic needing QoS treatment would be done using UDP-IP encapsulation designated by the tunnel session. For this reason, the RSIP module has to be aware of the UDP-IP encapsulation to use for a particular end-to-end session. Classification and scheduling of the QoS guaranteed end-to-end flow on the output interface of the RSIP gateway would be based on the UDP/IP encapsulation. Mapping between the tunnel session and end- to-end session could continue to use the mechanisms proposed in [RFC2746]. Although [RFC2746] proposes a number of approaches for this purpose, we propose using the SESSION_ASSOC object introduced because of its simplicity.
QoS処理を必要とするインバウンドデータトラフィックのカプセル化はトンネルセッションで指定されたUDP-IPカプセル化を使用し終わっているでしょう。 この理由で、RSIPモジュールは終わりから終わりへの特定のセッションに使用するUDP-IPカプセル化を意識していなければなりません。 終わりから終わりへの流動がRSIPゲートウェイの出力インタフェースで保証されたQoSの分類とスケジューリングはUDP/IPカプセル化に基づくでしょう。 トンネルセッションと終わりまでの終わりのセッションの間のマッピングは、[RFC2746]で提案されたメカニズムを使用し続けるかもしれません。 [RFC2746]はこのために多くのアプローチを提案しますが、私たちは、簡単さのために導入されたSESSION_ASSOCオブジェクトを使用するよう提案します。
5.4. IP Multicast
5.4. IPマルチキャスト
The amount of specific RSIP/multicast support that is required in RSIP hosts and gateways is dependent on the scope of multicasting in the RSIP-enabled network, and the roles that the RSIP hosts will play. In this section, we discuss RSIP and multicast interactions in a number of scenarios.
RSIPホストとゲートウェイで必要である特定のRSIP/マルチキャストサポートの量はRSIPによって可能にされたネットワークにおけるマルチキャスティングの範囲、およびRSIPホストが果たす役割に依存しています。 このセクションで、私たちは多くのシナリオにおけるRSIPとマルチキャスト相互作用について議論します。
Borella, et al. Experimental [Page 21] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[21ページ]RFC3102RSIP: フレームワーク2001年10月
Note that in all cases, the RSIP gateway MUST be multicast aware because it is on an administrative boundary between two domains that will not be sharing their all of their routing information. The RSIP gateway MUST NOT allow private IP addresses to be propagated on the public network as part of any multicast message or as part of a routing table.
すべての場合では、RSIPゲートウェイがそれが2つのドメインの間の管理境界にあるのでそれが共有されないのを意識しているマルチキャストであるに違いないことに注意してください、それら、それらのルーティング情報のすべて。 RSIPゲートウェイは、プライベートIPアドレスがどんなマルチキャストメッセージの一部として、または、経路指定テーブルの一部として公衆通信回線で伝播されるのを許容してはいけません。
5.4.1. Receiving-Only Private Hosts, No Multicast Routing on
Private Network
5.4.1. 受信唯一の個人的なホスト、私設のネットワークにおけるいいえマルチキャストルート設定
In this scenario, private hosts will not source multicast traffic, but they may join multicast groups as recipients. In the private network, there are no multicast-aware routers, except for the RSIP gateway.
このシナリオでは、個人的なホストはマルチキャストトラフィックの出典を明示しないでしょうが、彼らは受取人としてマルチキャストグループに加わるかもしれません。 私設のネットワークには、RSIPゲートウェイ以外のどんなマルチキャスト意識しているルータもありません。
Private hosts may join and leave multicast groups by sending the appropriate IGMP messages to an RSIP gateway (there may be IGMP proxy routers between RSIP hosts and gateways). The RSIP gateway will coalesce these requests and perform the appropriate actions, whether they be to perform a multicast WAN routing protocol, such as PIM, or to proxy the IGMP messages to a WAN multicast router. In other words, if one or more private hosts request to join a multicast group, the RSIP gateway MUST join in their stead, using one of its own public IP addresses.
個人的なホストは、適切なIGMPメッセージをRSIPゲートウェイに送ることによって、マルチキャストグループに加わって、出るかもしれません(RSIPホストとゲートウェイの間には、IGMPプロキシルータがあるかもしれません)。 RSIPゲートウェイは、これらの要求を合体させて、適切な行動を実行するでしょう、それらがマルチキャストWANルーティング・プロトコル、PIMなどか、プロキシにIGMPメッセージをWANマルチキャストルータに実行することになっているか否かに関係なく。 言い換えれば、1人以上の個人的なホストが、マルチキャストを接合するために、分類するよう要求するなら、RSIPゲートウェイは彼らの代わりに参加しなければなりません、それ自身の公共のIPアドレスの1つを使用して。
Note that private hosts do not need to acquire demultiplexing fields and use RSIP to receive multicasts. They may receive all multicasts using their private addresses, and by private address is how the RSIP gateway will keep track of their group membership.
個人的なホストが逆多重化野原を取得して、マルチキャストを受けるのにRSIPを使用する必要はないことに注意してください。 彼らはそれらのプライベート・アドレスを使用することですべてのマルチキャストを受けるかもしれません、そして、個人的で、アドレスはRSIPゲートウェイがどうそれらのグループ会員資格の動向をおさえるかということです。
5.4.2. Sending and Receiving Private Hosts, No Multicast Routing
on Private Network
5.4.2. 送受信の個人的なホスト、私設のネットワークにおけるいいえマルチキャストルート設定
This scenarios operates identically to the previous scenario, except that when a private host becomes a multicast source, it MUST use RSIP and acquire a public IP address (note that it will still receive on its private address). A private host sending a multicast will use a public source address and tunnel the packets to the RSIP gateway. The RSIP gateway will then perform typical RSIP functionality, and route the resulting packets onto the public network, as well as back to the private network, if there are any listeners on the private network.
このシナリオは同様に前のシナリオに作動します、個人的なホストがマルチキャストソースになると、RSIPを使用して、公共のIPアドレスを習得しなければならないのを除いて(それでも、それがプライベート・アドレスで受信されることに注意してください)。 マルチキャストを送る個人的なホストは、公共のソースアドレスを使用して、RSIPゲートウェイにパケットにトンネルを堀るでしょう。 RSIPゲートウェイは、公衆通信回線と、そして、私設のネットワークに次に、典型的なRSIPの機能性を実行して、結果として起こるパケットを発送して戻すでしょう、何かリスナーが私設のネットワークの一員であれば。
If there is more than one sender on the private network, then, to the public network it will seem as if all of these senders share the same IP address. If a downstream multicasting protocol identifies sources
次に、1人以上の送付者が公衆通信回線への私設のネットワークの一員であれば、まるでこれらの送付者が皆、同じIPアドレスを共有するかのように見えるでしょう。 川下のマルチキャスティングプロトコルがソースを特定するなら
Borella, et al. Experimental [Page 22] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[22ページ]RFC3102RSIP: フレームワーク2001年10月
based on IP address alone and not port numbers, then it is possible that these protocols will not be able to distinguish between the senders.
ポートナンバーではなく、IPアドレスだけに基づいて、その時、これらのプロトコルが送付者を見分けることができないのは、可能です。
6. RSIP Complications
6. RSIP複雑さ
In this section we document the know complications that RSIP may cause. While none of these complications should be considered "show stoppers" for the majority of applications, they may cause unexpected or undefined behavior. Where it is appropriate, we discuss potential remedial procedures that may reduce or eliminate the deleterious impact of a complication.
私たちが記録するこのセクション、RSIPが引き起こすかもしれない複雑さを知ってください。 アプリケーションの大部分の「名役者」であるとこれらの複雑さのどれかを考えるべきでない間、それらは予期していなかったか未定義の振舞いを引き起こすかもしれません。 それが適切であるところでは、私たちは複雑さの有害な影響を減少するか、または排除するかもしれない潜在的補修の手順について議論します。
6.1. Unnecessary TCP TIME_WAIT
6.1. 不要なTCPタイム誌_は待っています。
When TCP disconnects a socket, it enters the TCP TIME_WAIT state for a period of time. While it is in this state it will refuse to accept new connections using the same socket (i.e., the same source address/port and destination address/port). Consider the case in which an RSIP host (using RSAP-IP) is leased an address/port tuple and uses this tuple to contact a public address/port tuple. Suppose that the host terminates the session with the public tuple and immediately returns its leased tuple to the RSIP gateway. If the RSIP gateway immediately allocates this tuple to another RSIP host (or to the same host), and this second host uses the tuple to contact the same public tuple while the socket is still in the TIME_WAIT phase, then the host's connection may be rejected by the public host.
TCPがソケットから切断すると、それはしばらく、TCP TIME_WAIT状態に入ります。 この状態にある間、それは、同じソケット(すなわち、同じソースアドレス/ポートと目的地アドレス/港)を使用することで新しい接続を受け入れるのを拒否するでしょう。 RSIPホスト(RSAP-IPを使用する)が賃貸されて、アドレス/がtupleを移植するということであり、このtupleを使用する場合が場内放送/ポートtupleに連絡すると考えてください。 ホストが公共のtupleでセッションを終えて、すぐに賃貸されたtupleをRSIPゲートウェイに返すと仮定してください。 RSIPゲートウェイがすぐに、別のRSIPホスト(または同じホストに)にこのtupleを割り当てて、この2番目のホストがソケットがまだタイム誌_WAITフェーズにある間、同じ公共のtupleに連絡するのにtupleを使用するなら、ホストの接続は公共のホストによって拒絶されるかもしれません。
In order to mitigate this problem, it is recommended that RSIP gateways hold recently deallocated tuples for at least two minutes, which is the greatest duration of TIME_WAIT that is commonly implemented. In situations where port space is scarce, the RSIP gateway MAY choose to allocate ports in a FIFO fashion from the pool of recently deallocated ports.
この問題を緩和するために、RSIPゲートウェイが最近少なくとも2分間deallocated tuplesを維持するのは、お勧めです。(分間は一般的に実装されるタイム誌_WAITの最も大きい持続時間です)。 ポートスペースが不十分である状況で、RSIPゲートウェイは、最近「反-割り当て」られたポートのプールから先入れ先出し法ファッションでポートを割り当てるのを選ぶかもしれません。
6.2. ICMP State in RSIP Gateway
6.2. RSIPゲートウェイにおけるICMP状態
Like NAT, RSIP gateways providing RSAP-IP must process ICMP responses from the public network in order to determine the RSIP host (if any) that is the proper recipient. We distinguish between ICMP error packets, which are transmitted in response to an error with an associated IP packet, and ICMP response packets, which are transmitted in response to an ICMP request packet.
NATのように、RSAP-IPを提供するRSIPゲートウェイは、適切な受取人であるRSIPホスト(もしあれば)を決定するために公衆通信回線からICMP応答を処理しなければなりません。 私たちはICMP誤りパケットとICMP応答パケットを見分けます。(パケットは関連IPパケットがある誤りに対応して伝えられます)。(パケットはICMPリクエスト・パケットに対応して伝えられます)。
ICMP request packets originating on the private network will typically consist of echo request, timestamp request and address mask request. These packets and their responses can be identified by the tuple of source IP address, ICMP identifier, ICMP sequence number,
タイムスタンプ要求とアドレスマスクは、私設のネットワークで起因するICMPリクエスト・パケットがエコー要求から通常成るよう要求します。 ソースIPアドレス、ICMP識別子、ICMP一連番号のtupleはこれらのパケットと彼らの応答を特定できます。
Borella, et al. Experimental [Page 23] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[23ページ]RFC3102RSIP: フレームワーク2001年10月
and destination IP address. An RSIP host sending an ICMP request packet tunnels it to the RSIP gateway, just as it does TCP and UDP packets. The RSIP gateway must use this tuple to map incoming ICMP responses to the private address of the appropriate RSIP host. Once it has done so, it will tunnel the ICMP response to the host. Note that it is possible for two RSIP hosts to use the same values for the tuples listed above, and thus create an ambiguity. However, this occurrence is likely to be quite rare, and is not addressed further in this document.
そして、送付先IPアドレス。 ICMPリクエスト・パケットを送るRSIPホストはRSIPゲートウェイにそれにトンネルを堀ります、ちょうどTCPとUDPにパケットをするように。 RSIPゲートウェイは、適切なRSIPホストのプライベート・アドレスへの入って来るICMP応答を写像するのにこのtupleを使用しなければなりません。 いったんそうすると、それはホストへのICMP応答にトンネルを堀るでしょう。 2人のRSIPホストが上に記載されたtuplesに同じ値を使用するのが、可能であることに注意してください、そして、その結果、あいまいさを作成してください。 しかしながら、この発生は、かなりまれであることがありそうであり、さらに本書では演説されません。
Incoming ICMP error response messages can be forwarded to the appropriate RSIP host by examining the IP header and port numbers embedded within the ICMP packet. If these fields are not present, the packet should be silently discarded.
ICMPパケットの中で埋め込まれたIPヘッダーとポートナンバーを調べることによって、入って来るICMP誤り応答メッセージを適切なRSIPホストに送ることができます。 これらの分野が存在していないなら、パケットは静かに捨てられるべきです。
Occasionally, an RSIP host will have to send an ICMP response (e.g., port unreachable). These responses are tunneled to the RSIP gateway, as is done for TCP and UDP packets. All ICMP requests (e.g., echo request) arriving at the RSIP gateway MUST be processed by the RSIP gateway and MUST NOT be forwarded to an RSIP host.
時折、RSIPホストがICMP応答を送らなければならない、(例えば、ポート手の届かない、) これらの応答はそのままなRSIPゲートウェイにTCPとUDPパケットのためにしていた状態でトンネルを堀られます。 RSIPゲートウェイに到着するすべてのICMP要求(例えば、エコー要求)を、RSIPゲートウェイで処理しなければならなくて、RSIPホストに転送してはいけません。
6.3. Fragmentation and IP Identification Field Collision
6.3. 断片化とIP識別分野衝突
If two or more RSIP hosts on the same private network transmit outbound packets that get fragmented to the same public gateway, the public gateway may experience a reassembly ambiguity if the IP header ID fields of these packets are identical.
同じ私設のネットワークの2人以上のRSIPホストが同じ公共のゲートウェイに断片化される外国行きのパケットを伝えるなら、これらのパケットのIPヘッダーID分野が同じであるなら、公共のゲートウェイは再アセンブリのあいまいさを経験するかもしれません。
For TCP packets, a reasonably small MTU can be set so that fragmentation is guaranteed not to happen, or the likelihood or fragmentation is extremely small. If path MTU discovery works properly, the problem is mitigated. For UDP, applications control the size of packets, and the RSIP host stack may have to fragment UDP packets that exceed the local MTU. These packets may be fragmented by an intermediate router as well.
TCPパケットにおいて、合理的に小さいMTUが用意ができることができるので、断片化が起こらないように保証されるか、または見込みか断片化が非常に小さいです。 経路MTU探索が適切に働いているなら、問題は緩和されます。 UDPに関しては、アプリケーションはパケットのサイズを制御します、そして、RSIPホストスタックは地方のMTUを超えているUDPパケットを断片化しなければならないかもしれません。 これらのパケットはまた、中間的ルータによって断片化されるかもしれません。
The only completely robust solution to this problem is to assign all RSIP hosts that are sharing the same public IP address disjoint blocks of numbers to use in their IP identification fields. However, whether this modification is worth the effort of implementing is currently unknown.
この問題への唯一の完全に強健な解決はすべてのRSIPを割り当てるために、同じ公共のIPアドレスを共有しているホストがそれらのIP識別分野で使用するブロックの数をばらばらにならせるということです。 しかしながら、この変更は実装することの取り組みの価値があるかどうかが、現在、未知です。
6.4. Application Servers on RSAP-IP Hosts
6.4. RSAP-IPホストの上のアプリケーション・サーバー
RSAP-IP hosts are limited by the same constraints as NAT with respect to hosting servers that use a well-known port. Since destination port numbers are used as routing information to uniquely identify an RSAP-IP host, typically no two RSAP-IP hosts sharing the same public
RSAP-IPホストはウェルノウンポートを使用するホストサーバに関してNATと同じ規制で制限されます。 目的地ポートナンバーが唯一RSAP-IPホストを特定するために情報を発送するとして使用されるので、通常、いいえtwo、RSAP-IPは同じ共有している公衆を接待します。
Borella, et al. Experimental [Page 24] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[24ページ]RFC3102RSIP: フレームワーク2001年10月
IP address can simultaneously operate publically-available gateways on the same port. For protocols that operate on well-known ports, this implies that only one public gateway per RSAP-IP IP address / port tuple is used simultaneously. However, more than one gateway per RSAP-IP IP address / port tuple may be used simultaneously if and only if there is a demultiplexing field within the payload of all packets that will uniquely determine the identity of the RSAP-IP host, and this field is known by the RSIP gateway.
IPアドレスは同時に、同じポートの上の利用可能なpublicallyゲートウェイを操作できます。 ウェルノウンポートを作動させるプロトコルのために、これは、RSAP-IP IPアドレス/ポートtupleあたり公共の1つの門だけが同時に使用されるのを含意します。 そして、しかしながら、RSAP-IP IPアドレス/ポートtupleあたり1門以上が同時に使用されるかもしれない、すべてのパケットのペイロードの中に逆多重化分野がある場合にだけ、それは唯一RSAP-IPホストのアイデンティティを決定して、この分野はRSIPゲートウェイによって知られています。
In order for an RSAP-IP host to operate a publically-available gateway, the host must inform the RSIP gateway that it wishes to receive all traffic destined to that port number, per its IP address. Such a request MUST be denied if the port in question is already in use by another host.
RSAP-IPホストが利用可能なpublicallyゲートウェイを操作するように、ホストは、そのポートナンバーに運命づけられたすべてのトラフィックを受けたがっていることをRSIPゲートウェイに知らせなければなりません、IPアドレス単位で。 問題のポートが別のホストで既に使用中であるなら、そのような要求を否定しなければなりません。
In general, contacting devices behind an RSIP gateway may be difficult. A potential solution to the general problem would be an architecture that allows an application on an RSIP host to register a public IP address / port pair in a public database. Simultaneously, the RSIP gateway would initiate a mapping from this address / port tuple to the RSIP host. A peer application would then be required to contact the database to determine the proper address / port at which to contact the RSIP host's application.
一般に、RSIPゲートウェイの後ろでデバイスに連絡するのは難しいかもしれません。 一般的問題への潜在的解決はRSIPホストにおけるアプリケーションが公共のデータベースに公共のIPアドレス/ポート組を登録できるアーキテクチャでしょう。 同時に、RSIPゲートウェイはこのアドレス/ポートtupleからRSIPホストまでマッピングを開始するでしょう。 そして、同輩アプリケーションが、RSIPホストのアプリケーションに連絡する適切なアドレス/ポートを決定するためにデータベースに連絡するのに必要でしょう。
6.5. Determining Locality of Destinations from an RSIP Host
6.5. RSIPホストから目的地の場所を決定します。
In general, an RSIP host must know, for a particular IP address, whether it should address the packet for local delivery on the private network, or if it has to use an RSIP interface to tunnel to an RSIP gateway (assuming that it has such an interface available).
一般に、RSIPホストは知らなければなりません、特定のIPアドレスのために、地方の配送のために私設のネットワークでパケットを扱わなければならないべきであるか、またはRSIPゲートウェイ(それには利用可能なそのようなインタフェースがあると仮定する)にトンネルを堀るのにRSIPインタフェースを使用しなければならないなら。
If the RSIP hosts are all on a single subnet, one hop from an RSIP gateway, then examination of the local network and subnet mask will provide the appropriate information. However, this is not always the case.
RSIPホストがすべてただ一つのRSIPゲートウェイからのワンバウンドのサブネットにいると、企業内情報通信網とサブネットマスクの試験は適切な情報を提供するでしょう。 しかしながら、これはいつもそうであるというわけではありません。
An alternative that will work in general for statically addressed private networks is to store a list of the network and subnet masks of every private subnet at the RSIP gateway. RSIP hosts may query the gateway with a particular target IP address, or for the entire list.
一般に、静的に扱われた私設のネットワークで利く代替手段はネットワークのリストとRSIPゲートウェイのあらゆる個人的なサブネットのサブネットマスクを保存することです。 RSIPホストは特定の目標IPアドレス、または全体のリストのためにゲートウェイについて質問するかもしれません。
If the subnets on the local side of the network are changing more rapidly than the lifetime of a typical RSIP session, the RSIP host may have to query the location of every destination that it tries to communicate with.
ネットワークのローカル・サイドの上のサブネットが典型的なRSIPセッションの生涯より急速に変化するなら、RSIPホストはそれがコミュニケートしようとするあらゆる目的地の位置について質問しなければならないかもしれません。
Borella, et al. Experimental [Page 25] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[25ページ]RFC3102RSIP: フレームワーク2001年10月
If an RSIP host transmits a packet addressed to a public host without using RSIP, then the RSIP gateway will apply NAT to the packet (if it supports NAT) or it may discard the packet and respond with and appropriate ICMP message.
RSIPホストがRSIPを使用しないで公共のホストに扱われたパケットを伝えるならRSIPゲートウェイがNATをパケットに適用するか(NATをサポートするなら)、それは、ICMPメッセージをパケットを捨てて、応じて、当てるかもしれません。
A robust solution to this problem has proven difficult to develop. Currently, it is not known how severe this problem is. It is likely that it will be more severe on networks where the routing information is changing rapidly that on networks with relatively static routes.
この問題のロバスト解は開発するのが難しいと判明しました。 現在、この問題がどれくらい厳しいかは知られていません。 それがルーティング情報がネットワークで急速にそれを変えているネットワークで、より厳しくなる傾向がある、比較的、スタティックルート。
6.6. Implementing RSIP Host Deallocation
6.6. RSIPホストDeallocationを実装します。
An RSIP host MAY free resources that it has determined it no longer requires. For example, on an RSAP-IP subnet with a limited number of public IP addresses, port numbers may become scarce. Thus, if RSIP hosts are able to dynamically deallocate ports that they no longer need, more hosts can be supported.
RSIPホストはそれがもう必要でないことを決定したリソースを解放するかもしれません。 例えば、限られた数の公共のIPアドレスがあるRSAP-IPサブネットでは、ポートナンバーは不十分になるかもしれません。 したがって、RSIPホストがダイナミックに、彼らがもう必要としないポートを「反-割り当て」ることができるなら、より多くのホストをサポートすることができます。
However, this functionality may require significant modifications to a vanilla TCP/IP stack in order to implement properly. The RSIP host must be able to determine which TCP or UDP sessions are using RSIP resources. If those resources are unused for a period of time, then the RSIP host may deallocate them. When an open socket's resources are deallocated, it will cause some associated applications to fail. An analogous case would be TCP and UDP sessions that must terminate when an interface that they are using loses connectivity.
しかしながら、この機能性がバニラTCP/IPスタックへの重要な変更を必要とするかもしれない、適切に、実装します。 RSIPホストは、どのTCPかUDPセッションがRSIPリソースを使用しているかを決定できなければなりません。 それらのリソースがしばらく未使用であるなら、RSIPホストはそれらを「反-割り当て」るかもしれません。 開いているソケットのリソースが「反-割り当て」られると、それはいくつかの関連するアプリケーションに失敗されるでしょう。 類似のケースは、それらが使用しているインタフェースが接続性を失うと終わらなければならないTCPとUDPセッションでしょう。
On the other hand, this issue can be considered a resource allocation problem. It is not recommended that a large number (hundreds) of hosts share the same IP address, for performance purposes. Even if, say, 100 hosts each are allocated 100 ports, the total number of ports in use by RSIP would be still less than one-sixth the total port space for an IP address. If more hosts or more ports are needed, more IP addresses should be used. Thus, it is reasonable, that in many cases, RSIP hosts will not have to deallocate ports for the lifetime of their activity.
他方では、資源配分問題であるとこの問題を考えることができます。 性能目的のためにホストの多く(数百)が同じIPアドレスを共有することが勧められません。 たとえば、それぞれ100人のホストに100のポートを割り当てても、ポートの総数はそれでも、1/6未満がIPアドレスのための総ポートスペースであったなら中でRSIPを使用します。 より多くのホストか、より多くのポートが必要であるなら、より多くのIPアドレスが使用されるべきです。 したがって、それは妥当です、そんなに多くの場合RSIPホストが彼らの活動の生涯、deallocateにポートを持たないでしょう。
Since RSIP demultiplexing fields are leased to hosts, an appropriately chosen lease time can alleviate some port space scarcity issues.
RSIP逆多重化野原がホストに賃貸されるので、適切に選ばれたリース時間はいくつかのポートスペース不足問題を軽減できます。
6.7. Multi-Party Applications
6.7. マルチパーティアプリケーション
Multi-party applications are defined to have at least one of the following characteristics:
マルチパーティアプリケーションは少なくとも以下の特性の1つを持つために定義されます:
- A third party sets up sessions or connections between two
hosts.
- 第三者は2人のホストの間のセッションか接続をセットアップします。
Borella, et al. Experimental [Page 26] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[26ページ]RFC3102RSIP: フレームワーク2001年10月
- Computation is distributed over a number of hosts such that the
individual hosts may communicate with each other directly.
- 計算は、個々のホストが直接互いにコミュニケートできるように、多くのホストの上に広げられます。
RSIP has a fundamental problem with multi-party applications. If some of the parties are within the private addressing realm and others are within the public addressing realm, an RSIP host may not know when to use private addresses versus public addresses. In particular, IP addresses may be passed from party to party under the assumption that they are global endpoint identifiers. This may cause multi-party applications to fail.
RSIPには、マルチパーティアプリケーションに関する基本的な問題があります。 私設のアドレシング分野の中にパーティーのいくつかがあって、他のものが公立のアドレシング分野の中にいるなら、RSIPホストは、いつ場内放送に対してプライベート・アドレスを使用するかを知らないかもしれません。 特に、IPアドレスはそれらがグローバルな終点識別子であるという仮定でパーティーからパーティーまで通過されるかもしれません。 これはマルチパーティアプリケーションに失敗されるかもしれません。
There is currently no known solution to this general problem. Remedial measures are available, such as forcing all RSIP hosts to always use public IP addresses, even when communicating only on to other RSIP hosts. However, this can result in a socket set up between two RSIP hosts having the same source and destination IP addresses, which most TCP/IP stacks will consider as intra-host communication.
現在、この一般的問題への知られている解決が全くありません。 改善策は利用可能です、他のRSIPホストだけに交信さえするときすべてのRSIPホストに公共のIPアドレスをいつも使用させるのなどように。 しかしながら、これは同じソースがいる2人のRSIPホストと送付先IPアドレスの間でセットアップされたソケットをもたらすことができます。(ほとんどのTCP/IPスタックがイントラホストコミュニケーションであるとそれをみなすでしょう)。
6.8. Scalability
6.8. スケーラビリティ
The scalability of RSIP is currently not well understood. While it is conceivable that a single RSIP gateway could support hundreds of RSIP hosts, scalability depends on the specific deployment scenario and applications used. In particular, three major constraints on scalability will be (1) RSIP gateway processing requirements, (2) RSIP gateway memory requirements, and (3) RSIP negotiation protocol traffic requirements. It is advisable that all RSIP negotiation protocol implementations attempt to minimize these requirements.
RSIPのスケーラビリティは現在、よく理解されていません。 1RSIP門が何百人ものRSIPホストをサポートするかもしれないのが想像できますが、スケーラビリティは使用される特定の展開シナリオとアプリケーションによります。 スケーラビリティにおける3つの主要な規制が特に、(1)RSIPゲートウェイ処理所要になって、(2) RSIPゲートウェイメモリ要件、および(3)はRSIP交渉プロトコルトラフィック要件です。 すべてのRSIP交渉プロトコル実装が、これらの要件を最小にするのを試みるのは、賢明です。
7. Security Considerations
7. セキュリティ問題
RSIP, in and of itself, does not provide security. It may provide the illusion of security or privacy by hiding a private address space, but security can only be ensured by the proper use of security protocols and cryptographic techniques.
RSIPはそういうものとしてセキュリティを提供しません。 それはプライベート・アドレススペースを隠すことによって、セキュリティかプライバシーの幻想を供給するかもしれませんが、セキュリティプロトコルと暗号のテクニックの適切な使用でセキュリティを確実にすることができるだけです。
8. Acknowledgements
8. 承認
The authors would like to thank Pyda Srisuresh, Dan Nessett, Gary Jaszewski, Ajay Bakre, Cyndi Jung, and Rick Cobb for their input. The IETF NAT working group as a whole has been extremely helpful in the ongoing development of RSIP.
作者は彼らの入力についてPyda Srisuresh、ダンNessett、ゲーリーJaszewski、Ajay Bakre、シンディ・ユング、およびリック・コッブに感謝したがっています。 全体でIETF NATワーキンググループはRSIPの開発現況に非常に役立っています。
Borella, et al. Experimental [Page 27] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[27ページ]RFC3102RSIP: フレームワーク2001年10月
9. References
9. 参照
[DHCP-DNS] Stapp, M. and Y. Rekhter, "Interaction Between DHCP and
DNS", Work in Progress.
[DHCP-DNS] 「DHCPとDNSとの相互作用」というスタップ、M.、およびY.Rekhterは進行中で働いています。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2983]黒(D.)が「サービスとトンネルを差別化した」、RFC2983、10月2000日
[RFC3104] Montenegro, G. and M. Borella, "RSIP Support for End-to-
End IPSEC", RFC 3104, October 2001.
[RFC3104]モンテネグロとG.とM.Borella、「終わりから終わりへのIPSECのRSIPサポート」、RFC3104、2001年10月。
[RFC3103] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi,
"Realm Specific IP: Protocol Specification", RFC 3103,
October 2001.
[RFC3103] Borella、M.、Grabelsky、D.、最低気温、J.、およびK.谷口、「分野の特定のIP:」 「プロトコル仕様」、RFC3103、2001年10月。
[RFC2746] Terzis, A., Krawczyk, J., Wroclawski, J. and L. Zhang,
"RSVP Operation Over IP Tunnels", RFC 2746, January 2000.
[RFC2746] TerzisとA.とKrawczykとJ.とWroclawskiとJ.とL.チャン、「IP Tunnelsの上のRSVP操作」、RFC2746、2000年1月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.J.
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter(Y.、マスコウィッツ、B.、Karrenberg、D.、deグルート、G.J.、およびE.リア)は「個人的なインターネットのための配分を扱います」、BCP5、RFC1918、1996年2月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October
1996.
[RFC2002] パーキンス、C.、「IP移動性サポート」、RFC2002、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate
requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address
Translator (NAT) Terminology and Considerations", RFC
2663, August 1999.
[RFC2663] SrisureshとP.とM.Holdrege、「IPはアドレス変換機構(NAT)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
Jamin, "Resource Reservation Protocol (RSVP)", RFC 2205,
September 1997.
[RFC2205] ブレーデンとR.とチャンとL.とBersonとS.とハーツォグとS.とS.ジャマン、「資源予約プロトコル(RSVP)」、RFC2205 1997年9月。
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「差別化されたサービスのためのアーキテクチャ」、RFC2475、1998年12月。
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with
SLP", RFC 3105, October 2001.
[RFC3105] ケンフとJ.とG.モンテネグロ、「SLPと共にRSIPサーバを見つけます」、RFC3105、2001年10月。
Borella, et al. Experimental [Page 28] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[28ページ]RFC3102RSIP: フレームワーク2001年10月
10. Authors' Addresses
10. 作者のアドレス
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
マイケルBorella CommWorks3800Golf通り Meadowsイリノイ 60008を回転させます。
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
以下に電話をしてください。 (847) 262-3083 メールしてください: mike_borella@commworks.com
Jeffrey Lo Candlestick Networks, Inc 70 Las Colinas Lane, San Jose, CA 95119
ジェフリー最低気温燭台ネットワーク、Inc70Las Colinasレイン、サンノゼ、カリフォルニア 95119
Phone: (408) 284 4132 EMail: yidarlo@yahoo.com
以下に電話をしてください。 (408) 284 4132はメールされます: yidarlo@yahoo.com
David Grabelsky CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
デヴィッドGrabelsky CommWorks3800Golf通り Meadowsイリノイ 60008を回転させます。
Phone: (847) 222-2483 EMail: david_grabelsky@commworks.com
以下に電話をしてください。 (847) 222-2483 メールしてください: david_grabelsky@commworks.com
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエルE.モンテネグロサン・マイクロシステムズ研究所、ヨーロッパ29、chemin du Vieux Chene38240メラン・フランス
Phone: +33 476 18 80 45 EMail: gab@sun.com
以下に電話をしてください。 +33 476 18 80 45はメールされます: gab@sun.com
Borella, et al. Experimental [Page 29] RFC 3102 RSIP: Framework October 2001
Borella、他 実験的な[29ページ]RFC3102RSIP: フレームワーク2001年10月
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright(C)インターネット協会(2001)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Borella, et al. Experimental [Page 30]
Borella、他 実験的[30ページ]
一覧
スポンサーリンク
