Network Working Group M. Borella
Request for Comments: 3103 D. Grabelsky
Category: Experimental CommWorks
J. Lo
Candlestick Networks
K. Taniguchi
NEC USA
October 2001
Realm Specific IP: Protocol Specification
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 the 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 presents a protocol with which to implement Realm Specific IP (RSIP). The protocol defined herein allows negotiation of resources between an RSIP host and gateway, so that the host can lease some of the gateway's addressing parameters in order to establish a global network presence. This protocol is designed to operate on the application layer and to use its own TCP or UDP port. In particular, the protocol allows a gateway to allocate addressing and control parameters to a host such that a flow policy can be enforced at the gateway.
この文書では、レルム特定IP（RSIP）を実装するとプロトコルを提示します。ホストは、グローバルネットワークのプレゼンスを確立するためにゲートウェイのアドレス指定パラメータの一部をリースすることができるように、本明細書に定義されたプロトコルは、RSIPホストとゲートウェイ間でリソースのネゴシエーションを可能にします。このプロトコルは、アプリケーション層で動作するために、独自のTCPやUDPのポートを使用するように設計されています。具体的には、プロトコルは、ゲートウェイは、フローポリシーがゲートウェイに適用することができるように、ホストにアドレス指定および制御パラメータを割り当てることができます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Transport Protocol . . . . . . . . . . . . . . . . . . . . . 7
6. Host / Gateway Relationships . . . . . . . . . . . . . . . . 7
7. Gateway Flow Policy and State . . . . . . . . . . . . . . . . 8
7.1. Local Flow Policy . . . . . . . . . . . . . . . . . . . . . 9
7.2. Remote Flow Policy . . . . . . . . . . . . . . . . . . . . 9
7.3. Gateway State . . . . . . . . . . . . . . . . . . . . . . . 10
8. Parameter Specification and Formats . . . . . . . . . . . . . 11
8.1. Address . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.2. Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.3. Lease Time . . . . . . . . . . . . . . . . . . . . . . . . 13
8.4. Client ID . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.5. Bind ID . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.6. Tunnel Type . . . . . . . . . . . . . . . . . . . . . . . . 14
8.7. RSIP Method . . . . . . . . . . . . . . . . . . . . . . . . 14
8.8. 8.8. Error . . . . . . . . . . . . . . . . . . . . . . . . 14
8.9. Flow Policy . . . . . . . . . . . . . . . . . . . . . . . . 15
8.10. Indicator . . . . . . . . . . . . . . . . . . . . . . . . 15
8.11. Message Counter . . . . . . . . . . . . . . . . . . . . . 16
8.12. Vendor Specific Parameter . . . . . . . . . . . . . . . . 16
9. Message Types . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. ERROR_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 17
9.2. REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . . 18
9.3. REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . . . 19
9.4. DE-REGISTER_REQUEST . . . . . . . . . . . . . . . . . . . . 19
9.5. DE-REGISTER_RESPONSE . . . . . . . . . . . . . . . . . . . 20
9.6. ASSIGN_REQUEST_RSA-IP . . . . . . . . . . . . . . . . . . . 21
9.7. ASSIGN_RESPONSE_RSA-IP . . . . . . . . . . . . . . . . . . 22
9.8. ASSIGN_REQUEST_RSAP-IP . . . . . . . . . . . . . . . . . . 23
9.9. ASSIGN_RESPONSE_RSAP-IP . . . . . . . . . . . . . . . . . . 26
9.10. EXTEND_REQUEST . . . . . . . . . . . . . . . . . . . . . . 27
9.11. EXTEND_RESPONSE . . . . . . . . . . . . . . . . . . . . . 28
9.12. FREE_REQUEST . . . . . . . . . . . . . . . . . . . . . . . 28
9.13. FREE_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 29
9.14. QUERY_REQUEST . . . . . . . . . . . . . . . . . . . . . . 30
9.15. QUERY_RESPONSE . . . . . . . . . . . . . . . . . . . . . . 31
9.16. LISTEN_REQUEST . . . . . . . . . . . . . . . . . . . . . . 32
9.17. LISTEN_RESPONSE . . . . . . . . . . . . . . . . . . . . . 35
10. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 36
10.1. Use of Message Counters . . . . . . . . . . . . . . . . . 36
10.2. RSIP Host and Gateway Failure Scenarios . . . . . . . . . 37
10.3. General Gateway Policy . . . . . . . . . . . . . . . . . . 38
10.4. Errors Not From the RSIP Protocol . . . . . . . . . . . . 39
10.5. Address and Port Requests and Allocation . . . . . . . . . 40
10.6. Local Gateways and Flow Policy Interaction . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . 40
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 41
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
14. Appendix A: RSIP Error Numbers . . . . . . . . . . . . . . . 42
15. Appendix B: Message Types . . . . . . . . . . . . . . . . . 44
16. Appendix C: Example RSIP host/gateway transactions . . . . . 45
17. Appendix D: Example RSIP host state diagram . . . . . . . . 50
18. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
19. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 53
20. Full Copyright Statement . . . . . . . . . . . . . . . . . . 54
Network Address Translation (NAT) has gained popularity as a method of separating public and private address spaces, and alleviating network address shortages. A NAT translates the addresses of packets leaving a first routing realm to an address from a second routing realm, and performs the reverse function for packets entering the first routing realm from the second routing realm. This translation is performed transparently to the hosts in either space, and may include modification of TCP/UDP port numbers and IP addresses in packets that traverse the NAT.
ネットワークアドレス変換（NAT）は、パブリックとプライベートアドレス空間を分離して、ネットワークアドレスの不足を緩和する方法として人気を博しています。 NATは、第2のルーティングレルムからアドレスへの第1のルーティング領域を残してパケットのアドレスを変換し、第二のルーティング領域から第1のルーティング領域に入るパケットの逆の機能を実行します。この翻訳は、空間のいずれかのホストに透過的に実行され、NATを通過するパケットにTCP / UDPポート番号とIPアドレスの変更を含むことができます。
While a NAT does not require hosts to be aware of the translation, it will require an application layer gateway (ALG) for any protocol that transmits IP addresses or port numbers in packet payloads (such as FTP). Additionally, a NAT will not work with protocols that require IP addresses and ports to remain unmodified between the source and destination hosts, or protocols that prevent such modifications from occurring (such as some IPsec modes, or application-layer end-to-end encryption).
NATは翻訳を認識するホストを必要としないが、それは（FTPなど）パケットのペイロードにIPアドレスやポート番号を送信する任意のプロトコルのアプリケーション層ゲートウェイ（ALG）を必要とするであろう。また、NATは、送信元と宛先ホストとの間で非修飾のままにIPアドレスとポートを必要とするプロトコル、または（例えば、いくつかのIPsecモード、またはアプリケーション層のエンドツーエンド暗号化のように発生するような修正を防ぐプロトコルで動作しません。 ）。
An alternative to a NAT is an architecture that allows the hosts within the first (e.g., private) routing realm to directly use addresses and other routing parameters from the second (e.g., public) routing realm. Thus, RSIP [RSIP-FRAME] has been defined as a method for address sharing that exhibits more transparency than NAT. In particular, RSIP requires that an RSIP gateway (a router or gateway between the two realms) assign at least one address from the second routing realm, and perhaps some other resources, to each RSIP host. An RSIP host is a host in the first routing realm that needs to establish end-to-end connectivity to a host, entity or device in the second routing realm. Thus, the second routing realm is not directly accessible from the RSIP host, but this system allows packets to maintain their integrity from the RSIP host to their destination. ALGs are not required in the RSIP gateway.
NATの代わりに、第一内のホスト（例えば、プライベート）直接アドレスとレルムルーティング（例えば、公衆）は、第2から他のルーティングパラメータを使用するレルムをルーティング可能なアーキテクチャです。したがって、RSIP [RSIP-FRAME]はNATよりも透明度を示すアドレスを共有するための方法として定義されています。特に、RSIPはRSIPゲートウェイ（2つのレルム間のルーターまたはゲートウェイ）が各RSIPホストに、少なくとも一つの第2のルーティング領域からのアドレス、そしておそらくいくつかの他のリソースを割り当てることを要求します。 RSIPホストは、第2のルーティングレルムのホスト、エンティティまたはデバイスへのエンドツーエンド接続を確立する必要がある第1のルーティング領域内のホストです。これにより、第2のルーティング領域は、RSIPホストから直接アクセス可能ではないが、このシステムは、パケットがその宛先へRSIPホストからその完全性を維持することを可能にします。 ALGはRSIPゲートウェイで必要とされていません。
RSIP requires that hosts be modified so that they place some number of layer three, layer four or other values from those assigned by the RSIP gateway in each packet bound for the second routing realm.
RSIPは、ホストは、それらが第二のルーティング領域に向かう各パケットにRSIPゲートウェイによって割り当てられたものとはレイヤ3、レイヤ4、または他の値のいくつかの数を置くように改変することが必要です。
This document discusses a method for assigning parameters to an RSIP host from an RSIP gateway. The requirements, scope, and applicability of RSIP, as well as its interaction with other layer 3 protocols, are discussed in a companion framework document [RSIP-FRAME]. Extensions to this protocol that enable end-to-end IPsec are discussed in [RSIP-IPSEC].
この文書では、RSIPゲートウェイからRSIPホストにパラメータを割り当てるための方法を論じています。要件、範囲、およびRSIPの適用、ならびに他のレイヤ3つのプロトコルとの相互作用は、コンパニオン・フレームワークドキュメント[RSIP-FRAME]に記載されています。エンドツーエンドのIPsecを有効このプロトコルへの拡張は[RSIP-IPSEC]で議論されています。
The keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "SHALL", "SHALL NOT", "MAY" and "MAY NOT" that appear in this document are to be interpreted as described in [RFC2119].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED" は、 "べきでない"、 "SHALL" "SHOULD"、 "NOT SHALL"、解釈されるべきである "MAY" と "MAY NOT" この文書に表示されます[RFC2119]に記載されているように。
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 unique network addresses assigned by the Internet Assigned Number Authority (IANA) or an equivalent address registry.
インターネット割り当て番号機関（IANA）または同等のアドレスレジストリによって割り当てられた固有のネットワークアドレスを有するルーティングレルム。
RSIP Host
RSIPホスト
A host within the private realm that acquires publicly unique parameters from an RSIP gateway through the use of the RSIP client/server protocol.
RSIPクライアント/サーバプロトコルを使用してRSIPゲートウェイから公にユニークなパラメータを取得プライベートレルム内のホスト。
RSIP Gateway
RSIPゲートウェイ
A router situated on the boundary between a private realm and a public realm and owns one or more public IP addresses. An RSIP gateway is responsible for public parameter management and assignment to RSIP hosts. An RSIP gateway may act as a NAT router for hosts within the private realm that are not RSIP enabled.
ルータは、プライベート領域とパブリック領域の間の境界に位置し、一個の以上のパブリックIPアドレスを所有しています。 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. Discussed in detail in [RSIP-FRAME]
RSIP方法は、各RSIPホストは、公共分野からのユニークなIPアドレスが割り当てられています。 [RSIP-FRAME]に詳細に議論
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. Discussed in detail in [RSIP-FRAME]
各RSIPホストはIPアドレス（おそらく他のRSIPホストと共用）とパブリック領域からあたりアドレス一意のポートのいくつかの数を割り当てられるRSIP方法。 [RSIP-FRAME]に詳細に議論
Binding
バインディング
An association of some combination of a local address, one or more local ports, a remote address, and a remote port with an RSIP host.
ローカルアドレスのいくつかの組み合わせの関連付け、1つまたは複数のローカルポート、リモートアドレス、およびRSIPホストとリモートポート。
Resource
資源
A general way to refer to an item that an RSIP host leases from an RSIP gateway; e.g., an address or port.
RSIPゲートウェイからRSIPホストリースその項目を参照するための一般的な方法。例えば、アドレスまたはポート。
All other terminology found in this document is consistent with that of [RFC2663] and [RSIP-FRAME].
このドキュメントで見つかった他のすべての用語は、[RFC2663]と[RSIP-FRAME]のそれと一致しています。
For simplicity, in the remainder of this document we will assume that the RSIP hosts in the first routing realm (network) use private (e.g., see [RFC1918]) IP addresses, and that the second routing realm (network) uses public IP addresses. (This assumption is made without loss of generality and the ensuing discussion applies to more general cases.) The RSIP gateway connects the public and private realms and contains interfaces to both. Other NAT terminology found in this document is defined in [RFC2663].
簡単にするために、この文書の残りの部分では、我々は最初のレルム・ルーティング（ネットワーク）でRSIPホストが（例えば、[RFC1918]を参照）は、プライベートIPアドレス、および第2のルーティングレルム（ネットワーク）は、パブリックIPアドレスを使用していることを使用すると仮定します。 （この仮定は一般性を失うことなく行われ、その後の議論は、より一般的なケースに適用される。）RSIPゲートウェイは、パブリックおよびプライベートレルムを接続し、両方にインターフェースを含んでいます。このドキュメントで見つかった他のNATの用語は、[RFC2663]で定義されています。
The diagram below describes an exemplary reference architecture for RSIP.
以下の図はRSIPのための例示的な参照アーキテクチャを記述する。
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
ホストXおよびYは、それぞれ、異なるアドレス範囲AとBに属し、Nは（また、NAT機能を実行することができる）RSIPゲートウェイです。 N 2つのインターフェイスを有している：のNaアドレス空間Aに、およびNbアドレス空間B Nには、それが割り当てまたはアドレス空間にX及び他のホストに貸すことができるアドレス空間B内のアドレスのプールを有していてもよいです
A. These addresses are not shown above, but they can be denoted as Nb1, Nb2, Nb3 and so on.
A.これらのアドレスは、上記に示されていないが、彼らはそうでNB1、のNb2、NB3として表すことができます。
Host X, needing 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 from the RSIP gateway. Upon assignment of these parameters, the RSIP gateway creates a mapping, 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. A lease time is associated with each bind.
アドレス空間B内に位置するネットワークエンティティY、最初の交渉へのエンドツーエンド接続を確立する必要が、Xをホストし、RSIPゲートウェイからリソースの割り当てを取得します。これらのパラメータの割り当ての際に、RSIPゲートウェイは、Xのアドレス情報と割り当てられたリソースのマッピングを作成します。この結合は、正しくX.リース時間Yによって生成された逆多重化及びフォワードインバウンドトラフィックは各バインドに関連付けされた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 MUST support RSAP-IP and MAY support RSA-IP. Details of RSA-IP and RSAP-IP are found in [RSIP-FRAME].
RSA-IPとRSAP-IP：RSIPの二つの基本的なフレーバーがあります。 RSIPホストとゲートウェイはRSAP-IPをサポートしなければならないとRSA-IPをサポートするかもしれません。 RSA-IPとRSAP-IPの詳細は[RSIP-FRAME]に記載されています。
RSIP is an application layer protocol that requires the use of a transport layer protocol for end-to-end delivery of packets.
RSIPは、パケットのエンドツーエンド配信のためのトランスポート層プロトコルの使用を必要とするアプリケーション層プロトコルです。
RSIP gateways MUST support TCP, and SHOULD support UDP. Due to the fact that RSIP may be deployed across a wide variety of network links, RSIP hosts SHOULD support TCP, because of TCP's robustness across said variety of links. However, RSIP hosts MAY support UDP instead of TCP, or both UDP and TCP.
RSIPゲートウェイはTCPをサポートしなければならない、とUDPをサポートする必要があります。リンクの多様性を述べ渡っRSIPは、ネットワークリンクの幅広い全体に展開することができるという事実による、RSIPホストがあるため、TCPの堅牢性を、TCPをサポートする必要があります。しかし、RSIPホストは、UDPの代わりにTCP、またはUDPとTCPの両方をサポートすることができます。
For RSIP hosts and gateways using UDP, timeout and retransmissions MUST occur. We recommend a binary exponential backoff scheme with an initial duration of 12.5 ms, and a maximum of six retries (seven total attempts before failure). However, these parameters MAY be adjusted or tuned for specific link types or scenarios.
UDPを使用してRSIPホストとゲートウェイの場合、タイムアウトと再送信が発生しなければなりません。我々は、12.5ミリ秒の初期持続時間、6回のリトライ（故障前の7回の合計試行）の最大値を有する2進指数バックオフスキームをお勧めします。しかし、これらのパラメータを調整したり、特定のリンクの種類やシナリオに調整することができます。
Once a host and gateway have established a registration using either TCP or UDP, they may not switch between the two protocols for the duration of the registration. The decision of whether to use TCP or UDP is made by the client, and is determined by the transport protocol of the first packet sent by a client in a successful registration procedure.
ホストとゲートウェイは、TCPやUDPのいずれかを使用して、登録を確立したら、彼らは登録の期間中に2つのプロトコルを切り替えない場合があります。 TCPやUDPを使用するかどうかの決定は、クライアントによって行われ、成功した登録手続きにクライアントから送信された最初のパケットの転送プロトコルによって決定されます。
An RSIP host can be in exactly one of three fundamental relationships with respect to an RSIP gateway:
RSIPホストはRSIPゲートウェイに対して正確に3つの基本的な関係にあることができます。
Unregistered: The RSIP gateway does not know of the RSIP host's existence, and it will not forward or deliver globally addressed packets on behalf of the host. The only valid RSIP-related action for an RSIP host to perform in this state is to request registration with an RSIP gateway.
未登録：RSIPゲートウェイはRSIPホストの存在を知りませんし、それは転送しませんか世界的に提供するホストの代わりにパケットを取り上げました。この状態で実行するRSIPホストに対してのみ有効RSIP関連アクションはRSIPゲートウェイへの登録を要求することです。
Registered: The RSIP gateway knows of the RSIP host and has assigned it a client ID and has specified the flow policies that it requires of the host. However, no resources, such as addresses or ports, have been allocated to the host, and the gateway will not forward or deliver globally addressed packets on behalf of the host. All registrations have an associated lease time. If this lease time expires, the RSIP host automatically reverts to the unregistered state.
登録：RSIPゲートウェイはRSIPホストを知っているし、それをクライアントIDが割り当てられており、それがホストの要求するフローポリシーを指定しています。しかし、そのようなアドレスやポートなどの一切のリソースは、ホストに割り当てられていない、と前方またはグローバル配信しませんゲートウェイは、ホストの代わりにパケットを取り上げてきました。すべての登録は、関連するリース時間を持っています。このリース期間が満了した場合は、RSIPホストが自動的に登録されていない状態に戻ります。
Assigned: The RSIP gateway has granted one or more bindings of resources to the host. The gateway will forward and deliver globally addressed packets on behalf of the host. Each binding has an associated lease time. If this lease time expires, the binding is automatically revoked.
割り当て：RSIPゲートウェイがホストに資源の一つまたは複数のバインディングを付与しています。ゲートウェイは転送し、ホストに代わって世界的に取り組まパケットを配信します。各バインディングは、関連するリース時間を持っています。このリース期間が満了した場合、結合は自動的に取り消されます。
Architectures in which an RSIP host is simultaneously registered with more than one RSIP gateway are possible. In such cases, an RSIP host may be in different relationships with different RSIP gateways at the same time.
RSIPホストが同時に複数のRSIPゲートウェイに登録されたアーキテクチャが可能です。このような場合、RSIPホストは同時に異なるRSIPゲートウェイと異なる関係であってもよいです。
An RSIP gateway MAY redirect an RSIP host to use a tunnel endpoint for data traffic that is not the RSIP gateway itself, or perhaps is a different interface on the RSIP gateway. This is done by specifying the tunnel endpoint's address as part of an assignment. In such an architecture, it is desirable (though not necessary) for the RSIP gateway to have a method with which to notify the tunnel endpoint of assignments, and the expiration status of these assignments.
RSIPゲートウェイはRSIPゲートウェイ自体でない、またはおそらくRSIPゲートウェイ上の異なるインタフェースであるデータトラフィックのためのトンネルエンドポイントを使用するRSIPホストをリダイレクトすることができます。これは、割り当ての一部として、トンネルエンドポイントのアドレスを指定することによって行われます。このようなアーキテクチャでは、RSIPゲートウェイは割り当てのトンネルエンドポイント、及びこれらの割り当ての有効期限の状態を通知すると方法を有することが望ましい（必須ではないが）のためのものです。
Lease times for bindings and registrations are managed as follows. All lease times are given in units of seconds from the current time, indicating a time in the future at which the lease will expire. These expiration times are used in the ensuing discussion.
次のようにバインドし、登録のためのリース時間が管理されています。すべてのリース時間はリースが期限切れになるで将来の時刻を示す、現在時刻から秒単位で与えられます。これらの有効期限は、その後の議論の中で使用されています。
An initial expiration time (R) is given to a registration. Under this registration, multiple bindings may be established, each with their own expiration times (B1, B2, ...). When each binding is established or extended, the registration expiration time is adjusted so that the registration will last at least as long as the longest lease. In other words, when binding Bi is established or extended, the following calculation is performed: R = max(R, Bi).
初期有効期限（R）は登録に与えられます。この登録の下では、複数のバインディングは、自分自身の有効期限（B1、B2、...）と、それぞれを確立することができます。各結合が確立または拡張された場合、登録が最長のリースと少なくとも同じ長く続くように、登録の有効期限が調整されます。 Biが確立または拡張された結合換言すれば、以下の計算が行われる：R = MAX（R、BI）。
Under this scheme, a registration will never expire while any binding's lease is still valid. However, a registration may expire when the last binding's lease expires, or at some point thereafter.
任意のバインディングのリースがまだ有効である間、このスキームの下では、登録が期限切れになりません。最後のバインディングのリースの有効期限が切れたときただし、登録の有効期限が切れたり、その後いくつかの点で。
Since an RSIP gateway is likely to reside on the boundary between two or more different administrative domains, it is desirable to enable an RSIP gateway to be able to enforce flow-based policy. In other words, an RSIP gateway should have the ability to explicitly control which local addresses and ports are used to communicate with remote addresses and ports.
RSIPゲートウェイは、2つの以上の異なる管理ドメイン間の境界上に存在する可能性があるので、フローベースのポリシーを実施することができるようにRSIPゲートウェイを有効にすることが望ましいです。換言すれば、RSIPゲートウェイは、明示的にリモートアドレスおよびポートとの通信に使用されるローカルアドレスとポート制御する能力を有するべきです。
In the following, macro-flow policy refers to controlling flow policy at the granularity level of IP addresses, while micro-flow policy refers to controlling flow policy at the granularity of IP address and port tuples. Of course there may be no policy at all, which indicates that the RSIP gateway does not care about the flow parameters used by RSIP hosts. We consider two levels of local flow policy and three levels of remote flow policy.
マイクロ流ポリシーはIPアドレス及びポートのタプルの粒度でフローポリシ制御を意味しつつ以下に、マクロ・フロー・ポリシーは、IPアドレスの細分性レベルでフロー・ポリシーを制御することをいいます。もちろんRSIPゲートウェイはRSIPホストによって使用されるフローパラメータを気にしないことを示し全くポリシーが存在しない場合があります。私たちは、地元のフローポリシーとリモートフロー政策の三つのレベルの二つのレベルを考えます。
Local flow policy determines the granularity of control that an RSIP gateway has over the local addressing parameters that an RSIP host uses for particular sessions.
ローカルフローポリシーはRSIPゲートウェイはRSIPホストが特定のセッションのために使用するローカルアドレス指定パラメータにわたって有することを制御の粒度を決定します。
Since an RSIP host must use at least an IP address allocated by the gateway, the loosest level of local flow policy is macro-flow based. Under local macro-flow policy, an RSIP host is allocated an IP address (RSA-IP) or an IP address and one or more ports to use with it (RSAP-IP). However, the host may use the ports as it desires for establishing sessions with public hosts.
RSIPホストがゲートウェイによって割り当てられた、少なくともIPアドレスを使用しなければならないので、ローカルフローポリシーの最も緩いレベルは、マクロフロー基づいています。ローカルマクロフローポリシーの下で、RSIPホストは（RSAP-IP）で使用するIPアドレス（RSA-IP）、またはIPアドレスと1つの以上のポートが割り当てられます。それは公共のホストとのセッションを確立するために望むようしかし、ホストがポートを使用することができます。
Under micro-flow policy, a host is allocated exactly one port at a time. The host may request more ports, also one at a time. This policy gives the gateway very tight control over local port use, although it affords the host less flexibility.
マイクロフローポリシーの下では、ホストが一度に正確に一つのポートに割り当てられています。ホストはまた、一度に一つ以上のポートを要求することができます。それはホスト少ない柔軟性をもたらすが、このポリシーは、ローカルポートの使用を通じたゲートウェイ非常にタイトなコントロールを提供します。
Note that only local macro-flow policy can be used with RSA-IP, while either local macro-flow or local micro-flow policy may be used with RSAP-IP.
ローカルマクロフローまたはローカルマイクロ流ポリシーのいずれかがRSAP-IPで使用することができるが、ローカルマクロフローポリシーは、RSA-IPで使用することができることに留意されたいです。
Examples of how RSIP flow policy operates are given in Appendix C.
フローポリシーがどのように動作するかRSIPの例は、付録C.に与えられています
Remote flow policy determines the granularity of control that an RSIP gateway has over the remote (public) hosts with which an RSIP host communicates. In particular, remote flow policy dictates what level of detail that a host must specify addressing parameters of a remote host or application before the RSIP gateway allows the host to communicate with that host or application.
遠隔フローポリシーRSIPゲートウェイはRSIPホストが通信する遠隔（パブリック）ホスト上に有することを制御の粒度を決定します。特に、遠隔フローポリシーはRSIPゲートウェイは、ホストがそのホストまたはアプリケーションと通信することを可能にする前に、ホストがリモートホストまたはアプリケーションのアドレッシングのパラメータを指定する必要があり、詳細のレベルことを指示します。
The simplest and loosest form of flow policy is no policy at all. In other words, the RSIP gateway allocates addressing parameters to the host, and the host may use these parameters to communicate with any remote host, without explicitly notifying the gateway.
フロー政策の最も単純で最も緩い形はまったく政策ではありません。換言すれば、RSIPゲートウェイがホストにパラメータをアドレス割り当て、ホストが明示的にゲートウェイに通知することなく、任意のリモートホストと通信するようにこれらのパラメータを使用してもよいです。
Macro-flow policy requires that the host identify the remote address of the host that it wishes to communicate with as part of its request for local addressing parameters. If the request is granted, the host MUST use the specified local parameters only with the remote address specified, and MUST NOT communicate with the remote address using any local parameters but the ones allocated. However, the host may contact any port number at the remote host without explicitly notifying the gateway.
マクロフローポリシーは、ホストがローカルアドレス指定のパラメータのためにその要求の一部として、それが通信したいホストのリモートアドレスを識別することを必要とします。要求が許可されている場合は、ホストは指定されたリモートアドレスで指定されたローカルパラメータを使用しなければならない、と任意のローカルパラメータが、割り当てられたものを使用してリモートアドレスと通信してはなりません。しかし、ホストが明示的にゲートウェイに通知することなく、リモート・ホストの任意のポート番号に連絡してもよいです。
Micro-flow policy requires that the host identify the remote address and port of the host that it wishes to communicate with as part of its request for local addressing parameters. If the request is granted, the host MUST use the specified local parameters only with the remote address and port specified, and MUST NOT communicate with the remote address and port using any local parameters but the ones allocated.
マイクロフローポリシーは、ホストは、ローカルアドレス指定のパラメータのためにその要求の一部として、と通信することを望むホストのリモートアドレスおよびポートを識別することを必要とします。要求が許可されている場合は、ホストは指定されたリモートアドレスとポートに指定されたローカルパラメータを使用しなければならない、と任意のローカルパラメータが、割り当てられたものを使用してリモートアドレスとポートと通信してはなりません。
Remote flow policy is implemented in both the ingress and egress directions, with respect to the location of the RSIP gateway.
遠隔フローポリシーはRSIPゲートウェイの位置に対して、両方の入力および出力方向に実装されます。
An RSIP gateway must maintain state for all RSIP hosts and their assigned resources. The amount and type of state maintained depends on the local and remote flow policy. The required RSIP gateway state will vary based on the RSIP method, but will always include the chosen method's demultiplexing parameters.
RSIPゲートウェイは、すべてのRSIPホストとその割り当てられたリソースの状態を維持しなければなりません。状態維持の量と種類は、ローカルおよびリモートのフローポリシーに依存します。必要RSIPゲートウェイ状態がRSIP法に基づいて変化するが、常に選択された方法の逆多重化パラメータを含むであろう。
An RSIP gateway serving an RSIP host using the RSA-IP method MUST maintain the following minimum state to ensure proper mapping of incoming packets to RSIP hosts:
RSIPゲートウェイRSA-IP方式を用いてRSIPホストにサービスを提供するRSIPホストに着信パケットの正しいマッピングを保証するために、次の最小状態を維持しなければなりません。
- Host's private address - Host's assigned public address(es)
- ホストのプライベートアドレス - ホストの割り当てられたパブリックアドレス（複数可）
An RSIP gateway serving an RSIP host using the RSAP-IP method MUST maintain the following minimum state to ensure proper mapping of incoming packets to RSIP hosts:
RSAP-IP方式はRSIPホストに着信パケットの正しいマッピングを保証するために、次の最小状態を維持しなければならない使用RSIPホストにサービスを提供するRSIPゲートウェイ。
- Host's private address - Host's assigned public address(es) - Host's assigned port(s) per address
- ホストのプライベートアドレス - ホストの割り当てられたパブリックアドレス（複数可） - アドレスごとにホストに割り当てられたポート（複数可）
Regardless of whether the gateway is using RSA-IP or RSAP-IP, additional state is necessary if either micro-flow based or macro-flow based remote policy is used.
いずれかのマイクロ流は、ベースまたはマクロフローベースのリモートポリシーが使用される場合にかかわらず、ゲートウェイは、RSA-IP又はRSAP-IPを使用しているかどうかの、付加的な状態が必要です。
If the gateway is using macro-flow based remote policy, the following state must be maintained:
ゲートウェイは、マクロ・フローベースのリモートポリシーを使用している場合、次の状態が維持されなければなりません。
- Remote host's address
- リモートホストのアドレス
If the gateway is using micro-flow based remote policy, the following state must be maintained:
ゲートウェイは、マイクロフローベースのリモートポリシーを使用している場合、次の状態が維持されなければなりません。
- Remote host's address - Remote host's port
- リモートホストのアドレス - リモートホストのポート
More state MAY be used by an RSIP gateway if desired. For example, ToS/DS bytes may be recorded in order to facilitate quality of service support.
所望であれば、より多くの状態がRSIPゲートウェイによって使用されてもよいです。例えば、TOS / DSバイトはサービスのサポートの品質を容易にするために、記録されていてもよいです。
In this section we define the formats for RSIP parameters. Each RSIP message contains one or more parameters that encode the information passed between the host and gateway. The general format of all parameters is TLV (type-length-value) consisting of a 1-byte type followed by a 2-byte length followed by a 'length' byte value as shown below.
このセクションでは、RSIPパラメータのフォーマットを定義します。各RSIPメッセージは、ホストとゲートウェイとの間で渡される情報を符号化する1つ以上のパラメータを含んでいます。以下に示すように全てのパラメータの一般的な形式は、「長さ」バイトの値に続く2バイトの長さに続く1バイトのタイプからなるTLV（タイプ - 長さ - 値）です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value ...
+-+-+-+-+-+-+-+-+-+-+-+
The value field may be divided into a number of other fields as per the type of the parameter. Note that the length field encodes the number of bytes in the value field, NOT the overall number of bytes in the parameter.
値フィールドは、パラメータの種類ごとに他のフィールドに分割されてもよいです。長さフィールドは、値フィールドのバイト数、NOTパラメータ内のバイトの総数をコードしていることに注意してください。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length | Addrtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address...
+-+-+-+-+-+-+-+-+-+-+-+
The address parameter contains addressing information, either an IPv4 address or netmask, an IPv6 address or netmask, or a fully qualified domain name (FQDN). The Addrtype field is 1 byte in length, indicating the type of address.
アドレスパラメータは、情報、IPv4アドレスまたはネットマスク、IPv6アドレスまたはネットマスク、または完全修飾ドメイン名（FQDN）のいずれかへの対処が含まれています。 ADDRTYPEフィールドはアドレスのタイプを示す、長さが1バイトです。
Addrtype Length of address field (in bytes)
---- --------------------------------
0 Reserved 0
1 IPv4 4
2 IPv4 netmask 4
3 IPv6 16
4 FQDN varies
For FQDN (Fully qualified domain name), the length of the address field will be one less than the value of the length field, and the name will be represented as an ASCII string (no terminating character).
FQDN（完全修飾ドメイン名）の場合は、アドレスフィールドの長さは、長さフィールドの値より一つ少なくなり、名前はASCII文字列（無終端文字）として表現されます。
In some cases, it is necessary to specify a "don't care" value for an address. This is signified by a setting the length field to 1 and omitting the value field.
いくつかの例では、アドレスの「気にしない」の値を指定する必要があります。これは、1に長さフィールドを設定し、値フィールドを省略することによって示されます。
It is not valid for a host to request an address with an FQDN type as its local address (See specification of ASSIGN_REQUEST_RSA-IP and ASSIGN_REQUEST_RSAP-IP, below).
ホストはそのローカルアドレス（以下、ASSIGN_REQUEST_RSA-IPとASSIGN_REQUEST_RSAP-IPの仕様を参照してください）としてFQDNタイプとアドレスを要求することは有効ではありません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length | Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port number | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The ports parameter encodes zero or more TCP or UDP ports. When a single port is specified, the value of the number field is 1 and there is one port field following the number field. When more than one port is specified, the value of the number field will indicate the total number of ports contained, and the parameter may take one of two forms. If there is one port field, the ports specified are considered to be contiguous starting at the port number specified in the port field. Alternatively, there may be a number of port fields equal to the value of the number field. The number of port fields can be extrapolated from the length field.
ポートパラメータがゼロまたはそれ以上のTCPまたはUDPポートをコードしています。単一のポートが指定されている場合、番号フィールドの値が1であり、番号フィールド、次の1つのポートフィールドがあります。複数のポートが指定されている場合、番号フィールドの値が含まれているポートの総数を示します、パラメータは、二つのいずれかの形式をとることができます。 1つのポートフィールドがある場合、指定されたポートは、ポートフィールドに指定されたポート番号での連続始動であると考えられます。あるいは、番号フィールドの値に等しいポートフィールドの数が存在してもよいです。ポートフィールドの数は、長さフィールドから推定することができます。
In some cases, it is necessary to specify a don't care value for one or more ports (e.g., when a client application is using ephemeral source ports). This is accomplished by setting the length field to 1, setting the number field to the number of ports necessary, and omitting all port fields. The value of the number field MUST be greater than or equal to one.
いくつかの場合において、それは、1つ以上のポートのドントケア値を指定する必要がある（例えば、クライアント・アプリケーションは、エフェメラル送信元ポートを使用している場合）。これは、1に長さフィールドを設定する必要なポートの数に番号フィールドを設定し、すべてのポートフィールドを省略することによって達成されます。番号フィールドの値が1以上でなければなりません。
If micro-flow based policy applies to a given ports parameter, it MUST contain exactly one port field.
マイクロフローベースのポリシーは、特定のポートパラメータに適用された場合、それは正確に1つのポートフィールドを含まなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 4 | Lease time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The lease time parameter specifies the length, in seconds, of an RSIP host registration or parameter binding.
リース時間パラメータは、RSIPホスト登録やパラメータの結合、秒単位で、長さを指定します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 4 | Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The client ID parameter specifies an RSIP client ID. Client ID's by an RSIP gateway to differentiate RSIP hosts.
クライアントIDパラメータはRSIPクライアントのIDを指定します。 RSIPホストを区別するためにRSIPゲートウェイによって、クライアントのIDの。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 5 | Length = 4 | Bind ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bind ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The bind ID parameter specifies an RSIP bind ID. Bind ID's are used by RSIP hosts and gateways to differentiate an RSIP host's bindings.
バインドIDパラメータはRSIPバインドIDを指定します。バインドIDはRSIPホストのバインディングを区別するためにRSIPホストとゲートウェイによって使用されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 1 | Tunnel type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The tunnel type parameter specifies the type of tunnel used between an RSIP host and an RSIP gateway. Defined tunnel types are:
トンネル型パラメータは、RSIPホストとRSIPゲートウェイの間で使用されるトンネルのタイプを指定します。定義されたトンネルタイプは次のとおりです。
Tunnel Type
-----------
0 Reserved
1 IP-IP
2 GRE
3 L2TP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length = 1 | RSIP method |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The RSIP method parameter specifies an RSIP method. Defined RSIP methods are:
RSIPメソッドのパラメータは、RSIP方法を指定します。定義されたRSIP方法は以下のとおりです。
RSIP method
-----------
0 Reserved
1 RSA-IP
2 RSAP-IP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length = 2 | Error |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error |
+-+-+-+-+-+-+-+-+
The error parameter specifies an error. The currently defined error values are presented in Appendix A.
errorパラメータは、エラーを指定します。現在定義されたエラー値は、付録Aに提示されています
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 2 | Local |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Remote |
+-+-+-+-+-+-+-+-+
The flow policy parameter specifies both the local and remote flow policy.
フローポリシーパラメータは、ローカルおよびリモートの流れポリシーの両方を指定します。
Defined local flow policies are:
定義された局所的な流れの方針は以下のとおりです。
Local Flow Policy
-----------------
0 Reserved
1 Macro flows
2 Micro flows
Defined remote flow policies are:
定義されたリモートフローポリシーは、次のとおりです。
Remote Flow Policy
------------------
0 Reserved
1 Macro flows
2 Micro flows
3 No policy
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 10 | Length = 2 | Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value |
+-+-+-+-+-+-+-+-+
An indicator parameter is a general-purpose parameter, the use of which is defined by the message that it appears in. An RSIP message that uses an indicator parameter MUST define the meaning and interpretation of all of the indicator's possible values.
インジケータ・パラメータの汎用パラメータであり、の使用は、それが中に表示されるメッセージによって定義される。インジケータ・パラメータを使用していますRSIPメッセージが表示の可能なすべての値の意味と解釈を定義しなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 11 | Length = 4 | Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
A message counter parameter is used to mark RSIP messages with sequentially-increasing values. Message counters MUST be used with UDP, in order to facilitate reliability.
メッセージカウンタパラメータが順次増加値とRSIPメッセージをマークするために使用されます。メッセージカウンタは、信頼性を容易にするために、UDPを使用しなければなりません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 12 | Length | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Vendor ID | Subtype | Value...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The vendor specific parameter is used to encode parameters that are defined by a particular vendor. The vendor ID field is the vendor-specific ID assigned by IANA. Subtypes are defined and used by each vendor as necessary. An RSIP host or gateway SHOULD silently ignore vendor-specific messages that it does not understand.
ベンダー固有のパラメータは、特定のベンダによって定義されたパラメータを符号化するために使用されます。ベンダーIDフィールドは、IANAによって割り当てられたベンダー固有のIDです。サブタイプは、必要に応じて、各ベンダによって定義され、使用されています。 RSIPホストやゲートウェイは、静かにそれを理解していないベンダー固有のメッセージを無視すべきです。
RSIP messages consist of three mandatory fields, version, message type, and overall length, followed by one or more required parameters, followed in turn by zero or more optional parameters. In an RSIP message, all required parameters MUST appear in the exact order specified below. Optional parameters MAY appear in any order. Message format is shown below:
RSIPメッセージは、1つ以上の必要なパラメータが続く3つの必須フィールド、バージョン、メッセージタイプ、および全長、から成る、ゼロ以上の任意のパラメータによって順番に続きます。 RSIPメッセージに、必要なすべてのパラメータは、以下に指定正確な順序で現れなければなりません。オプションのパラメータは任意の順序で表示されることがあります。メッセージのフォーマットを以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message type | Overall length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Parameters...
+-+-+-+-+-+-+-+-+-+-+
The version number field is a single byte and specifies the RSIP version number that is being used. The current RSIP version number is 1.
バージョン番号フィールドは、シングルバイトで、使用されているRSIPバージョン番号を指定します。現在のRSIPバージョン番号は1です。
The message type field is a single byte and specifies the message contained in the current packet. There may be only one message per packet. Message types are given numerical assignments in Appendix B.
メッセージタイプフィールドは、シングルバイトで、現在のパケットに含まれるメッセージを指定します。パケットごとに1つだけのメッセージがあるかもしれません。メッセージタイプは、付録Bに数値の割り当てを与えられています
The overall length field is two bytes and contains the number of bytes in the RSIP message, including the three mandatory fields.
全体の長さフィールドは2バイトであり、3つの必須フィールドを含むRSIPメッセージのバイト数を含んでいます。
Most parameters are only allowed to appear once in each message. The exceptions are as follows:
ほとんどのパラメータは、唯一の、各メッセージに一度表示されるように許可されています。例外は次のとおりです。
- Multiple address parameters MUST appear in ASSIGN_REQUEST_RSA-IP, ASSIGN_RESPONSE_RSA-IP, ASSIGN_REQUEST_RSAP-IP, ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE.
- 複数のアドレスパラメータはASSIGN_REQUEST_RSA-IP、ASSIGN_RESPONSE_RSA-IP、ASSIGN_REQUEST_RSAP-IP、ASSIGN_RESPONSE_RSAP-IP、LISTEN_REQUESTとLISTEN_RESPONSEに現れなければなりません。
- Multiple ports parameters MUST appear in ASSIGN_REQUEST_RSAP-IP, ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE.
- 複数のポートのパラメータはASSIGN_REQUEST_RSAP-IP、ASSIGN_RESPONSE_RSAP-IP、LISTEN_REQUESTとLISTEN_RESPONSEに現れなければなりません。
- Multiple RSIP method and tunnel type parameters MAY appear in RESISTER_RESPONSE.
- 複数のRSIP方法及びトンネル型パラメータはRESISTER_RESPONSEに表示されることがあります。
- Multiple address parameters and multiple indicator parameters MAY appear in QUERY_REQUEST and QUERY_RESPONSE.
- 複数のアドレスパラメータと複数の指標のパラメータがQUERY_REQUESTとQUERY_RESPONSEに表示されることがあります。
The following message types are defined in BNF. Required parameters are enclosed in <> and MUST appear. Optional parameters are enclosed in [] and MAY appear. Not all message types need to be implemented in order to be RSIP compliant. For example, an RSIP host and/or gateway may not support LISTEN_REQUEST and LISTEN_RESPONSE, or may only support RSAP-IP and not RSA-IP.
次のメッセージタイプは、BNFで定義されています。必須パラメータは<>で囲まれていると表示される必要があります。オプションのパラメータは、[]で囲まれていると表示されることがあります。いないすべてのメッセージタイプは、RSIP準拠するために実装する必要があります。例えば、RSIPホスト及び/又はゲートウェイがLISTEN_REQUESTとLISTEN_RESPONSEをサポートしていない場合があり、または唯一RSAP-IPとしないRSA-IPをサポートすることができます。
An ERROR_RESPONSE is used to provide error messages from an RSIP gateway to an RSIP host. Usually, errors indicate that the RSIP gateway cannot or will not perform an action or allocate resources on behalf of the host. If the error is related to a particular client ID or bind ID, these associated parameters MUST be included. Multiple errors MAY NOT be reported in the same ERROR_RESPONSE. In situations where more than one error has occurred, the RSIP gateway MUST choose only one error to report.
ERROR_RESPONSEはRSIPホストにRSIPゲートウェイからエラーメッセージを提供するために使用されます。通常、エラーがRSIPゲートウェイがまたはアクションを実行したり、ホストの代わりにリソースを割り当てないであろうことはできないことを示しています。エラーが特定のクライアントIDまたはバインドIDに関連している場合、これらの関連するパラメータを含まなければなりません。複数のエラーは同じERROR_RESPONSEに報告することはできません。複数のエラーが発生している状況では、RSIPゲートウェイが報告するだけつのエラーを選択する必要があります。
<ERROR_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Error>
[Message Counter]
[Client ID]
[Bind ID]
An ERROR_RESPONSE message MUST only be transmitted by an RSIP gateway. An RSIP host that detects an error in a message received from an RSIP gateway MUST silently discard the message. There are no error conditions that can be caused by an ERROR_RESPONSE. An ERROR_RESPONSE is typically transmitted in response to a request from an RSIP host, but also may be transmitted asynchronously by an RSIP gateway.
ERROR_RESPONSEメッセージのみRSIPゲートウェイによって送信されなければなりません。 RSIPゲートウェイから受信したメッセージのエラーを検出RSIPホストは静かにメッセージを捨てなければなりません。 ERROR_RESPONSEによって引き起こされる可能性がエラー条件はありません。 ERROR_RESPONSEは、典型的には、RSIPホストからの要求に応じて送信されるだけでなく、RSIPゲートウェイによって非同期的に送信することができます。
The REGISTER_REQUEST message is used by an RSIP host to establish registration with an RSIP gateway. An RSIP host MUST register before it requests resources or services from an RSIP gateway. Once an RSIP host has registered with an RSIP gateway, it may not register again until it has de-registered from that gateway.
REGISTER_REQUESTメッセージはRSIPゲートウェイの登録を確立するためにRSIPホストによって使用されます。それはRSIPゲートウェイからのリソースまたはサービスを要求する前にRSIPホストが登録する必要があります。 RSIPホストはRSIPゲートウェイに登録されたらそれがゲートウェイから登録解除されるまで、再度登録しないことができます。
<REGISTER_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
[Message Counter]
The following message-specific error conditions exist:
次のメッセージ固有のエラー条件が存在します。
- If the host is already registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the ALREADY_REGISTERED error and the RSIP host's client ID.
- ホストがすでにゲートウェイに登録されている場合、ゲートウェイはALREADY_REGISTEREDエラーとRSIPホストのクライアントIDを含むERROR_RESPONSEで応じなければなりません。
- If the gateway's policy will not allow the host to register, the gateway MUST respond with an ERROR_RESPONSE containing the REGISTRATION_DENIED error.
- ゲートウェイのポリシーはホストが登録を許可しない場合、ゲートウェイはREGISTRATION_DENIEDエラーを含むERROR_RESPONSEで応じなければなりません。
The REGISTER_RESPONSE message is used by an RSIP gateway to confirm the registration of an RSIP host, and to provide a client ID, flow policy, and possibly a message counter and one or more RSIP methods and/or tunnel types.
REGISTER_RESPONSEメッセージはRSIPホストの登録を確認するために、クライアントIDを提供するために、ポリシーを流れ、そしておそらくメッセージカウンタと1つ以上のRSIPの方法および/またはトンネルタイプRSIPゲートウェイによって使用されます。
<REGISTER_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Lease time>
<Flow Policy>
[Message Counter]
[RSIP Method]...
[Tunnel Type]...
An RSIP gateway MUST assign a different client ID to each host that is simultaneously registered with it. The RSIP gateway MAY respond with one or more RSIP methods and tunnel types that it supports. If an RSIP method is not specified, RSAP-IP MUST be assumed. If a tunnel type is not specified, IP-IP MUST be assumed.
RSIPゲートウェイは同時に、それに登録されている各ホストに異なるクライアントIDを割り当てる必要があります。 RSIPゲートウェイは、一つ以上のRSIP方法とそれがサポートするトンネルタイプで応答することができます。 RSIP方法が指定されていない場合、RSAP-IPを想定しなければなりません。トンネル型が指定されていない場合、IP-IPを想定しなければなりません。
The DE-REGISTER_REQUEST message is used by an RSIP host to de-register with an RSIP gateway. If a host de-registers from the assigned state, all of the host's bindings are revoked. The host SHOULD NOT de-register from the unregistered state.
DE-REGISTER_REQUESTメッセージはRSIPゲートウェイと登録解除するRSIPホストによって使用されます。割り当てられた状態から、ホスト・デ・レジスタは、ホストのバインディングのすべてが取り消された場合。ホストが未登録の状態から登録解除すべきではありません。
<DE-REGISTER_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
The following message-specific error conditions exist:
次のメッセージ固有のエラー条件が存在します。
- If the host is not registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the REGISTER_FIRST error.
- ホストがゲートウェイに登録されていない場合、ゲートウェイはREGISTER_FIRSTエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the message contains an incorrect client ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_CLIENT_ID error.
- メッセージが間違ったクライアントIDが含まれている場合、ゲートウェイはBAD_CLIENT_IDエラーを含むERROR_RESPONSEで応じなければなりません。
If there are no errors that result from this message, the gateway MUST respond with an appropriate DE-REGISTER_RESPONSE. Upon de-registering a host, an RSIP gateway must delete all binds associated with that host and return their resources to the pool of free resources. Once a host has de-registered, it may not use any of the RSIP gateway's resources without registering again.
このメッセージに起因するエラーがない場合、ゲートウェイは適切なDE-REGISTER_RESPONSEで応答しなければなりません。ホストを解除登録時に、RSIPゲートウェイはそのホストに関連付けられているすべてのバインドを削除する必要があり、自由なリソースのプールにそのリソースを返します。ホストは登録解除したら、それは再び登録せずにRSIPゲートウェイのリソースのいずれかを使用することはできません。
The DE-REGISTER_RESPONSE message is used by an RSIP gateway to confirm the de-registration of an RSIP host or to force an RSIP host to relinquish all of its bindings and terminate its relationship with the RSIP gateway. Upon receiving a DE-REGISTER_RESPONSE message, an RSIP host MUST stop all use of the resources that have been allocated to it by the gateway.
DE-REGISTER_RESPONSEメッセージはRSIPホストの登録解除を確認するために、またはそのバインディングのすべてを放棄し、RSIPゲートウェイとの関係を終了するRSIPホストを強制的にRSIPゲートウェイによって使用されます。 DE-REGISTER_RESPONSEメッセージを受信すると、RSIPホストは、ゲートウェイによってそれに割り当てられたすべてのリソースの使用を停止する必要があります。
<DE-REGISTER_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
An RSIP gateway MUST send a DE-REGISTER_RESPONSE in response to a valid DE-REGISTER_REQUEST. An RSIP gateway MUST send a DE-REGISTER_RESPONSE to an RSIP host when that host's registration lease time times out. An RSIP gateway SHOULD send a DE-REGISTER_RESPONSE if it detects that it will no longer be able to perform RSIP functionality for a given host. An RSIP host MUST be ready to accept a DE-REGISTER_RESPONSE at any moment.
RSIPゲートウェイは、有効なDE-REGISTER_REQUESTに応じて、DE-REGISTER_RESPONSEを送らなければなりません。アウト時に、そのホストの登録リース時間時間RSIPゲートウェイはRSIPホストにDE-REGISTER_RESPONSEを送らなければなりません。それはもはや特定のホストに対してRSIP機能を実行することはできなくなることを検出した場合RSIPゲートウェイは、DE-REGISTER_RESPONSEを送るべきです。 RSIPホストはいつでもDE-REGISTER_RESPONSEを受け入れる準備ができなければなりません。
The ASSIGN_REQUEST_RSA-IP message is used by an RSIP host to request resources to use with RSA-IP. Note that RSA-IP cannot be used in combination with micro-flow based local policy.
ASSIGN_REQUEST_RSA-IPメッセージはRSA-IPで使用するためのリソースを要求するためにRSIPホストが使用されます。 RSA-IPマイクロフローベースのローカルポリシーと組み合わせて使用することができないことに留意されたいです。
<ASSIGN_REQUEST_RSA-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]
The RSIP host specifies two address parameters. The RSIP host may request a particular local address by placing that address in the first address parameter. To indicate that it has no preference for local address, the RSIP host may place a "don't care" value in the address parameter.
RSIPホストは、2つのアドレスパラメータを指定します。 RSIPホストは、最初のアドレスパラメータでそのアドレスを配置することによって、特定のローカルアドレスを要求することができます。それはローカルアドレスのための好みを持っていないことを示すために、RSIPホストは、アドレスパラメータの値を「気にしない」を配置します。
If macro-flow based remote policy is used, the host MUST specify the remote address that it will use this binding (if granted) to contact; however, the remote port number MAY remain unspecified. If micro-flow based remote policy is used, the host MUST specify the remote address and port number that it will use this binding (if granted) to contact. If no flow policy is used, the RSIP host may place a "don't care" value in the value fields of the respective address and ports parameters.
マクロフローベースのリモートポリシーが使用される場合、ホストは、それが接触する（許可された場合）、この結合を使用することリモートアドレスを指定する必要があります。ただし、リモートポート番号が指定されていないままになることがあります。マイクロ流ベースのリモートポリシーが使用される場合、ホストは、それが接触する（許可された場合）、この結合を使用することをリモートアドレスとポート番号を指定しなければなりません。何のフローポリシーが使用されていない場合、RSIPホストはそれぞれのアドレスとポートパラメータの値フィールドに値を「気にしない」を配置します。
The following message-specific error conditions exist:
次のメッセージ固有のエラー条件が存在します。
- If the host is not registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the REGISTER_FIRST error.
- ホストがゲートウェイに登録されていない場合、ゲートウェイはREGISTER_FIRSTエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the message contains an incorrect client ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_CLIENT_ID error.
- メッセージが間違ったクライアントIDが含まれている場合、ゲートウェイはBAD_CLIENT_IDエラーを含むERROR_RESPONSEで応じなければなりません。
- If the local address parameter is a don't care value and the RSIP gateway cannot allocate ANY addresses, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNAVAILABLE error.
- ローカルアドレスパラメータが値を気にしないとRSIPゲートウェイがANYアドレスを割り当てることができない場合には、RSIPゲートウェイはLOCAL_ADDR_UNAVAILABLEエラーを含むERROR_RESPONSEで応じなければなりません。
- If the local address parameter is not a don't care value there are three possible error conditions:
- ローカルアドレスパラメータは気にしない値でない場合には三つの可能なエラー条件があります。
o If the RSIP gateway cannot allocate ANY addresses, it MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNAVAILABLE error.
RSIPゲートウェイがANYアドレスを割り当てることができない場合は、O、それはLOCAL_ADDR_UNAVAILABLEエラーを含むERROR_RESPONSEで応じなければなりません。
o If the RSIP gateway cannot allocate the requested address because it is in use, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
それが使用されているので、RSIPゲートウェイは、要求されたアドレスを割り当てることができない場合は、O、RSIPゲートウェイはLOCAL_ADDR_INUSEエラーを含むERROR_RESPONSEで応じなければなりません。
o If the RSIP gateway cannot allocate the requested address because it is not allowed by policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNALLOWED error.
それはポリシーで許可されていないので、RSIPゲートウェイは、要求されたアドレスを割り当てることができない場合は、O、RSIPゲートウェイはLOCAL_ADDR_UNALLOWEDエラーを含むERROR_RESPONSEで応じなければなりません。
- If macro-flow based remote policy is used and the requested remote address is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the REMOTE_ADDR_UNALLOWED error.
- マクロ・フローベースのリモートポリシーが使用され、要求されたリモートアドレスがRSIPゲートウェイのポリシーで許可されていない場合、RSIPゲートウェイはREMOTE_ADDR_UNALLOWEDエラーを含むERROR_RESPONSEで応答しなければなりません。
- If micro-flow based remote policy is used and the requested remote address / port pair is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED error.
- マイクロ流ベースのリモートポリシーが使用され、要求されたリモートアドレス/ポートのペアがRSIPゲートウェイのポリシーで許可されていない場合、RSIPゲートウェイはREMOTE_ADDRPORT_UNALLOWEDエラーを含むERROR_RESPONSEで応答しなければなりません。
- If an unsupported or unallowed tunnel type is specified, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the BAD_TUNNEL_TYPE error.
- サポートされていない、または許可されていないトンネル型が指定されている場合、RSIPゲートウェイはBAD_TUNNEL_TYPEエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the host has not specified local or remote address or port information in enough detail, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION error.
- ホストが十分に詳細にローカルまたはリモートのアドレスやポート情報を指定していない場合、RSIPゲートウェイはFLOW_POLICY_VIOLATIONエラーを含むERROR_RESPONSEで応答しなければなりません。
The ASSIGN_RESPONSE_RSA-IP message is used by an RSIP gateway to deliver parameter assignments to an RSIP host using RSA-IP. A host-wise unique bind ID, lease time, and tunnel type must be provided for every assignment.
ASSIGN_RESPONSE_RSA-IPメッセージは、RSA-IPを使用して、RSIPホストにパラメータの割り当てを提供するためにRSIPゲートウェイによって使用されます。ホストごとのユニークなバインドID、リース期間、およびトンネルタイプは、すべての割り当てのために提供されなければなりません。
<ASSIGN_RESPONSE_RSA-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]
9.7.3. Behavior
If no remote flow policy is used, the RSIP gateway MUST use "don't care" values for the remote address and ports parameters. If macro-flow based remote policy is used, the remote address parameter MUST contain the address specified in the associated request, and the remote ports parameter MUST contain a "don't care" value. If micro-flow based remote policy is used, the remote address and remote ports parameters MUST contain the address and port information specified in the associated request.
何のリモートフローポリシーが使用されていない場合、RSIPゲートウェイは、リモートアドレスとポートパラメータの値を「気にしない」を使用しなければなりません。マクロフローベースのリモートポリシーが使用される場合、リモートアドレスパラメータが関連する要求で指定されたアドレスを含まなければならない、とリモートポートパラメータが「ドントケア」値を含まなければなりません。マイクロ流ベースのリモートポリシーが使用される場合、リモートアドレスとリモートポートのパラメータが関連する要求で指定されたアドレスとポート情報を含まなければなりません。
If the host detects an error or otherwise does not "understand" the gateway's response, it SHOULD send a FREE_REQUEST with the bind ID from the said ASSIGN_RESPONSE_RSA-IP. This will serve to help synchronize the states of the host and gateway.
ホストがエラーを検出したか、そうでない場合はゲートウェイの応答を「理解」していない場合、それは言っASSIGN_RESPONSE_RSA-IPからバインドIDとFREE_REQUESTを送るべきです。これは、ホストとゲートウェイの状態を同期させる手助けするのに役立つであろう。
The address of a tunnel endpoint that is not the RSIP gateway MAY be specified. If this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint.
RSIPゲートウェイないトンネルエンドポイントのアドレスを指定することができます。このパラメータが指定されていない場合、RSIPゲートウェイは、トンネルのエンドポイントであると仮定しなければなりません。
The ASSIGN_REQUEST_RSAP-IP message is used by an RSIP host to request resources to use with RSAP-IP. The RSIP host specifies two address and two port parameters, the first of each, respectively, refer to the local address and port(s) that will be used, and the second of each, respectively, refer to the remote address and port(s) that will be contacted.
ASSIGN_REQUEST_RSAP-IPメッセージがRSAP-IPで使用するためのリソースを要求するためにRSIPホストが使用されます。 RSIPホストはリモートアドレスとポート（単数または複数を指し、それぞれ、2つのアドレスをそれぞれ2つのポートパラメータ、それぞれの最初に、指定し、使用されるローカルアドレスとポート（複数可）を参照し、各々の第2 ）それは、ご連絡させていただきます。
<ASSIGN_REQUEST_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]
An RSIP host may request a particular local address by placing that address in the value field of the first address parameter. The RSIP host may request particular local ports by placing them in the first port parameter. To indicate that it has no preference for local address or ports, the RSIP host may place a "don't care" value in the respective address or ports parameters.
RSIPホストは、第1のアドレスのパラメータの値フィールドにそのアドレスを配置することによって、特定のローカルアドレスを要求することができます。 RSIPホストは、第1のポートパラメータでそれらを置くことによって、特定のローカルポートを要求することができます。それはローカルアドレスやポートのための好みを持っていないことを示すために、RSIPホストは、それぞれのアドレスやポートパラメータの値を「気にしない」を配置します。
If macro-flow based remote policy is used, the host MUST specify the remote address that it will use this binding (if granted) to contact; however, the remote port number(s) MAY remain unspecified. If micro-flow based remote policy is used, the host MUST specify the remote address and port number(s) that it will use this binding (if granted) to contact. If no flow policy is used, the RSIP host may place a value of all 0's in the value fields of the respective address or port parameters.
マクロフローベースのリモートポリシーが使用される場合、ホストは、それが接触する（許可された場合）、この結合を使用することリモートアドレスを指定する必要があります。ただし、リモートポート番号（複数可）、不特定残ることがあります。マイクロ流ベースのリモートポリシーが使用される場合、ホストは接触することは（許可された場合）、この結合を使用することをリモートアドレスとポート番号（複数可）を指定する必要があります。何のフローポリシーが使用されていない場合、RSIPホストは、それぞれのアドレスやポートのパラメータの値フィールドに全て0の値を入れることができます。
The following message-specific error conditions exist:
次のメッセージ固有のエラー条件が存在します。
- If the host is not registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the REGISTER_FIRST error.
- ホストがゲートウェイに登録されていない場合、ゲートウェイはREGISTER_FIRSTエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the message contains an incorrect client ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_CLIENT_ID error.
- メッセージが間違ったクライアントIDが含まれている場合、ゲートウェイはBAD_CLIENT_IDエラーを含むERROR_RESPONSEで応じなければなりません。
- If the local address parameter is a don't care value and the RSIP gateway cannot allocate ANY addresses, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNAVAILABLE error.
- ローカルアドレスパラメータが値を気にしないとRSIPゲートウェイがANYアドレスを割り当てることができない場合には、RSIPゲートウェイはLOCAL_ADDR_UNAVAILABLEエラーを含むERROR_RESPONSEで応じなければなりません。
- If the local address parameter is not a don't care value there are five possible error conditions:
- ローカルアドレスパラメータは気にしない値でない場合には5つの可能なエラー条件があります。
o If the RSIP gateway cannot allocate ANY addresses, it MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNAVAILABLE error.
RSIPゲートウェイがANYアドレスを割り当てることができない場合は、O、それはLOCAL_ADDR_UNAVAILABLEエラーを含むERROR_RESPONSEで応じなければなりません。
o If the RSIP gateway cannot allocate the requested address because it is in use, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
それが使用されているので、RSIPゲートウェイは、要求されたアドレスを割り当てることができない場合は、O、RSIPゲートウェイはLOCAL_ADDR_INUSEエラーを含むERROR_RESPONSEで応じなければなりません。
o If the RSIP gateway cannot allocate the requested address because it is not allowed by policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNALLOWED error.
それはポリシーで許可されていないので、RSIPゲートウェイは、要求されたアドレスを割り当てることができない場合は、O、RSIPゲートウェイはLOCAL_ADDR_UNALLOWEDエラーを含むERROR_RESPONSEで応じなければなりません。
o If the RSIP gateway cannot allocate a requested address / port tuple because it is in use, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDRPORT_INUSE error.
それが使用されているため、O RSIPゲートウェイは、要求されたアドレス/ポート組を割り当てることができない場合、RSIPゲートウェイはLOCAL_ADDRPORT_INUSEエラーを含むERROR_RESPONSEで応答しなければなりません。
o If the RSIP gateway cannot allocate a requested address / port tuple because it is not allowed by policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDRPORT_UNALLOWED error.
それはポリシーで許可されていないため、RSIPゲートウェイは、要求されたアドレス/ポート組を割り当てることができない場合はO、RSIPゲートウェイはLOCAL_ADDRPORT_UNALLOWEDエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the RSIP host requests a number of ports (greater that one), but does not specify particular port numbers (i.e., uses "don't care" values) the RSIP gateway cannot grant the entire request, the RSIP gateway MUST return an ERROR_RESPONSE containing the LOCAL_ADDRPORT_UNAVAILABLE error.
- RSIPホストがポート（1その以上）の数を要求したが、RSIPゲートウェイが要求全体を付与することはできません、RSIPゲートウェイは返さなければならない（つまり、値を「気にしない」を使用して）特定のポート番号を指定していない場合LOCAL_ADDRPORT_UNAVAILABLEエラーを含むERROR_RESPONSE。
- If macro-flow based remote policy is used and the requested remote address is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the REMOTE_ADDR_UNALLOWED error.
- マクロ・フローベースのリモートポリシーが使用され、要求されたリモートアドレスがRSIPゲートウェイのポリシーで許可されていない場合、RSIPゲートウェイはREMOTE_ADDR_UNALLOWEDエラーを含むERROR_RESPONSEで応答しなければなりません。
- If micro-flow based remote policy is used and the requested remote address / port pair is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED error.
- マイクロ流ベースのリモートポリシーが使用され、要求されたリモートアドレス/ポートのペアがRSIPゲートウェイのポリシーで許可されていない場合、RSIPゲートウェイはREMOTE_ADDRPORT_UNALLOWEDエラーを含むERROR_RESPONSEで応答しなければなりません。
- If an unsupported or unallowed tunnel type is specified, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the BAD_TUNNEL_TYPE error.
- サポートされていない、または許可されていないトンネル型が指定されている場合、RSIPゲートウェイはBAD_TUNNEL_TYPEエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the host has not specified local or remote address or port information in enough detail, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION error.
- ホストが十分に詳細にローカルまたはリモートのアドレスやポート情報を指定していない場合、RSIPゲートウェイはFLOW_POLICY_VIOLATIONエラーを含むERROR_RESPONSEで応答しなければなりません。
The ASSIGN_RESPONSE_RSAP-IP message is used by an RSIP gateway to deliver parameter assignments to an RSIP host. A host-wise unique bind ID, lease time, and tunnel type must be provided for every assignment.
ASSIGN_RESPONSE_RSAP-IPメッセージはRSIPホストにパラメータの割り当てを提供するためにRSIPゲートウェイによって使用されます。ホストごとのユニークなバインドID、リース期間、およびトンネルタイプは、すべての割り当てのために提供されなければなりません。
<ASSIGN_RESPONSE_RSAP-IP> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Lease Time>
<Tunnel Type>
[Address (tunnel endpoint)]
[Message Counter]
Regardless of local flow policy, a local address and port(s) MUST be assigned to the host. If macro-flow based local policy is used, the host is assigned an address and one or more ports. If micro-flow based local policy is used, the host is assigned an address and exactly one port.
かかわらず、ローカルフローポリシの、ローカルアドレスとポート（複数可）は、ホストに割り当てられなければなりません。マクロフローベースのローカルポリシーが使用される場合、ホストはアドレスと1つの以上のポートが割り当てられています。マイクロ流ベースのローカルポリシーが使用される場合、ホストは、アドレスと正確に一つのポートが割り当てられています。
If no remote flow policy is used, the RSIP gateway MUST use "don't care" values for the remote address and ports parameters. If macro-flow based remote policy is used, the remote address parameter MUST contain the address specified in the associated request, and the remote ports parameter must contain a "don't care" value. If micro-flow based remote policy is used, the remote address and remote ports parameters MUST contain the address and port information specified in the associated request.
何のリモートフローポリシーが使用されていない場合、RSIPゲートウェイは、リモートアドレスとポートパラメータの値を「気にしない」を使用しなければなりません。マクロフローベースのリモートポリシーを使用する場合は、リモートアドレスパラメータは、関連する要求で指定されたアドレスを含まなければならない、とリモートポートパラメータは「気にしない」の値が含まれている必要があります。マイクロ流ベースのリモートポリシーが使用される場合、リモートアドレスとリモートポートのパラメータが関連する要求で指定されたアドレスとポート情報を含まなければなりません。
If the host detects an error or otherwise does not "understand" the gateway's response, it SHOULD send a FREE_REQUEST with the bind ID from the said ASSIGN_RESPONSE_RSAP-IP. This will serve to help synchronize the states of the host and gateway.
ホストがエラーを検出したか、そうでない場合はゲートウェイの応答を「理解」していない場合、それは言っASSIGN_RESPONSE_RSAP-IPからバインドIDとFREE_REQUESTを送るべきです。これは、ホストとゲートウェイの状態を同期させる手助けするのに役立つであろう。
The address of a tunnel endpoint that is not the RSIP gateway MAY be specified. If this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint.
RSIPゲートウェイないトンネルエンドポイントのアドレスを指定することができます。このパラメータが指定されていない場合、RSIPゲートウェイは、トンネルのエンドポイントであると仮定しなければなりません。
The EXTEND_REQUEST message is used to request a lease extension to a current bind. It may be used with both RSA-IP and RSAP-IP. The host MUST specify its client ID and the bind ID in question, and it MAY suggest a lease time to the gateway.
EXTEND_REQUESTメッセージは、現在のバインドにリースの延長を要求するために使用されます。これは、RSA-IPとRSAP-IPの両方で使用することができます。ホストは、そのクライアントID、問題のバインドIDを指定する必要があり、それがゲートウェイにリース時間を提案することができます。
<EXTEND_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Lease Time]
[Message Counter]
The following message-specific error conditions exist:
次のメッセージ固有のエラー条件が存在します。
- If the host is not registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the REGISTER_FIRST error.
- ホストがゲートウェイに登録されていない場合、ゲートウェイはREGISTER_FIRSTエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the message contains an incorrect client ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_CLIENT_ID error.
- メッセージが間違ったクライアントIDが含まれている場合、ゲートウェイはBAD_CLIENT_IDエラーを含むERROR_RESPONSEで応じなければなりません。
- If the message contains an incorrect bind ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_BIND_ID error.
- メッセージが正しくないバインドIDが含まれている場合、ゲートウェイはBAD_BIND_IDエラーを含むERROR_RESPONSEで応じなければなりません。
If the RSIP gateway grants an extension to the host's lease, it MUST RESPOND with an appropriate EXTEND_RESPONSE message. If the lease is not renewed, the RSIP gateway MAY let it implicitly expire by doing nothing or make it explicitly expire by sending an appropriate FREE_RESPONSE message.
RSIPゲートウェイは、ホストのリースの延長を許可した場合、それは適切なEXTEND_RESPONSEメッセージで応答しなければなりません。リースが更新されていない場合は、RSIPゲートウェイは、それが暗黙のうちに何もしないことにより、有効期限が切れてみましょうか、それが明示的に適切なFREE_RESPONSEメッセージを送信することにより、有効期限が切れることがあります。
The EXTEND_RESPONSE message is used by an RSIP gateway to grant a requested lease extension. The gateway MUST specify the client ID of the host, the bind ID in question, and the new assigned lease time.
EXTEND_RESPONSEメッセージは、要求されたリースの延長を許可するRSIPゲートウェイによって使用されます。ゲートウェイは、ホスト、問題のバインドID、および新しい割り当てられたリース時間のクライアントIDを指定する必要があります。
<EXTEND_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Lease Time>
[Message Counter]
The RSIP gateway will determine lease time as per its local policy. The returned time is to be interpreted as the number of seconds before the lease expires, counting from the time at which the message is sent/received.
RSIPゲートウェイは、ローカルポリシーに従ってリース時間を決定します。返された時間は、メッセージが受信/送信された時点から数えて、リースが期限切れになるまでの秒数として解釈されるべきです。
The FREE_REQUEST message is used by an RSIP host to free a binding. The given bind ID identifies the bind to be freed. Resources may only be freed using the granularity of a bind ID.
FREE_REQUESTメッセージはバインディングを解放するためにRSIPホストが使用されます。与えられたバインドIDを解放するためのバインドを識別する。リソースにのみバインドIDの粒度を使用して解放することができます。
<FREE_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Message Counter]
The following message-specific error conditions exist:
次のメッセージ固有のエラー条件が存在します。
- If the host is not registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the REGISTER_FIRST error.
- ホストがゲートウェイに登録されていない場合、ゲートウェイはREGISTER_FIRSTエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the message contains an incorrect client ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_CLIENT_ID error.
- メッセージが間違ったクライアントIDが含まれている場合、ゲートウェイはBAD_CLIENT_IDエラーを含むERROR_RESPONSEで応じなければなりません。
- If the message contains an incorrect bind ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_BIND_ID error.
- メッセージが正しくないバインドIDが含まれている場合、ゲートウェイはBAD_BIND_IDエラーを含むERROR_RESPONSEで応じなければなりません。
If a host receives an error in response to a FREE_REQUEST, this may indicate that the host and gateway's states have become unsynchronized. Therefore, the host SHOULD make an effort to resynchronize, such as freeing resources then re-requesting them, or de-registering then re-registering.
ホストはFREE_REQUESTに応じて、エラーを受信した場合、これはホストとゲートウェイの状態が同期しなくなっていることを示してもよいです。したがって、ホストは、そのような彼らを再要求し、その後リソースを解放して、再同期するための努力をしなければならない、または脱登録、再登録、その後。
The FREE_RESPONSE message is used by an RSIP gateway to acknowledge a FREE_REQUEST sent by an RSIP host, and to asynchronously deallocate resources granted to an RSIP host.
FREE_RESPONSEメッセージはRSIPホストによって送信さFREE_REQUESTを確認するためにRSIPゲートウェイで使用され、そして非同期割り当て解除のリソースがRSIPホストに付与します。
<FREE_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
[Message Counter]
An RSIP host must always be ready to accept a FREE_RESPONSE, even if its lease on the specified bind ID is not yet expired.
RSIPホストは常に指定されたバインドIDのリースがまだ有効期限が切れていない場合でも、FREE_RESPONSEを受け入れる準備ができなければなりません。
A QUERY_REQUEST message is used by an RSIP host to ask an RSIP gateway whether or not a particular address or network is local or remote. The host uses this information to determine whether to contact the host(s) directly (in the local case), or via RSIP (in the remote case).
QUERY_REQUESTメッセージは、特定のアドレスまたはネットワークがローカルかリモートであるか否かRSIPゲートウェイを依頼するRSIPホストによって使用されます。ホストは、（ローカルの場合）ホスト（単数または複数）に直接に接触するかどうかを決定するためにこの情報を使用して、またはRSIPを介して（遠隔場合）。
This message defines an indicator parameter with a 1-byte value field and 2 defined values:
このメッセージは、1バイトの値フィールドと2つの定義された値を有するインジケータ・パラメータを定義します。
- 1 address - 2 network
- 1番地 - 2ネットワーク
<QUERY_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
[Address Tuple]...
[Network Tuple]...
where
<Address Tuple> ::= <Indicator (address)>
<Address>
<Network Tuple> ::= <Indicator (network)>
<Address (network)>
<Address (netmask)>
One or more address or network tuples may be specified. Each tuple encodes a request regarding the locality (local or remote) of the encoded address or network. If no tuple is specified, the RSIP gateway should interpret the message as a request for all tuples that it is willing to provide. Note that the FQDN form of the address parameter cannot be used to specify the address of a network, and only the netmask form of the address parameter can be used to specify the netmask of a network.
一つ以上のアドレスまたはネットワークのタプルを指定することができます。各タプルは、符号化されたアドレスまたはネットワークの（ローカルまたはリモート）局所性に関する要求をエンコードします。何組が指定されていない場合、RSIPゲートウェイは、提供する意思があるすべてのタプルのための要求としてメッセージを解釈すべきです。アドレスパラメータのFQDNの形式は、ネットワークのアドレスを指定するために使用することができず、アドレスパラメータのみネットマスク形態は、ネットワークのネットマスクを指定するために使用することができることに留意されたいです。
If an RSIP gateway cannot determine whether a queried host or network is local or remote, it SHOULD transmit a QUERY_RESPONSE with no response specified for the said host or network.
RSIPゲートウェイ照会ホストまたはネットワークは、ローカルまたはリモートであるかを判断できない場合は、前記ホストまたはネットワークに指定されない応答でQUERY_RESPONSEを送信しなければなりません。
The following message-specific error conditions exist:
次のメッセージ固有のエラー条件が存在します。
- If the host is not registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the REGISTER_FIRST error.
- ホストがゲートウェイに登録されていない場合、ゲートウェイはREGISTER_FIRSTエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the message contains an incorrect client ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_CLIENT_ID error.
- メッセージが間違ったクライアントIDが含まれている場合、ゲートウェイはBAD_CLIENT_IDエラーを含むERROR_RESPONSEで応じなければなりません。
A QUERY_RESPONSE message is used by an RSIP gateway to answer a QUERY_REQUEST from an RSIP host.
QUERY_RESPONSEメッセージはRSIPホストからQUERY_REQUESTに答えるためにRSIPゲートウェイによって使用されます。
This message defines an indicator parameter with a 1-byte value field and 4 defined values:
このメッセージは、1バイトの値フィールド及び4つの定義された値を有するインジケータ・パラメータを定義します。
- 1 local address - 2 local network - 3 remote address - 4 remote network
- 1ローカルアドレス - 2ローカルネットワーク - 3つのリモートアドレス - 4リモートネットワーク
<QUERY_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
[Message Counter]
[Local Address Tuple]...
[Local Network Tuple]...
[Remote Address Tuple]...
[Remote Network Tuple]...
where
どこ
<Local Address Tuple> ::= <Indicator (local address)>
<Address>
<Local Network Tuple> ::= <Indicator (local network)>
<Address (network)>
<Address (netmask)>
<Remote Address Tuple> ::= <Indicator (remote address)>
<Address>
<Remote Network Tuple> ::= <Indicator (remote network)>
<Address (network)>
<Address (netmask)>
An RSIP gateway has some leeway in how it responds to a QUERY_REQUEST. It may just provide the information requested, if it can provide such information. It may provide its complete list of address and networks, in order to minimize the number of requests that the host needs to perform in the future. How an RSIP gateway responds may depend on network traffic considerations as well.
RSIPゲートウェイは、それがQUERY_REQUESTにどのように応答するかでいくつかの余裕を持っています。それは、このような情報を提供することができればそれだけで、要求された情報を提供することができます。これは、ホストが、将来的に実行する必要のある要求の数を最小限に抑えるために、アドレスやネットワークのその完全なリストを提供することができます。どのようにRSIPゲートウェイが応答することだけでなく、ネットワークトラフィックの考慮事項に依存してもよいです。
If an RSIP gateway sends a QUERY_RESPONSE that does not contain any tuples, or a QUERY_RESPONSE that does not contain a tuple that applies to an associated tuple in the associated QUERY_REQUEST, this should be interpreted that the RSIP gateway does not know whether the queried host or network is local or remote. Appropriate host behavior upon receipt of such a message is to assume that the queried host or network is remote.
RSIPゲートウェイは、任意のタプルを含まないQUERY_RESPONSE、または関連QUERY_REQUESTに関連したタプルに適用されるタプルを含まないQUERY_RESPONSEを送信した場合、これはRSIPゲートウェイ照会ホストかどうかわからないと解釈されるべきである、またはネットワークは、ローカルまたはリモートです。このようなメッセージを受信すると、適切な宿主ビヘイビア照会ホストまたはネットワークがリモートであると仮定することです。
Note that an RSIP gateway is not expected to maintain a complete list of all remote hosts and networks. In fact, a typical RSIP gateway will only maintain a list of the networks and hosts that it knows are local (private with respect to the RSIP host).
RSIPゲートウェイがすべてのリモートホストとネットワークの完全なリストを維持することが期待されていないことに留意されたいです。実際には、典型的なRSIPゲートウェイはネットワークのリストを維持し、それが（RSIPホストに関してプライベート）ローカルです知っていることをホストします。
A LISTEN_REQUEST message is sent by an RSIP host that wants to register a service on a particular address and port number. The host must include its client ID, local address parameter and ports parameters, and remote address and ports parameters. The client MAY suggest a lease time and one or more tunnel types.
LISTEN_REQUESTメッセージは、特定のアドレスとポート番号でサービスを登録したいRSIPホストによって送信されます。ホストは、そのクライアントID、ローカルアドレスパラメータおよびポートパラメータ、およびリモートアドレスとポートのパラメータを含める必要があります。クライアントは、リース時間と1つまたは複数のトンネルタイプを提案することができます。
<LISTEN_REQUEST> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
[Message Counter]
[Lease Time]
[Tunnel Type]...
If the host wants to listen on a particular address or port, it may specify these in the address and ports parameters. Otherwise it may leave one or both of these parameters with "don't care" values.
ホストが特定のアドレスまたはポートでリッスンしたい場合は、アドレスとポートのパラメータでこれらを指定することもできます。それ以外の場合は「気にしない」の値を持つこれらのパラメータのいずれかまたは両方を残すことができます。
If no remote flow policy is being used, the host MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the host MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the host MUST specify the remote address and ports parameter.
何のリモートフローポリシーが使用されていない場合、ホストは「気にしない」値をリモートアドレスとポートパラメータの両方を入力する必要があります。マクロフローベースのリモートポリシーを使用する場合は、ホストはリモートアドレスを指定する必要がありますが、またはリモートポート（複数可）を指定しない場合があります。マイクロ流ベースのリモートポリシーが使用される場合、ホストはリモートアドレスとポートパラメータを指定する必要があります。
Once a LISTEN_REQUEST has been granted, the RSIP gateway MUST forward all packets destined to the address and port in question to the host, even if the remote host address and port tuple has not been previously contacted by the host.
LISTEN_REQUESTが付与された後、RSIPゲートウェイは、リモートホストアドレスとポートタプルが以前にホストによって接触していない場合でも、ホストに問題のアドレスとポート宛のすべてのパケットを転送する必要があります。
LISTEN_REQUEST is not necessary for RSA-IP.
LISTEN_REQUESTは、RSA-IPのための必要はありません。
The following message-specific error conditions exist:
次のメッセージ固有のエラー条件が存在します。
- If the host is not registered with the gateway, the gateway MUST respond with an ERROR_RESPONSE containing the REGISTER_FIRST error.
- ホストがゲートウェイに登録されていない場合、ゲートウェイはREGISTER_FIRSTエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the message contains an incorrect client ID, the gateway MUST respond with an ERROR_RESPONSE containing the BAD_CLIENT_ID error.
- メッセージが間違ったクライアントIDが含まれている場合、ゲートウェイはBAD_CLIENT_IDエラーを含むERROR_RESPONSEで応じなければなりません。
- If the local address parameter is a don't care value and the RSIP gateway cannot allocate ANY addresses, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNAVAILABLE error.
- ローカルアドレスパラメータが値を気にしないとRSIPゲートウェイがANYアドレスを割り当てることができない場合には、RSIPゲートウェイはLOCAL_ADDR_UNAVAILABLEエラーを含むERROR_RESPONSEで応じなければなりません。
- If the local address parameter is not a don't care value there are five possible error conditions:
- ローカルアドレスパラメータは気にしない値でない場合には5つの可能なエラー条件があります。
o If the RSIP gateway cannot allocate ANY addresses, it MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNAVAILABLE error.
RSIPゲートウェイがANYアドレスを割り当てることができない場合は、O、それはLOCAL_ADDR_UNAVAILABLEエラーを含むERROR_RESPONSEで応じなければなりません。
o If the RSIP gateway cannot allocate the requested address because it is in use, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE error.
それが使用されているので、RSIPゲートウェイは、要求されたアドレスを割り当てることができない場合は、O、RSIPゲートウェイはLOCAL_ADDR_INUSEエラーを含むERROR_RESPONSEで応じなければなりません。
o If the RSIP gateway cannot allocate the requested address because it is not allowed by policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNALLOWED error.
それはポリシーで許可されていないので、RSIPゲートウェイは、要求されたアドレスを割り当てることができない場合は、O、RSIPゲートウェイはLOCAL_ADDR_UNALLOWEDエラーを含むERROR_RESPONSEで応じなければなりません。
o If the RSIP gateway cannot allocate the requested address / port tuple because it is in use, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDRPORT_INUSE error.
それが使用されているため、O RSIPゲートウェイは、要求されたアドレス/ポート組を割り当てることができない場合、RSIPゲートウェイはLOCAL_ADDRPORT_INUSEエラーを含むERROR_RESPONSEで応答しなければなりません。
o If the RSIP gateway cannot allocate the requested address / port tuple because it is not allowed by policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDRPORT_UNALLOWED error.
それはポリシーで許可されていないため、RSIPゲートウェイは、要求されたアドレス/ポート組を割り当てることができない場合はO、RSIPゲートウェイはLOCAL_ADDRPORT_UNALLOWEDエラーを含むERROR_RESPONSEで応答しなければなりません。
- If macro-flow based remote policy is used and the requested remote address is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the REMOTE_ADDR_UNALLOWED error.
- マクロ・フローベースのリモートポリシーが使用され、要求されたリモートアドレスがRSIPゲートウェイのポリシーで許可されていない場合、RSIPゲートウェイはREMOTE_ADDR_UNALLOWEDエラーを含むERROR_RESPONSEで応答しなければなりません。
- If micro-flow based remote policy is used and the requested remote address / port pair is not allowed by the RSIP gateway's policy, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED error.
- マイクロ流ベースのリモートポリシーが使用され、要求されたリモートアドレス/ポートのペアがRSIPゲートウェイのポリシーで許可されていない場合、RSIPゲートウェイはREMOTE_ADDRPORT_UNALLOWEDエラーを含むERROR_RESPONSEで応答しなければなりません。
- If an unsupported or unallowed tunnel type is specified, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the BAD_TUNNEL_TYPE error.
- サポートされていない、または許可されていないトンネル型が指定されている場合、RSIPゲートウェイはBAD_TUNNEL_TYPEエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the host has not specified local or remote address or port information in enough detail, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the FLOW_POLICY_VIOLATION error.
- ホストが十分に詳細にローカルまたはリモートのアドレスやポート情報を指定していない場合、RSIPゲートウェイはFLOW_POLICY_VIOLATIONエラーを含むERROR_RESPONSEで応答しなければなりません。
A LISTEN_RESPONSE message is used by an RSIP gateway to respond to a LISTEN_REQUEST message from an RSIP host. The RSIP gateway MUST issue a bind ID, and specify the address and port which have been granted to the host. The gateway must also specify a tunnel type and lease time.
LISTEN_RESPONSEメッセージはRSIPホストからLISTEN_REQUESTメッセージに応答するためにRSIPゲートウェイによって使用されます。 RSIPゲートウェイは、バインドIDを発行し、ホストに付与されているアドレスとポートを指定する必要があります。ゲートウェイは、トンネルタイプを指定し、時間をリースしなければなりません。
If no remote flow policy is being used, the gateway MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the gateway MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the gateway MUST specify the remote address and ports parameter.
何のリモートフローポリシーが使用されていない場合、ゲートウェイは「気にしない」値をリモートアドレスとポートパラメータの両方を入力する必要があります。マクロフローベースのリモートポリシーが使用される場合、ゲートウェイは、リモート・アドレスを指定する必要がありますが、またはリモートポート（複数可）を指定してもしなくてもよいです。マイクロ流ベースのリモートポリシーが使用される場合、ゲートウェイは、リモートアドレスとポートパラメータを指定する必要があります。
<LISTEN_RESPONSE> ::= <Version>
<Message Type>
<Overall Length>
<Client ID>
<Bind ID>
<Address (local)>
<Ports (local)>
<Address (remote)>
<Ports (remote)>
<Tunnel Type>
<Lease Time>
[Address (tunnel endpoint)]
[Message Counter]
If no remote flow policy is being used, the gateway MUST fill both the remote address and ports parameters with "don't care" values. If macro-flow based remote policy is used, the gateway MUST specify the remote address, but MAY or MAY NOT specify the remote port(s). If micro-flow based remote policy is used, the gateway MUST specify the remote address and ports parameter.
何のリモートフローポリシーが使用されていない場合、ゲートウェイは「気にしない」値をリモートアドレスとポートパラメータの両方を入力する必要があります。マクロフローベースのリモートポリシーが使用される場合、ゲートウェイは、リモート・アドレスを指定する必要がありますが、またはリモートポート（複数可）を指定してもしなくてもよいです。マイクロ流ベースのリモートポリシーが使用される場合、ゲートウェイは、リモートアドレスとポートパラメータを指定する必要があります。
The address of a tunnel endpoint that is not the RSIP gateway MAY be specified. If this parameter is not specified, the RSIP gateway MUST be assumed to be the tunnel endpoint.
RSIPゲートウェイないトンネルエンドポイントのアドレスを指定することができます。このパラメータが指定されていない場合、RSIPゲートウェイは、トンネルのエンドポイントであると仮定しなければなりません。
Message counters are conceptually similar to sequence numbers. They are necessary to facilitate reliability when UDP is the transport protocol. Each UDP message is marked with a message counter. When such a message is transmitted, the message is stored in a "last message" buffer. For RSIP hosts, a timer is set to expire at the appropriate timeout value.
メッセージカウンタは、シーケンス番号と概念的に類似しています。 UDPは、トランスポートプロトコルであるとき、彼らは信頼性を容易にするために必要です。各UDPメッセージは、メッセージのカウンターが付いています。そのようなメッセージが送信されると、メッセージは、「最後のメッセージ」バッファに格納されます。 RSIPホストの場合、タイマーは、適切なタイムアウト値で期限切れになるように設定されています。
General rules:
一般的なルール：
- When an RSIP host transmits a message with a message counter value of n, the RSIP gateway's response will contain a message counter value of n.
- RSIPホストは、nのメッセージカウンタの値を持つメッセージを送信する場合、RSIPゲートウェイの応答は、n個のメッセージカウンタ値を含むであろう。
- An RSIP host will not increment its message counter value to n+1 until it receives a message from the RSIP gateway with a message counter value of n.
- それは、nのメッセージカウンタ値とRSIPゲートウェイからメッセージを受信するまでRSIPホストは、n + 1に対するメッセージカウンタの値をインクリメントしないであろう。
- An RSIP gateway begins all sessions with a message counter value of 1.
- RSIPゲートウェイ1のメッセージカウンタの値を持つすべてのセッションを開始します。
- If the message counter value reaches the maximum possible 32- bit value, it will wrap around to 1, not 0.
- メッセージカウンタの値が最大の可能な32ビット値に達した場合、それは1ではなく0にラップアラウンドします。
- If a message with a message counter value of n is transmitted by an RSIP host, but a timer expires before a response to that message is received, the copy of the message (from the "last message" buffer) is retransmitted.
- n個のメッセージカウンタの値を持つメッセージがRSIPホストによって送信されたが、そのメッセージに対する応答が受信される前にタイマが満了している場合、（「最後のメッセージ」バッファからの）メッセージのコピーが再送されます。
- When an RSIP gateway receives a duplicate copy of a message with a message counter value of n, it transmits the contents of its "last message" buffer.
- RSIPゲートウェイは、nのメッセージカウンタ値とメッセージの複製コピーを受信すると、その「最後のメッセージ」バッファの内容を送信します。
- When the RSIP gateway transmits an asynchronous RSIP message (an RSIP message for which there was no request by the RSIP host), a message counter value of 0 MUST be used. Note that only three RSIP messages can be transmitted asynchronously: ERROR_RESPONSE, DE-REGISTER_RESPONSE, and FREE_RESPONSE. These messages may also be transmitted in response to an RSIP host request, so their message counter values MAY be non-zero.
- RSIPゲートウェイは非同期RSIPメッセージ（RSIPホストによってない要求が存在しなかったためRSIPメッセージ）を送信する場合、0のメッセージカウンタの値が使用されなければなりません。唯一の3 RSIPのメッセージが非同期に送信することができることに注意してください：ERROR_RESPONSE、DE-REGISTER_RESPONSE、およびFREE_RESPONSE。そのメッセージカウンタ値が非0であってもよいので、これらのメッセージはまた、RSIPホスト要求に応答して送信されてもよいです。
- If a message counter is not present in a message from an RSIP host, but is required, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the MESSAGE_COUNTER_REQUIRED error.
- メッセージカウンタがRSIPホストからのメッセージに存在しないが、必要な場合、RSIPゲートウェイはMESSAGE_COUNTER_REQUIREDエラーを含むERROR_RESPONSEで応答しなければなりません。
When either the RSIP host or gateway suffers from an unrecoverable failure, such as a crash, all RSIP-related state will be lost. In this section, we describe the sequence of events that will occur in both host and gateway failures, and how the host and gateway re-synchronize.
RSIPホストまたはゲートウェイのいずれかが回復不能な障害に罹患している場合、このようなクラッシュとして、すべてのRSIP関連状態が失われることになります。このセクションでは、ホストとゲートウェイの両方の障害で発生するイベントのシーケンスを説明し、どのようにホストとゲートウェイを再同期します。
After a host failure, the host will reboot and be unaware of any RSIP state held on its behalf at the gateway.
ホストに障害が発生した後、ホストを再起動し、ゲートウェイで、その代わりに保持されている任意のRSIP状態を知らないであろう。
If the host does not immediately attempt to re-establish a session, it may receive RSIP packets on the RSIP client application port that it was using before it rebooted. If an RSIP client application is not active on this port, these packets will be responded to with ICMP port unreachable messages. If TCP is the transport protocol, it is likely that the connection will be terminated with a TCP RST. If an RSIP client is active on this port, it will not recognize the session that these packets belong to, and it SHOULD silently ignore them.
ホストはただちにセッションを再確立しようとしていない場合、それは再起動する前に、それは使用していたRSIPクライアントアプリケーションポート上のRSIPパケットを受信することができます。 RSIPクライアントアプリケーションがこのポートでアクティブでない場合、これらのパケットは、ICMPポート到達不能メッセージで応答します。 TCPはトランスポートプロトコルである場合、接続がTCP RSTで終了される可能性があります。 RSIPクライアントがこのポートでアクティブになっている場合は、これらのパケットが属するセッションを認識しません、それは静かにそれらを無視すべきです。
The RSIP host may also receive packets from a remote host with which it was communicating before it rebooted. These packets will be destined to the RSIP tunnel interface, which should not exist. Thus they SHOULD be silently discarded by the RSIP host's stack, or the RSIP host will transmit appropriate ICMP messages to the tunnel endpoint (e.g., the RSIP gateway). The behavior of the system with respect to sessions that were active before the reboot should be similar to that of a publically addressable non-RSIP host that reboots.
RSIPホストはまた、再起動する前にそれが通信していると、リモートホストからパケットを受信することができます。これらのパケットは存在しないはずRSIPトンネルインターフェース宛であろう。したがって彼らは静かRSIPホストのスタックによって廃棄されるべきである、またはRSIPホストは、トンネルエンドポイント（例えば、RSIPゲートウェイ）に適切なICMPメッセージを送信します。再起動前にアクティブであったセッションに対するシステムの挙動は、リブート公にアドレス可能な非RSIPホストのものと類似していなければなりません。
Upon rebooting, an RSIP host may attempt to establish a new RSIP session with the RSIP gateway. Upon receiving the REGISTER_REQUEST message, the RSIP gateway will be able to determine that, as far as it is concerned, the RSIP host is already registered. Thus, it will transmit an ERROR_RESPONSE with the ALREADY_REGISTERED message. Upon receipt of this message, the RSIP host will know the client ID of its old registration, and SHOULD immediately transmit a DE-REGISTER_REQUEST using this client ID. After this is accomplished, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
リブートすると、RSIPホストはRSIPゲートウェイと新しいRSIPセッションを確立することを試みることができます。 REGISTER_REQUESTメッセージを受信すると、RSIPゲートウェイは限り、それが関係しているように、RSIPホストが既に登録されている、ことを決定することができるであろう。したがって、ALREADY_REGISTEREDメッセージでERROR_RESPONSEを送信します。このメッセージを受信すると、RSIPホストはその昔、登録のクライアントIDを知っているだろう、とすぐにこのクライアントIDを使用してDE-REGISTER_REQUESTを送信しなければなりません。これが達成された後、RSIPホストとゲートウェイの状態が同期された、新しいRSIPセッションが確立されてもよいです。
If the RSIP host does not de-register itself from the RSIP gateway, it will eventually receive a DE-REGISTER_RESPONSE from the gateway, when the gateway times out the host's session. Since the DE-REGISTER_RESPONSE will refer to a client ID that has no meaning to the host, the host SHOULD silently ignore such a message. At this point, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
RSIPホストがいない場合はRSIPゲートウェイから自分自身を登録解除、それは最終的には、ゲートウェイからDE-REGISTER_RESPONSEを受け取る際に、ホストのセッションアウトゲートウェイ回。 DE-REGISTER_RESPONSEがホストに意味を持たないクライアントIDを参照しますので、ホストは静かにそのようなメッセージを無視する必要があります。この時点で、RSIPホストとゲートウェイの状態が同期された、新しいRSIPセッションが確立されてもよいです。
After a gateway failure, the gateway will reboot and be unaware of any RSIP state held by an RSIP host.
ゲートウェイに障害が発生した後、ゲートウェイが再起動し、RSIPホストによって保持された任意のRSIP状態を知らないであろう。
Since the gateway will not attempt to contact any of its RSIP hosts, a problem will first be detected when either an RSIP host sends an RSIP message to the gateway, an RSIP host sends tunneled data to the gateway, or data from a remote host intended for an RSIP host arrives.
ゲートウェイはそのRSIPホストのいずれかに連絡しようとしないので、RSIPホストのいずれかがゲートウェイにRSIPメッセージを送信するとき、問題が最初に検出され、RSIPホストは、ゲートウェイにトンネルデータを送信、またはリモートホストからのデータが意図しますRSIPホストのために到着しました。
In the first case, the RSIP gateway SHOULD immediately response to all messages (except for a REGISTER_REQUEST) with an ERROR_RESPONSE with a REGISTER_FIRST error. Upon receipt of such a message, an RSIP host MUST interpret the message as an indication of a loss of synchronization between itself and the RSIP gateway. The RSIP host SHOULD immediately transmit a DE-REGISTRATION_REQUEST with its old client ID (which will generate another error, but this error SHOULD be ignored by the host). At this point, the states of the RSIP host and gateway have been synchronized, and a new RSIP session may be established.
最初のケースでは、RSIPゲートウェイは直ちに応答（REGISTER_REQUESTを除く）のすべてのメッセージにREGISTER_FIRSTエラーとERROR_RESPONSE有するべきです。そのようなメッセージを受信すると、RSIPホストは、それ自体とRSIPゲートウェイとの間の同期の損失の指標としてメッセージを解釈しなければなりません。 RSIPホストはすぐにその古いクライアントIDとDE-REGISTRATION_REQUEST送信すべきである（別のエラーが生成されますが、このエラーはホストによって無視されるべきです）。この時点で、RSIPホストとゲートウェイの状態が同期された、新しいRSIPセッションが確立されてもよいです。
In the second case, all data that an RSIP host sends to the tunneled interface of an RSIP server will either (1) be discarded silently, (2) responded to with an ICMP Destination Unreachable message, such as "Communication Administratively Prohibited", or (3) blindly routed to the intended destination. In all of the above cases, the RSIP gateway will not have an explicit method to notify the RSIP host of the problem. To prevent a long term communications outage, small lease times of several minutes can be set by the RSIP gateway.
第二のケースでは、RSIPホストはRSIPサーバのトンネリングインターフェースに送信するすべてのデータは、（1）黙って破棄される、（2）は、「通信管理上禁止」として、ICMP宛先到達不能メッセージによって応答、又は（3）盲目的に意図された宛先にルーティングされます。上記の場合の全てにおいて、RSIPゲートウェイは、問題のRSIPホストに通知する明示的な方法がありません。長期間の通信障害を防止するために、数分の小さなリース時間がRSIPゲートウェイによって設定することができます。
In the third case, the RSIP gateway SHOULD discard all incoming packets and/or respond with ICMP Port Unreachable messages.
第3のケースで、RSIPゲートウェイは、すべての着信パケットを破棄すべきである、および/またはICMPポート到達不能メッセージで応答します。
There is a significant amount of RSIP gateway policy that may be implemented, but is beyond the scope of this document. We expect that most of this policy will be site-specific or implementation-specific and therefore do not make any recommendations. Examples of general gateway policy include:
そこに実装することができるRSIPゲートウェイポリシー、かなりの量があるが、この文書の範囲を超えています。当社は、この方針のほとんどは、サイト固有または実装固有になりますので、任意の勧告をしないことを期待しています。一般的なゲートウェイ・ポリシーの例としては、
- How ports are allocated to RSIP hosts. - Preferred length of lease times.
- どのようにポートはRSIPホストに割り当てられています。 - リース時間の好ましい長さ。
- How flow policy is applied to which hosts. - How an RSIP gateway with multiple public IP addresses that may be leased by RSIP clients determines how to partition and/or lease these addresses.
- どのように政策を流れはどのホストに適用されます。 - RSIPクライアントにリースすることができる複数のパブリックIPアドレスを持つRSIPゲートウェイは、パーティションおよび/またはこれらのアドレスをリースする方法を決定する方法。
Once an RSIP host and gateway have established a relationship and the host is assigned resources to use, error may occur due to the host's misuse of the resources or its attempting to use unassigned resources. The following error behavior is defined:
RSIPホストとゲートウェイが関係を確立していると、ホストが使用するリソースを割り当てられると、エラーが原因ホストのリソースの誤用またはそのが割り当てられていないリソースを使用しようとするに発生する可能性があります。次のエラー動作が定義されています。
- If a host attempts to use a local address which it has not been allocated, the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the LOCAL_ADDR_UNALLOWED error.
- ホストは、それが割り当てられていないローカルアドレスを使用しようとすると、RSIPゲートウェイは、関連するパケット（単数または複数）を削除してホストにLOCAL_ADDR_UNALLOWED誤差を含むERROR_RESPONSEを送らなければなりません。
- If a host attempts to use a local address / port tuple which it has not been allocated, the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the LOCAL_ADDRPORT_UNALLOWED error.
- ホストは、それが割り当てられていないローカルアドレス/ポートのタプルを使用しようとすると、RSIPゲートウェイは、関連するパケット（単数または複数）を削除してホストにLOCAL_ADDRPORT_UNALLOWED誤差を含むERROR_RESPONSEを送らなければなりません。
- If a host attempts to contact a remote address which has not been properly specified or otherwise approved (e.g., via an ASSIGN_RESPONSE_RSAP-IP and macro or micro based remote flow policy), the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the REMOTE_ADDR_UNALLOWED error.
- ホストが（ASSIGN_RESPONSE_RSAP-IPおよびマクロまたはミクロベースのリモートフローポリシーを介して、例えば）が正しく指定されたまたはそうでなければ承認されていないリモートアドレスに連絡しようとすると、RSIPゲートウェイは、関連するパケット（単数または複数）を削除して送信しなければなりませんホストREMOTE_ADDR_UNALLOWEDエラーを含むERROR_RESPONSE。
- If a host attempts to contact a remote address / port tuple which has not been properly specified or otherwise approved (e.g., via an ASSIGN_RESPONSE_RSAP-IP and micro based remote flow policy), the RSIP gateway MUST drop the associated packet(s) and send the host an ERROR_RESPONSE containing the REMOTE_ADDRPORT_UNALLOWED error.
- ホストが（ASSIGN_RESPONSE_RSAP-IP及びマイクロベースのリモートフローポリシーを介して、例えば）が正しく指定されたまたはそうでなければ承認されていないリモートアドレス/ポートのタプルに連絡しようとすると、RSIPゲートウェイは、関連するパケット（単数または複数）を削除しなければなりませんホストにREMOTE_ADDRPORT_UNALLOWEDエラーを含むERROR_RESPONSEを送ります。
- If a host attempts to establish or use an improper tunnel type, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the BAD_TUNNEL_TYPE error.
- ホストが確立または不適切なトンネル型を使用しようとすると、RSIPゲートウェイはBAD_TUNNEL_TYPEエラーを含むERROR_RESPONSEで応答しなければなりません。
- If the RSIP gateway's detects a local fault which prevents its RSIP server module from continuing operation, the RSIP gateway MUST respond with an ERROR_RESPONSE containing the INTERNAL_SERVER_ERROR error.
- RSIPゲートウェイのは、継続的な操作からそのRSIPサーバモジュールを防ぎローカル障害を検出すると、RSIPゲートウェイはINTERNAL_SERVER_ERRORエラーを含むERROR_RESPONSEで応じなければなりません。
Regardless of local flow policy, an RSIP host may "suggest" that it would like to use a particular local address and/or port number in a particular binding. An RSIP gateway that cannot grant such a request, because the specified resources are already in use, MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_INUSE or LOCAL_ADDRPORT_INUSE values.
かかわらず、局所的な流れの政策の、RSIPホストは、それが特定の結合に特定のローカルアドレスおよび/またはポート番号を使用したいことを「提案」があります。指定されたリソースがすでに使用中であるため、そのような要求を許可することができないRSIPゲートウェイは、LOCAL_ADDR_INUSE又はLOCAL_ADDRPORT_INUSE値を含むERROR_RESPONSEで応答しなければなりません。
An RSIP host may initialize a publically accessible gateway (such as an FTP or HTTP gateway) by transmitting a LISTEN_REQUEST message to an RSIP gateway and receiving a LISTEN_RESPONSE. However, unless no remote flow policy is used, the gateway will have to specify the address or address and port of a single remote host that will be allowed to contact it. Obviously, such as restriction is not very useful for hosts that require their gateways to be accessible by any remote host.
RSIPホストはRSIPゲートウェイにLISTEN_REQUESTメッセージを送信し、LISTEN_RESPONSEを受信することによって（例えばFTPやHTTPゲートウェイなど）を公的にアクセス可能なゲートウェイを初期化することができます。いかなる遠隔フローポリシーが使用されていない場合を除きしかし、ゲートウェイは、それに連絡することを許可される単一のリモートホストのアドレスまたはアドレスおよびポートを指定する必要があります。もちろん、制限などの任意のリモートホストからアクセスできるように彼らのゲートウェイを必要とするホストのために非常に有用ではありません。
This indicates that there is a conflict between flow-based policy and support for gateways. The main purpose of enforcing flow-based policy for LISTEN_REQUESTs is that it allows an RSIP gateway tight control over how an RSIP host uses ports and the associated accounting. For example, an RSIP host, operating under remote micro-flow based policy and using a protocol such as FTP, will have to specify the address and port that it will receive FTP data on, as well as the address and port that the gateway will transmit data from, in a LISTEN_REQUEST.
これは、ゲートウェイのフローベースのポリシーと支持体との間に矛盾があることを示しています。 LISTEN_REQUESTsのフローベースのポリシーを実施する主な目的は、RSIPホストは、ポートと関連付けられた課金を使用する方法上RSIPゲートウェイタイトな制御を可能にすることです。例えば、RSIPホストは、遠隔マイクロ流ベースのポリシーの下で動作し、FTPなどのプロトコルを使用して、そのゲートウェイが意志アドレスおよびポートが上のFTPデータを受信するだけでなく、アドレスおよびポートを指定する必要がありますLISTEN_REQUESTで、データを送信します。
In general, an RSIP gateway may not allow arbitrary hosts to start public gateways because of the traffic and security concerns. Thus, we recommend that if remote micro-flow based policy is used, that an RSIP gateway only allow public gateways on RSIP hosts via administrative override.
一般的に、RSIPゲートウェイは、任意のホストが原因トラフィックやセキュリティの懸念の公開ゲートウェイを開始することができないかもしれません。したがって、我々は、リモートマイクロフローベースのポリシーが使用されている場合、RSIPゲートウェイのみ管理オーバーライド経由RSIPホスト上のパブリックゲートウェイを許可することをことをお勧めします。
Currently, RSIP hosts can only be identified by their local IP address or MAC address.
現在、RSIPホストは自分のローカルIPアドレスやMACアドレスで識別することができます。
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は、それ自体が、セキュリティを提供しません。これは、プライベートアドレス空間を非表示にすることで、セキュリティやプライバシーの錯覚を提供することができるが、セキュリティはセキュリティプロトコルと暗号技術の適切な使用によって確保することができます。
An RSIP gateway should take all measures deemed necessary to prevent its hosts from performing intentional or unintentional denial-of-service attacks by request large sets of resources.
RSIPゲートウェイは、リソースの要求大集合によって故意または意図しないサービス拒否攻撃を実行することから、そのホストを防ぐために必要と考えられるすべての措置をとるべきです。
Currently, RSIP hosts can only be identified by their local IP address or, in some cases, MAC address. It is desirable to allow RSIP messages sent between a host and gateway to be authenticated. Further discussion of such authentication can be found in [RSIP-FRAME].
現在、RSIPホストは自分のローカルIPアドレスや、いくつかの例では、MACアドレスで識別することができます。ホストとゲートウェイの間で送信されるRSIPメッセージが認証されることを可能にすることが望ましいです。そのような認証のさらなる議論は、[RSIP-FRAME]に見出すことができます。
Discussion of RSIP support for end-to-end IPsec can be found in [RSIP-IPSEC].
エンドツーエンドのIPsecのRSIPサポートの議論は[RSIP-IPSEC]に見出すことができます。
All of the designations below have been registered by the IANA.
以下の名称のすべてがIANAによって登録されています。
- RSIP port number: 4555 - RSIP error codes (see Appendix A). - RSIP message type codes (see Appendix B). - RSIP tunnel types, methods, and flow policies.
- RSIPポート番号：4555 - RSIPエラーコード（付録Aを参照してください）。 - RSIPメッセージタイプコード（付録Bを参照）。 - RSIPトンネルタイプ、方法、およびフローポリシー。
RSIP parameter values are designated as follows:
次のようにRSIPパラメータ値が指定されています。
- 0 Reserved - 1-240 Assigned by IANA - 241-255 Reserved for private use
- 0予約 - IANAによって割り当てられた1から240 - 241から255私的使用のために予約
New registrations for the above namespaces are recommended to be allocated via the Specification Required method documented in [RFC2434].
上記の名前空間のための新しい登録は[RFC2434]で文書仕様が必要でメソッドを経由して割り当てることが推奨されています。
The authors would like to specifically thank Gabriel Montenegro, Pyda Srisuresh, Brian Carpenter, Eliot Lear, Dan Nessett, Gary Jaszewski, Naveen Rajanikantha, Sudhakar Ramakrishna, Jim March, 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、のNaveen Rajanikantha、Sudhakarラーマクリシュナ、ジム・マーチ、そしてリック・コブを特に感謝したいと思います。全体としてIETF NATワーキンググループはRSIPの継続的な開発に非常に役立っています。
This section provides descriptions for the error values in the RSIP error parameter.
このセクションでは、RSIPエラーパラメータのエラー値のための説明を提供します。
All errors are grouped into the following categories:
すべてのエラーは、次のカテゴリに分類されます。
100's: General errors.
100さん：一般的なエラー。
101: UNKNOWN_ERROR. An error that cannot be identified has occurred. This error should be used when all other error messages are inappropriate.
101：UNKNOWN_ERROR。特定できないエラーが発生しました。他のすべてのエラーメッセージが不適切な場合に、このエラーを使用する必要があります。
102: USE_TCP. A host has attempted to use UDP on a server that only supports TCP.
102：USE_TCP。ホストがTCPだけをサポートするサーバー上でUDPを使用しようとしました。
103: FLOW_POLICY_VIOLATION: A host has not specified address or port information in enough detail for its assigned flow policy.
103：FLOW_POLICY_VIOLATION：ホストが割り当てられたフローポリシーのために十分な詳細にアドレスやポート情報を指定していません。
104: INTERNAL_SERVER_ERROR: An RSIP server application has detected an unrecoverable error within itself or the RSIP gateway.
104：INTERNAL_SERVER_ERROR：RSIPサーバアプリケーションは、それ自体またはRSIPゲートウェイ内のエラーを検出しました。
105: MESSAGE_COUNTER_REQUIRED: An RSIP host did not use a message counter parameter in a situation in which it should have.
105：MESSAGE_COUNTER_REQUIRED：RSIPホストは、それが持っているべき状況でメッセージカウンタパラメータを使用していませんでした。
106: UNSUPPORTED_RSIP_VERSION: An RSIP host sent a message with a version number that is not supported by the RSIP gateway.
106：UNSUPPORTED_RSIP_VERSION：RSIPホストはRSIPゲートウェイによってサポートされていないバージョン番号とメッセージを送りました。
200's: Parameter and message errors. The gateway uses these errors when it detects that a parameter or message is malformed, as well as when it does not understand a parameter or message.
200さん：パラメータとメッセージの誤り。それは、パラメータやメッセージを理解していないとき、ゲートウェイは、パラメータまたはメッセージが不正であることを検出した場合、これらのエラーを使用して、など。
201: MISSING_PARAM. The request does not contain a required parameter.
201：MISSING_PARAM。リクエストは、必要なパラメータが含まれていません。
202: DUPLICATE_PARAM. The request contains an illegal duplicate parameter.
202：DUPLICATE_PARAM。要求は違法複製パラメータが含まれています。
203: EXTRA_PARAM. The request contains a parameter that it should not.
203：EXTRA_PARAM。要求は、それがいけないパラメータが含まれています。
204: ILLEGAL_PARAM. The gateway does not understand a parameter type.
204：ILLEGAL_PARAM。ゲートウェイは、パラメータの型を理解していません。
205: BAD_PARAM. A parameter is malformed.
205：BAD_PARAM。パラメータが不正な形式です。
206: ILLEGAL_MESSAGE. The gateway does not understand the message type. The message type is neither mandatory nor optional.
206：ILLEGAL_MESSAGE。ゲートウェイは、メッセージの種類を理解していません。メッセージタイプは、必須でもオプションでもありません。
207: BAD_MESSAGE. A message is malformed and gateway parsing failed.
207：BAD_MESSAGE。メッセージは、不正な形式で、ゲートウェイの解析に失敗しました。
208: UNSUPPORTED_MESSAGE: The host has transmitted an optional message that the gateway does not support.
208：UNSUPPORTED_MESSAGE：ホストは、ゲートウェイがサポートしていない任意のメッセージを送信してきました。
300's: Permission, resource, and policy errors. The gateway uses these errors when a host has attempted to do something that it is not permitted to do, or something that violated gateway policy.
300さん：許可、リソース、およびポリシーのエラー。ホストはそれを行うことを許可されていない何か、またはゲートウェイのポリシーに違反し何かをしようとしたとき、ゲートウェイは、これらのエラーを使用しています。
301: REGISTER_FIRST. The RSIP host has attempted to request or use resources without registering.
301：REGISTER_FIRST。 RSIPホストは登録せずに、要求または使用リソースにしようとしました。
302: ALREADY_REGISTERED. The host has attempted to register again without first de-registering.
302：ALREADY_REGISTERED。ホストは、最初のデ登録せずに再登録しようとしました。
303: ALREADY_UNREGISTERED. The host has attempted to de-register but it is already in the unregistered state.
303：ALREADY_UNREGISTERED。ホストは、登録解除しようとしたが、それは未登録状態に既にあります。
304: REGISTRATION_DENIED. The gateway will not allow the host to register.
304：REGISTRATION_DENIED。ゲートウェイは、ホストが登録することはできません。
305: BAD_CLIENT_ID. The host has referred to itself with the wrong client ID.
305：BAD_CLIENT_ID。ホストが間違ったクライアントIDと自身に言及しています。
306: BAD_BIND_ID. The request refers to a bind ID that is not valid for the host.
306：BAD_BIND_ID。要求は、ホストに対して有効ではありませんバインドIDを指します。
307: BAD_TUNNEL_TYPE. The request refers to a tunnel type that is not valid for the host.
307：BAD_TUNNEL_TYPE。要求は、ホストに対して有効でないトンネルタイプを指します。
308: LOCAL_ADDR_UNAVAILABLE. The gateway is currently not able to allocate ANY local address, but the host may try again later.
308：LOCAL_ADDR_UNAVAILABLE。ゲートウェイは現在、任意のローカルアドレスを割り当てることができませんが、ホストは、後でもう一度試してください。
309: LOCAL_ADDRPORT_UNAVAILABLE. The gateway is currently not able to allocate ANY local IP address / port tuple of the requested magnitude (i.e., number of ports), but the host may try again later.
309：LOCAL_ADDR PORT UNAVAILABLE。ゲートウェイは、現在要求大きさ（即ち、ポートの数）の任意のローカルIPアドレス/ポートのタプルを割り当てることができないが、ホストは、後で再試行してもよいです。
310: LOCAL_ADDR_INUSE. The gateway was not able to allocate the requested local address because it is currently used by another entity.
310：LOCAL_ADDR_INUSE。それは現在、別のエンティティによって使用されるため、ゲートウェイは、要求されたローカルアドレスを割り当てることができませんでした。
311: LOCAL_ADDRPORT_INUSE. The gateway was not able to allocate the requested local address / port tuple because it is currently used by another entity.
311：LOCAL_ADDRPORT_INUSE。ゲートウェイは、それが現在別のエンティティによって使用されているため、要求されたローカルアドレス/ポート組を割り当てることができませんでした。
312: LOCAL_ADDR_UNALLOWED. The gateway will not let the host use the specified local IP address due to policy.
312：LOCAL_ADDR_UNALLOWED。ゲートウェイは、ホストが原因ポリシーに指定されたローカルIPアドレスを使用させません。
313: LOCAL_ADDRPORT_UNALLOWED. The gateway will not let the host use the specified local address / port pair due to policy.
313：LOCAL_ADDRPORT_UNALLOWED。ゲートウェイは、ホストがポリシーのために、指定したローカルアドレス/ポートのペアを使用せません。
314: REMOTE_ADDR_UNALLOWED. The gateway will not allow the host to establish a session to the specified remote address.
314：REMOTE_ADDR_UNALLOWED。ゲートウェイは、ホストが指定されたリモートアドレスにセッションを確立することはできません。
315: REMOTE_ADDRPORT_UNALLOWED. The gateway will not allow the host to establish a session to the specified remote address / port tuple.
315：REMOTE_ADDRPORT_UNALLOWED。ゲートウェイは、ホストが指定されたリモートアドレス/ポートのタプルにセッションを確立することはできません。
400's: IPsec errors. All errors specific to RSIP / IPsec operation. See [RSIP-IPSEC].
400さん：IPsecのエラー。 RSIP / IPsecの動作に固有のすべてのエラー。 [RSIP-IPSEC]を参照してください。
This section defines the values assigned to RSIP message types. We also indicate which RSIP entity, host or gateway, produces each messages, and whether it is mandatory or optional. All *_REQUEST messages are only to be implemented on hosts, while all *_RESPONSE messages are only to be implemented on gateways. RSIP implementations (both host and gateway) MUST support all mandatory messages in order to be considered "RSIP compliant".
このセクションでは、RSIPメッセージタイプに割り当てられた値を定義します。我々はまた、RSIPエンティティ、ホストまたはゲートウェイは、各メッセージを生成し、それが必須またはオプションであるかどうかかを示します。すべての* _responseメッセージがゲートウェイのみに実装されるようにしている間、すべての* _REQUESTメッセージは、ホストだけに実装されることになります。 RSIP実装（ホストとゲートウェイの両方）「RSIP対応」とみなされるために、すべての必須のメッセージをサポートしなければなりません。
Value Message Implementation Status
------------------------------------------------------------
1 ERROR_RESPONSE gateway mandatory
2 REGISTER_REQUEST host mandatory
3 REGISTER_RESPONSE gateway mandatory
4 DE-REGISTER_REQUEST host mandatory
5 DE-REGISTER_RESPONSE gateway mandatory
6 ASSIGN_REQUEST_RSA-IP host optional
7 ASSIGN_RESPONSE_RSA-IP gateway optional
8 ASSIGN_REQUEST_RSAP-IP host mandatory
9 ASSIGN_RESPONSE_RSAP-IP gateway mandatory
10 EXTEND_REQUEST host mandatory
11 EXTEND_RESPONSE gateway mandatory
12 FREE_REQUEST host mandatory
13 FREE_RESPONSE gateway mandatory
14 QUERY_REQUEST host optional
15 QUERY_RESPONSE gateway mandatory
16 LISTEN_REQUEST host optional
17 LISTEN_RESPONSE gateway optional
In this appendix, we present an exemplary series of annotated transactions between an RSIP host and an RSIP gateway. All host to gateway traffic is denote by `C --> S' and all gateway to host traffic is denoted by `S --> C'. Parameter values are denoted inside of parentheses. Versions, message types, and overall lengths are not included in order to save space. "Don't care" values are indicated by 0's.
この付録では、RSIPホストとRSIPゲートウェイとの間の注釈付きトランザクションの例示的な一連を示します。 「 - > C `Sで示され、トラフィックをホストするすべてのゲートウェイ」> S - トラフィックをゲートウェイにするすべてのホストは、` Cで示してあります。パラメータ値は括弧の中に示されています。バージョン、メッセージタイプ、および全体的な長さは、スペースを節約するためには含まれません。 「気にしないでください」の値が0ので示されています。
A ports parameter is represented by the number of ports followed by the port numbers, separated by dashes. For example, 2-1012-1013 indicates two ports, namely 1012 and 1013, while 16-10000 indicates 16 ports, namely 10000-10015, and 4-0 indicates four ports, but the sender doesn't care where they are.
ポートパラメータはダッシュで区切られたポート番号、続いてポートの数で表されます。例えば16-10000 16ポート、すなわち10000から10015を示しながら、2-1012-1013は、二つのポート、すなわち1012および1013を示し、及び4-0は、4つのポートを示しているが、彼らがどこにある送信者が気にしません。
IPv4 addresses are assumed.
IPv4アドレスが想定されています。
16.1. RSAP-IP with Local Macro-flow Based Policy and No Remote Flow Policy
16.1. ローカルマクロフローベースのポリシーとRSAP-IPおよびノーリモートフローポリシー
This example exhibits the loosest policy framework for RSAP-IP.
この例ではRSAP-IPのための最も緩い政策の枠組みを示します。
C --> S: REGISTER_REQUEST ()
C - > S：REGISTER_REQUEST（）
The host attempts to register with the gateway.
ホストは、ゲートウェイに登録しようと試みます。
S --> C: REGISTER_RESPONSE (Client ID = 1, Local Flow Policy = Macro, Remote Flow policy = None, Lease Time = 600)
S - > C：REGISTER_RESPONSE（クライアントID = 1、ローカルフローポリシー=マクロ、リモートフローポリシー=なし、リース期間= 600）
The gateway responds, assigning a Client ID of 1, local macro-flow based policy and no remote flow policy. No RSIP method is indicated, so RSAP-IP is assumed. No tunnel type is indicated, so IP-IP is assumed. A lease time of 600 seconds is assigned.
ゲートウェイは、1のクライアントID、ローカルマクロフローベースのポリシーと無遠隔フローポリシーを割り当て、応答します。いいえRSIP方法が示されていないので、RSAP-IPが想定されます。いいえトンネルタイプは示されていないので、IP-IPが想定されます。 600秒のリース時間が割り当てられます。
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) = 0, Ports (local) = 4-0, Address (remote) = 0, Ports (remote) = 0, Lease Time = 3600)
C - > S：ASSIGN_REQUEST_RSAP-IP：（クライアントID = 1、アドレス（ローカル）= 0、ポート（ローカル）= 4-0、リモートアドレス（）= 0、リモートポート（）= 0、リース時間= 3600 ）
The host requests an address and four ports to use with it, but doesn't care which address or ports are assigned. The host does not specify the remote address or ports either. The host suggests a lease time of 3600 seconds.
ホストはそれを使用するアドレスとポート4を要求しますが、割り当てられたアドレスやポートを気にしません。ホストは、リモートアドレスやポートを指定していません。ホストは、3600秒のリース時間を示唆しています。
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 1, Address (local) = 149.112.240.156, Ports (local) = 4-1234, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800, Tunnel Type = IP-IP)
S - > C：ASSIGN_RESPONSE_RSAP-IP：（クライアントID = 1、バインドID = 1、アドレス（ローカル）= 149.112.240.156、ポート（ローカル）= 4から1234、リモートアドレス（）= 0、リモートポート（） = 0、リース期間= 1800、トンネルタイプ= IP-IP）
The gateway responds by indicating that a bind ID of 1 has been assigned to IP address 149.112.240.156 with ports 1234-1237. Any remote host may be communicated with, using any remote port number. The lease time has been assigned to be 1800 seconds, and the tunnel type is confirmed to be IP-IP.
ゲートウェイは、1のバインドIDが、ポート1234から1237でIPアドレス149.112.240.156に割り当てられていることを示すことによって応答します。リモートホストは、任意のリモートポート番号を使用して、と通信することができます。リース時間は1800秒であることを割り当てられており、トンネルタイプはIP-IPであることが確認されました。
The host is now able to communicate with any host on the public network using these resources.
ホストは現在、これらのリソースを使用して、パブリックネットワーク上の任意のホストと通信することができます。
C --> S: QUERY_REQUEST: (Client ID = 1, Indicator = network, Address (network) = 10.20.60.0, Address (netmask) 255.255.255.0)
C - > S：QUERY_REQUEST：（クライアントID = 1、インジケータ=ネットワークアドレス（ネットワーク）= 10.20.60.0、アドレス（ネットマスク）255.255.255.0）
The host asks the gateway if the network 10.20.60.0/24 is local.
ネットワーク10.20.60.0/24がローカルである場合、ホストは、ゲートウェイを尋ねます。
S --> C: QUERY_RESPONSE: (Client ID = 1, Indicator = network, Address (network) = 10.20.60.0, Address (netmask) = 255.255.255.0)
S - > C：QUERY_RESPONSE：（クライアントID = 1、インジケータ=ネットワークアドレス（ネットワーク）= 10.20.60.0、アドレス（ネットマスク）= 255.255.255.0）
The gateway responds indicating that the network in question is local.
ゲートウェイは、問題のネットワークがローカルであることを示す応答します。
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 1, Address (local) = 149.112.240.156, Ports (local) = 8-1238, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)
C - > S：ASSIGN_REQUEST_RSAP-IP：（クライアントID = 1、アドレス（ローカル）= 149.112.240.156、ポート（ローカル）= 8から1238、リモートアドレス（）= 0、リモートポート（）= 0、リース時間= 1800）
The host requests eight more particular ports for use with RSAP-IP with the same address. A lease of 1800 seconds is requested. IP-IP tunneling is implied by default.
ホストは、同じアドレスを持つRSAP-IPで使用するための8つの特定のポートを要求します。 1800秒のリースが要求されています。 IP-IPトンネリングはデフォルトで暗示されます。
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 1, Bind ID = 2, Address (local) = 149.112.240.156, Ports (local) = 8-1305, Address (remote) = 0, Ports (remote) = 0, Lease Time = 1800)
S - > C：ASSIGN_RESPONSE_RSAP-IP：（クライアントID = 1、バインドID = 2、アドレス（ローカル）= 149.112.240.156、ポート（ローカル）= 8から1305、リモートアドレス（）= 0、リモートポート（） = 0、= 1800リース時間）
The gateway grants the request with the same address, but with a different set of ports. IP-IP tunneling is implied by default.
ゲートウェイは、同じアドレスで要求を許可するが、ポートの異なるセットを有します。 IP-IPトンネリングはデフォルトで暗示されます。
C --> S: FREE_REQUEST (Client ID = 1, Bind ID = 1)
C - > S：FREE_REQUEST（クライアントID = 1、バインドID = 1）
The host frees bind ID 1; i.e., ports 1234-1237 from IP address 149.112.240.156. Note that the address itself is still assigned to the host because the host is still assigned ports 1305-1314.
ホストはバインドID 1を解放します。すなわち、IPアドレス149.112.240.156からポート1234から1237。ホストがまだポート1305から1314に割り当てられているため、アドレス自体がまだホストに割り当てられていることに注意してください。
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1)
S - > C：FREE_RESPONSE（クライアントID = 1、バインドID = 1）
The gateway acknowledges that Bind ID 1 has been freed.
ゲートウェイは、バインドID 1が解放されたことを認めています。
C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time = 1800)
C - > S：EXTEND_REQUEST（クライアントID = 1、バインドID = 2、リース時間= 1800）
The host request that the lease on bind ID 1 be extended for 1800 seconds.
バインドID 1のリースは、1800秒のために拡張することがホスト要求。
S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time = 1800)
S - > C：EXTEND_RESPONSE（クライアントID = 1、バインドID = 2、リース時間= 1800）
The gateway confirms the request.
ゲートウェイは、要求を確認します。
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2)
S - > C：FREE_RESPONSE（クライアントID = 1、バインドID = 2）
The gateway forces the host to free the resources of bind ID 2.
ゲートウェイは、バインドID 2のリソースを解放するためにホストを強制します。
C --> S: DE-REGISTER_REQUEST (Client ID = 1)
C - > S：DE-REGISTER_REQUEST（クライアントID = 1）
The host de-registers with the sever.
サーバとホストの登録解除。
S --> C: DE-REGISTER_RESPONSE (Client ID = 1)
S - > C：DE-REGISTER_RESPONSE（クライアントID = 1）
The gateway acknowledges that the host has de-registered.
ゲートウェイは、ホストが登録解除したことを認めています。
16.2. RSAP-IP with Local Micro-flow Based Policy and Remote Micro-flow Based Policy
16.2. ローカルマイクロフローベースのポリシーとリモートマイクロフローベースのポリシーとRSAP-IP
This example exhibits the strictest policy framework for RSAP-IP.
この例ではRSAP-IPのための最も厳格な政策の枠組みを示します。
C --> S: REGISTER_REQUEST ()
C - > S：REGISTER_REQUEST（）
The host attempts to register with the gateway.
ホストは、ゲートウェイに登録しようと試みます。
S --> C: REGISTER_RESPONSE (Client ID = 5, Local Flow Policy = Micro, Remote Flow policy = Micro, RSIP Method = RSAP-IP, RSIP Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = GRE, Lease Time = 600)
S - > C：REGISTER_RESPONSE（クライアントID = 5、局所的な流れ方針=マイクロ、リモートフローポリシー=マイクロ、RSIP方法= RSAP-IP、RSIP方法= RSA-IP、トンネル型= IP-IP、トンネル型= GRE 、リース期間= 600）
The gateway responds, assigning a Client ID of 5, local micro-flow based policy and remote micro-flow based policy. Both RSAP-IP and RSA-IP are supported. Both IP-IP and GRE tunnel types are supported. A lease time of 600 seconds is assigned.
ゲートウェイ5のクライアントID、ローカルマイクロ流ベースのポリシーおよびリモートマイクロ流ベースのポリシーを割り当て、応答します。 RSAP-IPおよびRSA-IPの両方がサポートされています。両方のIP-IPとGREトンネルタイプがサポートされています。 600秒のリース時間が割り当てられます。
C --> S: ASSIGN_REQUEST_RSAP-IP: (Client ID = 5, Address (local) = 0, Ports (local) = 0, Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)
C - > S：ASSIGN_REQUEST_RSAP-IP：（クライアントID = 5、アドレス（ローカル）= 0、ポート（ローカル）= 0、リモートアドレス（）= 38.196.73.6、リモートポート（）= 21、リース時間= 600 、トンネルタイプ= IP-IP）
The host requests a local address and a port assignment to use with it. The host indicates that it wants to contact host 38.196.73.6 at port 21 (FTP control). The host requests a lease time of 600 seconds and a tunnel type of IP-IP.
ホストはローカルアドレスとそれに使用するポートの割り当てを要求します。ホストはポート21（FTPコントロール）でホスト38.196.73.6に連絡することを望んでいることを示しています。ホストは、600秒のリース時間とIP-IPのトンネルタイプを要求します。
S --> C: ASSIGN_RESPONSE_RSAP-IP: (Client ID = 5, Bind ID = 1, Address (local) = 149.112.240.156, Ports (local) = 2049, Address (remote) = 38.196.73.6, Ports (remote) = 21, Lease Time = 600, Tunnel Type = IP-IP)
S - > C：ASSIGN_RESPONSE_RSAP-IP：（クライアントID = 5、バインドID = 1、アドレス（ローカル）= 149.112.240.156、ポート（ローカル）= 2049、リモートアドレス（）= 38.196.73.6、ポート（リモート） = 21、リース期間= 600、トンネルタイプ= IP-IP）
The gateway responds by indicating that a bind ID of 1 has been assigned to IP address 149.112.240.156 with port 2049. Only host 38.196.73.6 at port 21 may be contacted. The lease time has been assigned to be 600 seconds, and the tunnel type is confirmed to be IP-IP.
ゲートウェイは、接触させることができる1のバインドIDのみポート21に38.196.73.6をホストポート2049でIPアドレス149.112.240.156に割り当てられていることを示すことによって応答します。リース時間は600秒に割り当てられており、トンネルタイプはIP-IPであることが確認されました。
C --> S: LISTEN_REQUEST: (Client ID = 5, Address (local) = 149.112.240.156, Ports (local) = 2050, Address (remote) = 38.196.73.6, Ports (remote) = 20)
C - > S：LISTEN_REQUEST：（クライアントID = 5、アドレス（ローカル）= 149.112.240.156、ポート（ローカル）= 2050、リモートアドレス（）= 38.196.73.6、リモートポート（）= 20）
The host requests a listen port 2050 at the same address that it has been assigned. Only host 38.196.73.6 from ports 20 (FTP data) will be able to contact it.
ホストは、それが割り当てられている同じアドレスでポート2050を聞く要求します。それだけに連絡することができるであろうポートから38.196.73.6 20（FTPデータ）をホストします。
S --> C: LISTEN_RESPONSE: (Client ID = 5, Address (local) = 149.112.240.156, Ports (local) = 2050, Address (remote) = 38.196.73.6, Ports (remote) = 20, Lease Time = 600, Tunnel Type = IP-IP)
S - > C：LISTEN_RESPONSE：（クライアントID = 5、アドレス（ローカル）= 149.112.240.156、ポート（ローカル）= 2050、リモートアドレス（）= 38.196.73.6、リモートポート（）= 20、リース時間= 600 、トンネルタイプ= IP-IP）
The gateway confirms the request and assigns a lease time of 600 seconds and a tunnel type of IP-IP.
ゲートウェイは、要求を確認し、600秒のリース時間とIP-IPのトンネルタイプを割り当てます。
C --> S: DE-REGISTER_REQUEST (Client ID = 5)
C - > S：DE-REGISTER_REQUEST（クライアントID = 5）
The host de-registers with the sever.
サーバとホストの登録解除。
S --> C: DE-REGISTER_RESPONSE (Client ID = 5)
S - > C：DE-REGISTER_RESPONSE（クライアントID = 5）
The gateway acknowledges that the host has de-registered. All of the host's bindings have been implicitly revoked.
ゲートウェイは、ホストが登録解除したことを認めています。ホストのバインディングのすべてが暗黙のうちに取り消されました。
16.3. RSA-IP with Local Macro-flow Based Policy and Remote Macro-flow based Policy
16.3. ローカルマクロフローベースのポリシーとリモートマクロフローベースのポリシーにRSA-IP
This example exhibits a medium level of control for RSA-IP.
この例では、RSA-IPの制御の中間レベルを示します。
C --> S: REGISTER_REQUEST ()
C - > S：REGISTER_REQUEST（）
The host attempts to register with the gateway.
ホストは、ゲートウェイに登録しようと試みます。
S --> C: REGISTER_RESPONSE (Client ID = 3, Local Flow Policy = Macro, Remote Flow policy = Macro, RSIP Method = RSAP-IP, RSIP Method = RSA-IP, Tunnel Type = IP-IP, Tunnel Type = L2TP, Lease Time = 600)
S - > C：REGISTER_RESPONSE（クライアントID = 3、局所的な流れ方針=マクロ、リモートフローポリシー=マクロ、RSIP方法= RSAP-IP、RSIP方法= RSA-IP、トンネル型= IP-IP、トンネル型= L2TP 、リース期間= 600）
The gateway responds, assigning a Client ID of 3, local macro-flow based policy and remote macro-flow based policy. Both RSAP-IP and RSA-IP are supported. Both IP-IP and L2TP tunnel types are supported. A lease time of 600 seconds is assigned.
ゲートウェイは、3つのクライアントID、ローカルマクロフローベースのポリシーおよびリモートマクロフローベースのポリシーを割り当て、応答します。 RSAP-IPおよびRSA-IPの両方がサポートされています。両方のIP-IPおよびL2TPトンネルタイプがサポートされています。 600秒のリース時間が割り当てられます。
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) = 0, Address (remote) = www.foo.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type = IP-IP)
C - > S：ASSIGN_REQUEST_RSA-IP：（クライアントID = 3、アドレス（ローカル）= 0、アドレス（遠隔）= www.foo.com、リモートポート（）= 0、リース時間= 3600、トンネルタイプ= IP -IP）
The host requests a local address and indicates that it wants to contact host www.foo.com.
ホストは、ローカルアドレスを要求し、それがホストwww.foo.comに連絡することを望んでいることを示しています。
S --> C: ERROR_RESPONSE: (Error = REMOTE_ADDR_UNALLOWED, Client ID = 3)
S - > C：ERROR_RESPONSE：（エラー= REMOTE_ADDR_UNALLOWED、クライアントID = 3）
The gateway indicates that the host is not permitted to establish communication with www.foo.com.
ゲートウェイは、ホストがwww.foo.comとの通信を確立することを許可されていないことを示します。
C --> S: ASSIGN_REQUEST_RSA-IP: (Client ID = 3, Address (local) = 0, Address (remote) = www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type = IP-IP)
C - > S：ASSIGN_REQUEST_RSA-IP：（クライアントID = 3、アドレス（ローカル）= 0、アドレス（遠隔）= www.bar.com、リモートポート（）= 0、リース時間= 3600、トンネルタイプ= IP -IP）
The host requests a local address and indicates that it wants to contact host www.bar.com.
ホストは、ローカルアドレスを要求し、それがホストwww.bar.comに連絡することを望んでいることを示しています。
S --> C: ASSIGN_RESPONSE_RSA-IP: (Client ID = 3, Bind ID = 1, Address (local) = 149.112.240.17, Address (remote) = www.bar.com, Ports (remote) = 0, Lease Time = 3600, Tunnel Type = IP-IP)
S - > C：ASSIGN_RESPONSE_RSA-IP：（クライアントID = 3、バインドID = 1、アドレス（ローカル）= 149.112.240.17、アドレス（遠隔）= www.bar.com、リモートポート（）= 0、リース時間= 3600、トンネルタイプ= IP-IP）
The gateway responds by granting local IP address 149.112.240.17 to the host, and permitting it to communicate with www.bar.com, at any port. Requested lease time and tunnel type are also granted.
ゲートウェイがホストにローカルIPアドレス149.112.240.17を付与し、任意のポートで、www.bar.comと通信することを可能にすることによって応答します。要求されたリース時間やトンネルタイプも付与されます。
C --> S: DE-REGISTER_REQUEST (Client ID = 3)
C - > S：DE-REGISTER_REQUEST（クライアントID = 3）
The host de-registers with the sever.
サーバとホストの登録解除。
S --> C: DE-REGISTER_RESPONSE (Client ID = 3)
S - > C：DE-REGISTER_RESPONSE（クライアントID = 3）
The gateway acknowledges that the host has de-registered. All of the host's bindings have been implicitly revoked.
ゲートウェイは、ホストが登録解除したことを認めています。ホストのバインディングのすべてが暗黙のうちに取り消されました。
This appendix provides an exemplary diagram of RSIP host state. The host begins in the unregistered state. We assume that for UDP, if a message is lost, the host will timeout and retransmit another copy of it. We recommend a 7-fold binary exponential backoff timer for retransmissions, with the first timeout occurring after 12.5 ms. This diagram does not include transitions for the LISTEN_REQUEST message.
この付録では、RSIPホスト状態の例示的な図を提供します。ホストが未登録の状態で開始されます。私たちは、メッセージが失われた場合、UDPのために、ホストがタイムアウトし、それを別のコピーを再送することを想定しています。私たちは、最初のタイムアウトが12.5ミリ秒後に発生すると、再送信のための7倍のバイナリ指数バックオフタイマーをお勧めします。この図は、LISTEN_REQUESTメッセージのトランジションが含まれていません。
send
REGISTER_REQUEST
+------------+ +------------+
| |------------->|Registration|<-- timeout/send
+--->|Unregistered|<-------------| Pending |--- REGISTER_REQUEST
| | | +------------+
| +------------+ 7th timeout/recv |
| ^ ERROR_RESPONSE |
| | |
| | |
| |7th timeout/recv |recv timeout/send
| |DE-REGISTER_RESPONSE |REGISTER_RESPONSE QUERY_REQUEST
| | | ^ |
| | | | |
| | | send | |
| | send DE- v QUERY_REQUEST | |
| +----------------+ REGISTER_REQUEST+----------+ +----------+
| | Registered |<----------------| |--------->|Registered|
| | De-registration| |Registered| | Query |
| | Pending |---------------->| |<---------| Pending |
| +----------------+ recv +----------+ +----------+
| | ^ ERROR_RESPONSE ^ | 7th timeout/recv
| | | | | QUERY_RESPONSE or
| timeout/send | | ERROR_RESPONSE
| DE-REGISTER_REQUEST 7th timeout/recv| |
| ERROR_RESPONSE | |
| | |
| +----------------+ | |
| |Go to Registered| | |send
| +----------------+ | |ASSIGN_REQUEST
| ^ timeout/send | |
| |Yes FREE_REQUEST | |
| + | | | |
| + + v | | v
| + + 7th timeout/ +--------+ +----------+
| + Are all + recv | Free | |Assignment|<--timeout/send
| + resources +<-----------|Pending | | Pending |---ASSIGN_REQUEST
| + freed? + FREE_RESPONSE+--------+ +----------+
| + + ^ | |
| + + | | |
| + | | |recv
| |No send | |recv |ASSIGN_RESPONSE
| v ERROR_REQUEST| |ERROR_ |
| +---------------+ | |RESPONSE |
| | Go to Assigned| | | | 7th timeout/recv
| +---------------+ | | | QUERY_RESPONSE or
| recv | | | ERROR_RESPONSE
| +---------------+ERROR_RESPONSE | v v +-----------+
| | Assigned |-------------->+-------------+-------->| Assigned |
+>|De-registration| | Assigned | | Query |
| Pending |<--------------+-------------+<--------| Pending |
+---------------+ send ^ | +-----------+
^ | DE-REGISTER_REQUEST | | send ^ |
| | | | QUERY_REQUEST | |
| | | | | |
timeout/send 7th/timeout/recv | |send | |
DE-REGISTER_ ASSIGN_RESPONSE | |ASSIGN_REQUEST timeout/send
REQUEST or ERROR_RESPONSE| | QUERY_REQUEST
| |
| v
+----------+
| Assigned |
|Assignment|
| Pending |
+----------+
^ |
| |
timeout/send
ASSIGN_REQUEST
[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月。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[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月。
[RSIP-FRAME] Borella, M. Lo, J., Grabelsky, D. and G. Montenegro, "Realm Specific IP: Framework", RFC 3102, October 2001.
[RSIP-FRAME]ボレッラ、M.ロー、J.、Grabelsky、D.およびG.モンテネグロ、 "レルム特定IP：フレームワーク"、RFC 3102、2001年10月。
[RSIP-IPSEC] Montenegro, G. and M. Borella, "RSIP Support for End-to-end IPSEC", RFC 3104, October 2001.
[RSIP-IPSEC]モンテネグロ、G.およびM.ボレッラ、 "エンドツーエンドのIPSECのためのRSIPサポート"、RFC 3104、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
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
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
Kunihiro Taniguchi NEC USA C&C Research Labs. 110 Rio Robles San Jose, CA 95134
くにひろ たにぐち ねＣ うさ Ｃ＆Ｃ れせあｒｃｈ ぁｂｓ。 １１０ りお ろｂぇｓ さん じょせ、 か ９５１３４
Phone: (408) 943-3031 EMail: taniguti@ccrl.sj.nec.com
電話：（408）943-3031 Eメール：taniguti@ccrl.sj.nec.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機能のための基金は現在、インターネット協会によって提供されます。