[要約] RFC 3103は、Realm Specific IP（RSIP）プロトコルの仕様を定めたものであり、異なるIPレルム間の通信を可能にすることを目的としています。RSIPは、ネットワークのスケーラビリティとセキュリティを向上させるために設計されています。
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
レルム固有のIP：プロトコル仕様
Status of this Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
IESG Note
IESGノート
The IESG notes that the set of documents describing the RSIP technology imply significant host and gateway changes for a complete implementation. In addition, the floating of port numbers can cause problems for some applications, preventing an RSIP-enabled host from interoperating transparently with existing applications in some cases (e.g., IPsec). Finally, there may be significant operational complexities associated with using RSIP. Some of these and other complications are outlined in section 6 of 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テクノロジーを説明するドキュメントのセットが、完全な実装のために重要なホストとゲートウェイの変更を暗示していることを指摘しています。さらに、ポート番号が浮かんでいると、一部のアプリケーションに問題が発生する可能性があり、RSIP対応のホストが既存のアプリケーションと透過的に相互運用することを防ぐことができます（例えば、IPSEC）。最後に、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番目のルーティングレルムのアドレスに翻訳し、2番目のルーティングレルムから最初のルーティングレルムを入力するパケットの逆関数を実行します。この翻訳は、いずれかのスペースでホストに透過的に実行され、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フレーム]は、NATよりも透明性を示すアドレス共有の方法として定義されています。特に、RSIPでは、RSIPゲートウェイ（2つの領域の間のルーターまたはゲートウェイ）が、2番目のルーティングレルム、そしておそらく他のリソースから各RSIPホストに少なくとも1つのアドレスを割り当てることを要求しています。RSIPホストは、2番目のルーティング領域でホスト、エンティティ、またはデバイスへのエンドツーエンドの接続を確立する必要がある最初のルーティング領域のホストです。したがって、2番目のルーティングレルムはRSIPホストから直接アクセスできませんが、このシステムにより、パケットはRSIPホストから宛先までの完全性を維持できます。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では、ホストを変更することで、2番目のルーティングレルムにバインドされた各パケットの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フレーム]で説明されています。エンドツーエンドのIPSECを有効にするこのプロトコルへの拡張については、[rsip-inpec]で説明されています。
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].
キーワードは「必要」、「必須」、「必須」、「は」、「はははない」、「そうではない」、「しなければ」、「そうしない」、「可能な」、「そうでない」このドキュメントに表示されることは解釈されます[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]で指定されている範囲（10.0.0.0.0/8、172.16.0.0/12、192.168.0.0/16）の範囲（10.0.0.0.0/12、172.0.0.0.0/12）、またはインターネットから不可能なアドレスを使用するルーティング領域。
Public Realm
公共部門
A routing realm with 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.
プライベートレルムとパブリックレルムの境界に位置し、1つ以上の公開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ホストにパブリックレルムから一意のIPアドレスが割り当てられるRSIPメソッド。[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フレーム]の用語と一致しています。
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
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はRSIPゲートウェイです（NAT機能も実行できます）。nには2つのインターフェイスがあります。アドレススペースAとアドレススペースBのNBには、アドレススペース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.
ホストXは、アドレススペースB内に位置するネットワークエンティティYへのエンドツーエンド接続を確立する必要があり、RSIPゲートウェイからリソースの割り当てを最初に交渉および取得します。これらのパラメーターを割り当てると、RSIPゲートウェイは、Xのアドレス指定情報、および割り当てられたリソースのマッピングを作成します。このバインディングにより、RSIPゲートウェイはXに対してYによって生成されたインバウンドトラフィックを正しく脱マルチプレックスおよび転送することができます。リース時間は各バインドに関連付けられています。
Using the public parameters assigned by the RSIP gateway, RSIP hosts tunnel data packets across address space A to the RSIP gateway. The RSIP gateway acts as the end point of such tunnels, stripping off the outer headers and routing the inner packets onto the public realm. As mentioned above, an RSIP gateway maintains a mapping of the assigned public parameters as demultiplexing fields for uniquely mapping them to RSIP host private addresses. When a packet from the public realm arrives at the RSIP gateway and it matches a given set of demultiplexing fields, then the RSIP gateway will tunnel it to the appropriate RSIP host. The tunnel headers of outbound packets from X to Y, given that X has been assigned Nb, are as follows:
RSIPゲートウェイによって割り当てられたパブリックパラメーターを使用して、RSIPは、アドレススペースAにRSIPゲートウェイにトンネルデータパケットをホストします。RSIPゲートウェイは、そのようなトンネルのエンドポイントとして機能し、外側のヘッダーを取り除き、内側のパケットをパブリックレルムにルーティングします。上記のように、RSIPゲートウェイは、割り当てられたパブリックパラメーターのマッピングを、RSIPホストのプライベートアドレスにユニークにマッピングするための非複数のフィールドとして維持します。パブリックレルムからのパケットがRSIPゲートウェイに到着し、特定の非gultiplexingフィールドに一致すると、RSIPゲートウェイは適切なRSIPホストにトンネルします。xがNBに割り当てられていることを考えると、xからyからyまでのアウトバウンドパケットのトンネルヘッダーは次のとおりです。
+---------+---------+---------+
| X -> Na | Nb -> Y | payload |
+---------+---------+---------+
There are two basic flavors of RSIP: RSA-IP and RSAP-IP. RSIP hosts and gateways MUST support RSAP-IP and MAY support RSA-IP. Details of RSA-IP and RSAP-IP are found in [RSIP-FRAME].
RSIPにはRSA-IPとRSAP-IPの2つの基本的なフレーバーがあります。RSIPホストとゲートウェイはRSAP-IPをサポートする必要があり、RSA-IPをサポートする場合があります。RSA-IPおよびRSAP-IPの詳細は[RSIPフレーム]にあります。
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をサポートする必要があります。ただし、RSIPホストは、TCPの代わりにUDP、または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回の試行）をお勧めします。ただし、これらのパラメーターは、特定のリンクタイプまたはシナリオに合わせて調整または調整できます。
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つの基本的な関係のうち正確な1つになります。
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ゲートウェイは、ホストに1つ以上のリソースを付与しました。ゲートウェイは、ホストに代わってグローバルにアドレス指定されたパケットを転送および配信します。各バインディングには、関連するリース時間があります。このリース時間が期限切れになると、バインディングは自動的に取り消されます。
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.
以下では、Macro-Flowポリシーとは、IPアドレスの粒度レベルでのフローポリシーの制御を指し、マイクロフローポリシーとは、IPアドレスとポートタプルの粒度でフローポリシーを制御することを指します。もちろん、ポリシーはまったくないかもしれません。これは、RSIPゲートウェイがRSIPホストが使用するフローパラメーターを気にしないことを示しています。2つのレベルのローカルフローポリシーと3つのレベルのリモートフローポリシーを検討します。
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ホストにIPアドレス（RSA-IP）またはIPアドレスと1つ以上のポート（RSAP-IP）が割り当てられます。ただし、ホストは、パブリックホストとのセッションを確立するために希望するポートを使用する場合があります。
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.
マイクロフローポリシーでは、ホストは一度に正確に1つのポートを割り当てられます。ホストは、より多くのポートを一度に1つずつ要求する場合があります。このポリシーにより、ゲートウェイはローカルポートの使用を非常に厳しく制御できますが、ホストの柔軟性は低くなります。
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.
RSA-IPでローカルマクロフローポリシーのみを使用できるのに対し、ローカルマクロフローまたはローカルマイクロフローポリシーのいずれかをRSAP-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:
RSA-IPメソッドを使用してRSIPホストを提供するRSIPゲートウェイは、RSIPホストへの着信パケットの適切なマッピングを確保するために、次の最小状態を維持する必要があります。
- Host's private address - Host's assigned public address(es)
- ホストのプライベートアドレス - ホストに割り当てられたパブリックアドレス（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
- ホストのプライベートアドレス-HOSTに割り当てられたパブリックアドレス（ES） - ホストが割り当てられたアドレスごとに割り当てられたポート
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つ以上のパラメーターが含まれています。すべてのパラメーターの一般的な形式は、1バイトのタイプで構成されるTLV（タイプ長値）に続いて2バイトの長さに続いて、以下に示すように「長さ」のバイト値が続きます。
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.
値フィールドは、パラメーターのタイプに従って、他の多くのフィールドに分割される場合があります。長さフィールドは、パラメーター内の全体のバイト数ではなく、値フィールドのバイト数をコードすることに注意してください。
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.
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（完全資格のあるドメイン名）の場合、アドレスフィールドの長さは長さフィールドの値よりも1つずつ、名前は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).
ホストがローカルアドレスとしてFQDNタイプのアドレスをリクエストすることは無効です（agside_request_rsa-ipおよびagside_request_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 = 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つあります。 複数のポートが指定されている場合、数字フィールドの値は含まれるポートの総数を示し、パラメーターは2つのフォームのいずれかを取ることができます。 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.
BIND 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.
エラーパラメーターはエラーを指定します。 現在定義されているエラー値は、付録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メッセージは、3つの必須フィールド、バージョン、メッセージタイプ、および全長で構成され、その後1つ以上の必要なパラメーターが続き、その後はゼロ以上のオプションパラメーターが続きます。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.
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:
ほとんどのパラメーターは、各メッセージに1回のみ表示されることができます。例外は次のとおりです。
- 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.
- 複数のアドレスパラメーターは、assight_request_rsa-ip、assight_response_rsa-ip、assight_request_rsap-ip、assight_response_rsap-ip、listen_request、およびristen_responseに表示する必要があります。
- Multiple ports parameters MUST appear in ASSIGN_REQUEST_RSAP-IP, ASSIGN_RESPONSE_RSAP-IP, LISTEN_REQUEST and LISTEN_RESPONSE.
- 複数のポートパラメーターは、assight_request_rsap-ip、assight_response_rsap-ip、risten_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ホストおよび/またはゲートウェイは、riste_requestおよびlisten_responseをサポートしない場合、またはRSA-IPではなくRSAP-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ゲートウェイは報告する1つのエラーのみを選択する必要があります。
<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.
- ホストが既にゲートウェイに登録されている場合、ゲートウェイは、既に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.
- ゲートウェイのポリシーでホストの登録が許可されない場合、ゲートウェイは登録_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ゲートウェイによって使用され、RSIPホストの登録を確認し、クライアントID、フローポリシー、および場合によってはメッセージカウンター、1つ以上の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ゲートウェイは、サポートする1つ以上の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.
assight_request_rsa-ipメッセージは、RSIPホストによって使用され、RSA-IPで使用するリソースを要求します。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.
- ローカルアドレスパラメーターがCARE VALUETでない場合、RSIPゲートウェイがアドレスを割り当てることができない場合、RSIPゲートウェイはlocal_addr_unavailableエラーを含むERROR_RESPONSEで応答する必要があります。
- If the local address parameter is not a don't care value there are three possible error conditions:
- ローカルアドレスパラメーターが気にしない価値がない場合、3つの可能なエラー条件があります。
o If the RSIP gateway cannot allocate ANY addresses, it MUST respond with an ERROR_RESPONSE containing the LOCAL_ADDR_UNAVAILABLE error.
o RSIPゲートウェイがアドレスを割り当てることができない場合、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.
o RSIPゲートウェイが使用されているため、要求されたアドレスを割り当てることができない場合、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.
o RSIPゲートウェイがポリシーで許可されていないために要求されたアドレスを割り当てることができない場合、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.
assight_response_rsa-ipメッセージは、RSIPゲートウェイで使用され、RSA-IPを使用して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.
ホストがエラーを検出するか、ゲートウェイの応答を「理解」しない場合、上記のagsid_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.
assight_request_rsap-ipメッセージは、RSIPホストによって使用され、RSAP-IPで使用するリソースを要求します。RSIPホストは、それぞれの最初のアドレスと2つのポートパラメーターをそれぞれ指定します。それぞれ、使用されるローカルアドレスとポートを参照し、それぞれ2番目はリモートアドレスとポートを参照します（sを参照します（s））それは連絡されます。
<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ホストは、最初のアドレスパラメーターの値フィールドにそのアドレスを配置することにより、特定のローカルアドレスを要求できます。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(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.
- ローカルアドレスパラメーターがCARE VALUETでない場合、RSIPゲートウェイがアドレスを割り当てることができない場合、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.
o RSIPゲートウェイがアドレスを割り当てることができない場合、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.
o RSIPゲートウェイが使用されているため、要求されたアドレスを割り当てることができない場合、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.
o RSIPゲートウェイがポリシーで許可されていないために要求されたアドレスを割り当てることができない場合、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.
o RSIPゲートウェイがポリシーで許可されていないために要求されたアドレス /ポートタプルを割り当てることができない場合、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ホストが多くのポートを要求します（それよりも大きい）が、特定のポート番号を指定していない場合（つまり、「気にしない」値を使用します）、RSIPゲートウェイは要求全体を許可できません。RSIPゲートウェイはerror_responseを返す必要がありますlocal_addrport_unavailableエラーを含む。
- 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.
assight_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つ以上のポートが割り当てられます。マイクロフローベースのローカルポリシーが使用されている場合、ホストにはアドレスと正確な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.
ホストがエラーを検出するか、ゲートウェイの応答を「理解」しない場合、上記のagside_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ゲートウェイによって使用され、RSIPホストから送信されたFree_Requestを確認し、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.
指定されたバインドIDでのリースがまだ期限切れになっていない場合でも、RSIPホストは常に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.
1つ以上のアドレスまたはネットワークタプルを指定できます。各タプルは、エンコードされたアドレスまたはネットワークのローカリティ（ローカルまたはリモート）に関するリクエストをエンコードします。タプルが指定されていない場合、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ゲートウェイで使用され、rsipホストからquery_requestに応答します。
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.
LISTE_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.
リモートホストアドレスとポートタプルがホストから以前に連絡されていない場合でも、rsipゲートウェイが問題のアドレスとポートに導かれるすべてのパケットをホストに転送する必要があります。
LISTEN_REQUEST is not necessary for RSA-IP.
rsa-ipにはlisten_requestは必要ありません。
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.
- ローカルアドレスパラメーターがCARE VALUETでない場合、RSIPゲートウェイがアドレスを割り当てることができない場合、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.
o RSIPゲートウェイがアドレスを割り当てることができない場合、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.
o RSIPゲートウェイが使用されているため、要求されたアドレスを割り当てることができない場合、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.
o RSIPゲートウェイがポリシーで許可されていないために要求されたアドレスを割り当てることができない場合、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.
o RSIPゲートウェイがポリシーで許可されていないために要求されたアドレス /ポートタプルを割り当てることができない場合、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.
rsipゲートウェイでlisten_responseメッセージを使用して、rsipホストからのlisten_requestメッセージに応答します。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.
- RSIPホストは、メッセージカウンター値がnのメッセージカウンター値を使用してRSIPゲートウェイからメッセージを受信するまで、n 1に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ビット値に達すると、0ではなく1に包みます。
- 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。これらのメッセージは、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ゲートウェイは、メッセージ_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ホストが適切なICMPメッセージをトンネルエンドポイントに送信します（例：RSIPゲートウェイ）。再起動前にアクティブだったセッションに関するシステムの動作は、再起動する公開可能な非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ホストが既に登録されていることを判断できます。したがって、既に_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_Firstエラーを備えたERROR_RESPONSEを使用して、すべてのメッセージ（Register_Requestを除く）に直ちに応答する必要があります。このようなメッセージを受け取ると、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.
2番目のケースでは、RSIPホストがRSIPサーバーのトンネルインターフェイスに送信するすべてのデータは、（1）静かに破棄されます。（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ゲートウェイは関連するパケットをドロップし、Hostに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ゲートウェイは関連するパケットをドロップして送信する必要がありますrifem_addrport_unallowedエラーを含むエラー_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ゲートウェイの厳しい制御を可能にすることです。たとえば、リモートマイクロフローベースのポリシーの下で操作し、FTPなどのプロトコルを使用するRSIPホストは、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フレーム]にあります。
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予約済み-1-240 IANAによって割り当てられた-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.
著者は、特にガブリエル・モンテネグロ、ピダ・スリューシュ、ブライアン・カーペンター、エリオット・リア、ダン・ネセット、ゲイリー・ジャシェフスキー、ネイビーン・ラジャニカンサ、スダカル・ラマクリシュナ、ジム・マーチ、リック・コブに感謝します。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's：一般的なエラー。
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：既に_registered。ホストは、最初に登録せずに再び登録しようとしました。
303: ALREADY_UNREGISTERED. The host has attempted to de-register but it is already in the unregistered state.
303：既に_unregistered。ホストは登録解除を試みましたが、すでに登録されていない状態にあります。
304: REGISTRATION_DENIED. The gateway will not allow the host to register.
304：登録_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_addrport_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's：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エンティティ、ホスト、またはゲートウェイが、各メッセージを生成するか、それが必須かオプションかを示します。すべての *_requestメッセージはホストにのみ実装されますが、すべての *_ Responseメッセージはゲートウェイにのみ実装されます。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.
ポートパラメーターは、ダッシュで区切られたポート番号が続くポートの数で表されます。たとえば、2-1012-1013は2つのポート、すなわち1012と1013を示し、16-10000は16ポート、つまり10000-10015、4-0は4つのポートを示しますが、送信者はどこにいるかを気にしません。
IPv4 addresses are assumed.
IPv4アドレスが想定されています。
This example exhibits the loosest policy framework for RSAP-IP.
この例は、RSAP-IPの最もゆるいポリシーフレームワークを示しています。
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)
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)
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)
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)
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)
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) 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.
c-> s：assile_request_rsap-ip ：（クライアントid = 1、address（local）= 149.112.240.156、ports（local）= 8-1238、address（remote）= 0、ports（remote）= 0、リース時間= 1800）ホストは、同じアドレスを持つ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)
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)
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.
ホストはBind ID 1を解放します。つまり、IPアドレス149.112.240.156からのポート1234-1237。ホストにはポート1305-1314が割り当てられているため、アドレス自体がホストにまだ割り当てられていることに注意してください。
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 1)
The gateway acknowledges that Bind ID 1 has been freed.
ゲートウェイは、Bind ID 1が解放されたことを認めています。
C --> S: EXTEND_REQUEST (Client ID = 1, Bind ID = 2, Lease Time =
1800)
The host request that the lease on bind ID 1 be extended for 1800 seconds.
ホストは、Bind ID 1のリースを1800秒間延長することを要求します。
S --> C: EXTEND_RESPONSE (Client ID = 1, Bind ID = 2, Lease Time =
1800)
The gateway confirms the request.
ゲートウェイはリクエストを確認します。
S --> C: FREE_RESPONSE (Client ID = 1, Bind ID = 2)
The gateway forces the host to free the resources of bind ID 2.
ゲートウェイは、ホストにBind ID 2のリソースを解放することを強制します。
C --> S: DE-REGISTER_REQUEST (Client ID = 1)
The host de-registers with the sever.
ホストはseverを使用して削除します。
S --> C: DE-REGISTER_RESPONSE (Client ID = 1)
The gateway acknowledges that the host has de-registered.
ゲートウェイは、ホストが登録されていることを認めています。
This example exhibits the strictest policy framework for RSAP-IP.
この例は、RSAP-IPの最も厳格なポリシーフレームワークを示しています。
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)
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)
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)
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.
ゲートウェイは、ポート2049で1のバインドIDが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)
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を要求します。ポート20（FTPデータ）からのホスト38.196.73.6のみが連絡できます。
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)
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)
The host de-registers with the sever.
ホストはseverを使用して削除します。
S --> C: DE-REGISTER_RESPONSE (Client ID = 5)
The gateway acknowledges that the host has de-registered. All of the host's bindings have been implicitly revoked.
ゲートウェイは、ホストが登録されていることを認めています。ホストのバインディングはすべて暗黙的に取り消されています。
This example exhibits a medium level of control for RSA-IP.
この例は、RSA-IPの中程度のコントロールを示しています。
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)
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)
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)
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)
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)
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)
The host de-registers with the sever.
ホストはseverを使用して削除します。
S --> C: DE-REGISTER_RESPONSE (Client 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の場合、メッセージが失われた場合、ホストはタイムアウトし、その別のコピーを再送信すると仮定します。再送信には7倍のバイナリ指数バックオフタイマーをお勧めします。最初のタイムアウトは12.5ミリ秒後に発生します。この図には、reast_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.、Moskowitz、B.、Karrenberg、D.、de Groot、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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. Holdrege、「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フレーム] Borella、M。Lo、J.、Grabelsky、D。、およびG. Montenegro、「Realm固有の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
Michael Borella Commworks 3800 Golf Rd。ローリングメドウズIL 60008
Phone: (847) 262-3083 EMail: mike_borella@commworks.com
電話：（847）262-3083メール：mike_borella@commworks.com
David Grabelsky CommWorks 3800 Golf Rd. Rolling Meadows IL 60008
David Grabelsky Commworks 3800 Golf Rd。ローリングメドウズIL 60008
Phone: (847) 222-2483 EMail: david_grabelsky@commworks.com
電話：（847）222-2483メール：david_grabelsky@commworks.com
Jeffrey Lo Candlestick Networks, Inc 70 Las Colinas Lane, San Jose, CA 95119
Jeffrey Lo Candlestick Networks、Inc 70 Las Colinas Lane、San Jose、CA 95119
Phone: (408) 284 4132 EMail: yidarlo@yahoo.com
電話：（408）284 4132メール：yidarlo@yahoo.com
Kunihiro Taniguchi NEC USA C&C Research Labs. 110 Rio Robles San Jose, CA 95134
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メール：taniguti@ccrl.sj.nec.com
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。