[要約] RFC 3102は、特定の領域に関連するIPアドレスのフレームワークについての要約です。その目的は、異なる領域間でのIPアドレスの一意性を確保し、ネットワークの管理と運用を容易にすることです。
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
Realm Specific IP: Framework
レルム固有のIP：フレームワーク
Status of this 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.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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テクノロジーを説明するドキュメントのセットが、完全な実装のために重要なホストとゲートウェイの変更を暗示していることを指摘しています。さらに、ポート番号が浮かんでいると、一部のアプリケーションに問題が発生する可能性があり、RSIP対応のホストが既存のアプリケーションと透過的に相互運用することを防ぐことができます（例えば、IPSEC）。最後に、RSIPの使用に関連する重要な運用上の複雑さがある場合があります。これらおよびその他の合併症のいくつかは、RFC 3102のセクション6およびRFC 3104の付録に概説されています。したがって、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.
このドキュメントでは、レルム固有のIP（RSIP）の一般的なフレームワークを検証します。RSIPは、パケットのエンドツーエンドの完全性が維持されるNATの代替として意図されています。実装の問題、展開シナリオ、および他のレイヤー3つのプロトコルとの相互作用に焦点を当てています。
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
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.
ネットワークアドレス変換（NAT）は、アドレス指定スペースの分離を可能にする人気のあるメカニズムになりました。NATルーターは、ネットワークレイヤーを調べて変更する必要があり、場合によっては、NATルーターが接続しているアドレス指定ドメインを横切る各パケットのヘッダー、場合によっては輸送層を変更する必要があります。これにより、NATのメカニズムはインターネット接続のエンドツーエンドの性質に違反し、パケットのエンドツーエンドの完全性を必要とするプロトコルを破壊します。
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）の存在が必要です。たとえば、ほとんどのNATは、FTPのアルグを備えた出荷で、その制御チャネルにIPアドレスとポート番号を送信します。RSIP（レルム固有の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ホストに付与します。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.
rsipは、natに、ある種の「修正」と見なすことができます。NATの制限の一部なしに、いくつかのシナリオでいくつかのIPアドレス不足の問題を改善する可能性があります。ただし、IPアドレス不足の問題に対する長期的な解決策ではありません。RSIPにより、ある程度のアドレス領域の透明性が、2つの異なるスコープのある、または完全に異なるアドレス指定された領域の間で達成することができます。これにより、領域への対処間のエンドツーエンドのパケットの透明性を可能にするための便利なアーキテクチャになります。RSIPは、IPv4ネットワークの民間住所に展開され、公開されたIPv4ネットワークへのアクセスを付与するために使用される予定です。ただし、プライベートIPv4ネットワークの代わりに、IPv6ネットワークまたは非IPネットワークがある場合があります。したがって、RSIPは、IPスタックとIPアプリケーションを使用してホストにIP接続を可能にしますが、ネイティブIPアクセスはありません。そのため、DNSおよびトンネリングと併せてRSIPを使用して、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合併症」をご覧ください。
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ホストまたはIPv6ホストが公開されたIPv4ネットワークへのアクセスを可能にするシナリオに焦点を当てています。
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.
[RFC1918]で指定されている範囲（10.0.0.0.0/8、172.16.0.0/12、192.168.0.0/16）の範囲（10.0.0.0.0/12、172.0.0.0.0/12）、またはインターネットから不可能なアドレスを使用するルーティング領域。
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ゲートウェイを介して別のアドレス指定領域からアドレス指定パラメーターを取得するアドレス指定領域内のホスト。
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.
少なくとも1つのレルムで1つ以上のIPアドレスが割り当てられている2つのアドレス指定レルムの境界にあるルーターまたはゲートウェイ。RSIPゲートウェイは、1つの領域から他の領域のRSIPホストへのパラメーター管理と割り当てを担当します。RSIPゲートウェイは、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.
各RSIPホストにパブリックレルムから一意のIPアドレスが割り当てられる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.
各RSIPホストにIPアドレス（おそらく他の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]の用語と一致しています。
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].
キーワードは「必要」、「必要」、「必須」、「shall」、「shall "、" sulld "、" nove "、" becommented "、" may "、および" optional "は、[RFC2119]で説明されているように解釈されます。
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
Xa Na Nb Yb
[X]------( Addr sp. A )----[N]-----( Addr sp. B )-------[Y]
( Network ) ( Network )
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とアドレススペースBのNBには、アドレススペースBにアドレスのプールがある場合があります。上に示すが、それらはNB1、NB2、NB3などとして示されることができます。
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.
よくあることですが、アドレススペースA内のホストはプライベートアドレスを使用する可能性がありますが、RSIPゲートウェイはアドレススペースAからの1つ以上のプライベートアドレスが住所スペースBからのパブリックアドレスに加えてマルチホームされています。したがって、我々は通常、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.
ホストXは、アドレススペースB内に位置するネットワークエンティティYへのエンドツーエンドの接続を確立したいと考えています。最初に、RSIPゲートウェイからリソース（アドレスおよびアドレススペースbのその他のルーティングパラメーターなど）の割り当てを最初に交渉して取得します。これらのパラメーターを割り当てると、RSIPゲートウェイは、Xのアドレス指定情報と割り当てられたリソースの「バインド」と呼ばれるマッピングを作成します。このバインディングにより、RSIPゲートウェイはXでYによって生成されるムルチプレックスを正しく脱マルチプレックスおよび転送するインバウンドトラフィックを可能にします。RSIPゲートウェイで許可されている場合、Xは同じRSIPゲートウェイまたはいくつかのRSIPゲートウェイに複数のそのようなバインディングを作成する場合があります。リース時間は、各バインドに関連付けられる必要があります。
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 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は、アドレススペースAにRSIPゲートウェイにトンネルデータパケットをホストします。RSIPゲートウェイは、そのようなトンネルのエンドポイントとして機能し、外側のヘッダーを取り除き、内側のパケットをパブリックレルムにルーティングします。上記のように、RSIPゲートウェイは、割り当てられたパブリックパラメーターのマッピングを、RSIPホストのプライベートアドレスにユニークにマッピングするための非複数のフィールドとして維持します。パブリックレルムからのパケットがRSIPゲートウェイに到着し、特定の非gultiplexingフィールドに一致すると、RSIPゲートウェイは適切なRSIPホストにトンネルします。xがNBに割り当てられていることを考えると、xからyからyまでのアウトバウンドパケットのトンネルヘッダーは次のとおりです。
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+
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にはRSA-IPとRSAP-IPの2つの基本的なフレーバーがあります。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ゲートウェイから複数のアドレスをリースできます。RSA-IPセッションの非gultiplexingフィールドには、ホストにリースされた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ゲートウェイは、アドレスあたりのポート番号のプールと同様に、IPアドレスのプールを維持します。RSIPホストは、使用するIPアドレスと1つ以上のポートをリースします。アドレス /ポートタプルが特定のホストに割り当てられると、そのホストのみがプールに戻されるまでタプルを使用できます。ホストは、特別に割り当てられていないアドレス /ポートの組み合わせを使用することはできません。ホストは、割り当てられたタプルにバインドされたゲートウェイアプリケーションを実行できますが、RSIPゲートウェイがホストへのタプルに運命づけられているすべてのトラフィックをルーティングすることに同意していない限り、アプリケーションはパブリックネットワークで利用できません。ホストは、同じまたは異なるRSIPゲートウェイから複数のタプルをリースする場合があります。RSAP-IPセッションの非gultiplexingフィールドには、ホストにリースされたタプルを含める必要があります。
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 one or more tunnels to RSIP gateways. An RSIP host MUST NOT respond to ARPs for a public realm address that it leases.
RSIPホストは、RSIPゲートウェイからリースするIPアドレスの1つ以上の仮想インターフェイスを維持できる必要があります。ホストはまた、トンネリングをサポートし、1つ以上のトンネルのRSIPゲートウェイのエンドポイントとして機能する必要があります。RSIPホストは、リースするパブリックレルムアドレスのARPに応答してはなりません。
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.
RSIPゲートウェイは、2つ以上の領域の間にパケットをルーティングするマルチホームのホストです。多くの場合、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ゲートウェイには、NAT機能が含まれる場合があるため、RSIP対応のないプライベートネットワーク上のホストがパブリックネットワークと通信できます。RSIPゲートウェイは、RSIPホストに割り当てられたすべてのリソースを管理する必要があります。この管理は、現地のポリシーに従って行うことができます。
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])
- ESPまたはAHヘッダーに存在するIPSEC SPI（[RFC3104]を参照）
- others
- その他他人余人余人
Note that these fields may be augmented by source IP address and source TCP or UDP port.
これらのフィールドは、ソースIPアドレスとソースTCPまたはUDPポートによって拡張される場合があることに注意してください。
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アドレスが割り当てられている場合、各RSIPホストに一意のパブリックIPアドレスがマッピングされます。
- 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アドレスが複数のRSIPホストに使用されている場合、後続のヘッダーには、ホストごとに一意の値を割り当てる少なくとも1つのフィールドが必要になる必要があります。IPプロトコルフィールドを使用して、後続のヘッダーで、これらの非複数形成フィールドがどうあるべきかを判断する必要があります。
- 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の場合、宛先ポート番号を使用できます。ただし、TCP/UDPポート番号が複数のRSIPホストで同じである場合、パケットのペイロードセクションには、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ペイロード内には非gultiplexingフィールドとして使用可能な他のフィールドが存在する必要があります。言い換えれば、これらのフィールドは、ホストごとに一意になることが保証されるように設定できる必要があります。通常、これには、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ゲートウェイが着信パケットの適切なフィールドをマスクして調べることができるように、すべての脱gultiplexingフィールドがよく知られている固定場所で発生することが望ましいです。暗号化された反転フィールドは、ルーティングに使用してはなりません。
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.
RSIPゲートウェイとホストは、RSA-IPを使用する場合、RSAP-IPを使用する場合はIPアドレス /ポートタプル、および他のモードで使用する他の脱却フィールドを使用する場合、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プロトコルは、少なくとも、以下を許可する必要があります。
- RSIP hosts to request assignments of demultiplexing fields
- RSIPホストは、非複数のフィールドの割り当てを要求します
- RSIP gateways to assign demultiplexing fields with an associated lease time
- RSIPゲートウェイに関連するリース時間で非gultiplexingフィールドを割り当てる
- RSIP gateways to reclaim assigned demultiplexing fields
- 割り当てられたDemultiplexingフィールドを取り戻すための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プロトコルがRSIPメソッド（RSA-IPまたはRSAP-IP）をネゴシエートすることと、プライベートネットワーク全体で使用されるトンネルのタイプが望ましいですが、必須ではありません。プロトコルは拡張可能であり、ベンダー固有の拡張を促進する必要があります。
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を介して通信できます。すべてのRSIPゲートウェイではTCPサポートが必要ですが、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ゲートウェイは、シークレットキー（たとえば、Kerberosによって配布される）を共有するか、プライベート/公開キーペアを持っている必要があります。後者の場合、エンティティの公開キーを各メッセージで計算し、結果にハッシュ関数を適用してメッセージハッシュを形成できます。
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）静的パブリックIPアドレス（つまり、RSIPゲートウェイのパブリックアドレス）およびパブリックホストの検索のためのパブリックDNSサービス、（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情報をパブリックネットワークに伝播してはなりません。
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ホストがAとPTRレコードをパブリックDNSで更新できる場合があります。これらの更新は、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ホストが住所に対して持っているという主張は、アドレスとともにリースしたポートに関するみです。したがって、2つ以上のRSIPホストのFQDNSが同じIPアドレスにマッピングできます。ただし、パブリックホストは、特定のアドレスで実行されているすべてのアプリケーションが同じ論理ホストによって所有されていることを期待する場合がありますが、そうではありません。RSAP-IPと動的DNSを慎重に統合することをお勧めします。
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アドレスで、もう1つは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オプションは、DHCPOFFERメッセージでRSIPゲートウェイのIPアドレスを提供できます。したがって、ホストのスタートアップ手順は次のとおりです。（1）DHCPを実行します。（2）DHCPofferにRSIPゲートウェイオプションが存在する場合、そのIPアドレスをRSIPゲートウェイとして記録します。
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]で指定されているように、RSIPゲートウェイはSLP（サービスロケーションプロトコル）を介して発見できます。定義されたSLPテンプレートにより、RSIPサービスのプロビジョニングとロードバランシングが可能になります。
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の実装の問題について説明します。
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スタックの実装に関連付けられていることに注意してください。RSA-IPをサポートするために、IPトンネルとルーティングコードの変更とドライバーインターフェイスを作成する必要がある場合があります。RSAP-IPのサポートには、一時的なポート選択コードの変更も必要です。ホストに複数のTCP/IPスタックまたはTCP/IPスタックおよびその他の通信スタックがある場合、RSIPはRSIPを使用するTCP/IPスタックに関連付けられているパケット/セッションでのみ動作します。RSIPはアプリケーション固有ではなく、スタックに実装されている場合、スタックを使用するすべてのアプリケーションの下で動作します。
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が既存のネットワークに与える影響を調べます。
In this section we discuss a number of potential RSIP deployment scenarios. The selection below are not comprehensive and other scenarios may emerge.
このセクションでは、多くの潜在的なRSIP展開シナリオについて説明します。以下の選択は包括的ではなく、他のシナリオが出現する可能性があります。
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.
最大数百のホストがRSIP対応ルーターの後ろに居住します。パブリックネットワークへのゲートウェイは1つしかないため、RSIPゲートウェイは1つだけである可能性があります。このRSIPゲートウェイは、1つの、またはおそらくいくつかのパブリックIPアドレスのみを制御できます。RSIPゲートウェイは、ファイアウォール機能を実行したり、特定の宛先ポートへのインバウンドトラフィックを、プライベートネットワーク上の少数の専用ゲートウェイにルーティングすることもできます。
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 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.
このカテゴリには、たった1つの住居内と複数の居住ユニット内のネットワーキングの両方が含まれます。最大で数百のホストがゲートウェイのリソースを共有します。特に、これらのデバイスの多くは、薄いホストまたはいわゆる「ネットワークアプライアンス」である可能性があるため、頻繁にパブリックインターネットへのアクセスを必要としません。RSIPゲートウェイは、住宅ファイアウォールの一部として実装される可能性が高く、特定の宛先ポートにトラフィックをプライベートネットワーク上の少数の専用ゲートウェイにルーティングすることが求められる場合があります。パブリックネットワークへの1つのゲートウェイのみが存在し、このゲートウェイのRSIPゲートウェイが1つのIPアドレスのみを制御する可能性があります。企業イントラネットへの安全なエンドツーエンドのVPNアクセスのサポートが重要です。
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.
ホスピタリティネットワークは、旅行者が短期間（数分または数時間）使用する一般的なタイプの「ホスティング」ネットワークです。例のシナリオには、ホテル、会議センター、空港、鉄道駅があります。最大で数百のホストがゲートウェイのリソースを共有します。RSIPゲートウェイは、ファイアウォールの一部として実装される場合があり、おそらく特定の宛先ポートにトラフィックをプライベートネットワーク上の専用ゲートウェイにルーティングするために使用されないでしょう。パブリックネットワークへの1つのゲートウェイのみが存在し、このゲートウェイのRSIPゲートウェイが1つのIPアドレスのみを制御する可能性があります。企業イントラネットへの安全なエンドツーエンドのVPNアクセスのサポートが重要です。
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アドレスを使用するために、Dialup Remote Access Concencoratorに配置できます。最大で数百のホストがゲートウェイのリソースを共有します。RSIPゲートウェイは、ファイアウォールの一部として実装される場合としない場合があります。また、特定の宛先ポートにトラフィックをプライベートネットワーク上の専用ゲートウェイにルーティングするために使用されない可能性があります。パブリックネットワークへの1つのゲートウェイのみが存在し（リモートアクセスコンセントレーター自体）、このゲートウェイのRSIPゲートウェイが少数のIPアドレスを制御します。企業イントラネットへの安全なエンドツーエンドのVPNアクセスのサポートが重要です。
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ゲートウェイに短期間登録します。最大で数百のホストがゲートウェイのリソースを共有します。RSIPゲートウェイは、ファイアウォールの一部として実装される場合があり、おそらく特定の宛先ポートにトラフィックをプライベートネットワーク上の専用ゲートウェイにルーティングするために使用されないでしょう。パブリックネットワークへの1つのゲートウェイのみが存在し、このゲートウェイのRSIPゲートウェイが少数のIPアドレスを制御する可能性があります。企業イントラネットへの安全なエンドツーエンドのVPNアクセスのサポートが重要です。
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アドレスやポートなど）を割り当てる場合があります。 この顧客は、RSIPを使用して、個々のエンドホストの間でポート範囲とアドレス（ES）をさらに細分化することができます。 RSIP割り当てのレベルがいくつあるかに関係なく、RSIPはパブリック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の相互作用を調査することです。
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 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.0/24のIPアドレスを担当しています。これらのアドレスをRSIPホストとRSIPゲートウェイに配布します。指定された構成では、アドレス149.112.240.0-149.112.240.127をRSIPゲートウェイBに配布し、149.112.240.128-149.112.240.254をRSIPゲートウェイCにアドレスします。このブロードキャストパケットは、RSIPゲートウェイAの背後にある任意のホストに配布できます。また、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ゲートウェイAをRSIPゲートウェイBおよびCの「親」と呼び、RSIPゲートウェイBとCをRSIPゲートウェイAの「子供」と呼びます。親の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ゲートウェイは、必ずしもアドレス（ES）とポートが子供のRSIPゲートウェイに分配されることをブロックすることを認識しているわけではありません。したがって、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.
たとえば、上記の図のコンテキストでは、RSIPゲートウェイCの後ろのホスト10.0.0.1は、割り当てられた外部IPアドレス（たとえば、149.112.240.130）を使用し、10.0.0.0/8サブネットからRSIPゲートウェイCへのパケットをトンネルします。。RSIPゲートウェイCは、外側のIPヘッダーを取り除きます。ソースパブリックIPアドレスとソースポート番号が有効であることを確認した後、RSIPゲートウェイCは10.0.2.0/8サブネット上のパケットをRSIPゲートウェイAにトンネルします。ソースパブリック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ゲートウェイは、子供にパラメーターを割り当てるときに親から継承するパラメーター割り当ての制約を考慮する必要があります。たとえば、子供のRSIPゲートウェイにIPアドレスで3600秒のリース時間が与えられた場合、現在の時間とリース時間とリースが割り当てられた時間を、アドレスの最大許容リース時間を計算するために比較する必要があります。アドレスをRSIPホストまたはチャイルドRSIPゲートウェイに割り当てることです。
+--------+ +--------+
| NAT w/ | | RSIP |
hosts ------+ RSIP +------+ gate- +----- public network
| host | | way |
+--------+ +--------+
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.
このアーキテクチャでは、RSIPゲートウェイはNATボックスとパブリックネットワークの間にあります。NATにはRSIPホストも装備されています。NATは、ホストがパブリックネットワークにセッションを確立するため、RSIPゲートウェイからリソースを動的に要求します。ホストはRSIP操作を認識していません。この構成では、ホストがエンドツーエンドの透明性を持つことはできません。したがって、NATは依然としてALGSを必要とし、アーキテクチャはIPSECをサポートできません。
+--------+ +--------+
RSIP | RSIP | | |
hosts ------+ gate- +------+ NAT +----- public network
| way | | |
+--------+ +--------+
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をサポートできません。NATボックス以外にパブリックネットワークへの別のゲートウェイがある場合、ホストは透明性を持つ可能性があり、このゲートウェイはRSIPの背後にあるカスケードRSIPをサポートします。
+--------+ +--------+
RSIP | | | RSIP |
hosts ------+ NAT +------+ gate- +----- public network
| | | way |
+--------+ +--------+
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シグナリングは、RSIPアルグがインストールされている場合、NATを通過できる場合があります。ただし、RSIPデータフローには、外部IPアドレスがNATによって翻訳されます。NATは、RSIPが適切に動作するようにポート番号を翻訳してはなりません。したがって、この文脈では、従来のNATのみが理にかなっています。
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つのオブジェクトに影響するため、他のレイヤー3つのプロトコルに影響を与えます。このセクションでは、これらのプロトコルに対する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つのプロトコルと相互作用する方法の完全な技術仕様が必要な場合、別のドキュメントにはそれが含まれます。
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保護パケット（IPSECセキュリティ協会（SA）に送信されるパケット）にIPヘッダーに続いてAHまたはESPヘッダーを挿入します。これらのヘッダーには、32ビットセキュリティパラメーターインデックス（SPI）フィールドが含まれており、その値は受信側によって決定されます。SPIフィールドは常に明確です。したがって、SAの交渉中、RSIPホストは、特定のSPI値を使用するように公開ピアに指示できます。このSPI値は、割り当てられたIPアドレスとともに、RSIPゲートウェイで使用して、RSIPホストにパケットを一意に識別してルーティングできます。RSIPホストがアドレスごとに一意のSPIを使用することを保証するために、RSIPゲートウェイがアドレス/ポートタプルとともにホストにユニークなSPIを割り当てる必要があります。
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アドレスごとに異なるイニシエーターCookie（IKEペイロードの最初の8バイト）を使用する必要があります。RSIPゲートウェイは、イニシエーターCookie値に基づいて、着信IKEパケットを適切なホストにルーティングできます。イニシエーターCookieは、ポートやスピスなど、交渉できます。ただし、同じイニシエーターCookieを同時に使用しようとする同じIPアドレスを割り当てた2つのホストの可能性が非常に小さいため、RSIPゲートウェイは、すでに使用されているCookie値でIKEパケットをドロップすることでCookieの独自性を保証できます。
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が適用される場合があります。特に、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の統合は、継続的な検討のトピックです。
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相互作用について説明します。
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タイプオブサービス（現在DS）バイトの「マーク」を使用して、複数のレベルのベストエフォルトサービスをサポートできます。DSバイトの各値は、差別化されたサービスコードポイント（DSCP）と呼ばれ、特定のホップごとの動作を表します。この動作は、すべての管理ドメインで同じではない場合があります。差別化されたサービスをサポートするために明示的なシグナル伝達は必要ありません。
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割り当てのマイクロフロー（アドレス/ポートタプル）の知識を適用できます。RSA-IPの場合、RSIPゲートウェイは必ずしもマイクロフローの知識を持っているわけではないため、RSIPホスト（もしあれば）が作成したマークに依存するか、パケットにデフォルトのポリシーを適用する必要があります。
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が外側ヘッダーと内側のヘッダーの間に常にコピーされる可能性が高いという可能性があります。ただし、実装により、より一般的なケースが可能になるはずです。
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 case of having senders within the private realm and receivers within the public realm is not discussed although concepts mentioned here may be applicable.
[RFC2205]で定義されている統合サービスモデルでは、RSVPを使用したシグナリングが必要であり、通信エンドポイント間の中間ノードのリソース予約をセットアップします。RSIPが展開される最も一般的なシナリオでは、プライベートレルム内にある受信機は、公共の領域内にある送信者とのコミュニケーションセッションを開始します。このセクションでは、このようなシナリオでのRSIPアーキテクチャとRSVPの相互作用について説明します。ここで言及されている概念が適用できるかもしれませんが、公共の領域内に送信者と受信者を持っているというあまり一般的ではないケースは議論されていません。
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パスメッセージは送信者からレシーバーに下流に流れ、RSIPゲートウェイとはインバウンドし、RSVP RESVメッセージは反対方向に流れます。RSIPはプライベートレルム内のRSIPホストとゲートウェイ間のトンネルを使用するため、RSIPトンネル内でRSVPメッセージがどのように処理されるかは、[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.
[RFC2476]の用語に続いて、RSIPホストとゲートウェイの間にタイプ1のトンネルが存在する場合、RSIPゲートウェイを含むすべての中間ノードは、これらのノードに予約されていない非RSVP認識クラウドとして扱われます。トンネルは、ソースと宛先の間のパス上の単一の（論理的な）リンクと見なされます。エンドツーエンドのRSVPメッセージは、通常のIPパケットと同じ方法でカプセル化されたトンネルを介して転送されます。これは、最も一般的で適用可能な展開シナリオと考えています。
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.
ただし、タイプ2または3つのトンネルをトンネリングエンドポイント間に展開する必要がある場合、エンドツーエンドのRSVPセッションは、静的マッピング（タイプ2）または動的マッピング（タイプ3）をトンネルセッションにする必要があります。エンドツーエンドのRSVPメッセージは、通常のIPパケットと同じ方法でカプセル化されたトンネルを介して転送されますが、トンネルエンドポイント間にトンネルセッションが確立され、エンドツーエンドセッションのトンネル内でのQoS予約が確保されます。特別なQoS保証が必要なデータトラフィックは、UDP/IPヘッダーにカプセル化され、通常のトラフィックは通常のIP-IPカプセル化を使用してカプセル化されます。RSIPホストレシーバーに流れるすべてのデータトラフィックにQOS処理が与えられるタイプ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.
データトラフィックをUDP/IPまたは通常のIP-IPトンネルに選択的にチャネリングできるタイプ2展開シナリオ、またはエンドツーエンドセッションをトンネルセッションに動的にマッピングできるタイプ3の展開、RSIPモデルとの統合複雑で注意が必要です。（これらは、トンネルリンクを拡張可能なソフトパイプと見なすことができる場合であることに注意してください。）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 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].
- 転送のためにIPレイヤーに渡す前に着信ストリームのカプセル化を行うRSIPゲートウェイの実装の場合、RSVPデーモンは、着信RSVPパスメッセージの受信時に明示的に信号を送信する必要があります。 RSIP実装は、デフォルトのトンネリングを行う代わりに、RSVPパスメッセージを認識し、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ゲートウェイのグローバルインターフェイスの1つを想定することにより、RSIPホストがRSIPゲートウェイに一時的な存在感を持つことができます。その結果、RSVPパスメッセージはRSIPゲートウェイにアドレス指定されます。また、着信RSVPパス内のRSVPセッションオブジェクトは、RSIPゲートウェイによってRSIPホストにリースされたグローバル宛先アドレス、宛先ポート（およびプロトコル）タプルを運びます。したがって、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シグナリングフローの場合、RSIPモジュールは、RSVPにパケットを処理する前に、IPヘッダーとRSVPセッションオブジェクトのパケット変換を行います。ホストにリースされたグローバルアドレスは、ホストの真のプライベートアドレスに翻訳されます。（このメカニズムは、RSA-IPとRSAP-IPの両方で機能することに注意してください。）RSIPモジュールは、RSVPデーモンが生成するエンドツーエンドパスメッセージのプライベートパラメーター（プラストンネリング）に反対の翻訳を行う必要があります。RSIPホストレシーバー。RSVPアウトバウンドコントロールメッセージに対して、セッションオブジェクトの翻訳も実行する必要があります。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オブジェクトを使用することを提案します。
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とマルチキャストの相互作用について説明します。
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アドレスをパブリックネットワークに伝播することを許可してはなりません。
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ゲートウェイは、これらの要求を合体し、PIMなどのマルチキャストWANルーティングプロトコルを実行するか、WANマルチキャストルーターにIGMPメッセージをプロキシを実行するかどうかにかかわらず、適切なアクションを実行します。言い換えれば、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.
プライベートホストは、非gultiplexingフィールドを取得し、RSIPを使用してマルチキャストを受け取る必要がないことに注意してください。プライベートアドレスを使用してすべてのマルチキャストを受け取る場合があり、プライベートアドレスとは、RSIPゲートウェイがグループメンバーシップを追跡する方法です。
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 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アドレスを共有しているように見えます。下流のマルチキャストプロトコルがポート番号ではなくIPアドレスのみに基づいてソースを識別する場合、これらのプロトコルが送信者を区別できない可能性があります。
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が引き起こす可能性のある合併症を文書化します。これらの合併症のいずれも、大部分のアプリケーションで「ストッパーを表示する」と見なされるべきではありませんが、予期しないまたは未定義の動作を引き起こす可能性があります。それが適切な場合、合併症の有害な影響を軽減または排除する可能性のある潜在的な治療手順について議論します。
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を使用）が住所/ポートタプルをリースし、このタプルを使用してパブリックアドレス/ポートタプルに連絡する場合を検討してください。ホストがパブリックタプルとのセッションを終了し、すぐにリースしたタプルをRSIPゲートウェイに返すとします。RSIPゲートウェイがすぐにこのタプルを別のRSIPホスト（または同じホスト）に割り当て、この2番目のホストはソケットがまだtime_waitフェーズにある間に同じパブリックタプルに接触するためにタプルを使用している場合、ホストの接続は拒否される場合があります公のホストによって。
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分間扱います。これは、一般的に実装されているTime_Waitの最大の期間です。ポートスペースが不足している状況では、RSIPゲートウェイは、最近扱われたポートのプールからFIFOファッションでポートを割り当てることを選択できます。
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応答を処理する必要があります。関連するIPパケットを使用したエラーに応じて送信されるICMPエラーパケットと、ICMPリクエストパケットに応じて送信される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, 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.
プライベートネットワークで発信するICMPリクエストパケットは、通常、エコーリクエスト、タイムスタンプリクエスト、アドレスマスクリクエストで構成されます。これらのパケットとその応答は、ソースIPアドレス、ICMP識別子、ICMPシーケンス番号、および宛先IPアドレスのタプルによって識別できます。TCPとUDPパケットと同様に、ICMPリクエストパケットトンネルをRSIPゲートウェイに送信するRSIPホスト。RSIPゲートウェイは、このタプルを使用して、適切なRSIPホストのプライベートアドレスに着信ICMP応答をマッピングする必要があります。そうすれば、ホストに対するICMP応答をトンネルします。2つのRSIPホストが上記のタプルに同じ値を使用し、したがって曖昧さを作成することが可能であることに注意してください。ただし、この発生は非常にまれである可能性が高く、このドキュメントではこれ以上対処されていません。
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エラー応答メッセージは、ICMPパケットに埋め込まれたIPヘッダーとポート番号を調べることにより、適切な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応答を送信する必要があります（たとえば、到達不可能なポートなど）。これらの応答は、TCPおよびUDPパケットで行われるように、RSIPゲートウェイにトンネルされています。RSIPゲートウェイに到着するすべてのICMPリクエスト（ECHOリクエストなど）は、RSIPゲートウェイによって処理される必要があり、RSIPホストに転送してはなりません。
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を設定して、フラグメンテーションが発生しないようにするか、尤度や断片化が非常に小さいように設定できます。Path 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.
この問題の唯一の完全に堅牢な解決策は、IP識別フィールドで使用する同じパブリックIPアドレスの分離ブロックを共有しているすべてのRSIPホストを割り当てることです。ただし、この変更が実装の努力の価値があるかどうかは現在不明です。
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 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.
RSAP-IPホストは、よく知られているポートを使用するサーバーをホストすることに関して、NATと同じ制約によって制限されます。宛先ポート番号はRSAP-IPホストを一意に識別するためのルーティング情報として使用されるため、通常、同じパブリックIPアドレスを共有する2つのRSAP-IPホストが同じポートで公開されたゲートウェイを同時に動作させることはできません。よく知られているポートで動作するプロトコルの場合、これは、RSAP-IP IPアドレス /ポートタプルごとに1つのパブリックゲートウェイのみが同時に使用されることを意味します。ただし、RSAP-IPアドレス /ポートタプルごとに複数のゲートウェイを同時に使用できます。すべてのパケットのペイロード内に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ホストが公開可能なゲートウェイを操作するためには、ホストは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ゲートウェイは、このアドレス /ポートタプルからRSIPホストへのマッピングを開始します。その後、ピアアプリケーションがデータベースに連絡して、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ホストがすべて1つのサブネットに載っている場合、RSIPゲートウェイから1つのホップを使用すると、ローカルネットワークとサブネットマスクの検査が適切な情報を提供します。ただし、これは必ずしもそうではありません。
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ホストは通信しようとするすべての宛先の場所を照会する必要がある場合があります。
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.
この問題に対する堅牢な解決策は、開発が困難であることが証明されています。現在、この問題がどれほど深刻かはわかりません。ルーティング情報が比較的静的なルートを持つネットワークのそれよりも急速に変化しているネットワークでは、より深刻になる可能性があります。
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ポートに割り当てられたとしても、RSIPが使用しているポートの総数は、IPアドレスの総ポートスペースの6分の1未満です。より多くのホストまたはより多くのポートが必要な場合は、より多くのIPアドレスを使用する必要があります。したがって、多くの場合、RSIPホストがアクティビティの生涯にわたってポートを扱う必要がないことは合理的です。
Since RSIP demultiplexing fields are leased to hosts, an appropriately chosen lease time can alleviate some port space scarcity issues.
RSIPの非gultiplexingフィールドはホストにリースされるため、適切に選択されたリース時間は、いくつかのポートスペースの希少性の問題を軽減する可能性があります。
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つのホスト間のセッションまたは接続を設定します。
- 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アドレスを使用するように強制するなど、是正措置が利用可能です。ただし、これにより、同じソースと宛先IPアドレスを持つ2つのRSIPホストの間にソケットがセットアップされる可能性があり、ほとんどのTCP/IPスタックはホスト内通信と見なされます。
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のスケーラビリティは現在よく理解されていません。単一のRSIPゲートウェイが何百ものRSIPホストをサポートできると考えられますが、スケーラビリティは使用される特定の展開シナリオとアプリケーションに依存します。特に、スケーラビリティに関する3つの主要な制約は、（1）RSIPゲートウェイ処理要件、（2）RSIPゲートウェイメモリ要件、および（3）RSIPネゴシエーションプロトコルトラフィック要件です。すべてのRSIPネゴシエーションプロトコルの実装がこれらの要件を最小限に抑えようとすることをお勧めします。
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は、それ自体がセキュリティを提供しません。プライベートアドレススペースを隠すことにより、セキュリティまたはプライバシーの幻想を提供する場合がありますが、セキュリティはセキュリティプロトコルと暗号化技術を適切に使用することによってのみ保証できます。
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 Srisush、Dan Nessett、Gary Jaszewski、Ajay Bakre、Cyndi Jung、Rick Cobbの入力に感謝したいと思います。IETF NATワーキンググループ全体は、RSIPの進行中の開発において非常に役立ちました。
[DHCP-DNS] Stapp, M. and Y. Rekhter, "Interaction Between DHCP and DNS", Work in Progress.
[DHCP-DNS] Stapp、M。およびY. Rekhter、「DHCPとDNS間の相互作用」は進行中です。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。、「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[RFC3104] Montenegro, G. and M. Borella, "RSIP Support for End-to-End IPSEC", RFC 3104, October 2001.
[RFC3104]モンテネグロ、G。およびM.ボレラ、「エンドツーエンドIPSECのRSIPサポート」、RFC 3104、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.、Lo、J。およびK. Taniguchi、「Realm固有のIP：プロトコル仕様」、RFC 3103、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. Zhang、「RSVP Operation over IP Tunnels」、RFC 2746、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.、Moskowitz、B.、Karrenberg、D.、de Groot、G.J。E.リア、「プライベートインターネットのアドレス配分」、BCP 5、RFC 1918、1996年2月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002] Perkins、C。、「IP Mobility Support」、RFC 2002、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、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）用語と考慮事項」、RFC 2663、1999年8月。
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource Reservation Protocol (RSVP)", RFC 2205, September 1997.
[RFC2205] Braden、R.、Zhang、L.、Berson、S.、Herzog、S.、S。Jamin、「Resource Reservation Protocol（RSVP）」、RFC 2205、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] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、RFC 2475、1998年12月。
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with SLP", RFC 3105, October 2001.
[RFC3105] Kempf、J。およびG. Montenegro、「SLPでRSIPサーバーの検索」、RFC 3105、2001年10月。
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
Michael Borella Commworks 3800 Golf Rd。ローリングメドウズIL 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
Jeffrey Lo Candlestick Networks、Inc 70 Las Colinas Lane、San Jose、CA 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
David Grabelsky Commworks 3800 Golf Rd。ローリングメドウズIL 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、ケミンデュヴィューチェーン38240メイランフランス
Phone: +33 476 18 80 45
EMail: gab@sun.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
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エディター機能の資金は現在、インターネット協会によって提供されています。