Internet Engineering Task Force (IETF) R. Taylor
Request for Comments: 9758 Aalyria Technologies
Updates: 6260, 7116, 9171 E. Birrane, III
Category: Standards Track JHU/APL
ISSN: 2070-1721 May 2025
This document updates the specification of the 'ipn' URI scheme previously defined in RFC 6260 and the IANA registries established in RFC 7116. It also updates the rules for the encoding and decoding of these URIs when used as an Endpoint Identifier (EID) in the Bundle Protocol version 7 (BPv7) as defined in RFC 9171. These updates clarify the structure and behavior of the 'ipn' URI scheme, define new encodings of 'ipn' scheme URIs, and establish the registries necessary to manage this scheme.
このドキュメントは、RFC 6260で以前に定義されていた「IPN」URIスキームとRFC 7116で確立されたIANAレジストリの仕様を更新します。また、バンドルプロトコルバージョン7（BPV7）でRFC 9171のbehaftion fent a frustments a struction strants a struction sturtationのエンドポイント識別子（eid）として使用された場合、これらのURIのエンコードとデコードのルールも更新します。URIスキーム、「IPN」スキームURIの新しいエンコーディングを定義し、このスキームを管理するために必要なレジストリを確立します。
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 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9758.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9758で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Definitions
3. Core Concepts
3.1. The Null ipn URI
3.2. Allocator Identifiers
3.2.1. Allocator Identifier Ranges
3.2.2. The Default Allocator
3.3. Node Numbers
3.3.1. Fully Qualified Node Numbers
3.4. Special Node Numbers
3.4.1. The Zero Node Number
3.4.2. LocalNode ipn URIs
3.4.3. Private Use Node Numbers
3.5. Service Numbers
4. Textual Representation of ipn URIs
4.1. 'ipn' URI Scheme Text Syntax
5. Usage of ipn URIs with BPv7
5.1. Uniqueness Constraints
5.2. The Null Endpoint
5.3. BPv7 Node ID
5.4. LocalNode ipn EIDs
5.5. Private Use ipn EIDs
5.6. Well-Known Service Numbers
5.7. Administrative Endpoints
6. CBOR Representation of ipn URIs with BPv7
6.1. ipn EID CBOR Encoding
6.1.1. Two-Element Scheme-Specific Encoding
6.1.2. Three-Element Scheme-Specific Encoding
6.2. ipn EID CBOR Decoding
6.3. 'ipn' URI Scheme CBOR Syntax
6.4. ipn EID Matching
7. Special Considerations
7.1. Scheme Compatibility
7.2. CBOR Representation Interoperability
7.3. Text Representation Compatibility
7.4. Bundle Protocol Version 6 Compatibility
7.5. Late Binding
8. Security Considerations
8.1. Reliability and Consistency
8.2. Malicious Construction
8.3. Back-End Transcoding
8.4. Local and Private Use ipn EIDs
8.5. Sensitive Information
8.6. Semantic Attacks
9. IANA Considerations
9.1. 'ipn' Scheme URI Allocator Identifiers Registry
9.1.1. Guidance for Designated Experts
9.2. 'ipn' Scheme URI Default Allocator Node Numbers Registry
9.3. 'ipn' Scheme URI Well-Known Service Numbers for BPv7
Registry
9.3.1. Guidance for Designated Experts
10. References
10.1. Normative References
10.2. Informative References
Appendix A. 'ipn' URI Scheme Text Representation Examples
A.1. Using the Default Allocator
A.2. Using a Non-Default Allocator
A.3. The Null ipn URI
A.4. The LocalNode ipn URI
Appendix B. 'ipn' URI Scheme CBOR Encoding Examples
B.1. Using the Default Allocator
B.2. Using a Non-Default Allocator
B.3. The Null Endpoint
Acknowledgments
Authors' Addresses
The 'ipn' URI scheme was originally defined in [RFC6260] and [RFC7116] as a way to identify network nodes and node services using concisely encoded integers that can be processed faster and with fewer resources than other verbose identifier schemes. The scheme was designed for use with the experimental Bundle Protocol version 6 (BPv6) [RFC5050], and "IPN" was defined as an acronym for the term "InterPlanetary Network" in reference to its intended use for deep-space networking. Since then, the efficiency benefits of integer identifiers make 'ipn' scheme URIs useful for any network operating with limited power, bandwidth, and/or compute budget. Therefore, the term "IPN" is now used as a non-acronymous name.
「IPN」URIスキームは、もともと[RFC6260]および[RFC7116]で定義されており、他の動詞識別子スキームよりも迅速かつより少ないリソースで処理できる暗同一のエンコードされた整数を使用して、ネットワークノードとノードサービスを識別する方法として定義されていました。このスキームは、実験バンドルプロトコルバージョン6（BPV6）[RFC5050]で使用するために設計され、「IPN」は、ディープスペースネットワークの使用を目的とした「惑星界ネットワーク」という用語の頭字語として定義されました。それ以来、整数識別子の効率的な利点により、「IPN」スキームは、限られた電力、帯域幅、および/または計算予算で動作するネットワークに役立ちます。したがって、「IPN」という用語は、非記名名として使用されています。
Similar to the experimental BPv6, the standardized Bundle Protocol version 7 (BPv7) [RFC9171] codifies support for the use of the 'ipn' URI scheme for the specification of bundle Endpoint Identifiers (EIDs). The publication of BPv7 has resulted in operational deployments of BPv7 nodes for both terrestrial and non-terrestrial use cases. This includes BPv7 networks operating over the terrestrial Internet and BPv7 networks operating in self-contained environments behind a shared administrative domain. The growth in the number and scale of deployments of BPv7 has been accompanied by a growth in the usage of the 'ipn' URI scheme, which has highlighted areas to improve the structure, moderation, and management of this scheme.
実験BPV6と同様に、標準化されたバンドルプロトコルバージョン7（BPV7）[RFC9171]は、バンドルエンドポイント識別子（EIDS）の仕様のために「IPN」URIスキームの使用をサポートします。BPV7の公開により、地上および非地球の両方のユースケースのBPV7ノードの運用展開が行われました。これには、地上インターネットで動作するBPV7ネットワークと、共有管理ドメインの背後にある自己完結型環境で動作するBPV7ネットワークが含まれます。BPV7の展開数と規模の増加には、「IPN」URIスキームの使用の成長が伴い、このスキームの構造、緩和、および管理を改善する領域を強調しています。
By updating [RFC7116] and [RFC9171], this document updates the specification of the 'ipn' URI scheme in a backwards-compatible way, in order to provide needed improvements both in the scheme itself and in its usage to specify EIDs with BPv7. Specifically, this document:
[RFC7116]と[RFC9171]を更新することにより、このドキュメントは、スキーム自体とBPV7でEIDを指定するための使用の両方で必要な改善を提供するために、「IPN」URIスキームの仕様を後方互換的な方法で更新します。具体的には、このドキュメント：
* introduces a hierarchical structure for the assignment of 'ipn' scheme URIs,
* 「IPN」スキームの割り当てのための階層構造を導入します。
* clarifies the behavior and interpretation of 'ipn' scheme URIs,
* 「IPN」スキームの行動と解釈を明確にします。
* defines efficient encodings of 'ipn' scheme URIs, and
* 「IPN」スキームのurisの効率的なエンコーディングを定義します
* updates/defines the registries associated with this scheme.
* このスキームに関連付けられたレジストリを更新/定義します。
Although originally developed by the deep-space community for use with the Bundle Protocol, the 'ipn' URI scheme is sufficiently generic to be used in other environments where a concise unique representation of a resource on a particular node is required.
もともとディープスペースコミュニティがバンドルプロトコルで使用するために開発されましたが、「IPN」URIスキームは、特定のノード上のリソースの簡潔な一意の表現が必要な他の環境で使用するのに十分に一般的です。
It is important to remember that, like most other URI schemes, the 'ipn' URI scheme defines a unique identifier of a resource, and it does not include any topological information describing how to route messages to that resource.
他のほとんどのURIスキームと同様に、「IPN」URIスキームはリソースの一意の識別子を定義し、そのリソースにメッセージをルーティングする方法を説明するトポロジ情報は含まれていないことを覚えておくことが重要です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。
For the remainder of this document, the term "ipn URI" is used to refer to a URI that uses the 'ipn' URI scheme.
このドキュメントの残りの部分では、「IPN URI」という用語は、「IPN」URIスキームを使用するURIを参照するために使用されます。
Every ipn URI, no matter whether it is expressed with a textual representation or a binary encoding, MUST be considered as a tuple of the following three components:
すべてのIPN URIは、テキスト表現で表現されていても、バイナリエンコードで表現されていても、次の3つのコンポーネントのタプルと見なす必要があります。
* The Allocator Identifier
* アロケーター識別子
* The Node Number
* ノード番号
* The Service Number
* サービス番号
The Allocator Identifier indicates the entity responsible for assigning Node Numbers to individual resource nodes, maintaining uniqueness whilst avoiding the need for a single registry for all assigned Node Numbers. See Section 3.2.
Allocator識別子は、個々のリソースノードにノード番号を割り当てる責任のあるエンティティを示し、割り当てられたすべてのノード番号の単一レジストリの必要性を回避しながら一意性を維持します。セクション3.2を参照してください。
The Node Number is a shared identifier assigned to all ipn URIs for resources co-located on a single node. See Section 3.3.
ノード番号は、単一のノードと共同住宅されたリソースのために、すべてのIPN URIに割り当てられた共有識別子です。セクション3.3を参照してください。
The Service Number is an identifier to distinguish between resources on a given node. See Section 3.5.
サービス番号は、特定のノード上のリソースを区別する識別子です。セクション3.5を参照してください。
The combination of these three components guarantees that every correctly constructed ipn URI uniquely identifies a single resource. Additionally, the combination of the Allocator Identifier and the Node Number provides a mechanism to uniquely identify the node on which a particular resource is expected to exist. See Section 3.3.1.
これら3つのコンポーネントの組み合わせにより、正しく構築されたすべてのIPN URIが単一のリソースを一意に識別することが保証されます。さらに、アロケーター識別子とノード番号の組み合わせは、特定のリソースが存在すると予想されるノードを一意に識別するメカニズムを提供します。セクション3.3.1を参照してください。
It has been found that there is value in defining a unique Null ipn URI to indicate "nowhere". This ipn URI is termed the "Null ipn URI" and has all three components (the Allocator Identifier, Node Number, and Service Number) set to the value zero (0). No resource identified by the Null ipn URI exists, and any destination identified by such a resource is therefore by definition unreachable.
「どこにも」を示すために、一意のnull ipn uriを定義することには価値があることがわかっています。このIPN URIは「Null IPN URI」と呼ばれ、3つのコンポーネント（アロケーター識別子、ノード番号、およびサービス番号）すべてが値ゼロ（0）に設定されています。NULL IPN URIによって識別されるリソースは存在しません。したがって、そのようなリソースによって識別される宛先は、定義により到達不能です。
An Allocator is any organization that wishes to assign Node Numbers for use with the 'ipn' URI scheme and has the facilities and governance to manage a public registry of assigned Node Numbers. The authorization to assign these numbers is provided through the assignment of an Allocator Identifier by IANA. Regardless of other attributes of an Allocator (such as a name, point of contact, or other identifying information), Allocators are identified by Allocator Identifiers: unique, unsigned integers in the range 0 to 2^(32-1).
Allocatorは、「IPN」URIスキームで使用するためにノード番号を割り当てたいと希望する任意の組織であり、割り当てられたノード番号のパブリックレジストリを管理するための機能とガバナンスを備えています。これらの番号を割り当てる許可は、IANAによるAllocator Identifierの割り当てを通じて提供されます。アロケーターの他の属性（名前、連絡先、またはその他の識別情報など）に関係なく、アロケーターはアロケーター識別子によって識別されます。
The Allocator Identifier MUST be the sole mechanism used to identify the Allocator that has assigned the Node Number in an ipn URI. An Allocator may have multiple assigned Allocator Identifiers, but a given Allocator Identifier MUST only be associated with a single Allocator.
アロケーター識別子は、IPN URIにノード番号を割り当てたアロケーターを識別するために使用される唯一のメカニズムでなければなりません。アロケーターには複数の割り当てられたアロケーター識別子がある場合がありますが、特定のアロケーター識別子は単一のアロケーターにのみ関連付けられる必要があります。
A new IANA registry, "'ipn' Scheme URI Allocator Identifiers", is defined for the registration of Allocator Identifiers; see Section 9.1. Although the uniqueness of Allocator Identifiers is required to enforce the uniqueness of ipn URIs, some identifiers are explicitly reserved for experimentation or future use.
新しいIANAレジストリ「「IPN」スキームURI Allocator Identifiers」は、アロケーター識別子の登録に対して定義されています。セクション9.1を参照してください。IPN URIの独自性を実施するには、アロケーター識別子の一意性が必要ですが、一部の識別子は実験または将来の使用のために明示的に予約されています。
Each Allocator assigns Node Numbers according to its own policies, without risk of creating an identical ipn URI, as permitted by the rules in Section 3.3. Other than ensuring that any Node Numbers it allocates are unique amongst all Node Numbers it assigns, an Allocator does not need to coordinate its allocations with other Allocators.
各アロケーターは、セクション3.3のルールで許可されているように、同一のIPN URIを作成するリスクなしに、独自のポリシーに従ってノード番号を割り当てます。割り当てられるノード番号が割り当てられるすべてのノード番号の中で一意であることを確認する以外に、アロケーターは他のアロケーターと割り当てを調整する必要はありません。
If a system does not require interoperable deployment of 'ipn' scheme URIs, then the Private Use Node Numbers range (Section 3.4.3), reserved by the Default Allocator (Section 3.2.2) for this purpose, is to be used.
システムが「IPN」スキームURIの相互運用可能な展開を必要としない場合、この目的のためにデフォルトのアロケーター（セクション3.2.2）によって予約されたプライベート使用ノード番号範囲（セクション3.4.3）が使用されます。
Some organizations with internal hierarchies may wish to delegate the allocation of Node Numbers to one or more of their sub-organizations. Rather than assigning unique Allocator Identifiers to each sub-organization on a first-come, first-served basis, there are operational benefits in assigning Allocator Identifiers to such an organization in a structured way. This allows an external observer to detect that a group of Allocator Identifiers is organizationally associated.
内部階層を持つ一部の組織では、ノード番号の割り当てを1つ以上のサブ組織に委任したい場合があります。先着順で各サブ組織に一意のアロケーター識別子を割り当てるのではなく、構造化された方法でそのような組織にアロケーター識別子を割り当てる際には、運用上の利点があります。これにより、外部オブザーバーは、アロケーター識別子のグループが組織的に関連付けられていることを検出できます。
An Allocator Identifier range is a set of consecutive Allocator Identifiers associated with the same Allocator. Each individual Allocator Identifier in a given range SHOULD be assigned to a distinct sub-organization of the Allocator. Assigning identifiers in this way allows external observers to both associate individual Allocator Identifiers with a single organization and usefully differentiate amongst sub-organizations.
アロケーター識別子範囲は、同じアロケーターに関連付けられた連続したアロケーター識別子のセットです。特定の範囲の各アロケーター識別子は、アロケーターの明確なサブ組織化に割り当てる必要があります。この方法で識別子を割り当てることで、外部のオブザーバーは、個々のアロケーター識別子を単一の組織に関連付け、サブ組織間で有効に区別することができます。
The practice of associating a consecutive range of numbers with a single organization is inspired by the Classless Inter-Domain Routing (CIDR) assignment of Internet addresses described in [RFC4632]. In that assignment scheme, an organization (such as an Internet Service Provider (ISP)) is assigned a network prefix such that all addresses sharing that same prefix are considered to be associated with that organization.
連続範囲の数字を単一の組織に関連付ける慣行は、[RFC4632]に記載されているインターネットアドレスのクラスレスドメイン間ルーティング（CIDR）割り当てに触発されています。その割り当てスキームでは、組織（インターネットサービスプロバイダー（ISP）など）にネットワークプレフィックスが割り当てられ、すべてのアドレスが同じプレフィックスがその組織に関連付けられていると見なされると考えられます。
Each Allocator Identifier range is identified by the first Allocator Identifier in the range and the number of consecutive identifiers in the range.
各アロケーター識別子範囲は、範囲内の最初のアロケーター識別子と範囲内の連続識別子の数によって識別されます。
Allocator Identifier ranges differ from CIDR addresses in two important ways:
アロケーター識別子の範囲は、2つの重要な方法でCIDRアドレスとは異なります。
1. Allocator Identifiers are used to identify organizations and are not, themselves, addresses.
1. アロケーター識別子は、組織を識別するために使用され、それ自体ではありません。
2. Allocator Identifiers may be less than 32 bits in length.
2. アロケーター識別子の長さは32ビット未満の場合があります。
In order to differentiate between Allocator Identifier ranges using efficient bitwise operations, all ranges MUST be of a size S that is a power of 2, and for a given range of length N bits, with S = 2^N, the least-significant N bits of the first Allocator Identifier MUST be all 0.
効率的なビットワイズ操作を使用してアロケーター識別子範囲を区別するために、すべての範囲は2のパワーであるサイズsでなければならず、特定の長さnビットの範囲で、s = 2^nで、最初のアロケーター識別子の最も重要なnビットはすべて0でなければなりません。
An example of the use of Allocator Identifier ranges for four organizations (A, B, C, and D) is as follows:
4つの組織（a、b、c、d）のアロケーター識別子範囲の使用の例は次のとおりです。
+==============+=============+=============+=====================+
| Organization | Range (dec) | Range (hex) | Range Length (Bits) |
+==============+=============+=============+=====================+
| Org A | 974848 .. | 0xEE000 .. | 7 bits |
| | 974975 | 0xEE07F | |
+--------------+-------------+-------------+---------------------+
| Org B | 974976 .. | 0xEE080 .. | 4 bits |
| | 974991 | 0xEE08F | |
+--------------+-------------+-------------+---------------------+
| Org C | 974992 .. | 0xEE090 .. | 1 bit |
| | 974993 | 0xEE091 | |
+--------------+-------------+-------------+---------------------+
| Org D | 974994 | 0xEE092 | 0 bits |
+--------------+-------------+-------------+---------------------+
Table 1: Allocator Identifier Range Assignment Example
表1：アロケーター識別子範囲の割り当ての例
With these assignments, any Allocator Identifier whose most-significant 25 bits match 0xEE000 belong to organization A. Similarly, any Allocator Identifier whose most-significant 28 bits match 0xEE080 belong to organization B, and any Allocator Identifier whose most-significant 31 bits are 0xEE090 belong to organization C. Organization D has a single Allocator Identifier, and hence a range of bit-length 0.
これらの割り当てでは、最も重要な25ビットが0xee000に一致するアロケーター識別子は、組織Aに属します。同様に、最も重要な28ビットが組織Bに属するアロケーター識別子、および最も重要な31ビットが0xee090が組織に属するアロケーター識別子を属するアロケーター識別子は、単一のアロケーターIDの範囲を持っています。
As of the publication of [RFC7116], the only organization permitted to assign Node Numbers was the Internet Assigned Numbers Authority (IANA), which assigned Node Numbers via the "CBHE Node Numbers" registry. This means that all ipn URIs created prior to the addition of Allocator Identifiers are assumed to have Node Number allocations that comply with the "CBHE Node Numbers" registry.
[RFC7116]の公開時点で、ノード番号を割り当てることを許可された唯一の組織は、「CBHEノード番号」レジストリを介してノード番号を割り当てたインターネット割り当て番号authority（IANA）でした。これは、アロケーター識別子を追加する前に作成されたすべてのIPN URIが、「CBHEノード番号」レジストリに準拠するノード番号割り当てがあると想定されることを意味します。
The presumption that Node Numbers are allocated by IANA from a specific registry, unless otherwise specified, is formalized in this update to the 'ipn' URI scheme by designating IANA as the Default Allocator and by assigning the Allocator Identifier zero (0) in the "'ipn' Scheme URI Allocator Identifiers" registry (Section 9.1) to the Default Allocator. In any case where an encoded ipn URI does not explicitly include an Allocator Identifier, an implementation MUST assume that the Node Number has been allocated by the Default Allocator.
特定のレジストリからIANAによってノード番号がIANAによって割り当てられているという推定は、特に指定されていない限り、このアップデートでは、IANAをデフォルトのアロケーターとして指定し、「「IPN」スキームURIアロケーター識別子（セクション9.1）にアロケーター識別子ゼロ（0）をデフォルトのアロケーターに割り当てることにより、「IPN」URIスキームの形式化されています。エンコードされたIPN URIにアロケーター識別子が明示的に含まれていない場合、実装は、デフォルトのアロケーターによってノード番号が割り当てられていると仮定する必要があります。
A new IANA registry, "'ipn' Scheme URI Default Allocator Node Numbers", is defined to control the allocation of Node Number values by the Default Allocator. This new registry inherits behaviors and existing assignments from the "CBHE Node Numbers" registry, and it reserves some other values as defined in Section 3.4 below.
新しいIANAレジストリ「「IPN」スキームURIデフォルトアロケーターノード番号」は、デフォルトのアロケーターによるノード番号値の割り当てを制御するために定義されます。この新しいレジストリは、「CBHEノード番号」レジストリからの動作と既存の割り当てを継承し、以下のセクション3.4で定義されている他の値を留保します。
A Node Number identifies a node that hosts a resource in the context of an Allocator. A Node Number is an unsigned integer. A single Node Number assigned by a single Allocator MUST refer to a single node.
ノード番号は、アロケーターのコンテキストでリソースをホストするノードを識別します。ノード番号は署名されていない整数です。単一のアロケーターによって割り当てられた単一のノード番号は、単一のノードを参照する必要があります。
All Node Number assignments, by all Allocators, MUST be in the range 0 to 2^(32-1).
すべてのアロケーターによるすべてのノード番号割り当ては、0〜2^（32-1）の範囲にある必要があります。
It is RECOMMENDED that Node Number zero (0) not be assigned by an Allocator to avoid confusion with the Null ipn URI (Section 3.1).
NULL IPN URI（セクション3.1）との混乱を避けるために、ノード番号ゼロ（0）をアロケーターによって割り当てられないことをお勧めします。
One of the advantages of ipn URIs is the ability to easily split the identity of a particular service from the node upon which the service exists. For example, a message received from one particular ipn URI may require a response to be sent to a different service on the same node that sent the original message. Historically, the identifier of the sending node has been colloquially referred to as the "node number" or "node identifier".
IPN URISの利点の1つは、特定のサービスのIDをサービスが存在するノードから簡単に分割できることです。たとえば、1つの特定のIPN URIから受信したメッセージでは、元のメッセージを送信した同じノード上の別のサービスに応答を送信する必要があります。歴史的に、送信ノードの識別子は、「ノード番号」または「ノード識別子」と口語的に呼ばれてきました。
To avoid future confusion, when referring to the identifier of a particular node, the term "Fully Qualified Node Number" (FQNN) MUST be used to refer to the combination of the Node Number component and Allocator Identifier component of an ipn URI that uniquely identifies a particular node. In other words, an FQNN is the unique identifier of a particular node that supports services identified by ipn URIs.
将来の混乱を避けるために、特定のノードの識別子を参照する場合、「完全に適格なノード番号」（FQNN）という用語を使用して、特定のノードを一意に識別するIPN URIのノード番号コンポーネントとアロケーター識別子コンポーネントの組み合わせを参照する必要があります。言い換えれば、FQNNは、IPN URIによって識別されたサービスをサポートする特定のノードの一意の識別子です。
In the examples in this document, FQNNs are written as (Allocator Identifier, Node Number). For example, (977000,100) is the FQNN for a node assigned Node Number 100 by an Allocator with Allocator Identifier 977000.
このドキュメントの例では、FQNNSは（Allocator Identifier、ノード番号）として記述されています。たとえば、（977000,100）は、アロケーター識別子977000を備えたアロケーターによって、ノード番号100を割り当てられたノードのFQNNです。
Some special-case Node Numbers are defined by the Default Allocator; see Section 9.2.
一部の特別ケースノード番号は、デフォルトのアロケーターによって定義されます。セクション9.2を参照してください。
The Default Allocator assigns the use of Node Number zero (0) solely for identifying the Null ipn URI (Section 3.1).
デフォルトのアロケーターは、NULL IPN URI（セクション3.1）を識別するためにのみ、ノード番号ゼロ（0）の使用を割り当てます。
This means that any ipn URI with a zero (0) Allocator Identifier and a zero (0) Node Number, but a non-zero Service Number component, is invalid. Such ipn URIs MUST NOT be composed, and processors of such ipn URIs MUST consider them as the Null ipn URI.
これは、ゼロ（0）アロケーター識別子とゼロ（0）ノード番号を持つIPN URIが、非ゼロサービス番号コンポーネントが無効であることを意味します。このようなIPN URIを構成する必要はなく、そのようなIPN URIのプロセッサをNULL IPN URIと見なす必要があります。
The Default Allocator reserves Node Number 2^(32-1) (0xFFFFFFFFF) to specify resources on the local node, rather than on any specific individual node.
デフォルトのアロケーターは、ノード番号2^（32-1）（0xffffffffff）を埋めて、特定の個々のノードではなくローカルノードにリソースを指定します。
This means that any ipn URI with a zero (0) Allocator Identifier and a Node Number of 2^(32-1) refers to a service on the local bundle node. This form of ipn URI is termed a "LocalNode ipn URI".
これは、ゼロ（0）アロケーター識別子と2^（32-1）のノード番号を持つIPN URIは、ローカルバンドルノードのサービスを指すことを意味します。この形式のIPN URIは、「LocalNode IPN URI」と呼ばれます。
The Default Allocator provides a range of Node Numbers that are reserved for Private Use, as defined in [RFC8126].
デフォルトのアロケーターは、[RFC8126]で定義されているように、プライベート使用のために予約されている一連のノード番号を提供します。
Any ipn URI with a zero (0) Allocator Identifier and a Node Number reserved for Private Use is not guaranteed to be unique beyond a single administrative domain. An administrative domain, as used here, is defined as the set of nodes that share a unique allocation of FQNNs from the Private Use range. These FQNNs can be considered to be functionally similar to private address space IPv4 addresses, as defined in [RFC1918].
ゼロ（0）アロケーター識別子とプライベート使用のために予約されているノード番号を持つIPN URIは、単一の管理ドメインを超えて一意であることは保証されていません。ここで使用される管理ドメインは、プライベート使用範囲からのFQNNの一意の割り当てを共有するノードのセットとして定義されます。これらのFQNNは、[RFC1918]で定義されているように、プライベートアドレススペースIPv4アドレスと機能的に類似していると見なすことができます。
Because of this lack of uniqueness, any implementation of a protocol using ipn URIs that resides on the border between administrative domains MUST have suitable mechanisms in place to prevent protocol units using such Private Use Node Numbers to cross between different administrative domains.
この一意性の欠如のため、管理ドメイン間の境界にあるIPN URIを使用したプロトコルの実装は、そのようなプライベート使用ノード番号を使用して異なる管理ドメイン間を越えてプロトコルユニットを防ぐために適切なメカニズムを整える必要があります。
A Service Number is an unsigned integer that identifies a particular service operating on a node. A service in this case is some logical function that requires its own resource identifier to distinguish it from other functions operating on the same node.
サービス番号は、ノードで動作する特定のサービスを識別する署名のない整数です。この場合のサービスは、同じノードで動作する他の関数と区別するために独自のリソース識別子を必要とするいくつかの論理関数です。
All 'ipn' scheme URIs comply with [RFC3986] and are therefore represented by a scheme identifier and a scheme-specific part. The scheme identifier is ipn, and the scheme-specific parts are represented as a sequence of numeric components separated with the '.' character. A formal definition is provided below (see Section 4.1) and can be informally considered as:
すべての「IPN」スキームは、urisが[RFC3986]に準拠しているため、スキーム識別子とスキーム固有の部分で表されます。スキーム識別子はIPNであり、スキーム固有の部分は、「。」で区切られた数値成分のシーケンスとして表されます。キャラクター。正式な定義を以下に示します（セクション4.1を参照）。
ipn:[<allocator-identifier>.]<node-number>.<service-number>
To keep the text representation concise, the following rules apply:
テキスト表現を簡潔に保つために、次のルールが適用されます。
1. All leading '0' characters MUST be omitted. A single '0' is valid.
1. すべての主要な「0」文字を省略する必要があります。単一の「0」が有効です。
2. If the Allocator Identifier is zero (0), then the <allocator-identifier> and '.' MAY be omitted.
2. アロケーター識別子がゼロ（0）の場合、<allocator-identifier> and '。'省略される場合があります。
3. If the Allocator Identifier is zero (0), and the Node Number is 2^(32-1) (i.e., the URI is a LocalNode ipn URI (Section 3.4.2)), then the character '!' SHOULD be used instead of the digits 4294967295, although both forms are valid encodings.
3. アロケーター識別子がゼロ（0）で、ノード番号が2^（32-1）の場合（つまり、URIがlocalNode IPN URI（セクション3.4.2））、文字「！」両方のフォームは有効なエンコーディングですが、数字4294967295の代わりに使用する必要があります。
Examples of the textual representation of ipn URIs can be found in Appendix A.
IPN URIのテキスト表現の例は、付録Aにあります。
The text syntax of an ipn URI MUST comply with the following ABNF syntax from [RFC5234] and repeats the core ABNF syntax rule for DIGIT defined by that specification:
IPN URIのテキスト構文は、[RFC5234]の次のABNF構文に準拠する必要があり、その仕様で定義された桁のコアABNF構文ルールを繰り返します。
ipn-uri = "ipn:" ipn-hier-part
ipn-hier-part = fqnn "." service-number
fqnn = "!" / allocator-part
allocator-part = [allocator-identifier "."] node-number
allocator-identifier = number
node-number = number
service-number = number
number = "0" / non-zero-number
non-zero-number = (%x31-39 *DIGIT)
DIGIT = %x30-39
From the earliest days of experimentation with the Bundle Protocol, there has been a need to identify the source and destination of a bundle. The IRTF BPv6 experimental specification [RFC5050] termed the logical source or destination of a bundle as an "Endpoint" identified by an "Endpoint Identifier" (EID). BPv6 EIDs are formatted as URIs. This definition and representation of EIDs was carried forward from the IRTF BPv6 specification [RFC5050] to the IETF BPv7 specification [RFC9171]. [RFC9171] additionally defined an IANA registry called the "Bundle Protocol URI Scheme Types" registry, which identifies those URI schemes that might be used to represent EIDs. The 'ipn' URI scheme is one such URI scheme.
バンドルプロトコルの実験の初期の日から、バンドルのソースと宛先を特定する必要がありました。IRTF BPV6実験仕様[RFC5050]は、バンドルの論理ソースまたは宛先を「エンドポイント識別子」（EID）によって識別される「エンドポイント」と呼びました。BPV6 EIDはURIとしてフォーマットされています。EIDSのこの定義と表現は、IRTF BPV6仕様[RFC5050]からIETF BPV7仕様[RFC9171]に繰り越されました。[RFC9171]は、EIDを表すために使用される可能性のあるURIスキームを識別する「バンドルプロトコルURIスキームタイプ」レジストリと呼ばれるIANAレジストリをさらに定義しました。「IPN」URIスキームは、そのようなURIスキームの1つです。
This section identifies the behavior and interpretation of 'ipn' scheme URIs that MUST be followed when using this URI scheme to represent EIDs in BPv7. An ipn URI used as a BPv7 or BPv6 EID is termed an "ipn EID".
このセクションでは、このURIスキームを使用してBPV7のEIDを表す場合に従わなければならない「IPN」スキームの動作と解釈を特定します。BPV7またはBPV6 EIDとして使用されるIPN URIは、「IPN EID」と呼ばれます。
An ipn EID MUST identify a singleton endpoint. The bundle processing node that is the sole member of that endpoint MUST be the node identified by the FQNN (Section 3.3.1) of the node.
IPN EIDは、Singletonエンドポイントを特定する必要があります。そのエンドポイントの唯一のメンバーであるバンドル処理ノードは、ノードのFQNN（セクション3.3.1）によって識別されるノードでなければなりません。
A single bundle processing node MAY have multiple ipn EIDs associated with it. However, all ipn EIDs that share any single FQNN MUST refer to the same bundle processing node.
単一のバンドル処理ノードには、複数のIPN EIDが関連付けられている場合があります。ただし、単一のFQNNを共有するすべてのIPN EIDは、同じバンドル処理ノードを参照する必要があります。
For example, ipn:977000.100.1, ipn:977000.100.2, and ipn:977000.100.3 MUST all refer to services registered on the bundle processing node identified with FQNN (977000,100). None of these EIDs could be registered on any other bundle processing node.
たとえば、IPN：977000.100.1、IPN：977000.100.2、およびIPN：977000.100.3は、FQNN（977000,100）で識別されたバンドル処理ノードに登録されているサービスを参照する必要があります。これらのEIDは、他のバンドル処理ノードに登録できませんでした。
Section 3.2 of [RFC9171] defines the concept of the Null endpoint, which is an endpoint that has no members and is identified by a special Null EID.
[RFC9171]のセクション3.2は、メンバーがないエンドポイントであり、特別なヌルEIDによって識別されるヌルエンドポイントの概念を定義しています。
Within the 'ipn' URI scheme, the Null EID is represented by the Null ipn URI (Section 3.1). This means that the URIs dtn:none (Section 4.2.5.1.1 of [RFC9171]), ipn:0.0, and ipn:0.0.0 all refer to the BPv7 Null endpoint.
「IPN」URIスキーム内で、null eidはnull ipn uri（セクション3.1）で表されます。これは、URIS DTN：なし（[RFC9171]のセクション4.2.5.1.1）、IPN：0.0、およびIPN：0.0.0がすべてBPV7 NULLエンドポイントを参照していることを意味します。
Section 4.2.5.2 of [RFC9171] introduces the concept of a "Node ID" that has the same format as an EID and uniquely identifies a bundle processing node.
[RFC9171]のセクション4.2.5.2では、EIDと同じ形式を持ち、バンドル処理ノードを一意に識別する「ノードID」の概念を紹介します。
Any ipn EID can serve as a "Node ID" for the bundle processing node identified by its FQNN (Section 3.3.1). That is, any ipn EID of the form ipn:A.B.C may be used as the Source Node ID of any bundle created by the bundle processing node identified by the FQNN (A,B).
すべてのIPN EIDは、FQNN（セクション3.3.1）で識別されたバンドル処理ノードの「ノードID」として機能します。つまり、フォームIPN：A.B.CのIPN EIDは、FQNN（a、b）によって識別されたバンドル処理ノードによって作成されたバンドルのソースノードIDとして使用できます。
When a LocalNode ipn URI (Section 3.4.2) is used as a BPv6 or BPv7 EID, it is termed a "LocalNode ipn EID".
LocalNode IPN URI（セクション3.4.2）がBPV6またはBPV7 EIDとして使用される場合、「LocalNode IPN EID」と呼ばれます。
Because a LocalNode ipn EID only has meaning on the local bundle node, any such EID MUST be considered non-routable. This means that any bundle using a LocalNode ipn EID as a bundle source or bundle destination MUST NOT be allowed to leave the local node. Equally, all externally received bundles featuring LocalNode EIDs as a bundle source or bundle destination MUST be discarded as invalid.
LocalNode IPN EIDはローカルバンドルノードにのみ意味があるため、そのようなEIDは不可能と見なされる必要があります。これは、バンドルソースまたはバンドル宛先としてLocalNode IPN EIDを使用するバンドルがローカルノードを離れることを許可してはならないことを意味します。同様に、Bundleソースまたはバンドル宛先としてLocalNode Eidsを備えたすべての外部から受信されたバンドルは、無効として破棄する必要があります。
LocalNode ipn EIDs MUST NOT be present in any other part of a bundle that is transmitted off of the local node. For example, a LocalNode ipn EID MUST NOT be used as a Bundle Protocol Security (BPSec) [RFC9172] security source for a bundle transmitted from the local bundle node, because such a source EID would have no meaning at a downstream bundle node.
LocalNode IPN EIDは、ローカルノードから送信されるバンドルの他の部分に存在してはなりません。たとえば、LocalNode IPN EIDは、ローカルバンドルノードから送信されたバンドルのバンドルプロトコルセキュリティ（BPSEC）[RFC9172]セキュリティソースとして使用してはなりません。このようなソースEIDはダウンストリームバンドルノードで意味がないためです。
LocalNode ipn EIDs MUST NOT be published in any node identification directory (such as a DNS registration) or presented as part of dynamic peer discovery, as the EID has no valid meaning for other nodes. For example, a LocalNode ipn EID MUST NOT be advertised as the peer Node ID during session negotiation in [RFC9174].
EIDには他のノードに対して有効な意味がないため、LocalNode IPN EIDSをノード識別ディレクトリ（DNS登録など）に公開したり、動的ピアディスカバリーの一部として提示したりする必要はありません。たとえば、[RFC9174]のセッション交渉中に、LocalNode IPN EIDをピアノードIDとして宣伝してはなりません。
Bundles destined for EIDs that use an ipn URI with an FQNN (Section 3.3.1) that is within the Private Use range of the Default Allocator (Section 3.2.2) are not universally unique; therefore, they are only valid within the scope of the current administrative domain. This means that any bundle using a Private Use ipn EID as a bundle source or bundle destination MUST NOT be allowed to cross administrative domains. All implementations that could be deployed as a gateway between administrative domains MUST be sufficiently configurable to ensure that this is enforced, and operators MUST ensure correct configuration.
デフォルトアロケーター（セクション3.2.2）のプライベート使用範囲内にあるFQNN（セクション3.3.1）を持つIPN URIを使用するEIDを対象としたバンドルは、普遍的に一意ではありません。したがって、それらは現在の管理ドメインの範囲内でのみ有効です。つまり、プライベート使用IPN EIDをバンドルソースまたはバンドル宛先として使用するバンドルは、管理ドメインを横断することを許可してはなりません。管理ドメイン間のゲートウェイとして展開できるすべての実装は、これが強制されることを確認するために十分に構成可能でなければならず、オペレーターは正しい構成を確認する必要があります。
Private Use ipn EIDs MUST NOT be present in any other part of a bundle that is destined for another administrative domain when the lack of uniqueness prevents correct operation. For example, a Private Use ipn EID MUST NOT be used as a BPSec [RFC9172] security source for a bundle when the bundle is destined for a different administrative domain.
私的使用IPN EIDは、一意性がないと正しい操作を防ぐ場合、別の管理ドメインに運命づけられているバンドルの他の部分に存在してはなりません。たとえば、プライベート使用IPN EIDは、バンドルが異なる管理ドメインに運命づけられている場合、バンドルのBPSEC [RFC9172]セキュリティソースとして使用してはなりません。
It is convenient for BPv7 services that have a public specification and wide adoption to be identified by a pre-agreed default Service Number, so that unless overridden by explicit configuration, such services can be sensibly assumed to be operating on the well-known Service Number on a particular node.
公開仕様と幅広い採用を備えたBPV7サービスは、事前にアグリーのデフォルトサービス番号によって識別されるために便利です。そのため、明示的な構成によってオーバーライドされない限り、そのようなサービスは特定のノードの有名なサービス番号で操作されていると想定できます。
If a different service uses the number, or the service uses a different number, BPv7 will continue to operate, but some configuration may be required to make the individual service operational.
別のサービスが数値を使用する場合、またはサービスが異なる数値を使用する場合、BPV7は引き続き動作しますが、個々のサービスを動作させるためにある程度の構成が必要になる場合があります。
A new IANA registry, "'ipn' Scheme URI Well-Known Service Numbers for BPv7", is defined for the registration of well-known BPv7 Service Numbers; see Section 9.3. This registry records the assignments of Service Numbers for well-known services and also explicitly reserves ranges for both experimentation and Private Use.
新しいIANAレジストリ「 'IPN' Scheme uri著名なサービス番号のbpv7」は、有名なBPV7サービス番号の登録に対して定義されています。セクション9.3を参照してください。このレジストリは、有名なサービスのサービス番号の割り当てを記録し、実験と私的使用の両方の範囲を明示的に留保します。
The service identified by a Service Number of zero (0) MUST be interpreted as the Administrative Endpoint of the node, as defined in Section 3.2 of [RFC9171].
[RFC9171]のセクション3.2で定義されているように、ゼロ（0）のサービス番号（0）によって識別されるサービスは、ノードの管理エンドポイントとして解釈する必要があります。
Non-zero Service Numbers MUST NOT be used to identify the Administrative Endpoint of a bundle node in an ipn EID.
ゼロ以外のサービス番号を使用して、IPN EIDのバンドルノードの管理エンドポイントを識別してはなりません。
Section 4.2.5.1 of [RFC9171] requires that any URI scheme used to represent BPv7 EIDs MUST define how the scheme-specific part of the URI scheme is encoded with Concise Binary Object Representation (CBOR) [RFC8949]. To meet this requirement, this section describes the CBOR encoding and decoding approach for ipn EIDs. The formal definition of the CBOR representation is specified; see Section 6.3.
[RFC9171]のセクション4.2.5.1では、BPV7 EIDを表すために使用されるURIスキームは、URIスキームのスキーム固有の部分が簡潔なバイナリオブジェクト表現（CBOR）[RFC8949]でエンコードされる方法を定義する必要があることを要求しています。この要件を満たすために、このセクションでは、IPN EidsのCBORエンコードおよびデコードアプローチについて説明します。CBOR表現の正式な定義が指定されています。セクション6.3を参照してください。
Generic URI approaches to encoding ipn EIDs are unlikely to be efficient because they do not consider the underlying structure of the 'ipn' URI scheme. Since the creation of the 'ipn' URI scheme was motivated by the need for concise identification and rapid processing, the encoding of ipn EIDs maintains these properties.
IPN EIDをエンコードするための一般的なURIアプローチは、「IPN」URIスキームの根本構造を考慮していないため、効率的ではありません。「IPN」URIスキームの作成は、簡潔な識別と迅速な処理の必要性によって動機付けられていたため、IPN EIDのエンコードはこれらの特性を維持しています。
Fundamentally, ipn EIDs from [RFC9171] are represented as a sequence of identifiers. In the text syntax, the numbers are separated with the '.' delimiter; in CBOR, this ordered series of numbers can be represented by an array. Therefore, when encoding ipn EIDs for use with BPv7, the scheme-specific part of an ipn URI MUST be represented as a CBOR array of either two (2) or three (3) elements. Each element of the array MUST be encoded as a single CBOR unsigned integer.
基本的に、[RFC9171]のIPN EIDは、識別子のシーケンスとして表されます。テキストの構文では、数値は「。」で区切られています。デリミタ;CBORでは、この順序付けられた一連の数値は、配列で表すことができます。したがって、BPV7で使用するためにIPN EIDをエンコードする場合、IPN URIのスキーム固有の部分は、2つまたは3つの要素のいずれかのCBORアレイとして表現する必要があります。配列の各要素は、単一のCbor unsigned Integerとしてエンコードする必要があります。
The structure and mechanisms of the two-element and three-element encodings are described below, and examples of the different encodings are provided in Appendix B.
2つの要素と3つの要素のエンコーディングの構造とメカニズムを以下に説明し、異なるエンコーディングの例を付録Bに示します。
In the two-element scheme-specific encoding of an ipn EID, the first element of the array is an encoding of the FQNN (Section 3.3.1), and the second element of the array is the ipn EID Service Number.
IPN EIDの2つの要素スキーム固有のエンコードでは、配列の最初の要素はFQNNのエンコード（セクション3.3.1）であり、アレイの2番目の要素はIPN EIDサービス番号です。
The FQNN encoding MUST be a 64-bit unsigned integer constructed in the following way:
FQNNエンコーディングは、次の方法で構築された64ビットの署名されていない整数でなければなりません。
1. The least significant 32 bits MUST represent the Node Number associated with the ipn EID.
1. 最も重要な32ビットは、IPN EIDに関連付けられたノード数を表す必要があります。
2. The most significant 32 bits MUST represent the Allocator Identifier associated with the ipn EID.
2. 最も重要な32ビットは、IPN EIDに関連付けられたアロケーター識別子を表す必要があります。
For example, the ipn EID of ipn:977000.100.1 has an FQNN of (977000,100), which would be encoded as 0xEE868_00000064. The resulting two-element array [0xEE868_00000064, 0x01] would be encoded in CBOR as the following 11-octet sequence:
たとえば、IPN：977000.100.1のIPN EIDには（977000,100）のFQNNがあり、0xee868_00000064としてエンコードされます。結果の2つの要素アレイ[0xee868_00000064、0x01]は、次の11オクテットシーケンスとしてCBORでエンコードされます。
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 ('ipn' URI scheme)
82 # 2-Element ipn EID encoding
1B 000EE86800000064 # Fully Qualified Node Number
01 # Service Number
The two-element scheme-specific encoding provides backwards compatibility with the encoding provided in Section 4.2.5.1.2 of [RFC9171]. When used in this way, the encoding of the FQNN replaces the use of the Node Number that was specified in [RFC9171]. When the Node Number is allocated by the Default Allocator (Section 3.2.2), the encoding of the FQNN and the encoding of the Node Number from [RFC9171] are identical.
2要素スキーム固有のエンコードは、[RFC9171]のセクション4.2.5.1.2に記載されているエンコードとの逆方向の互換性を提供します。この方法で使用すると、FQNNのエンコードは[RFC9171]で指定されたノード番号の使用を置き換えます。デフォルトのアロケーター（セクション3.2.2）によってノード番号が割り当てられている場合、FQNNのエンコードと[RFC9171]のノード番号のエンコードは同一です。
In the three-element scheme-specific encoding of an ipn EID:
IPN eidの3つの要素固有のエンコーディング：
1. the first element of the array is the Allocator Identifier,
1. 配列の最初の要素は、アロケーター識別子です。
2. the second element of the array is the Node Number, and
2. 配列の2番目の要素はノード番号、そして
3. the third element of the array is the Service Number.
3. 配列の3番目の要素はサービス番号です。
For example, the ipn EID of ipn:977000.100.1 would result in the three-element array of [977000,100,1], which would be encoded in CBOR as the following 9-octet sequence:
たとえば、IPN：977000.100.1のIPN EIDは、[977000,100,1]の3エレメント配列になります。
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 ('ipn' URI scheme)
83 # 3-Element ipn EID encoding
1A 000EE868 # Allocator Identifier
64 # Node Number
01 # Service Number
The three-element scheme-specific encoding allows for a more efficient representation of ipn EIDs using smaller Allocator Identifiers, and implementations are RECOMMENDED to use this encoding scheme unless explicitly mitigating for interoperability issues; see Section 7.1.
3エレメントスキーム固有のエンコードにより、より小さなアロケーター識別子を使用してIPN EIDをより効率的に表現できるようになり、相互運用性の問題を明示的に軽減しない限り、このエンコードスキームを使用することをお勧めします。セクション7.1を参照してください。
When encoding an ipn EID using the Default Allocator (Section 3.2.2) with this encoding scheme, the first element of the array is the value zero (0). In this case, using the equivalent two-element scheme-specific encoding (Section 6.1.1) will result in a more concise CBOR representation; therefore, it is RECOMMENDED that implementations use that encoding instead.
このエンコードスキームを使用してデフォルトのアロケーター（セクション3.2.2）を使用してIPN EIDをエンコードする場合、配列の最初の要素は値ゼロ（0）です。この場合、同等の2つの要素スキーム固有のエンコード（セクション6.1.1）を使用すると、より簡潔なCBOR表現が発生します。したがって、実装は代わりにそのエンコードを使用することをお勧めします。
The presence of different scheme-specific encodings does not introduce any decoding ambiguity.
異なるスキーム固有のエンコーディングの存在では、デコードのあいまいさは導入されません。
An ipn EID CBOR decoder can reconstruct an ipn EID using the following logic. In this description, the term enc_eid refers to the CBOR-encoded ipn EID, and the term ipn_eid refers to the decoded ipn EID.
IPN EID CBORデコーダーは、次のロジックを使用してIPN EIDを再構築できます。この説明では、enc_EIDという用語はCborエンコードIPN EIDを指し、IPN_EIDという用語はデコードされたIPN EIDを指します。
if enc_eid.len() == 3
{
ipn_eid.allocator_identifier := enc_eid[0];
ipn_eid.node_number := enc_eid[1];
ipn_eid.service_number := enc_eid[2];
}
else if enc_eid.len() == 2
{
ipn_eid.allocator_identifier := enc_eid[0] >> 32;
ipn_eid.node_number := enc_eid[0] & (2^(32-1));
ipn_eid.service_number := enc_eid[1];
}
When encoded in CBOR [RFC8949], a BPv7 endpoint identified by an ipn URI MUST comply with the following Concise Data Definition Language (CDDL) [RFC8610] specification:
CBOR [RFC8949]でエンコードされた場合、IPN URIによって識別されたBPV7エンドポイントは、以下の簡潔なデータ定義言語（CDDL）[RFC8610]仕様に準拠する必要があります。
eid = $eid .within eid-structure
eid-structure = [
uri-code: uint,
SSP: any
]
; ... Syntax for other uri-code values defined in RFC 9171 ...
$eid /= [
uri-code: 2,
SSP: ipn-ssp2 / ipn-ssp3
]
ipn-ssp2 = [
fqnn: uint, ; packed value
service-number: uint
]
ipn-ssp3 = [
allocator-identifier: uint .lt 4294967296,
node-number: uint .lt 4294967296,
service-number: uint
]
Note: The node-number component will be the numeric representation of the concatenation of the Allocator Identifier and Node Number when the two-element encoding scheme has been used.
注：ノード番号コンポーネントは、2つの要素エンコードスキームが使用されている場合のアロケーター識別子とノード番号の連結の数値表現です。
Regardless of whether the two-element or three-element scheme-specific encoding is used, ipn EID matching MUST be performed on the decoded EID information itself. Different encodings of the same ipn EID MUST be treated as equivalent when performing EID-specific functions.
2要素または3要素スキーム固有のエンコードが使用されるかどうかに関係なく、IPN EIDマッチングはデコードされたEID情報自体で実行する必要があります。同じIPN EIDの異なるエンコーディングは、EID固有の機能を実行する際に同等のものとして扱う必要があります。
For example, the ipn EID of ipn:977000.100.1 can be represented as either the two-element encoding of 0x821B000EE8680000006401 or the three-element encoding of 0x831A000EE868186401. While message integrity and other syntax-based checks may treat these values differently, any EID-based comparisons MUST treat these values the same: as representing the ipn EID ipn:977000.100.1.
たとえば、IPN：977000.100.1のIPN EIDは、0x821B000EE8680000006401の2つの要素エンコードまたは0x831A000EE868186401の3エレメントエンコードとして表すことができます。メッセージの整合性やその他の構文ベースのチェックは、これらの値を異なる方法で扱う可能性がありますが、EIDベースの比較はこれらの値を同じものに扱う必要があります。IPNEIDIPN：977000.100.1を表します。
The 'ipn' URI scheme provides a compact and hierarchical mechanism for identifying services on network nodes. There is a significant amount of utility in the 'ipn' URI scheme approach to identification. However, implementers should take into consideration the following observations on the use of the 'ipn' URI scheme, particularly in regard to interoperability with implementations that pre-date this specification.
「IPN」URIスキームは、ネットワークノードでサービスを識別するためのコンパクトで階層的なメカニズムを提供します。識別には「IPN」URIスキームアプローチにはかなりの量のユーティリティがあります。ただし、実装者は、特にこの仕様を事前にしている実装との相互運用性に関して、「IPN」URIスキームの使用に関する次の観察を考慮する必要があります。
The 'ipn' URI scheme update that has been presented in this document preserves backwards compatibility with any 'ipn' URI scheme going back to the provisional definition of the 'ipn' scheme in the experimental specification "Compressed Bundle Header Encoding (CBHE)" [RFC6260] in 2011. This means that any ipn URI that was valid prior to the publication of this update remains a valid ipn URI.
このドキュメントで提示されている「IPN」URIスキームアップデートは、実験仕様「圧縮バンドルヘッダーエンコード（CBHE）」[RFC6260]の「IPN」スキームの暫定的な定義に戻る「IPN」URIスキームとの後方互換性を保持します。
Similarly, the two-element scheme-specific encoding (Section 6.1.1) is also backwards compatible with the encoding of ipn URIs provided in [RFC9171]. Any existing implementation compliant with [RFC9171] will produce an ipn URI encoding in compliance with this specification.
同様に、2つの要素スキーム固有のエンコード（セクション6.1.1）は、[RFC9171]で提供されるIPN URIのエンコードと逆方向にも互換性があります。[RFC9171]に準拠した既存の実装は、この仕様に準拠してIPN URIエンコードを生成します。
The introduction of optional non-default Allocator Identifiers and a three-element scheme-specific encoding does not make this ipn URI scheme update forwards compatible. Existing implementations for which support of this update is desired MUST be updated to be able to process non-default Allocator Identifiers and three-element scheme-specific encodings. It is RECOMMENDED that BPv7 implementations upgrade to process these new features to benefit from the scalability provided by Allocator Identifiers and the encoding efficiencies provided by the three-element encoding.
オプションの非デフォルトアロケーター識別子と3エレメントスキーム固有のエンコードの導入では、このIPN URIスキームの更新は互換性がありません。この更新のサポートが望まれる既存の実装は、非デフォルトアロケーター識別子と3要素スキーム固有のエンコーディングを処理できるように更新する必要があります。BPV7の実装は、これらの新機能を処理して、アロケーター識別子によって提供されるスケーラビリティと、3エレメントエンコーディングによって提供されるエンコーディング効率の恩恵を受けることをお勧めします。
Care must be taken when deploying implementations that default to using the three-element encoding in networks that include implementations that only support the two-element encoding [RFC9171]. Because the existing implementations will reject bundles that use the three-element encoding as malformed, correct forwarding of semantically valid bundles will fail. The used mitigation for this issue depends on the nature of the interoperability required by the deployment. Techniques can include:
2つの要素エンコード[RFC9171]のみをサポートする実装を含むネットワークでの3つの要素エンコードを使用することにデフォルトの実装を展開するときは、注意する必要があります。既存の実装は、意味的に有効なバンドルの不正な転送としての3つの要素エンコードを使用するバンドルを拒否するため、失敗します。この問題の使用された緩和は、展開に必要な相互運用性の性質に依存します。テクニックには以下を含めることができます。
* A configuration option indicating when an implementation must use the two-element encoding for all ipn EIDs when processing bundles destined to a given endpoint. This would be suitable when adding a newer implementation to a network of existing implementations.
* 特定のエンドポイントに運命づけられたバンドルの処理時に、実装がすべてのIPN EIDの2エレメントエンコードを使用する必要があることを示す構成オプション。これは、既存の実装のネットワークに新しい実装を追加する場合に適しています。
* Selective bundle encapsulation, whereby bundles that are known to originate from implementations that do not support the three-element encoding are tunneled across regions of the network that require the three-element encoding. This would utilize specially configured "gateway nodes" to perform the tunnel encapsulation and decapsulation and would be suitable when joining an existing network to a larger network.
* 選択的なバンドルカプセル化。これにより、3要素エンコーディングをサポートしない実装から発生することが知られているバンドルは、3つの要素エンコーディングを必要とするネットワークの領域全体にトンネル化されます。これにより、特別に構成された「ゲートウェイノード」を利用して、トンネルのカプセル化と脱カプセル化を実行し、既存のネットワークをより大きなネットワークに結合するときに適しています。
Techniques that do not mitigate the problem include:
問題を軽減しないテクニックは次のとおりです。
* Heuristic determination of the correct encoding to use when responding to a bundle by examining the incoming bundle. It is not possible to determine whether the two-element encoding is required by the destination when composing a new bundle in response to the receipt of a bundle, such as a status report, because ipn EIDs assigned by the Default Allocator use the two-element encoding, whether or not the implementation supports the three-element encoding.
* 着信バンドルを調べてバンドルに応答するときに使用する正しいエンコーディングのヒューリスティックな決定。デフォルトのアロケーターによって割り当てられたIPN Eidsが2エレメントエンコードを使用するかどうか、実装が3つのエレメントエンコーディングをサポートするかどうかにかかわらず、ステータスレポートなどのバンドルの受領に応答して新しいバンドルを作成するときに、2つの要素エンコードが宛先によって必要とされるかどうかを判断することはできません。
* Transcoding bundles at intermediate nodes. [RFC9171] requires the bundle primary block to be immutable, and even if ipn EIDs in the primary block do not require rewriting, other blocks including the payload block may include ipn EIDs of which the transcoding node is unaware. Additionally, bundle blocks may be covered by bundle security blocks or bundle integrity blocks [RFC9172], making them immutable.
* 中間ノードでのトランスコーディングバンドル。[RFC9171]は、バンドルプライマリブロックを不変である必要があり、プライマリブロックのIPN EIDが書き換えを必要としない場合でも、ペイロードブロックを含む他のブロックには、トランスコーディングノードが認識されていないIPN EIDが含まれる場合があります。さらに、バンドルブロックは、バンドルセキュリティブロックまたはバンドルの整合性ブロック[RFC9172]で覆われている場合があり、不変になります。
The textual representation of ipn URIs is not forwards compatible with [RFC9171]. Therefore, care must be taken when deploying implementations or tooling that use the textural representation of ipn URIs and support for non-default Allocator Identifiers is required. For example, Section 4.6 of [RFC9174] specifies that the session initialization message "...SHALL contain the UTF-8 encoded node ID of the entity that sent the SESS_INIT message." In such cases, the considerations that apply to the use of the three-element CBOR encoding also apply to the text representation when a non-default Allocator Identifier is present.
IPN URIのテキスト表現は、[RFC9171]と互換性のある転送ではありません。したがって、IPN URIのテクスチャ表現を使用する実装またはツールを展開し、非デフォルトアロケーター識別子のサポートが必要である場合は、注意を払う必要があります。たとえば、[RFC9174]のセクション4.6は、セッション初期化メッセージ「... SESS_INITメッセージを送信したエンティティのUTF-8エンコードノードIDが含まれるものとしなければならないことを指定しています。そのような場合、3個の要素CBORエンコーディングの使用に適用される考慮事項は、非デフォルトアロケーター識別子が存在する場合にテキスト表現にも適用されます。
This document updates the use of ipn EIDs for BPv7; however, the 'ipn' URI scheme was originally defined for use with BPv6. This document does not update any of the behaviors, wire-formats, or mechanisms of BPv6. Therefore, ipn EIDs with non-default Allocator Identifiers MUST NOT be used with BPv6, and the Allocator Identifier prefix MUST be omitted from any textural representation. It should be noted that BPv6 has no concept of LocalNode EIDs and will therefore treat such EIDs as routable.
このドキュメントは、BPV7のIPN EIDの使用を更新します。ただし、「IPN」URIスキームは、もともとBPV6で使用するために定義されていました。このドキュメントでは、BPV6の動作、ワイヤー形式、またはメカニズムのいずれも更新されません。したがって、非デフォルトアロケーター識別子を持つIPN EIDをBPV6で使用する必要はなく、アロケーター識別子プレフィックスをテクスチャ表現から省略する必要があります。BPV6にはLocalNode Eidsの概念がないため、そのようなEidsをルーティング可能なものとして扱うことに注意する必要があります。
[RFC9171] mandates the concept of the "late binding" of an EID, whereby the address of the destination of a bundle is resolved from its identifier hop-by-hop as it transits a BPv7 network. This per-hop binding of identifiers to addresses underlines the fact that EIDs are purely names and should not carry any implicit or explicit information concerning the current location or reachability of an identified node and service. This removes the need to rename a node as its location changes.
[RFC9171]は、EIDの「後期結合」の概念を義務付けています。これにより、バンドルの宛先のアドレスは、BPV7ネットワークを通過する際に識別子ホップバイホップから解決されます。識別子のこのホップごとのバインディングは、Eidsが純粋に名前であり、識別されたノードとサービスの現在の位置または到達可能性に関する暗黙的または明示的な情報を携帯すべきではないという事実を強調しています。これにより、ロケーションが変更されたときにノードの名前を変更する必要がなくなります。
The concept of late binding is preserved in this 'ipn' URI scheme. Elements of an ipn URI MUST NOT be regarded as carrying information relating to location, reachability, or other addressing/routing concerns.
遅い結合の概念は、この「IPN」URIスキームに保存されています。IPN URIの要素は、場所、到達可能性、またはその他のアドレス指定/ルーティングの懸念に関する情報を持ち運ぶ情報と見なされてはなりません。
An example of incorrect behavior would be to assume that a given Allocator assigns Node Numbers derived from link-layer addresses and to interpret the Node Number component of an ipn URI directly as a link-layer address. No matter the mechanism an Allocator uses for the assignment of Node Numbers, they remain just numbers, without additional meaning.
誤った動作の例は、特定のアロケーターがリンク層アドレスから派生したノード番号を割り当てると仮定し、IPN URIのノード番号コンポーネントをリンク層アドレスとして直接解釈することです。アロケーターがノード番号の割り当てに使用しているメカニズムに関係なく、それらは追加の意味を持たずに、数字のままです。
This section updates the security considerations from Section 4.2.5.1.2 of [RFC9171] to account for the inclusion of Allocator Identifiers in the 'ipn' URI scheme when used with BPv7.
このセクションでは、[RFC9171]のセクション4.2.5.1.2のセキュリティに関する考慮事項を更新して、BPV7で使用した場合の「IPN」URIスキームにアロケーター識別子を含めることを説明します。
None of the BPv7 endpoints identified by ipn EIDs are guaranteed to be reachable at any time, and the identity of the processing entities operating on those endpoints is never guaranteed by the Bundle Protocol itself. Verification of the signature provided by the Block Integrity Block (BIB) targeting the bundle's primary block, as defined by "Bundle Protocol Security (BPSec)" [RFC9172], is required for this purpose.
IPN EIDによって特定されたBPV7エンドポイントはいずれも、いつでも到達可能であることが保証されておらず、これらのエンドポイントで動作する処理エンティティのIDは、バンドルプロトコル自体によって保証されません。この目的には、「バンドルプロトコルセキュリティ（BPSEC）」[RFC9172]で定義されているように、バンドルのプライマリブロックをターゲットとするブロック整合性ブロック（BIB）によって提供される署名の検証が必要です。
Malicious construction of a conformant ipn URI is limited to the malicious selection of Allocator Identifiers, Node Numbers, and Service Numbers. That is, a maliciously constructed ipn EID could be used to direct a bundle to an endpoint that might be damaged by the arrival of that bundle or, alternatively, to declare a false source for a bundle and thereby cause incorrect processing at a node that receives the bundle. In both cases (and indeed in all bundle processing), the node that receives a bundle should verify its authenticity and validity before operating on it in any way, such as with the use of BPSec [RFC9172] and TCP Convergence Layer version 4 (TCPCLv4) with TLS [RFC9174].
適合IPN URIの悪意のある構造は、アロケーター識別子、ノード番号、およびサービス番号の悪意のある選択に限定されています。つまり、悪意のあるIPN EIDを使用して、そのバンドルの到着によって損傷する可能性のあるエンドポイントにバンドルを向けるか、あるいはバンドルの誤ったソースを宣言し、バンドルを受信するノードでの処理が誤って処理されることがあります。どちらの場合も（そして実際にはすべてのバンドル処理で）、バンドルを受信するノードは、BPSEC [RFC9172]およびTCP収束層バージョン4（TCPCLV4）を使用してTLS [RFC9174]を使用するなど、あらゆる方法で操作する前にその信ity性と有効性を検証する必要があります。
The limited expressiveness of URIs of the 'ipn' scheme effectively eliminates the possibility of threats due to errors in back-end transcoding.
「IPN」スキームのURIの限られた表現力は、バックエンドトランスコーディングのエラーによる脅威の可能性を効果的に排除します。
Both LocalNode (Section 3.4.2) and Private Use (Section 3.4.3) ipn URIs present a risk to the stability of deployed BPv7 networks. If either type of ipn URI is allowed to propagate beyond the domain in which they are valid, then the required uniqueness of ipn URIs no longer holds, and this fact can be abused by a malicious node to prevent the correct functioning of the network as a whole.
LocalNode（セクション3.4.2）とプライベート使用（セクション3.4.3）の両方が、展開されたBPV7ネットワークの安定性のリスクを示しています。いずれかのタイプのIPN URIが有効なドメインを越えて伝播することが許可されている場合、IPN URIの必要な一意性はもはや保持されなくなり、この事実は悪意のあるノードによって乱用され、ネットワーク全体の正しい機能を防ぐことができます。
See Sections 5.4 and 5.5 for required behaviors to mitigate against this form of abuse.
この形式の虐待に対して緩和するために必要な行動については、セクション5.4および5.5を参照してください。
Because ipn URIs are used only to represent the numeric identities of resources, the risk of disclosure of sensitive information due to interception of these URIs is minimal. Examination of ipn URIs could be used to support traffic analysis; where traffic analysis is a plausible danger, bundles should be conveyed by secure convergence-layer protocols that do not expose endpoint IDs, such as TCPCLv4 [RFC9174].
IPN URIは、リソースの数値アイデンティティを表すためにのみ使用されるため、これらのURIの傍受による機密情報の開示のリスクは最小限です。IPN URIの検査は、トラフィック分析をサポートするために使用できます。トラフィック分析がもっともらしい危険である場合、TCPCLV4 [RFC9174]などのエンドポイントIDを公開しない安全な収束層プロトコルによってバンドルを伝える必要があります。
The simplicity of the 'ipn' URI scheme syntax minimizes the possibility of misinterpretation of a URI by a human user.
「IPN」URIスキームの構文の単純さは、人間のユーザーによるURIの誤解の可能性を最小限に抑えます。
The following sections detail the creation of two new IANA registries and the renaming of an existing IANA registry under the "Uniform Resource Identifier (URI) Schemes" registry group.
次のセクションでは、2つの新しいIANAレジストリの作成と、「均一リソース識別子（URI）スキーム」レジストリグループの下での既存のIANAレジストリの名前変更について詳しく説明しています。
IANA has also updated the reference for the 'ipn' scheme to this document in the "Uniform Resource Identifier (URI) Schemes" registry.
IANAはまた、「IPN」スキームの参照を「ユニフォームリソース識別子（URI）スキーム」レジストリでこのドキュメントに更新しました。
IANA has created a new registry titled "'ipn' Scheme URI Allocator Identifiers". Using terms defined in [RFC8126], the registration procedures for this registry are:
IANAは、「「IPN」スキームURI Allocator識別子」というタイトルの新しいレジストリを作成しました。[RFC8126]で定義されている用語を使用して、このレジストリの登録手順は次のとおりです。
+========================+==============+==================+
| Range | Registration | Note |
| | Procedures | |
+========================+==============+==================+
| 0..0xFFFF | Expert | Single Allocator |
| | Review | Identifiers only |
+------------------------+--------------+------------------+
| 0x10000..0x3FFFFFFF | Expert | |
| | Review | |
+------------------------+--------------+------------------+
| 0x40000000..0x7FFFFFFF | Experimental | |
| | Use | |
+------------------------+--------------+------------------+
| 0x80000000..0xFFFFFFFF | Reserved | Future Expansion |
+------------------------+--------------+------------------+
| >=0x100000000 | Reserved | |
+------------------------+--------------+------------------+
Table 2: Registration Procedures for the 'ipn' Scheme URI Allocator Identifiers Registry
表2：「IPN」スキームURIアロケーター識別子レジストリの登録手順
Each entry in this registry associates one or more Allocator Identifiers with a single organization. Within the registry, the organization is identified using the "Name" and "Change Controller" fields. It is expected that each identified organization will publish some listing of allocated Node Numbers, the pointer to which is listed in the "Reference" field of the registry.
このレジストリの各エントリは、1つ以上のアロケーター識別子を単一の組織に関連付けます。レジストリ内では、組織は「名前」と「Change Controller」フィールドを使用して識別されます。識別された各組織は、割り当てられたノード番号のリストを公開することが期待されます。これは、レジストリの「参照」フィールドにリストされているポインターです。
Note that the "Single Allocator Identifiers only" language in the registration procedure for this registry indicates that, within the indicated range, the allocation of a sequence of consecutive Allocator Identifiers to a single organization is prohibited.
このレジストリの登録手順の「単一のアロケーター識別子のみ」の言語は、示された範囲内で、単一の組織への連続するアロケーター識別子のシーケンスの割り当てが禁止されていることを示していることに注意してください。
The initial values in the registry are:
レジストリの初期値は次のとおりです。
+=========+=============+===============+======+=========+==========+
|Name |Range (dec) |Range (hex) |Range |Reference|Change |
| | | |Length| |Controller|
| | | |(Bits)| | |
+=========+=============+===============+======+=========+==========+
|Default |0 |0x0 |0 |RFC 9758,|IETF |
|Allocator| | | |Section | |
| | | | |3.2.2 | |
+---------+-------------+---------------+------+---------+----------+
|Example |974848-978943|0xEE000-0xEEFFF|12 |RFC 9758 |IETF |
|Range | | |bits | | |
+---------+-------------+---------------+------+---------+----------+
Table 3: Initial Values in the 'ipn' Scheme URI Allocator Identifiers Registry
表3：「IPN」スキームURIアロケーター識別子レジストリの初期値
The "Example Range" is assigned for use in examples in documentation and sample code.
「例の範囲」は、ドキュメントとサンプルコードの例で使用するために割り当てられます。
Due to the nature of the CBOR encoding of unsigned integers used for Allocator Identifiers with BPv7, Allocator Identifiers with a low value number are encoded more efficiently than larger numbers. This makes low value Allocator Identifiers more desirable than larger Allocator Identifiers; therefore, care must be taken when assigning Allocator Identifier ranges to ensure that a single applicant is not granted a large swathe of highly desirable numbers at the expense of other applicants. To this end, designated experts are strongly recommended to familiarize themselves with the CBOR encoding of unsigned integers in [RFC8949].
BPV7のアロケーター識別子に使用される署名されていない整数のCBORエンコードの性質により、値が少ないアロケーター識別子は、より多くの数よりも効率的にエンコードされます。これにより、より大きなアロケーター識別子よりも低い値アロケーター識別子が望ましいものになります。したがって、他の申請者を犠牲にして、単一の申請者が非常に望ましい数字の大きな範囲を認められないようにするために、アロケーター識別子範囲を割り当てるときは注意を払う必要があります。この目的のために、指定された専門家は、[RFC8949]の符号なし整数のCBORエンコーディングに慣れるために強くお勧めします。
IANA has renamed the "CBHE Node Numbers" registry (defined in Section 3.2.1 of [RFC7116]) to the "'ipn' Scheme URI Default Allocator Node Numbers" registry and moved it to the "Uniform Resource Identifier (URI) Schemes" registry group. IANA has added the following note to the "CBHE Node Numbers" registry:
IANAは、「CBHEノード番号」レジストリ（[RFC7116]のセクション3.2.1で定義）を「「IPN」デフォルトアロケーターノード番号」レジストリに変更し、「ユニフォームリソース識別子（URI）スキーム」レジストリグループに移動しました。IANAは、「CBHEノード番号」レジストリに次のメモを追加しました。
Note: Renamed "CBHE Node Numbers" as "'ipn' Scheme URI Default Allocator Node Numbers" and moved it to <https://www.iana.org/assignments/uri-schemes> per RFC 9758.
注：「cbheノード番号」と改名された「 'ipn' scheme uri default allocator numbers」と名前を付けて、<https://www.iana.org/assignments/uri-schemes> RFC 9758に移動しました。
Using terms defined in [RFC8126], the registration procedures for this registry are:
[RFC8126]で定義されている用語を使用して、このレジストリの登録手順は次のとおりです。
+====================+=========================+
| Range | Registration Procedures |
+====================+=========================+
| 1..0x3FFF | Private Use |
+--------------------+-------------------------+
| 0x4000..0xFFFFFFFE | Expert Review |
+--------------------+-------------------------+
| >=0x100000000 | Invalid |
+--------------------+-------------------------+
Table 4: Registration Procedures for the 'ipn' Scheme URI Default Allocator Node Numbers Registry
表4：「IPN」スキームURIデフォルトアロケーターノード番号レジストリの登録手順
IANA has registered the following values in the "'ipn' Scheme URI Default Allocator Node Numbers" registry:
IANAは、「「IPN」スキームURIデフォルトアロケーターノード番号」レジストリに次の値を登録しています。
+============+===============================+===================+
| Value | Description | Reference |
+============+===============================+===================+
| 0 | Reserved for the Null ipn URI | [RFC7116] and RFC |
| | | 9758, Section 3.1 |
+------------+-------------------------------+-------------------+
| 4294967295 | Reserved for LocalNode ipn | RFC 9758, |
| | URIs | Section 3.4.2 |
+------------+-------------------------------+-------------------+
Table 5: New Values in the 'ipn' Scheme URI Default Allocator Node Numbers Registry
表5：「IPN」スキームURIデフォルトアロケーター番号レジストリの新しい値
As IANA has only renamed the registry, all existing registrations will remain.
IANAはレジストリの変更のみであるため、既存のすべての登録は残ります。
IANA has created a new registry titled "'ipn' Scheme URI Well-Known Service Numbers for BPv7". Using terms defined in [RFC8126], the registration procedures for this registry are:
IANAは、BPV7の「「IPN」スキームURIの有名なサービス番号」というタイトルの新しいレジストリを作成しました。[RFC8126]で定義されている用語を使用して、このレジストリの登録手順は次のとおりです。
+=====================+===============================+
| Range | Registration Procedures |
+=====================+===============================+
| 1..127 | Private Use |
+---------------------+-------------------------------+
| 128..255 | Standards Action |
+---------------------+-------------------------------+
| 0x0100..0x7FFF | Private Use |
+---------------------+-------------------------------+
| 0x8000..0xFFFF | Specification Required |
+---------------------+-------------------------------+
| 0x10000..0xFFFFFFFF | Private Use |
+---------------------+-------------------------------+
| >=0x100000000 | Reserved for future expansion |
+---------------------+-------------------------------+
Table 6: Registration Procedures for the 'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry
表6：「IPN」スキームの登録手順BPV7レジストリの有名なサービス番号
The initial values in the registry are:
レジストリの初期値は次のとおりです。
+================+=============================+===================+
| Value | Description | Reference |
+================+=============================+===================+
| 0 | The Administrative Endpoint | [RFC9171] and RFC |
| | | 9758, Section 5.7 |
+----------------+-----------------------------+-------------------+
| 0xEEE0..0xEEEF | Example Range | RFC 9758 |
+----------------+-----------------------------+-------------------+
Table 7: Initial Values in the 'ipn' Scheme URI Well-Known Service Numbers for BPv7 Registry
表7：BPV7レジストリの「IPN」スキームの初期値URIの有名なサービス番号
The "Example Range" is assigned for use in examples in documentation and sample code.
「例の範囲」は、ドキュメントとサンプルコードの例で使用するために割り当てられます。
This registry is intended to record the default Service Numbers for well-known, interoperable services that are available and of use to the entire BPv7 community; hence, all ranges not marked for Private Use MUST have a corresponding publicly available specification describing how one interfaces with the service.
このレジストリは、利用可能であり、BPV7コミュニティ全体で使用される、よく知られている相互運用可能なサービスのデフォルトのサービス番号を記録することを目的としています。したがって、個人使用のためにマークされていないすべての範囲には、サービスとの1つのインターフェイスを説明する対応する公開されている仕様が必要です。
Services that are specific to a particular deployment or co-operation may require a registry to reduce administrative burden, but do not require an entry in this registry.
特定の展開または協力に固有のサービスは、管理上の負担を軽減するためにレジストリが必要になる場合がありますが、このレジストリへのエントリは必要ありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6260] Burleigh, S., "Compressed Bundle Header Encoding (CBHE)",
RFC 6260, DOI 10.17487/RFC6260, May 2011,
<https://www.rfc-editor.org/info/rfc6260>.
[RFC7116] Scott, K. and M. Blanchet, "Licklider Transmission
Protocol (LTP), Compressed Bundle Header Encoding (CBHE),
and Bundle Protocol IANA Registries", RFC 7116,
DOI 10.17487/RFC7116, February 2014,
<https://www.rfc-editor.org/info/rfc7116>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data
Definition Language (CDDL): A Notational Convention to
Express Concise Binary Object Representation (CBOR) and
JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610,
June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5050] Scott, K. and S. Burleigh, "Bundle Protocol
Specification", RFC 5050, DOI 10.17487/RFC5050, November
2007, <https://www.rfc-editor.org/info/rfc5050>.
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
[RFC9174] Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
Tolerant Networking TCP Convergence-Layer Protocol Version
4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
<https://www.rfc-editor.org/info/rfc9174>.
This section provides some example ipn URIs in their textual representation.
このセクションでは、テキスト表現にIPN URIの例を示します。
Consider the ipn URI identifying Service Number 2 on Node Number 1 allocated by the Default Allocator (0) (Section 3.2.2).
デフォルトのアロケーター（0）（セクション3.2.2）によって割り当てられたノード番号1のサービス番号2を識別するIPN URIを検討してください。
The recommended seven-character representation of this URI would be as follows:
このURIの推奨される7文字の表現は次のとおりです。
ipn:1.2
The nine-character representation of this URI, with the explicit Allocator Identifier, would be as follows:
明示的なアロケーター識別子を備えたこのURIの9文字の表現は次のとおりです。
ipn:0.1.2
Consider the ipn URI identifying Service Number 3 on Node Number 1 allocated by Allocator 977000.
Allocator 977000によって割り当てられたノード番号1のIPN URI識別サービス番号3を検討してください。
The 14-character representation of this URI would be as follows:
このURIの14文字の表現は次のとおりです。
ipn:977000.1.3
The Null ipn URI (Section 3.1) is represented as:
null IPN URI（セクション3.1）は次のように表されています。
ipn:0.0
Consider the ipn URI identifying Service Number 7 on the local node.
ローカルノードのIPN URI識別サービス番号7を考慮してください。
The recommended seven-character representation of this URI would be as follows:
このURIの推奨される7文字の表現は次のとおりです。
ipn:!.7
The numeric 16-character representation of this URI would be as follows:
このURIの数値16文字表現は次のとおりです。
ipn:4294967295.7
This section provides some example CBOR encodings of ipn EIDs.
このセクションでは、IPN EidsのCborエンコーディングの例を示します。
Consider the ipn EID ipn:1.1. This textual representation of an ipn EID identifies Service Number 1 on Node Number 1 allocated by the Default Allocator (0) (Section 3.2.2).
IPN EID IPNを検討してください：1.1。IPN EIDのこのテキスト表現は、デフォルトのアロケーター（0）（セクション3.2.2）によって割り当てられたノード番号1のサービス番号1を識別します。
The recommended five-octet encoding of this EID using the two-element scheme-specific encoding would be as follows:
2つの要素スキーム固有のエンコードを使用して、このEIDの推奨される5オクテットエンコードは次のとおりです。
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 ('ipn' URI scheme)
82 # 2-Element ipn EID encoding
01 # Node Number
01 # Service Number
The six-octet encoding of this EID using the three-element scheme-specific encoding would be as follows:
3要素スキーム固有のエンコードを使用してこのEIDの6オクテットエンコードは次のとおりです。
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 ('ipn' URI scheme)
83 # 3-Element ipn EID encoding
00 # Default Allocator
01 # Node Number
01 # Service Number
Consider the ipn EID ipn:977000.1.1. This textual representation of an ipn EID identifies Service Number 1 on Node Number 1 allocated by Allocator 977000.
IPN EID IPN：977000.1.1を検討してください。IPN EIDのこのテキスト表現は、Allocator 977000によって割り当てられたノード番号1のサービス番号1を識別します。
The recommended 10-octet encoding of this EID using the three-element scheme-specific encoding would be as follows:
3要素スキーム固有のエンコードを使用して、このEIDの推奨10オクテットエンコードは次のとおりです。
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 ('ipn' URI scheme)
83 # 3-Element ipn EID encoding
1A 000EE868 # Allocator Identifier
01 # Node Number
01 # Service Number
The 13-octet encoding of this EID using the two-element scheme-specific encoding would be as follows:
2つの要素スキーム固有のエンコードを使用したこのEIDの13オクテットエンコードは次のとおりです。
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 ('ipn' URI scheme)
82 # 2-Element ipn EID encoding
1B 000EE86800000001 # Fully Qualified Node Number
01 # Service Number
The Null EID of ipn:0.0 can be encoded in the following ways:
IPNのnull eid：0.0は、次の方法でエンコードできます。
The recommended five-octet encoding of the Null ipn EID using the two-element scheme-specific encoding would be as follows:
2つの要素スキーム固有のエンコードを使用して、NULL IPN EIDの推奨される5オクテットエンコードは次のとおりです。
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 ('ipn' URI scheme)
82 # 2-Element ipn EID encoding
00 # Node Number
00 # Service Number
The six-octet encoding of the Null ipn EID using the three-element scheme-specific encoding would be as follows:
3エレメントスキーム固有のエンコードを使用して、null IPN EIDの6オクテットエンコードは次のとおりです。
82 # 2-Element Endpoint Encoding
02 # uri-code: 2 ('ipn' URI scheme)
83 # 3-Element ipn EID encoding
00 # Default Allocator
00 # Node Number
00 # Service Number
The following DTN Working Group participants contributed technical material, use cases, and critical technical reviews for this URI scheme update: Scott Burleigh of the IPNGROUP, Keith Scott, Brian Sipos of the Johns Hopkins University Applied Physics Laboratory, Jorge Amodio of LJCV Electronics, and Ran Atkinson.
以下のDTNワーキンググループの参加者は、このURIスキームの更新の技術資料、ユースケース、および重要な技術レビューを貢献しました。IPNGroupのスコットバーリー、キーススコット、ジョンズホプキンス大学のブライアンSipos Applied Physics Laboratory、LJCV ElectronicsのJorge Amodio、およびAtkinsonを実行しました。
Additionally, the authors wish to thank members of the CCSDS SIS-DTN Working Group at large who provided useful reviews and commentary on this document and its implications for the future of networked space exploration.
さらに、著者は、この文書に関する有用なレビューと解説とネットワーク化された宇宙探査の将来への影響を提供しているCCSDS SIS-DTNワーキンググループのメンバーに感謝したいと考えています。
Rick Taylor
Aalyria Technologies
Email: rtaylor@aalyria.com
Edward J. Birrane, III
The Johns Hopkins University Applied Physics Laboratory
Email: Edward.Birrane@jhuapl.edu