Internet Engineering Task Force (IETF) M. Eisler
Request for Comments: 5665 NetApp
Updates: 1833 January 2010
Category: Standards Track
ISSN: 2070-1721
IANA Considerations for Remote Procedure Call (RPC)
Network Identifiers and Universal Address Formats
Abstract
抽象
This document lists IANA Considerations for Remote Procedure Call (RPC) Network Identifiers (netids) and RPC Universal Network Addresses (uaddrs). This document updates, but does not replace, RFC 1833.
この文書では、リモートプロシージャコール（RPC）ネットワーク識別子（netids）とRPCユニバーサルネットワークアドレス（uaddrs）のためのIANAの考慮事項を示しています。このドキュメントの更新、しかし、RFC 1833に代わるものではありません。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5665.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5665で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction and Motivation .....................................3
2. Requirements Language ...........................................3
3. Considerations for the Netid of the Stream Control
Transmission Protocol ...........................................3
4. Security Considerations .........................................3
5. IANA Considerations .............................................3
5.1. IANA Considerations for Netids .............................4
5.1.1. Initial Registry ....................................6
5.1.2. Updating Registrations ..............................8
5.2. IANA Considerations for Uaddr Formats ......................8
5.2.1. Initial Registry ....................................9
5.2.2. Updating Registrations .............................10
5.2.3. Uaddr Formats ......................................10
5.2.3.1. Uaddr Format for System V Release
4 Loopback Transports .....................10
5.2.3.2. Uaddr Format for Netid "-" ................10
5.2.3.3. Uaddr Format for Most IPv4 Transports .....11
5.2.3.4. Uaddr Format for Most IPv6 Transports .....11
5.2.3.5. Uaddr Format for ICMP over IPv4 and IPv6 ..11
5.3. Cross Referencing between the Netid and Format Registry ...12
5.4. Port Assignment for NFS over SCTP .........................12
6. References .....................................................12
6.1. Normative References ......................................12
6.2. Informative References ....................................12
Appendix A. Acknowledgments ......................................14
The concepts of an RPC (defined in RFC 5531 [4]) Network Identifier (netid) and an RPC Universal Address (uaddr) were introduced in RFC 1833 [1] for distinguishing network addresses of multiple protocols and representing those addresses in a canonical form. RFC 1833 states that a netid "is defined by a system administrator based on local conventions, and cannot be depended on to have the same value on every system". (The netid is contained in the field r_netid of the data type rpcb_entry, and the uaddr is contained in the field r_addr of the same data type, where rpcb_entry is defined in RFC 1833.) Since the publication of RFC 1833, it has been found that protocols like Network File System version 4 (NFSv4.0) [5] and RPC/ RDMA (Remote Direct Memory Access) [6] depend on consistent values of netids and representations of uaddrs. Current practices tend to ensure this consistency. Thus, this document identifies the considerations for IANA to establish registries of netids and uaddr formats for RPC and specifies the initial content of the two registries.
（RFC 5531で定義された[4]）RPCネットワーク識別子（NETID）とRPCユニバーサルアドレス（uaddr）の概念は、複数のプロトコルの区別ネットワークアドレス[1] RFC 1833年に導入され、標準形式でこれらのアドレスを表すました。 RFC 1833は、NETIDは、「ローカル規則に基づいて、システム管理者によって定義され、すべてのシステムで同じ値を持つようにに依存することはできない」と述べています。 （NETIDは、データ型rpcb_entryのフィールドr_netidに含まれ、そしてuaddrがrpcb_entryは、RFC 1833で定義されている同じデータ型のフィールドR_ADDRに含まれる）RFC 1833の刊行ので、発見されましたネットワークファイルシステムバージョン4（NFSv4.0）のようなプロトコル[5]及びRPC / RDMA（リモートダイレクトメモリアクセス）[6] netidsとuaddrsの表現の一貫した値に依存しています。現在の慣行は、この一貫性を確保する傾向があります。したがって、このドキュメントは、RPCのためnetidsとuaddr形式のレジストリを確立するために、IANAのための考慮事項を識別し、2つのレジストリの初期内容を指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[2]。
3. Considerations for the Netid of the Stream Control Transmission Protocol
ストリーム制御伝送プロトコルのNETID 3.検討事項
The Stream Control Transmission Protocol (SCTP) (described in RFC 4960 [7]) is a connection-oriented protocol that supports both byte-streamed and record-oriented data transfer. When the "sctp" and "sctp6" netids are used, the Open Network Computing (ONC) RPC Record Marking standard (see Section 11 of RFC 5531 [4]) is not used; instead, SCTP's native record-oriented data transfer is used.
ストリーム制御伝送プロトコル（SCTP）（RFC 4960に記載され[7]）バイト・ストリーミングおよびレコード指向データ転送の両方をサポートするコネクション型のプロトコルです。 「SCTP」および「sctp6のいずれか」netidsが使用される場合、オープンネットワークコンピューティング（ONC）標準マーキングRPCレコードが使用されない（RFC 5531 [4]のセクション11を参照します）。代わりに、SCTPのネイティブレコード指向データ転送が使用されています。
Since this document is only concerned with the IANA management of the Network Identifier (netid) and Universal Network Addresses (uaddrs) format registry, it raises no new security issues.
このドキュメントは、ネットワーク識別子（NETID）とユニバーサルネットワークアドレス（uaddrs）形式レジストリのIANA管理のみに関心あるので、それはどんな新しい安全保障問題も提起しません。
This section uses terms that are defined in RFC 5226 [8].
このセクションでは、RFC 5226で定義されている用語を使用する[8]。
IANA has created a registry called "ONC RPC Netids". The remainder of this section describes the registry.
IANAは、「ONC RPC Netids」と呼ばれるレジストリを作成しました。このセクションの残りの部分は、レジストリを記述する。
All assignments to the ONC RPC Netids registry are made on one of two bases:
ONC RPC Netidsレジストリへのすべての割り当ては、2つの塩基のいずれかで作られています：
o A First Come First Served basis subregistry per Section 4.1 of RFC 5226.
o最初RFC 5226のセクション4.1あたりまず添え基底副登録を来ります。
o A Standards Action basis subregistry per Section 4.1 of RFC 5226.
RFC 5226のセクション4.1あたりO規格のアクション基底副登録。
The eXternal Data Representation (XDR) encoding allows netids to be up to 2^32 - 1 octets in length, but the registry will only allow a much shorter length. Assignments made on a Standards Action basis should be assigned netids 1 to 8 octets long. Assignments made on a First Come First Served basis should be assigned netids 9 to 128 octets long. Some exceptions are listed in Table 2.
外部データ表現（XDR）エンコードがnetidsは、最大2 ^ 32個のにすることができます - 長さが1オクテットが、レジストリははるかに短い長さをできるようになります。標準アクションに基づいて行わ割り当ては1〜8オクテット長netidsを割り当てる必要があります。最初に作られた割り当ては、最初に役立った基礎を来る9 128オクテット長いnetidsを割り当てる必要があります。いくつかの例外を表2に記載されています。
Some portion of the netid name space is Reserved:
NETID名前空間の一部が予約されています：
o All netids, regardless of length, that start with the prefixes "STDS" or "FCFS" are Reserved, in order to extend the name space of either Standards Action or First Come First Served bases.
O接頭辞「性感染症」または「FCFS」で始まる長さに関係なくすべてのnetidsは、標準アクションまたは最初に来まず添え拠点のいずれかの名前空間を拡張するために、予約されています。
o To give the IESG the flexibility in the future to permit Private and Experimental Uses, all netids with the prefixes "PRIV" or "EXPE" are Reserved.
IESGにプライベートと実験的な用途を可能にするために、将来の柔軟性を提供するために、Oは、接頭辞「PRIV」または「EXPE」を持つすべてのnetidsが予約されています。
o To prevent confusion with the control protocol by the same name [9], netids with the prefix "ICMP" are Reserved.
oは、同じ名前[9]によって制御プロトコルとの混同を防止するために、接頭辞「ICMP」とnetidsが予約されています。
o Since netids are not constructed in an explicit hierarchical manner, this document does not provide for Hierarchical Allocation of netids. Nonetheless, all netids containing the octet "." are Reserved for future possible provision of Hierarchical Allocation.
netids明示的な階層的に構成されていないので、O、この文書はnetidsの階層的割当てを提供しません。それにもかかわらず、オクテットを含むすべてのnetids「」階層割当の将来の可能性提供のために予約されています。
o The zero length netid is Reserved.
Oゼロ長NETIDが予約されています。
A recommended convention for netids corresponding to transports that work over the IPv6 protocol is to have "6" as the last character in the netid's name.
IPv6プロトコルを介してその作業を輸送するために、対応するnetidsのための推奨されている規則は、NETIDの名前の最後の文字として「6」を持つことです。
There are two subregistries of netids: one for Standards Action assignments and one for First Come First Served assignments. Each registry of netids is a list of assignments, each containing five fields for each assignment.
まず標準化のためのアクションの割り当てのために1つずつ来て最初に添え割り当て：netidsの2 subregistriesがあります。 netidsの各レジストリは、各割り当てについて、各含む5つのフィールド割り当てのリストです。
1. A US-ASCII string name that is the actual netid. The netid should be 1 to 8 octets long for the Standards Action subregistry, and 9 to 128 octets long for the First Come First Served subregistry. The netid MUST NOT conflict with any other registered netid. Despite the fact that netids are case sensitive, the netid, when mapped to all upper case, MUST NOT conflict with the value of any other registered netid after the registered netid is mapped to upper case. In addition, when mapped to upper case, the prefix of the netid MUST NOT be equal to a Reserved prefix.
実際のNETIDある1. A US-ASCII文字列名。まず最初に役立った副登録を来るためNETIDは、長い長い標準アクション副登録のための1〜8オクテット、および9 128オクテットをする必要があります。 NETIDは、他の登録はnetidと競合してはなりません。登録NETIDを大文字にマッピングされた後netidsは、大文字と小文字が区別されているという事実にもかかわらず、すべて大文字にマッピングNETIDは、他の登録されたNETIDの値と競合してはいけません。また、アッパーケースにマッピングされた場合、NETIDの接頭辞は予約プレフィックスに等しいはずがありません。
2. A constant name that can be used for software programs that wish to use the transport protocol associated with the netid. The name of the constant typically has the prefix "NC_", and a suffix equal to the upper-case version of the netid. This constant name should be a constant that is valid in the 'C' programming language. This constant name MUST NOT conflict with any other netid constant name. Constant names with the prefix "NC_STDS", "NC_FCFS", "NC_PRIV", "NC_EXPE", and "NC_ICMP" are Reserved. Constant names with a prefix of "NC_" and a total length of 11 characters or less should be for assignments made on the Standards Action basis. The constant "NC_" is Reserved. The constant name can be 1 to 131 octets long.
2. NETIDに関連付けられているトランスポートプロトコルを使用するソフトウェアプログラムのために使用することができる定数名。定数の名前は、典型的には、接頭辞「NC_」、およびNETIDの大文字バージョンに等しいサフィックスを有します。この定数名は、「C」プログラミング言語で有効な定数でなければなりません。この定数名は、他のNETID定数名と競合してはなりません。接頭辞 "NC_STDS"、 "NC_FCFS" との定数名は、 "NC_PRIV"、 "NC_EXPE"、および "NC_ICMPは、" 予約されています。 「NC_」の接頭辞と11文字以下の長さの合計と定数名は、標準のアクションに基づいて行わ割り当てのためにする必要があります。定数「NC_は、」予約されています。定数名は1〜131オクテットの長さにすることができます。
Given the typical derivation of the constant name from the netid,
the registration of the constant might be considered redundant.
This is not always true. For example, a netid might use a
character that is not valid in the programming language. The
first entry of Table 1 provides such an example.
3. A description and/or a reference to a description of how the netid will be used. For assignments made on a First Come First Served basis, the description should include, if applicable, a reference to the transport and network protocols corresponding to the netid. For assignments made on a Standards Action basis, the description field must include the RFC numbers of the protocol associated with the netid, including, if applicable, RFC numbers of the transport and network protocols.
3.説明および/またはNETIDが使用される方法の説明を参照します。最初に来る最初に配信基づいてなさ割り当てのために、説明は、該当する場合、NETIDに対応するトランスポート及びネットワークプロトコルへの参照を含める必要があります。標準アクションに基づいて行わ割り当てについては、説明フィールドは、トランスポートとネットワークプロトコルの、該当する場合は、RFC番号などNETID、関連するプロトコルのRFC番号を含める必要があります。
4. A point of contact of the registrant. For assignments made on a First Come First Served basis:
登録者の接触の4点。最初に来まず添え基づいて作られた割り当ての場合：
* the point of contact should include an email address.
*接触のポイントは、電子メールアドレスを含める必要があります。
* subject to authorization by a Designated Expert, the point of contact may be omitted for extraordinary situations, such as the registration of a commonly used netid where the owner is unknown.
*指定された専門家による認可を受け、接触点は、所有者が不明で一般的に使用されるNETIDの登録などの異常な状況のために省略されてもよいです。
For assignments made on a Standards Action basis, the point of contact is always determined by IESG.
標準アクションに基づいて行わ割り当てのために、接触のポイントは常にIESGによって決定されます。
5. A numerical value, used to cross reference the netid assignment with an assignment in the uaddr format registry (see Section 5.2). If the registrant is registering a netid that cross references an existing assignment in the uaddr format registry, then the registrant provides the actual value of the cross reference along with the date the registrant retrieved the cross reference value from the uaddr format registry. If the registrant is registering both a new netid and new uaddr format, then the registrant provides a value of TBD1 in the netid request, and uses TBD1 in the uaddr format request. IANA will then substitute TBD1 for the cross reference number IANA allocates. Note that if a document requests multiple netid and uaddr assignments, each additional uaddr format cross reference will be identified as TBD2, TBD3, ..., etc.
5.参照をuaddr形式レジストリ内の割り当てとNETID割り当てを横断するために使用される数値は、（セクション5.2を参照）。登録者は、相互参照がuaddr形式レジストリ内の既存の割り当ては、その後、登録日付と共に相互参照の実際の値を提供NETID登録されている場合は登録者はuaddrフォーマットレジストリから相互参照値を取得しました。登録者は、新しいNETIDと新しいuaddr形式の両方が登録されている場合、登録者はNETID要求にTBD1の値を提供し、uaddrフォーマット要求にTBD1を使用します。 IANAはその後IANAが割り当て相互参照番号のTBD1に置き換えます。文書が複数NETIDとuaddr割り当てを要求した場合、各追加uaddr形式の相互参照が...、等TBD2、TBD3、として識別されることに注意してください
The initial list of netids is broken into two subregistries: those assigned on a First Come First Served basis in Table 1 and those assigned on a Standards Action basis in Table 2. These lists will change as IANA registers additional netids as needed, and the authoritative list of registered netids will always live with IANA.
最初に割り当てられたものを、表1の最初の添え基礎を是非、必要に応じてIANAが追加netidsを登録するように、これらのリストは変更される表2に標準アクションごとに割り当てられた、と権威：netidsの初期リストは2 subregistriesに分割されます登録netidsのリストは常にIANAに住むことになります。
+-------------+--------------+---------------------------+-----+----+
| Netid | Constant | Description and/or | PoC | CR |
| | Name | Reference | | |
+-------------+--------------+---------------------------+-----+----+
| "-" | NC_NOPROTO | RFC1833 [1], | | 1 |
| | | Section 5.2.3.2 of RFC | | |
| | | 5665 | | |
| "ticlts" | NC_TICLTS | The loop back | | 0 |
| | | connectionless transport | | |
| | | used in System V Release | | |
| | | 4 and other operating | | |
| | | systems. Although this | | |
| | | assignment is made on a | | |
| | | First Come First Served | | |
| | | basis and is fewer than | | |
| | | nine characters long, the | | |
| | | exception is authorized. | | |
| | | See [10]. | | |
| "ticots" | NC_TICOTS | The loop back | | 0 |
| | | connection-oriented | | |
| | | transport used in System | | |
| | | V Release 4 and other | | |
| | | operating systems. See | | |
| | | [10]. Although this | | |
| | | assignment is made on a | | |
| | | First Come First Served | | |
| | | basis and is fewer than | | |
| | | nine characters long, the | | |
| | | exception is authorized. | | |
| "ticotsord" | NC_TICOTSORD | The loop back | | 0 |
| | | connection-oriented with | | |
| | | orderly-release transport | | |
| | | used in System V Release | | |
| | | 4 and other operating | | |
| | | systems. See [10]. | | |
+-------------+--------------+---------------------------+-----+----+
Table 1: Initial First Come First Served Netid Assignments
表1：初期最初に来る最初に役立ったNETIDの割り当て
PoC: Point of Contact.
PoC：連絡先のポイント。
CR: Cross Reference to the Uaddr Format Registry.
CR：Uaddr形式レジストリへのクロスリファレンス。
+---------+----------+----------------------------------+------+----+
| Netid | Constant | RFC(s) and Description (if | PoC | CR |
| | Name | needed) | | |
+---------+----------+----------------------------------+------+----+
| "rdma" | NC_RDMA | RFC 5666 [6], RFC 791 [11] | IESG | 2 |
| "rdma6" | NC_RDMA6 | RFC 5666 [6], RFC 2460 [12] | IESG | 3 |
| "sctp" | NC_SCTP | RFC 4960 [7], RFC 791 [11], | IESG | 2 |
| | | Section 3 of RFC 5665 | | |
| "sctp6" | NC_SCTP6 | RFC 4960 [7], RFC 2460 [12], | IESG | 3 |
| | | Section 3 of RFC 5665 | | |
| "tcp" | NC_TCP | RFC 793 [13], RFC 791 [11], | IESG | 2 |
| | | Section 11 of RFC 5531 [4] | | |
| "tcp6" | NC_TCP6 | RFC 793 [13], RFC 2460 [12], | IESG | 3 |
| | | Section 11 of RFC 5531 [4] | | |
| "udp" | NC_UDP | RFC 768 [14], RFC 791 [11] | IESG | 2 |
| "udp6" | NC_UDP6 | RFC 768 [14], RFC 2460 [12] | IESG | 3 |
+---------+----------+----------------------------------+------+----+
Table 2: Initial Standards Action Netid Assignments
表2：初期規格アクションNETIDの割り当て
Per Section 5.2 of RFC 5226, the registrant is always permitted to update a registration made on a First Come First Served basis "subject to the same constraints and review as with new registrations". The IESG or a Designated Expert is permitted to update any registration made on a First Come First Served basis, which normally is done when the PoC cannot be reached in order to make necessary updates. Examples where an update would be needed include, but are not limited to: the email address or other contact information becomes invalid; the reference to the corresponding protocol becomes obsolete or unavailable; RFC 1833 is updated or replaced in such a way that the scope of netids changes, requiring additional fields in the assignment.
RFC 5226の5.2節ごとに、登録者は常に最初に作られた、登録が最初に役立った基礎「新規登録と同じ制約と見直しの対象を」さあ更新することが許可されています。 IESGまたは指定エキスパートは、まずのPoCは、必要な更新を行うために達することができないときに通常行われている根拠を、添え是非最初に行われたすべての登録を更新することが許可されています。更新が必要になる例としては、これらに限定されない：電子メールアドレスまたはその他の連絡先情報は無効になります。対応するプロトコルへの参照は、廃止または使用不能になりました。 RFC 1833は、更新またはnetids変化の範囲は、割り当てに追加のフィールドを必要とするように置換されます。
Only the IESG, on the advice of a Designated Expert, can update a registration made on a Standards Action basis.
唯一のIESGは、指定専門家のアドバイスに、標準アクションに基づいて行わ登録を更新することができます。
IANA has created a registry called "ONC RPC Uaddr Format Registry" (called the "format registry" for the remainder of this document). The remainder of this section describes the registry.
IANAは（この文書の残りのための「形式レジストリ」と呼ばれる）「ONC RPC Uaddr形式レジストリ」と呼ばれるレジストリを作成しました。このセクションの残りの部分は、レジストリを記述する。
All assignments to the format registry are made on one of two bases:
形式レジストリのすべての割り当ては、2つの塩基のいずれかで作られています：
o First Come First Served basis per Section 4.1 of RFC 5226.
OまずRFC 5226のセクション4.1あたり最初に役立った基礎を来ります。
o Standards Action per Section 4.1 of RFC 5226.
RFC 5226のセクション4.1あたりO規格アクション。
The registry of formats is a list of assignments, each containing four fields for each assignment.
フォーマットのレジストリは、各割り当ての各々含む4つのフィールド割り当てのリストです。
1. The basis for the assignment, which can be either FCFS for First Come First Served assignments or STDS for Standards Action assignments.
1.もどちらかFCFSは、まず最初にするために役立っ割り当てやSTDS標準化のためのアクションの割り当てを来ることができる割り当ての基礎。
2. A description and/or reference to a description of the actual uaddr format. Assignments made on a Standards Action basis always have a reference to an RFC.
0002及び/又は実際のuaddrフォーマットの説明を参照します。標準アクションに基づいて行わ割り当ては常にRFCへの参照を持っています。
3. For assignments made on a First Come First Served basis, a point of contact, including an email address. Subject to authorization by a Designated Expert, the point of contact may be omitted for extraordinary situations, such as the registration of a commonly used format where the owner is unknown. For assignments made on a Standards Action basis, the point of contact is always determined by the IESG.
最初に作られた割り当て3.電子メールアドレスなど、連絡先のポイントを最初に役立った基礎を来ります。指定された専門家による承認を条件として、接触点は、所有者が不明で一般的に使用される形式の登録のような異常な状況のために省略されてもよいです。標準アクションに基づいて行わ割り当てのために、接触のポイントは常にIESGによって決定されます。
4. A numerical value, used to cross reference the format assignment with an assignment in the netid registry. The registrant provides a value of TBD1 for the cross reference field when requesting an assignment. IANA will assign TBD1 to a real value. Note that if a document requests multiple uaddr assignments, each additional uaddr format cross reference will be identified as TBD2, TBD3, ..., etc.
交差するために使用される前記数値は、NETIDレジストリの割り当てとフォーマットの割り当てを参照します。割り当てを要求するとき、登録は、相互参照フィールドのTBD1の値を提供します。 IANAは、実際の値にTBD1を割り当てます。文書が複数uaddr割り当てを要求した場合、各追加uaddr形式の相互参照がTBD2、TBD3、...、等として識別されることに注意してください
All requests for assignments to the format registry on a Standards Action basis are only for Standards Track RFCs approved by the IESG.
標準アクションごとに形式レジストリへの割り当てのためのすべての要求はIESGによって承認された標準化過程のRFCのためにのみです。
The initial list of formats is in Table 3. This list will change as IANA registers additional formats as needed, and the authoritative list of registered formats will always live with IANA.
フォーマットの最初のリストは、IANAが必要に応じて追加のフォーマット、および常にIANAに住むことになり、登録フォーマットの正式なリストを登録すると、このリストが変更されます。表3にあります。
+-------+-----------------------------------------------+------+----+
| Basis | Description and/or Reference | PoC | CR |
+-------+-----------------------------------------------+------+----+
| FCFS | System V Release 4 loopback transport uaddr | | 0 |
| | format. Section 5.2.3.1 of RFC 5665 | | |
| FCFS | Uaddr format for NC_NOPROTO. Section 5.2.3.2 | | 1 |
| | of RFC 5665 | | |
| STDS | Uaddr format for IPv4 transports. | IESG | 2 |
| | Section 5.2.3.3 of RFC 5665 | | |
| STDS | Uaddr format for IPv6 transports. | IESG | 3 |
| | Section 5.2.3.4 of RFC 5665 | | |
+-------+-----------------------------------------------+------+----+
Table 3: Initial Format Assignments
表3：初期フォーマットの割り当て
The registrant is always permitted to update a registration made on a First Come First Served basis "subject to the same constraints and review as with new registrations." The IESG is permitted to update any registration made on a First Come First Served basis, which normally is done when the PoC cannot be reached in order to make necessary updates. Examples where an update would be needed include, but are not limited to: the email address or other contact information becomes invalid; the reference to the format description becomes obsolete or unavailable; RFC 1833 is updated or replaced in such a way that the scope of uaddr formats changes, requiring additional fields in the assignment.
登録者は、常に、まず基礎添え是非最初に作られた登録を更新することが許可され、「新規登録と同じ制約と見直しの対象とします。」 IESGは、PoCが必要な更新を行うために達することができないときに通常行われている最初に来る最初に役立った基礎の上に行われた登録を更新することが許可されています。更新が必要になる例としては、これらに限定されない：電子メールアドレスまたはその他の連絡先情報は無効になります。フォーマット記述への参照が廃止または使用不能になりました。 RFC 1833は、更新またはuaddrの範囲は、割り当てに追加のフィールドを必要とする変更をフォーマットするように置換されています。
Only the IESG, on the advice of a Designated Expert, can update a registration made on a Standards Action basis.
唯一のIESGは、指定専門家のアドバイスに、標準アクションに基づいて行わ登録を更新することができます。
Although RFC 1833 specifies the uaddr as the XDR data type string (hence, limited to US-ASCII), implementations of the System V Release 4 loopback transports will use an opaque string of octets. Thus, the format of a loopback transport address is any non-zero length array of octets.
RFC 1833は、XDRデータ型列としてuaddrを指定しますが（したがって、US-ASCIIに限る）、System Vリリース4ループバックトランスポートの実装はオクテットの不透明な文字列を使用します。したがって、ループバックトランスポート・アドレスのフォーマットは、オクテットの任意の非ゼロ長の配列です。
There is no address format for netid "-". This netid is apparently for internal use for supporting some implementations of RFC 1833.
「 - 」はnetidのためのアドレス形式はありません。このNETIDは、RFC 1833のいくつかの実装をサポートするための内部使用のために明らかです。
Most transport protocols that operate over IPv4 use 16-bit port numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The format of the uaddr for the above 16-bit port transports (when used over IPv4) is the US-ASCII string:
IPv4の上で動作ほとんどの転送プロトコルは、RDMA [6]、[7] SCTP、TCP [13]、およびUDP [14]を含む16ビットのポート番号を使用します。 （IPv4の上で使用）上記16ビットポートのトランスポートのためのuaddrのフォーマットは、US-ASCII文字列です。
h1.h2.h3.h4.p1.p2
h1.h2.h3.h4.p1.p2
The prefix "h1.h2.h3.h4" is the standard textual form for representing an IPv4 address, which is always four octets long. Assuming big-endian ordering, h1, h2, h3, and h4 are, respectively, the first through fourth octets each converted to ASCII-decimal. The suffix "p1.p2" is a textual form for representing a service port. Assuming big-endian ordering, p1 and p2 are, respectively, the first and second octets each converted to ASCII-decimal. For example, if a host, in big-endian order, has an address in hexadecimal of 0xC0000207 and there is a service listening on, in big-endian order, port 0xCB51 (decimal 52049), then the complete uaddr is "192.0.2.7.203.81".
接頭辞「h1.h2.h3.h4は」4つのオクテット長常にIPv4アドレスを、表現するための標準的なテキスト形式です。それぞれ、ビッグエンディアン順序、H1、H2、H3、およびH4をしていると仮定すると、各第四オクテット〜第はASCII-10進数に変換しました。接尾辞「p1.p2は、」サービスポートを表現するためのテキスト形式です。それぞれ、ビッグエンディアン順序、P1とP2をしていると仮定すると、第一及び第二のオクテットはそれぞれ、ASCII-10進数に変換しました。例えば、ホストは、ビッグエンディアン順で、0xC0000207の16進数でアドレスを持ち、上のリスニングサービスがある場合には、ビッグエンディアン順、ポート0xCB51（52049を10進数）で、その後、完全なuaddrは「192.0.2.7です.203.81" 。
Most transport protocols that operate over IPv6 use 16-bit port numbers, including RDMA [6], SCTP [7], TCP [13], and UDP [14]. The format of the uaddr for the above 16-bit port transports (when used over IPv6) is the US-ASCII string:
IPv6で動作するほとんどの転送プロトコルは、RDMA [6]、[7] SCTP、TCP [13]、およびUDP [14]を含む16ビットのポート番号を使用します。 （IPv6の上で使用）上記16ビットポートのトランスポートのためのuaddrのフォーマットは、US-ASCII文字列です。
x1:x2:x3:x4:x5:x6:x7:x8.p1.p2
X1：X2：X3：X4：X5：X6：X7：x8.p1.p2
The suffix "p1.p2" is the service port, and is computed the same way as with uaddrs for transports over IPv4 (see Section 5.2.3.3). The prefix "x1:x2:x3:x4:x5:x6:x7:x8" is the preferred textual form for representing an IPv6 address as defined in Section 2.2 of RFC 4291 [3]. Additionally, the two alternative forms specified in Section 2.2 of RFC 4291 are also acceptable.
接尾辞「p1.p2は、」サービスポートで、とIPv4の上にトランスポート（項5.2.3.3を参照）uaddrsと同じ方法で計算されます。接頭辞 "X1：X2：X3：X4：X5：X6：X7：X8は" RFC 4291のセクション2.2で定義されたIPv6アドレスを表すための好ましいテキスト形式である[3]。また、RFC 4291のセクション2.2で指定された2つの代替形態も許容されます。
As ICMP is not a true transport, there is no uaddr format for ICMP. The netid assignments "icmp" and "icmp6" and their shared uaddr "format" are listed to prevent any registrant from allocating the netids "icmp" and "icmp6" for a purpose that would likely cause confusion.
ICMPが真の輸送ないので、ICMPのためのuaddrフォーマットはありません。 NETID割り当て「ICMP」と「ICMP6」とその共有uaddr「フォーマット」はそうな混乱を引き起こすために、netids「ICMP」と「ICMP6」を割り振るから任意の登録者を防ぐために記載されています。
The last field of the netids registry is used to cross reference with the last field of the format registry. IANA is under no obligation to maintain the same numeric values in cross references when updating each registry; i.e., IANA is free to "re-number" these corresponding fields. However, if IANA does so, both the netid and format registries must be updated atomically.
netidsレジストリの最後のフィールドは、フォーマットレジストリの最後のフィールドと参照を横断するために使用されます。 IANAは、各レジストリを更新する際に相互参照で、同じ数値を維持する義務を負いません。すなわち、IANAは「再番号」これらの対応するフィールドに無料です。 IANAがそうする場合は、両方のNETIDおよびフォーマットレジストリがアトミックに更新する必要があります。
Port 2049 is assigned to NFS over SCTP for the sctp and sctp6 netids.
ポート2049は、SCTPとsctp6のいずれかnetidsのためのSCTP上でNFSに割り当てられています。
[1] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995.
[1]スリニバサン、R.、 "ONC RPCバージョン2への結合プロトコル"、RFC 1833、1995年8月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[3] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[4] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, May 2009.
[4] Thurlow、R.、 "RPC：リモートプロシージャコールプロトコル仕様バージョン2"、RFC 5531、2009年05月05日。
[5] Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Beame, C., Eisler, M., and D. Noveck, "Network File System (NFS) version 4 Protocol", RFC 3530, April 2003.
[5] Shepler、S.、キャラハン、B.、ロビンソン、D.、Thurlow、R.、Beame、C.、アイスラー、M.、およびD. Noveck、 "ネットワークファイルシステム（NFS）バージョン4プロトコル"、 RFC 3530、2003年4月。
[6] Talpey, T. and B. Callaghan, "Remote Direct Memory Access Transport for Remote Procedure Call", RFC 5666, January 2010.
[6] Talpey、T.とB.キャラハン、 "リモートプロシージャコールのためのリモートダイレクトメモリアクセス交通"、RFC 5666、2010年1月。
[7] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[7]スチュワート、R.、エド。、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[8] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[9] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[9]ポステル、J.、 "インターネット制御メッセージプロトコル"、STD 5、RFC 792、1981年9月。
[10] American Telephone and Telegraph Company, "UNIX System V, Release 4 Programmer's Guide: Networking Interfaces, ISBN 0139470786", 1990.
[10]アメリカ電信電話会社、 "UNIX System Vの、リリース4プログラマーズ・ガイド：ネットワークインタフェース、ISBN 0139470786"、1990年。
[11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[11]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[12]デアリング、S.とR. Hindenと "インターネットプロトコル、バージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[13] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[13]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[14]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
Appendix A. Acknowledgments
付録A.謝辞
Lisa Dusseault, Lars Eggert, Pasi Eronen, Tim Polk, Juergen Schoenwaelder, and Robert Sparks reviewed the document and gave valuable feedback.
リサDusseault、ラースEggertの、パシEronen、ティムポーク、ユルゲンSchoenwaelder、そしてロバート・スパークスは、文書をレビューし、貴重なフィードバックを与えました。
Author's Address
著者のアドレス
Mike Eisler NetApp 5765 Chase Point Circle Colorado Springs, CO 80919 US
マイク・アイスラーNetAppの5765チェイスポイントサークルコロラドスプリングズ、コロラド州80919米国
Phone: +1-719-599-9026 EMail: mike@eisler.com
電話：+ 1-719-599-9026 Eメール：mike@eisler.com