[要約] RFC 5665は、RPCネットワーク識別子とユニバーサルアドレス形式のIANAに関する考慮事項についての要約です。その目的は、RPCネットワーク識別子とユニバーサルアドレス形式の標準化と管理を助けることです。
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
リモートプロシージャコール（RPC）ネットワーク識別子とユニバーサルアドレス形式のIANAの考慮事項
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ユニバーサルネットワークアドレス（UADDR）に関する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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
RPC（RFC 5531 [4]で定義されている）ネットワーク識別子（NetID）とRPCユニバーサルアドレス（UADDR）の概念は、複数のプロトコルのネットワークアドレスを区別し、それらのアドレスを標準的な形式で表すためにRFC 1833 [1]で導入されました。。RFC 1833は、NetIDは「ローカル規則に基づいてシステム管理者によって定義されており、すべてのシステムで同じ値を持つことに依存することはできない」と述べています。（NetIDはデータ型RPCB_ENTRYのフィールドR_NETIDに含まれており、UADDRは同じデータ型のフィールドR_ADDRに含まれています。RPCB_ENTRYはRFC 1833で定義されています。）RFC 1833の公開以来、それは発見されています。ネットワークファイルシステムバージョン4（NFSV4.0）[5]およびRPC/ RDMA（リモートダイレクトメモリアクセス）[6]などのプロトコルは、NetIDの一貫した値とUADDRの表現に依存します。現在のプラクティスは、この一貫性を確保する傾向があります。したがって、このドキュメントは、IANAがRPCのNetIDSおよびUADDR形式のレジストリを確立するための考慮事項を特定し、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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [2]に記載されているように解釈される。
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.
o RFC 5226のセクション4.1ごとの標準アクションベースサブレジストリ。
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）エンコードにより、NetIDの長さは最大2^32-1オクテットになりますが、レジストリの長さははるかに短くなります。標準訴訟ベースで行われた割り当てには、NetIDS 1〜8オクターの長さを割り当てる必要があります。先着順で行われた割り当ては、NetIDS 9〜128オクテットの長さを割り当てる必要があります。いくつかの例外を表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 長さに関係なく、すべてのNetIDは、標準アクションの名前スペースを拡張するか、最初に提供された基盤のいずれかの名前スペースを拡張するために、「STDS」または「FCFS」から始まるすべてのNetIDが予約されています。
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.
o IESGに、プライベートおよび実験的使用を許可する将来の柔軟性を与えるために、プレフィックス「PRIV」または「Expe」を備えたすべてのNetIDが予約されています。
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.
o NetIDは明示的な階層的な方法で構築されていないため、このドキュメントはNetIDの階層的割り当てを提供しません。それにもかかわらず、オクテットを含むすべてのNetID。階層的割り当ての将来の可能な提供のために予約されています。
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プロトコルを介して動作するトランスポートに対応するNetIDの推奨条約は、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.
NetIDには2つのサブレジストリがあります。1つは標準アクションの割り当て用で、もう1つは最初に提供される割り当てです。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.
1. 実際のNetIDであるUS-ASCII文字列名。NetIDは、標準アクションサブレジストリでは1〜8オクテットの長さであり、最初のサブレジストリで最初に来るのは9〜128オクテットでなければなりません。NetIDは、他の登録されたNetIDと競合してはなりません。NetIDSはケースに敏感であるという事実にもかかわらず、NetIDは、すべての大文字にマッピングされた場合、登録済みの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.
NetIDからの定数名の典型的な導出を考えると、定数の登録は冗長と見なされる場合があります。これは常に真実ではありません。たとえば、NetIDは、プログラミング言語では有効でない文字を使用する場合があります。表1の最初のエントリは、そのような例を示します。
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.
NetIDSの初期リストは2つのサブレジストリに分割されます。表1で最初に提供されたものと表2に標準訴訟ベースで割り当てられたリストがあります。これらのリストは、IANAが必要に応じて追加のNetIDを登録すると変更されます。登録されたNetIDのリストは、常に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.
o RFC 5226のセクション4.1ごとの標準訴訟。
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. 割り当ての根拠は、最初に最初に提供される課題のFCF、または標準訴訟の割り当てのSTDのいずれかです。
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.
2. 実際の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.
4. 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.
フォーマットの初期リストは表3に記載されています。このリストは、IANAが必要に応じて追加の形式を登録すると変更され、登録形式の権威あるリストは常にIANAとともに存在します。
+-------+-----------------------------------------------+------+----+
| 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はUADDRをXDRデータ型文字列（したがって、US-ASCIIに限定）として指定していますが、System V Release 4 Loopback Transportsの実装は、オクテットの不透明な文字列を使用します。したがって、ループバック輸送アドレスの形式は、オクテットのゼロ以外の長さの配列です。
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]、SCTP [7]、TCP [13]、およびUDP [14]を含む16ビットポート番号を使用します。上記の16ビットポートトランスポート（IPv4を介して使用する場合）の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」は、IPv4アドレスを表すための標準的なテキストフォームであり、常に4オクテットの長さです。ビッグエンディアンの注文を仮定すると、H1、H2、H3、およびH4は、それぞれASCII-Decimalに変換された最初の〜4番目のオクテットです。接尾辞「P1.P2」は、サービスポートを表すためのテキストフォームです。ビッグエンディアンの注文を想定すると、P1とP2はそれぞれ1番目と2番目のオクテットがASCII-Decimalに変換されます。たとえば、ホストが大エンジンの順序で16進数のアドレスを持っている場合、0xc0000207の住所があり、大幅な順序でポート0xcb51（小数52049）を聞いているサービスがあります。.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]、SCTP [7]、TCP [13]、およびUDP [14]を含む16ビットポート番号を使用します。上記の16ビットポートトランスポート（IPv6を介して使用する場合）のUADDRの形式は、US-ASCII文字列です。
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を超える輸送用のUADDRと同じ方法で計算されます（セクション5.2.3.3を参照）。"x1：x2：x3：x4：x5：x6：x7：x8"は、RFC 4291 [3]のセクション2.2で定義されているIPv6アドレスを表すための好ましいテキスト形式です。さらに、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 NetIDのSCTPを介してNFSに割り当てられています。
[1] Srinivasan, R., "Binding Protocols for ONC RPC Version 2", RFC 1833, August 1995.
[1] Srinivasan、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[3] Hinden、R。and S. Deering、「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年5月。
[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.、Callaghan、B.、Robinson、D.、Thurlow、R.、Beame、C.、Eisler、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. Callaghan、「リモートプロシージャコールのリモートダイレクトメモリアクセストランスポート」、RFC 5666、2010年1月。
[7] Stewart, R., Ed., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[7] Stewart、R.、ed。、「Stream Control Transmission Protocol」、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] Postel、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] American Telephone and Telegraph Company、「UNIX System V、リリース4プログラマーズガイド：ネットワーキングインターフェイス、ISBN 0139470786」、1990。
[11] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[11] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[12] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[12] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[13] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[13] Postel、J。、「トランスミッションコントロールプロトコル」、STD 7、RFC 793、1981年9月。
[14] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[14] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
Lisa Dusseault, Lars Eggert, Pasi Eronen, Tim Polk, Juergen Schoenwaelder, and Robert Sparks reviewed the document and gave valuable feedback.
Lisa Dusseault、Lars Eggert、Pasi Eronen、Tim Polk、Juergen Schoenwaelder、およびRobert Sparksがこの文書をレビューし、貴重なフィードバックを与えました。
Author's Address
著者の連絡先
Mike Eisler NetApp 5765 Chase Point Circle Colorado Springs, CO 80919 US
Mike Eisler NetApp 5765チェイスポイントサークルコロラドスプリングス、CO 80919 US
Phone: +1-719-599-9026
EMail: mike@eisler.com