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
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.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。それはどんな種類のインターネット標準を指定しません。改善のための議論や提案が要求されています。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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技術を記述したドキュメントのセットは、完全な実装のための重要なホストとゲートウェイの変更を意味するものではありことを指摘しています。また、ポート番号の浮きがある場合には、既存のアプリケーション（例えば、IPsecの）と透過的相互運用からRSIP対応ホストを防止する、いくつかの用途のために問題を引き起こす可能性があります。最後に、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はその制御チャネル上のIPアドレスとポート番号を送信FTPのALG、同梱されています。 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アドレッシング領域からのリソース（例えば、アドレス及び他のルーティングパラメータ）を使用できるようにすることによって、別のアドレス指定領域に存在するホストの付与の概念に基づいています。 RSIPゲートウェイは、NATルータを置き換えて、プライベートネットワーク上のRSIPを意識したホストはRSIPホストと呼ばれています。 RSIPはRSIPホストにそのようなリソースを付与するRSIPゲートウェイの能力を必要とします。 ALGは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接続を可能にします。このように、RSIPは、デュアルスタックホストは、ローカルまたはリモートのIPv4またはIPv6ホストと通信することができるように、IPv4およびIPv6ネットワークをブリッジするために、DNSおよびトンネリングに関連して、使用することができます。
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]で指定された範囲からプライベートIPアドレスを使用するレルム（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）、またはインターネットからの非ルーティング可能なアドレス。
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つ以上のIPアドレスが割り当てられている2のアドレス範囲の境界に位置するルータやゲートウェイ。 RSIPゲートウェイは、一の領域から他のレルムの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方法は、各RSIPホストは、公共分野からのユニークなIPアドレスが割り当てられています。
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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "NOT SHALL" "ものと" この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "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
RSIPホストRSIPゲートウェイホスト
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は（また、NAT機能を実行することができる）RSIPゲートウェイです。 N 2つのインターフェイスを有している：のNaアドレス空間Aに、およびNbアドレス空間B Nには、それが割り当てまたはアドレス空間AにX及び他のホストに貸すことができるアドレス空間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.
アドレス空間B内に位置するネットワークエンティティY、最初の交渉へのエンドツーエンド接続を確立することを望む、Xをホストし、リソースの割り当て（例えば、アドレス及びアドレス空間Bの他のルーティングパラメータ）RSIPゲートウェイから取得します。これらのパラメータの割り当ての際に、RSIPゲートウェイは、Xのアドレス情報と割り当てられたリソースの「バインド」と呼ばれるマッピングを作成します。このRSIPゲートウェイによって許可されている場合の結合はRSIPゲートウェイ正しくする逆多重化およびX用Yによって生成された順方向インバウンドトラフィックを可能にする、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ゲートウェイに到着し、それが分離フィールドの所与のセットと一致した場合、その後RSIPゲートウェイは、適切なRSIPホストへのトンネルをします。次のようにXがNbのが割り当てられていることを考えると、Xから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.
RSA-IPとRSAP-IP：RSIPの二つの基本的なフレーバーがあります。 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ゲートウェイは、IPアドレスのプールがRSIPホストによってリースされるアドレスを維持します。ホスト要求に応じて、RSIPゲートウェイがホストにIPアドレスを割り当てます。アドレスは特定のホストに割り当てられたら、アドレスがプールに戻されるまで、唯一そのホストアドレスを使用してもよいです。ホストは、具体的にそれらに割り当てられていないアドレスを使用することはできません。ホストは、割り当てられたアドレスとの組み合わせで任意のTCP / UDPポートを使用することができます。ホストはまた、任意のポートでゲートウェイ・アプリケーションを実行することができ、これらのアプリケーションは、RSIPゲートウェイからの支援なしに公衆網に利用できるようになります。ホストは、同一または異なるRSIPゲートウェイから複数のアドレスをリースするかもしれません。 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ゲートウェイは、IPアドレスのプールをアドレス並びにアドレスごとポート番号のプールを維持します。 RSIPホストは、IPアドレスとそれに使用する1つのまたは複数のポートをリースします。アドレス/ポートのタプルが特定のホストに割り当てられた後、それがプール（単数または複数）に戻されるまで、唯一そのホストは、タプルを使用することができます。ホストは、具体的にそれらに割り当てられていないアドレス/ポートの組み合わせを使用することはできません。ホストは、割り当てられたタプルにバインドされたゲートウェイアプリケーションを実行することができるが、RSIPゲートウェイがルートにホストにタプル宛てのすべてのトラフィックを合意している場合を除き、そのアプリケーションは、パブリックネットワークに使用することはできません。ホストは、同一または異なるRSIPゲートウェイから複数のタプルをリースするかもしれません。 RSAP-IPセッションの分波フィールドは、ホストにリースタプル（単数または複数）を含まなければなりません。
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アドレス（ES）のための1つまたは複数の仮想インターフェースを維持できなければなりません。ホストはまた、トンネリングをサポートし、RSIPゲートウェイへの1つまたは複数のトンネルのエンドポイントとして機能することができなければなりません。 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ゲートウェイは、マルチホームホストである二つ以上のレルム間のルートパケット。多くの場合、RSIPゲートウェイは、二つ以上の管理ドメイン間の境界ルータです。それはまた、トンネリングをサポートし、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ホストに割り当てられているすべてのリソースを管理しなければなりません。この管理は、ローカルポリシーに従って行うことができます。
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ゲートウェイによって使用されるマッピングのタイプに応じて、分離フィールドは、以下の一つ以上であることが定義されています。
- 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 ESPまたはAHヘッダー内に存在する（[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アドレスが各ホストに割り当てられている場合には、一意のパブリック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アドレスが複数のRSIPホストに使用される場合、後続のヘッダは、それが逆多重化フィールドとして使用できるように、ホストごとに一意の値が割り当てられることになる少なくとも一つのフィールドを有していなければなりません。 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ペイロード内の他のフィールドが存在しなければなりません。言い換えれば、これらのフィールドは、彼らはホストごとの一意であることが保証されるように設定することができなければなりません。 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ゲートウェイはマスクアウトし、着信パケットに適切なフィールドを調べることができるように、すべての逆多重化フィールドがで周知の固定位置を発生することが望ましいです。暗号化されている多重分離フィールドは、ルーティングのために使用してはいけません。
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アドレス/ポートの組を用いて、そして場合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プロトコルは、最低限、を可能にしなければなりません。
- 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プロトコルため、必須ではないけれども、望ましいです。プロトコルは拡張可能であるとベンダ固有の拡張を容易にするはずです。
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を介して通信することができます。 UDPのサポートはオプションである一方、TCPのサポートは、すべてのRSIPゲートウェイに必要とされます。 RSIPホスト、TCP、UDP、またはその両方でサポートすることができます。しかし、一度RSIPホストとゲートウェイは、TCPやUDPのいずれかを使用して通信し始めている、彼らは他のトランスポートプロトコルに切り替えないかもしれません。 TCPは、物理的なメディアタイプおよびトラフィック負荷の幅広い堅牢であることが知られているので、この文書で考慮RSIP実装と展開では、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ゲートウェイは（ケルベロスによって、例えば、分散）または公開/秘密鍵ペアを有しています。後者の場合には、エンティティの公開鍵は、各メッセージおよびメッセージのハッシュを形成する結果に適用されるハッシュ関数にわたって計算することができます。
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サービスをマッピングします唯一のRSIPホスト用のプライベートネットワーク、および（3）ダイナミック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対応ネットワークは、パブリックDNSに更新され、そのAおよびPTRレコードを持っているのFQDNとRSIPホストを可能にしてもよいです。これらの更新は、RSIPによって容易にアドレス割り当てに基づいて、ダイナミックDNS [DHCP-DNS]にDHCPの更新と同様の方法で行われるべきです。 RSIPゲートウェイは両方を更新することができるが、特に、RSIPホストは、レコードをPTRそのAレコードを更新しなくさせなければなりません。 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ホストのFQDNが同じ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つの重要な部分（特に）が必要です。一つは、それ自身として使用するローカル（プライベート）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オプションは、DHCPOFFERメッセージにRSIPゲートウェイのIPアドレスを提供することができます。次のようにこのように、ホストの起動手順は次のようになります（1）DHCPを実行し、RSIPゲートウェイオプションがDHCPOFFERに存在する場合（2）、その中の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]で指定されるようにあるいは、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スタックの実装に関連付けられています。 IPトンネリングやルーティング・コードの修正、ならびにドライバインタフェースは、RSA-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対応ルータの背後に存在します。一つだけ、パブリックネットワークへのゲートウェイ、したがって、唯一のRSIPゲートウェイがあるだろうと思われます。このRSIPゲートウェイは一つだけ、または多分いくつかの、パブリック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ゲートウェイは、住宅、ファイアウォールの一部として実装される可能性がある、そしてそれは、プライベートネットワーク上の専用のゲートウェイの数が少ない上に、特定の宛先ポートへのトラフィックをルーティングする際に呼び出されてもよいです。パブリックネットワークへの唯一のゲートウェイが存在し、このゲートウェイの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ゲートウェイは、ファイアウォールの一部として実装されてもよく、それはおそらく、プライベートネットワーク上の専用のゲートウェイへの特定の宛先ポートへのトラフィックをルーティングするために使用されません。パブリックネットワークへの唯一のゲートウェイが存在し、このゲートウェイの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アドレスを多重化するために、ダイヤルアップリモートアクセスコンセントレータに配置することができます。百せいぜい数のホストは、ゲートウェイのリソースを共有します。 RSIPゲートウェイは、またはファイアウォールの一部として実装してもしなくてもよい、そしてそれはおそらく、プライベートネットワーク上の専用のゲートウェイへの特定の宛先ポートへのトラフィックをルーティングするために使用されません。公衆ネットワークへの唯一のゲートウェイが存在する（リモート・アクセス・コンセントレータ自体）と、このゲートウェイの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ゲートウェイは、ファイアウォールの一部として実装されてもよく、それはおそらく、プライベートネットワーク上の専用のゲートウェイへの特定の宛先ポートへのトラフィックをルーティングするために使用されません。パブリックネットワークへの唯一のゲートウェイが存在し、このゲートウェイの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を使用することができます。どんなに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.254 RSIPゲートウェイCにサブネットブロードキャストアドレス、149.112.240.255は、そう、引き取り手のないままでなければならないことに注意してください - 149.112.240.128 149.112.240.127 RSIPゲートウェイBへ、及びアドレス - 特定の構成では、149.112.240.0アドレスを配布しますそのブロードキャストパケットはまた、RSIPゲートウェイAとRSIPゲートウェイBとCの間のサブネットはプライベートアドレスを使用するRSIPゲートウェイA.背後にある任意のホストに分散させることができます。
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ゲートウェイのAを参照してください、と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ゲートウェイは、必ずしもアドレス（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意志トンネルRSIPゲートウェイA. RSIPゲートウェイAに10.0.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ゲートウェイは、それがその子にパラメータを割り当てると、その親から継承するパラメータの割り当ての制約を考慮に入れなければなりません。子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はまだのALGを必要とし、アーキテクチャは、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はまだのALGを必要とし、アーキテクチャは、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 ALGがインストールされている場合、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を使用しますが、この動作は必須ではありません。二つ以上のRSIPホストが元ポート500でIKEを実行している場合、それらは、割り当てられたIPアドレスごとに異なる開始クッキー（IKEペイロードの最初の8バイト）を使用する必要があります。 RSIPゲートウェイは、イニシエータクッキー値に基づいて、適切なホストへのルートの着信IKEパケットにできるようになります。イニシエータクッキーは、ポートやSPIのように、交渉することができます。同時に同じイニシエータクッキーを使用しようと同じIPアドレスを割り当てられた2つのホストの可能性は非常に小さいので、RSIPゲートウェイは、既に使用されているクッキー値でIKEパケットをドロップすることにより、クッキーの一意性を保証することができます。
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 RESVメッセージが逆方向に流れながら、公共分野における送信者と、のRSVP PATHメッセージは、RSIPゲートウェイに対する着信、送信側から受信側へ下流に流れます。 RSIPは、RSVPメッセージはRSIPトンネル内で処理される方法プライベート領域内の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.
タイプ1のトンネルがRSIPホストとゲートウェイの間に存在する場合は[RFC2476]の用語以下、RSIPゲートウェイを含む全ての中間ノードは、これらのノードに確保されたQoSことなく、非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予約を確保するためにトンネルエンドポイント間で確立されます。通常のトラフィックが通常のIP-IPカプセル化を使用してカプセル化される一方で、特別なQoS保証を必要とするデータトラフィックは、UDP / 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トンネル、またはエンドツーエンドのセッションを動的トンネルセッションにマッピングすることができるタイプ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 PATHメッセージの受信時にシグナリングされなければなりません。 RSIP実装は、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ホストを可能にします。その結果、RSVPのPATHメッセージがRSIPゲートウェイに対処するでしょう。また、着信のRSVP PATH内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デーモンに対するによって生成されたエンドツーエンドのPATHメッセージのグローバルパラメータ（プラストンネリング）への民間からの逆変換を行う必要がありますRSIPホストレシーバー。 SESSIONオブジェクトの変換はまた、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ゲートウェイはマルチキャスト注意する必要があります。 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.
プライベートホストはRSIPゲートウェイ（RSIPホストとゲートウェイ間IGMPプロキシルータがあってもよい）に適切なIGMPメッセージを送信することによりマルチキャストグループに参加して残すことができます。 RSIPゲートウェイは、WANマルチキャストルータにPIMなど、又はプロキシに、それらはマルチキャストWANルーティングプロトコルを実行することかどうか、IGMPメッセージをこれらの要求を合体し、適切なアクションを実行します。一つ以上のプライベートホストがマルチキャストグループへの参加を要求した場合、他の言葉では、RSIPゲートウェイは、独自のパブリックIPアドレスのいずれかを使用して、その代わりに参加する必要があります。
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 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ゲートウェイは、最近一般的に実装されているTIME_WAITの最大期間である、少なくとも2分間のタプルを割り当て解除ホールドすることをお勧めします。ポート空間が不足している状況では、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アドレスの組によって同定することができます。 ICMP要求パケットを送信するRSIPホストはTCPとUDPパケットを同じよう、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要求（例えば、エコー要求）を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は、その断片化が起こらないことが保証され、または可能性または断片化が非常に小さいように設定することができます。パス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
RSAP - IPホストは、よく知られたポートを使用するサーバーをホストに対するNATと同じ制約によって制限されています。宛先ポート番号を一意RSAP-IPホストを識別するためのルーティング情報として使用されるので、典型的には2 RSAP-IPは、同じ公開を共有するホストありません
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アドレスが同時に同じポート上で公に利用可能なゲートウェイを動作させることができます。周知のポート上で動作するプロトコルの場合、これはRSAP-IP IPアドレス/ポートの組ごとに1つのパブリックゲートウェイが同時に使用されることを意味します。しかしながら、RSAP-IPごとに複数のゲートウェイが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ホストのために、ホストは、そのIPアドレスごとに、そのポート番号宛てのすべてのトラフィックを受信したいRSIPゲートウェイに通知しなければなりません。問題のポートが別のホストによって既に使用されている場合には、このような要求は拒否されなければなりません。
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ゲートウェイの背後にある接触装置は困難であり得ます。一般的な問題への潜在的な解決策は、公共のデータベース内のパブリックIPアドレス/ポートのペアを登録するRSIPホスト上のアプリケーションを可能にするアーキテクチャであろう。同時に、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ホストが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を使用せずにパブリックホスト宛に送信した場合、その後、（それがNATをサポートしている場合）RSIPゲートウェイはパケットに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アドレスの総ポート空間六分の一よりもさらに少なくなるであろう。以上のホストまたは複数のポートが必要な場合は、複数のIPアドレスを使用する必要があります。したがって、それは多くの場合、RSIPホストは、それらの活性の寿命のためのポートの割り当てを解除する必要がないことが、合理的です。
Since RSIP demultiplexing fields are leased to hosts, an appropriately chosen lease time can alleviate some port space scarcity issues.
RSIP分離フィールドはホストにリースされているので、適切に選択されたリース時間は、いくつかのポートスペースの不足の問題を軽減することができます。
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ホストにのみに通信を行う場合でも、常にパブリックIPアドレスを使用するすべてのRSIPホストを強制するよう、ご利用いただけます。しかし、これはほとんどのTCP / IPスタックは、ホスト内の通信と考えるだろうと同じ送信元と宛先のIPアドレスを持つ2つのRSIPホスト、間に設定ソケットにつながることができます。
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 Srisuresh、ダンNessett、ゲイリーJaszewski、アジャイBakre、シンディ・ユング、そしてリック・コブに感謝したいと思います。全体としてIETF NATワーキンググループはRSIPの継続的な開発に非常に役立っています。
[DHCP-DNS] Stapp, M. and Y. Rekhter, "Interaction Between DHCP and DNS", Work in Progress.
[DHCP-DNS]スタップ、M.およびY. Rekhter、 "DHCPとDNSとの相互作用" が進行中で働いています。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、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]ボレッラ、M.、Grabelsky、D.、ロー、J.及びK.谷口、 "レルム特定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.チャン、 "RSVPオペレーションオーバーIPトンネル"、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.、モスコウィッツ、B.、Karrenberg、D.、デ・グルート、G.J.およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2002] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
[RFC2002]パーキンス、C.、 "IPモビリティサポート"、RFC 2002、1996年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、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.ホールドレッジ、 "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]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（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]ブレイク、S.、ブラック、D.、カールソン、M.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC3105] Kempf, J. and G. Montenegro, "Finding an RSIP Server with SLP", RFC 3105, October 2001.
[RFC3105]ケンプ、J.とG.モンテネグロ、 "SLPとのRSIPサーバの検索"、RFC 3105、2001年10月。
Michael Borella CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
マイケルボレッラCommWorks 3800ゴルフRdを。ローリングメドウズIL 60008
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
電話：（847）262-3083 Eメール：mike_borella@commworks.com
Jeffrey Lo Candlestick Networks, Inc 70 Las Colinas Lane, San Jose, CA 95119
ジェフリー・ロー燭台ネットワークス、株式会社70ラスコリナスレーン、サンノゼ、CA 95119
Phone: (408) 284 4132 EMail: yidarlo@yahoo.com
電話：（408）284 4132 Eメール：yidarlo@yahoo.com
David Grabelsky CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
デビッドGrabelsky CommWorks 3800ゴルフRdを。ローリングメドウズIL 60008
Phone: (847) 222-2483 EMail: david_grabelsky@commworks.com
電話：（847）222-2483 Eメール：david_grabelsky@commworks.com
Gabriel E. Montenegro Sun Microsystems Laboratories, Europe 29, chemin du Vieux Chene 38240 Meylan FRANCE
ガブリエル・E.モンテネグロSun Microsystemsの研究所、欧州29、CHEMINドゥヴューシュヌ38240メランFRANCE
Phone: +33 476 18 80 45 EMail: gab@sun.com
電話：+33 476 18 80 45 Eメール：gab@sun.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。