[要約] RFC 6907は、RPKIオブジェクトの発行者と信頼する側のための使用事例と解釈についての要約です。このRFCの目的は、RPKIオブジェクトの使用方法と解釈に関するガイダンスを提供することです。
Internet Engineering Task Force (IETF) T. Manderson
Request for Comments: 6907 ICANN
Category: Informational K. Sriram
ISSN: 2070-1721 US NIST
R. White
Verisign
March 2013
Use Cases and Interpretations of Resource Public Key Infrastructure (RPKI) Objects for Issuers and Relying Parties
発行者と依存者のリソース公開鍵インフラストラクチャ（RPKI）オブジェクトの使用例と解釈
Abstract
概要
This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.
このドキュメントでは、パブリックRPKIでリソースパブリックキーインフラストラクチャ（RPKI）オブジェクトシナリオを作成または検出する際の、組織と依存者の方向性と解釈とともに、いくつかの使用例について説明します。これらの項目はすべて、インターネットルーティングシステムに関連してここで説明されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc6907.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6907で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................4
1.2. Documentation Prefixes .....................................4
1.3. Definitions ................................................4
2. Overview ........................................................6
2.1. General Interpretation of RPKI Object Semantics ............6
3. Origination Use Cases ...........................................7
3.1. Single Announcement ........................................8
3.2. Aggregate with a More Specific .............................8
3.3. Aggregate with a More Specific from a Different ASN ........9
3.4. Sub-Allocation to a Multi-Homed Customer ...................9
3.5. Restriction of a New Allocation ...........................10
3.6. Restriction of New ASN ....................................11
3.7. Restriction of a Part of an Allocation ....................11
3.8. Restriction of Prefix Length ..............................12
3.9. Restriction of Sub-Allocation Prefix Length ...............13
3.10. Aggregation and Origination by an Upstream Provider ......15
3.11. Rogue Aggregation and Origination by an Upstream
Provider .................................................16
4. Adjacency or Path Validation Use Cases .........................17
5. Partial Deployment Use Cases ...................................18
5.1. Parent Does Not Participate in RPKI .......................18
5.2. Only Some Children Participate in RPKI ....................18
5.3. Grandchild Does Not Participate in RPKI ...................19
6. Transfer Use Cases .............................................20
6.1. Transfer of In-Use Prefix and Autonomous System Number ....20
6.2. Transfer of In-Use Prefix .................................21
6.3. Transfer of Unused Prefix .................................22
7. Relying Party Use Cases ........................................22
7.1. Prefix-Origin Validation Use Cases ........................22
7.1.1. Covering ROA Prefix, maxLength Satisfied,
and AS Match .......................................23
7.1.2. Covering ROA Prefix, maxLength Exceeded,
and AS Match .......................................23
7.1.3. Covering ROA Prefix, maxLength Satisfied,
and AS Mismatch ....................................23
7.1.4. Covering ROA Prefix, maxLength Exceeded,
and AS Mismatch ....................................24
7.1.5. Covering ROA Prefix Not Found ......................24
7.1.6. Covering ROA Prefix and the ROA Is an AS 0 ROA .....24
7.1.7. Covering ROA Prefix Not Found but ROAs
Exist for a Covering Set of More Specifics .........25
7.1.8. AS_SET in Route and Covering ROA Prefix Not Found ..25
7.1.9. Singleton AS in AS_SET (in the Route),
Covering ROA Prefix, and AS Match ..................26
7.1.10. Singleton AS in AS_SET (in the Route),
Covering ROA Prefix, and AS Mismatch ..............26
7.1.11. Multiple ASs in AS_SET (in the Route) and
Covering ROA Prefix ...............................26
7.1.12. Multiple ASs in AS_SET (in the Route) and
ROAs Exist for a Covering Set of More Specifics ...27
7.2. ROA Expiry or Receipt of a CRL Revoking a ROA .............27
7.2.1. ROA of Parent Prefix Is Revoked ....................27
7.2.2. ROA of Prefix Revoked while Parent Prefix
Has Covering ROA Prefix with Different ASN .........28
7.2.3. ROA of Prefix Revoked while That of Parent
Prefix Prevails ....................................28
7.2.4. ROA of Grandparent Prefix Revoked while
That of Parent Prefix Prevails .....................28
7.2.5. Expiry of ROA of Parent Prefix .....................29
7.2.6. Expiry of ROA of Prefix while Parent Prefix
Has Covering ROA with Different ASN ................29
7.2.7. Expiry of ROA of Prefix while That of
Parent Prefix Prevails .............................29
7.2.8. Expiry of ROA of Grandparent Prefix while
That of Parent Prefix Prevails .....................29
8. Acknowledgements ...............................................30
9. Security Considerations ........................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................30
This document describes a number of use cases together with directions and interpretations for organizations and relying parties when creating or encountering Resource Public Key Infrastructure (RPKI) object scenarios in the public RPKI. All of these items are discussed here in relation to the Internet routing system.
このドキュメントでは、パブリックRPKIでリソースパブリックキーインフラストラクチャ（RPKI）オブジェクトシナリオを作成または検出する際の、組織と依存者の方向性と解釈とともに、いくつかの使用例について説明します。これらの項目はすべて、インターネットルーティングシステムに関連してここで説明されています。
It is assumed that the reader is familiar with the terms and concepts described in "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile" [RFC5280], "A Profile for X.509 PKIX Resource Certificates" [RFC6487], "X.509 Extensions for IP Addresses and AS Identifiers" [RFC3779], "A Profile for Route Origin Authorizations (ROAs)" [RFC6482], "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)" [RFC6483], and "BGP Prefix Origin Validation" [RFC6811].
読者は、「インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル」[RFC5280]、「X.509 PKIXリソース証明書のプロファイル」[RFC6487]で説明されている用語と概念に精通していることを前提としています。 ]、「IPアドレスとAS識別子のX.509拡張機能」[RFC3779]、「ルート発信元承認（ROA）のプロファイル」[RFC6482]、「リソース証明書の公開鍵インフラストラクチャ（PKI）とルートを使用したルート発信の検証Origin Authorizations（ROA）」[RFC6483]、および「BGP Prefix Origin Validation」[RFC6811]。
The documentation prefixes recommended in [RFC5737] are insufficient for use as example prefixes in this document. Therefore, this document uses RFC 1918 [RFC1918] address space for constructing example prefixes.
[RFC5737]で推奨されているドキュメントの接頭辞は、このドキュメントの接頭辞の例として使用するには不十分です。したがって、このドキュメントでは、RFC 1918 [RFC1918]アドレス空間を使用して、プレフィックスの例を作成しています。
For all of the use cases in this document, it is assumed that RPKI objects (e.g., resource certificates, ROAs) validate in accordance with [RFC6487] and [RFC6480]. In other words, we assume that corrupted RPKI objects, if any, have been detected and eliminated.
このドキュメントのすべてのユースケースでは、RPKIオブジェクト（リソース証明書、ROAなど）が[RFC6487]および[RFC6480]に従って検証することを前提としています。つまり、破損したRPKIオブジェクトがある場合は、それが検出され、除去されたと想定します。
The following definitions are in use in this document. Some of these definitions are reused or adapted from [RFC6811] with authors' permission.
このドキュメントでは、次の定義が使用されています。これらの定義の一部は、著者の許可を得て、[RFC6811]から再利用または適合されています。
Resource: An IP address prefix (simply called prefix or subnet) or an Autonomous System Number (ASN).
リソース：IPアドレスプレフィックス（単にプレフィックスまたはサブネットと呼ばれます）または自律システム番号（ASN）。
Allocation: A set of resources provided to an entity or organization for its use.
割り当て：エンティティまたは組織が使用するために提供されるリソースのセット。
Sub-allocation: A set of resources subordinate to an allocation assigned to another entity or organization.
サブ割り当て：別のエンティティまたは組織に割り当てられた割り当てに従属する一連のリソース。
Prefix: A prefix consists of a pair (IP address, prefix length), interpreted as is customary (see [RFC4632]).
プレフィックス：プレフィックスは、慣習的に解釈されるペア（IPアドレス、プレフィックス長）で構成されます（[RFC4632]を参照）。
Route: Data derived from a received BGP update, as defined in [RFC4271], Section 1.1. The route includes one prefix and an AS_PATH, among other things.
ルート：[RFC4271]、セクション1.1で定義されている、受信したBGPアップデートから派生したデータ。ルートには、とりわけ、1つのプレフィックスとAS_PATHが含まれます。
ROA: Route Origin Authorization (ROA) is an RPKI object signed by a prefix holder authorizing origination of said prefix from an origin AS specified in said ROA.
ROA：Route Origin Authorization（ROA）は、ROAで指定されたオリジンASからのプレフィックスの発信を承認するプレフィックスホルダーによって署名されたRPKIオブジェクトです。
AS 0 ROA: A ROA with ASN value 0 (zero) in the AS ID field. AS 0 ROA is an attestation by a prefix holder that the prefix described in the ROA, and any more specific prefix, should not be used in a routing context [RFC6483].
AS 0 ROA：AS IDフィールドにASN値0（ゼロ）のROA。 AS 0 ROAは、ROAで記述されたプレフィックス、およびより具体的なプレフィックスをルーティングコンテキストで使用してはならないというプレフィックスホルダーによる証明です[RFC6483]。
ROA prefix: The prefix from a ROA.
ROAプレフィックス：ROAからのプレフィックス。
ROA ASN: The origin ASN from a ROA.
ROA AND：ROWの元のASN。
maxLength: The maximum length up to which more specific prefixes of a ROA prefix may be originated from the corresponding ROA ASN. The maxLength is specified in the ROA.
maxLength：ROAプレフィックスのより具体的なプレフィックスが対応するROA ASNから発信されるまでの最大長。 maxLengthはROAで指定されます。
Route prefix: A prefix derived from a route.
ルート接頭辞：ルートから派生した接頭辞。
Route origin ASN: The origin AS number derived from a route. The origin AS number is:
ルート起点ASN：ルートから導出された起点AS番号。元のAS番号は次のとおりです。
o the rightmost AS in the final segment of the AS_PATH attribute in the route if that segment is of type AS_SEQUENCE, or
o セグメントのタイプがAS_SEQUENCEの場合、ルートのAS_PATH属性の最後のセグメントの右端のAS、または
o the BGP speaker's own AS number if that segment is of type AS_CONFED_SEQUENCE or AS_CONFED_SET or if the AS_PATH is empty, or
o そのセグメントのタイプがAS_CONFED_SEQUENCEまたはAS_CONFED_SETの場合、またはAS_PATHが空の場合は、BGPスピーカー自身のAS番号、または
o the distinguished value "NONE" if the final segment of the AS_PATH attribute is of any other type.
o AS_PATH属性の最後のセグメントが他のタイプの場合、識別値「NONE」。
Covering ROA prefix: A ROA prefix that is an exact match or a less specific when compared to the route prefix under consideration. In other words, the route prefix is said to have a covering ROA prefix when there exists a ROA such that the ROA prefix length is less than or equal to the route prefix length and the ROA prefix address matches the route prefix address for all bits specified by the ROA prefix length.
カバーするROAプレフィックス：検討中のルートプレフィックスと比較した場合、完全一致または特定性の低いROAプレフィックス。言い換えると、ROAプレフィックスの長さがルートプレフィックス長以下で、ROAプレフィックスアドレスが指定されたすべてのビットのルートプレフィックスアドレスと一致するROAが存在する場合、ルートプレフィックスはカバーするROAプレフィックスを持つと言いますROAプレフィックス長。
Covering ROA: If a ROA contains a covering ROA prefix for a route prefix under consideration, then the ROA is said to be a covering ROA for the route prefix.
カバリングROA：ROAに、検討中のルートプレフィックスのカバリングROAプレフィックスが含まれている場合、ROAはルートプレフィックスのカバリングROAと呼ばれます。
No covering ROA: No covering ROA exists for a route prefix under consideration.
カバーするROAがない：検討中のルートプレフィックスにカバーするROAがありません。
No other covering ROA: No other covering ROA exists (besides what is (are) already cited) for a route prefix under consideration.
他の対象となるROAはありません。検討中のルートプレフィックスには、他の対象となるROAはありません（既に引用されているものを除いて）。
Multi-homed prefix or subnet: A prefix (i.e., subnet) for which a route is originated through two or more autonomous systems.
マルチホームプレフィックスまたはサブネット：ルートが2つ以上の自律システムを介して発信されるプレフィックス（つまり、サブネット）。
Matched: A route's {prefix, origin AS} pair is said to be matched by a ROA when the route prefix has a covering ROA, and in addition, the route prefix length is less than or equal to the maxLength in said covering ROA and the route origin ASN is equal to the ASN in said covering ROA.
一致：ルートの{prefix、origin AS}ペアは、ルートプレフィックスにカバーするROAがあり、さらにルートプレフィックスの長さが上記のカバーするROAのmaxLength以下である場合、ROAと一致すると言われます。ルート起点ASNは、前述の対象ROAのASNに等しい。
Given these definitions, any given BGP route will be found to have one of the following "validation states":
これらの定義を前提として、特定のBGPルートは、次の「検証状態」のいずれかを持っていることがわかります。
o NotFound: The route prefix has no covering ROA.
o NotFound：ルートプレフィックスにROAが含まれていません。
o Valid: The route's {prefix, origin AS} pair is matched by at least one ROA.
o 有効：ルートの{prefix、origin AS}ペアは、少なくとも1つのROAと一致します。
o Invalid: The route prefix has at least one covering ROA and the route's {prefix, origin AS} pair is not matched by any ROA.
o 無効：ルートプレフィックスには少なくとも1つの対象ROAがあり、ルートの{prefix、origin AS}ペアはどのROAとも一致しません。
It is to be noted that no ROA can have the value "NONE" as its ROA ASN. Thus, a route whose origin ASN is "NONE" cannot be matched by any ROA. Similarly, no valid route can have an origin ASN of zero [AS0-PROC]. Thus, no route can be matched by a ROA whose ASN is zero (i.e., an AS 0 ROA) [RFC6483].
ROAがROA ASNとして値「NONE」を持つことはできないことに注意してください。したがって、起点ASNが「NONE」であるルートは、どのROAにも一致しません。同様に、有効なルートはゼロの起点ASNを持つことができません[AS0-PROC]。したがって、ASNがゼロのROA（つまり、AS 0 ROA）[RFC6483]によって一致するルートはありません。
In the interpretation of relying parties (RPs), or relying party routing software, it is important that a 'make before break' operational policy be applied. In part, this means that an RP should implement a routing decision process where a route is assumed to be intended (i.e., considered unsuspicious) unless proven otherwise by the existence of a valid RPKI object that explicitly invalidates the route (see Section 7.1 for examples). Also, especially in cases when a prefix is newly acquired by allocation/sub-allocation or due to prefix-ownership transfer, a ROA should be registered in RPKI prior to advertisement of the prefix in BGP. This is highly recommended for the following reasons. Observe that in the transfer case (considering a prefix transfer from Org A to Org B), even though Org A's resource cert would be revoked before issuing a resource cert to Org B, there may be some latency before all relying parties discard the previously received ROA of Org A for that prefix. The latency may be due to CRL propagation delay in the RPKI system or due to periodic polling by RPs, etc. Also, observe that in the sub-allocation case (from parent Org A to child Org B), there may be an existing ROA registered by Org A (with their own origin ASN) for a covering aggregate prefix relative to the prefix in consideration. If the new prefix owner (Org B) has not already registered their own ROA (i.e., ROA with their origin ASN), then the presence of a different covering ROA (i.e., one with a different origin ASN) belonging to Org A would result in invalid assessment for the route advertised by the new owner (Org B). Thus, in both cases (transfer or sub-allocation), it is prudent for the new owner (Org B) to ensure that its route for the prefix will be valid by proactively issuing a ROA before advertising the route. The ROA should be issued with sufficient lead time taking into consideration the RPKI propagation delays.
証明書利用者（RP）または証明書利用者ルーティングソフトウェアの解釈では、「メイクビフォーブレーク」運用ポリシーを適用することが重要です。これは、ルートを明示的に無効にする有効なRPKIオブジェクトの存在によって別の方法で証明されない限り、ルートが意図されている（つまり、疑わしくないと見なされる）ルーティング決定プロセスをRPが実装する必要があることを意味します（例についてはセクション7.1を参照） ）。また、特に割り当て/サブ割り当てによってプレフィックスが新たに取得された場合、またはプレフィックス所有権の転送により、ROAはBGPでプレフィックスをアドバタイズする前にRPKIに登録する必要があります。これは、次の理由で強く推奨されます。転送の場合（組織Aから組織Bへのプレフィックス転送を考慮して）、組織Aのリソース証明書が組織Bにリソース証明書を発行する前に取り消される場合でも、すべての依存パーティが以前に受け取ったものを破棄するまでに遅延が発生する可能性があることに注意してください。そのプレフィックスの組織AのROA。レイテンシは、RPKIシステムでのCRL伝播遅延、またはRPによる定期的なポーリングなどが原因である可能性があります。また、サブ割り当ての場合（親組織Aから子組織Bへ）、既存のROA検討中のプレフィックスに関連するカバーする集約プレフィックスについて、組織Aによって（独自のオリジンASNを使用して）登録されています。新しいプレフィックスの所有者（組織B）が自分のROA（つまり、起源ASNを持つROA）をまだ登録していない場合、組織Aに属する別のカバーするROA（つまり、起源ASNが異なるもの）が存在します。新しい所有者（組織B）によってアドバタイズされたルートの無効な評価。したがって、どちらの場合（転送またはサブ割り当て）でも、ルートをアドバタイズする前に積極的にROAを発行して、プレフィックスのルートが有効であることを確認することは、新しい所有者（組織B）にとって賢明です。 ROAは、RPKI伝播遅延を考慮して十分なリードタイムで発行する必要があります。
As stated earlier in Section 1.3, for all of the use cases in this document, it is assumed that RPKI objects (e.g., resource certificates, ROAs) validate in accordance with [RFC6487] and [RFC6480]. In other words, we assume that corrupted RPKI objects, if any, have been detected and eliminated.
セクション1.3で前述したように、このドキュメントのすべての使用例では、RPKIオブジェクト（リソース証明書、ROAなど）が[RFC6487]および[RFC6480]に従って検証することを前提としています。つまり、破損したRPKIオブジェクトがある場合は、それが検出され、除去されたと想定します。
While many of the examples provided here illustrate organizations using their own autonomous system numbers to originate routes, it should be recognized that a prefix holder need not necessarily be the holder of the autonomous system number used for the route origination.
ここで提供する例の多くは、ルートを開始するために独自の自律システム番号を使用する組織を示していますが、プレフィックスホルダーは必ずしもルートの開始に使用される自律システム番号のホルダーである必要はないことを認識してください。
This section deals with the various use cases where an organization has Internet resources and will announce routes to the Internet. It is based on operational observations of the existing routing system. In the following use cases, the phrase "relying parties interpret the route as intended" is generally meant to indicate that "relying parties interpret an announced route as having a valid origination AS".
このセクションでは、組織にインターネットリソースがあり、インターネットへのルートをアナウンスするさまざまな使用例を扱います。これは、既存のルーティングシステムの運用上の観察に基づいています。以下のユースケースでは、「依存パーティが意図したとおりにルートを解釈する」という表現は一般に、「依存パーティがアナウンスされたルートを有効な発信元ASを持っていると解釈する」ことを示します。
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.2.0/24. It wishes to announce the /24 prefix from ASN 64496 such that relying parties interpret the route as intended.
組織（ASN 64496の組織A）には、プレフィックス10.1.2.0/24が割り当てられています。依存パーティが意図したとおりにルートを解釈できるように、ASN 64496からの/ 24プレフィックスを発表したいと考えています。
The desired announcement (and organization) would be:
望ましいアナウンス（および組織）は次のとおりです。
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.2.0/24 | AS 64496 | Org A |
+----------------------------------------------+
The issuing party should create a ROA containing the following:
発行者は、以下を含むROAを作成する必要があります。
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16. It wishes to announce the more specific prefix 10.1.0.0/20 from ASN 64496 as well as the aggregate route such that relying parties interpret the routes as intended.
組織（ASN 64496の組織A）には、プレフィックス10.1.0.0/16が割り当てられています。依存パーティが意図したとおりにルートを解釈できるように、ASN 64496からのより具体的なプレフィックス10.1.0.0/20と集約ルートをアナウンスしたいと考えています。
The desired announcements (and organization) would be:
望ましいアナウンス（および組織）は次のとおりです。
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64496 | Org A |
+----------------------------------------------+
The issuing party should create a ROA containing the following:
発行者は、以下を含むROAを作成する必要があります。
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
| |-----------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
An organization (Org A with ASN 64496 and ASN 64511) has been allocated the prefix 10.1.0.0/16. It wishes to announce the more specific prefix 10.1.0.0/20 from ASN 64511 as well as the aggregate route from ASN 64496 such that relying parties interpret the routes as intended.
組織（ASN 64496およびASN 64511の組織A）には、プレフィックス10.1.0.0/16が割り当てられています。依存パーティが意図したとおりにルートを解釈できるように、ASN 64511からのより具体的なプレフィックス10.1.0.0/20とASN 64496からの集約ルートをアナウンスしたいと考えています。
The desired announcements (and organization) would be:
望ましいアナウンス（および組織）は次のとおりです。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64511 | Org A |
+---------------------------------------------+
The issuing party should create ROAs containing the following:
発行者は、以下を含むROAを作成する必要があります。
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16; it wishes to announce the more specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 to a customer (Org B with ASN 64511) who is multi-homed and will originate the prefix route from ASN 64511. ASN 64496 will also announce the aggregate route such that relying parties interpret the routes as intended.
組織（ASN 64496の組織A）には、プレフィックス10.1.0.0/16が割り当てられています。 ASN 64496からより具体的なプレフィックス10.1.0.0/20を発表したいと考えています。さらに、マルチホームで、ASN 64511からプレフィックスルートを発信する顧客（組織BとASN 64511）に10.1.16.0/20を委任しました。 ASN 64496は、依存ルートが意図したとおりにルートを解釈するように、集約ルートもアナウンスします。
The desired announcements (and organizations) would be:
必要なアナウンス（および組織）は次のとおりです。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64496 | Org A |
| 10.1.16.0/20 | AS 64511 | Org B |
+---------------------------------------------+
The issuing party should create ROAs containing the following:
発行者は、以下を含むROAを作成する必要があります。
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
| |-----------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
An organization has recently been allocated the prefix 10.1.0.0/16. Its network deployment is not yet ready to announce the prefix and wishes to restrict all possible announcements of 10.1.0.0/16 and more specifics in routing using RPKI.
最近、組織にプレフィックス10.1.0.0/16が割り当てられました。そのネットワーク配備はまだプレフィックスを発表する準備ができておらず、RPKIを使用したルーティングにおいて、10.1.0.0 / 16の可能性のあるすべてのアナウンスと詳細を制限したいと考えています。
The following announcements would be considered undesirable:
次のアナウンスは望ましくないと見なされます。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | ANY AS | ANY |
| 10.1.0.0/20 | ANY AS | ANY |
| 10.1.17.0/24 | ANY AS | ANY |
+---------------------------------------------+
The issuing party should create a ROA containing the following:
発行者は、以下を含むROAを作成する必要があります。
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.0.0/16 | 32 |
+----------------------------------------------+
This is known as an AS 0 ROA [RFC6483]. Also, please see the definition and related comments in Section 1.3.
これはAS 0 ROA [RFC6483]として知られています。また、セクション1.3の定義と関連コメントも参照してください。
An organization has recently been allocated an additional ASN 64511. Its network deployment is not yet ready to use this ASN and wishes to restrict all possible uses of ASN 64511 using RPKI.
最近、組織に追加のASN 64511が割り当てられました。そのネットワーク展開では、このASNを使用する準備がまだ整っておらず、RPKIを使用してASN 64511のすべての可能な使用を制限したいと考えています。
The following announcement would be considered undesirable:
次の発表は望ましくないと見なされます。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| ANY | AS 64511 | ANY |
+---------------------------------------------+
It is currently not possible to restrict use of autonomous system numbers.
現在、自律システム番号の使用を制限することはできません。
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16. Its network topology permits the announcement of 10.1.0.0/17. Org A wishes to restrict any possible announcement of 10.1.128.0/17 or more specifics of that /17 using RPKI.
組織（ASN 64496の組織A）には、プレフィックス10.1.0.0/16が割り当てられています。そのネットワークトポロジは10.1.0.0/17のアナウンスを許可します。組織Aは、RPKIを使用して、その/ 17の10.1.128.0/17またはそれ以上の詳細の可能なアナウンスを制限したいと考えています。
The desired announcement (and organization) would be:
望ましいアナウンス（および組織）は次のとおりです。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/17 | AS 64496 | Org A |
+---------------------------------------------+
The following announcements would be considered undesirable:
次のアナウンスは望ましくないと見なされます。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.128.0/17 | ANY AS | ANY |
| 10.1.128.0/24 | ANY AS | ANY |
+---------------------------------------------+
The issuing party should create ROAs containing the following:
発行者は、以下を含むROAを作成する必要があります。
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/17 | 17 |
+----------------------------------------------+
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 0 | 10.1.128.0/17 | 32 |
+----------------------------------------------+
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16; it wishes to announce the aggregate and any or all more specific prefixes up to and including a maximum length of /20, but never any more specific than a /20.
組織（ASN 64496の組織A）には、プレフィックス10.1.0.0/16が割り当てられています。集合体と最大長が/ 20までの特定のプレフィックスのいずれかまたはすべてをアナウンスしたいが、/ 20よりも具体的なものは決してない。
Examples of the desired announcements (and organization) would be:
必要なアナウンス（および組織）の例は次のとおりです。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/17 | AS 64496 | Org A |
| ... | AS 64496 | Org A |
| 10.1.128.0/20 | AS 64496 | Org A |
+---------------------------------------------+
The following announcements would be considered undesirable:
次のアナウンスは望ましくないと見なされます。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/21 | ANY AS | ANY |
| 10.1.0.0/22 | ANY AS | ANY |
| ... | ANY AS | ANY |
| 10.1.128.0/24 | ANY AS | ANY |
+---------------------------------------------+
The issuing party should create a ROA containing the following:
発行者は、以下を含むROAを作成する必要があります。
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 20 |
+----------------------------------------------+
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16. It sub-allocates several /20 prefixes to its multi-homed customers: Org B with ASN 64501 and Org C with ASN 64499, respectively. It wishes to restrict those customers from advertising any corresponding routes more specific than a /22.
組織（ASN 64496の組織A）には、プレフィックス10.1.0.0/16が割り当てられています。複数の/ 20プレフィックスを複数のホームを持つ顧客にサブ割り当てします。それぞれ、ASN 64501を使用するOrg BおよびASN 64499を使用するOrg Cです。それらの顧客が、/ 22よりも具体的な対応するルートを広告しないように制限したいと考えています。
The desired announcements (and organizations) would be:
必要なアナウンス（および組織）は次のとおりです。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A |
| 10.1.0.0/20 | AS 64501 | Org B |
| 10.1.128.0/20 | AS 64499 | Org C |
| 10.1.4.0/22 | AS 64501 | Org B |
+---------------------------------------------+
The following example announcements (and organizations) would be considered undesirable:
次のアナウンスの例（および組織）は望ましくないと見なされます。
+---------------------------------------------+
| Prefix | Origin AS |Organization |
+---------------------------------------------+
| 10.1.0.0/24 | AS 64501 | Org B |
| 10.1.128.0/24 | AS 64499 | Org C |
| ..... | ... | ... |
| 10.1.0.0/23 | ANY AS | ANY |
+---------------------------------------------+
The issuing party (Org A) should create ROAs containing the following:
発行者（組織A）は、以下を含むROAを作成する必要があります。
For Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64501 | 10.1.0.0/20 | 22 |
+----------------------------------------------+
For Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.128.0/20 | 22 |
+----------------------------------------------+
Consider four organizations with the following resources, which were acquired independently from any transit provider.
次のリソースを備えた4つの組織について考えてみましょう。これらは、交通機関から独立して取得されたものです。
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS 64496 | 10.1.0.0/24 |
| Org B | AS 64505 | 10.1.3.0/24 |
| Org C | AS 64499 | 10.1.1.0/24 |
| Org D | AS 64511 | 10.1.2.0/24 |
+-------------------------------------------------+
These organizations share a common upstream provider Transit X (ASN 64497) that originates an aggregate of these prefixes with the permission of all four organizations.
これらの組織は、4つの組織すべての許可を得て、これらのプレフィックスの集約を発信する共通のアップストリームプロバイダーであるTransit X（ASN 64497）を共有しています。
The desired announcements (and organizations) would be:
必要なアナウンス（および組織）は次のとおりです。
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS 64496 | Org A |
| 10.1.3.0/24 | AS 64505 | Org B |
| 10.1.1.0/24 | AS 64499 | Org C |
| 10.1.2.0/24 | AS 64511 | Org D |
| 10.1.0.0/22 | AS 64497 | Transit X |
+----------------------------------------------+
It is currently not possible for an upstream provider to make a valid aggregate announcement of independent prefixes. However, the issuing parties should create ROAs containing the following:
現在、アップストリームプロバイダーが独立したプレフィックスの有効な集約アナウンスを行うことはできません。ただし、発行者は以下を含むROAを作成する必要があります。
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64505 | 10.1.3.0/24 | 24 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+
Org D:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
Consider four organizations with the following resources that were acquired independently from any transit provider.
交通機関から独立して取得された次のリソースを持つ4つの組織について考えてみます。
+-------------------------------------------------+
| Organization | ASN | Prefix |
+-------------------------------------------------+
| Org A | AS 64496 | 10.1.0.0/24 |
| Org B | AS 64503 | 10.1.3.0/24 |
| Org C | AS 64499 | 10.1.1.0/24 |
| Org D | AS 64511 | 10.1.2.0/24 |
+-------------------------------------------------+
These organizations share a common upstream provider Transit X (ASN 64497) that originates an aggregate of these prefixes where possible. In this situation, Org B (ASN 64503, 10.1.3.0/24) does not wish for its prefix to be aggregated by the upstream provider.
これらの組織は、可能な場合はこれらのプレフィックスの集約を発信する共通のアップストリームプロバイダーであるTransit X（ASN 64497）を共有しています。この状況では、組織B（ASN 64503、10.1.3.0 / 24）は、そのプレフィックスが上流のプロバイダーによって集約されることを望んでいません。
The desired announcements (and organizations) would be:
必要なアナウンス（および組織）は次のとおりです。
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/24 | AS 64496 | Org A |
| 10.1.3.0/24 | AS 64503 | Org B |
| 10.1.1.0/24 | AS 64499 | Org C |
| 10.1.2.0/24 | AS 64511 | Org D |
| 10.1.0.0/23 | AS 64497 | Transit X |
+----------------------------------------------+
The following announcement would be considered undesirable:
次の発表は望ましくないと見なされます。
+----------------------------------------------+
| Prefix | Origin AS | Organization |
+----------------------------------------------+
| 10.1.0.0/22 | AS 64497 | Transit X |
+----------------------------------------------+
It is currently not possible for an upstream provider to make a valid aggregate announcement of independent prefixes. However, the issuing parties should create ROAs containing the following:
現在、アップストリームプロバイダーが独立したプレフィックスの有効な集約アナウンスを行うことはできません。ただし、発行者は以下を含むROAを作成する必要があります。
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/24 | 24 |
+----------------------------------------------+
Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64503 | 10.1.3.0/24 | 24 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64499 | 10.1.1.0/24 | 24 |
+----------------------------------------------+
Org D:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.2.0/24 | 24 |
+----------------------------------------------+
Use cases pertaining to adjacency or path validation are beyond the scope of this document and would be addressed in a separate document.
隣接関係またはパス検証に関連する使用例は、このドキュメントの範囲外であり、別のドキュメントで扱われます。
An organization (Org A with ASN 64511) is multi-homed and has been assigned the prefix 10.1.0.0/20 from its upstream (Transit X with ASN 64496). Org A wishes to announce the prefix 10.1.0.0/20 from ASN 64511 to its other upstream(s). Org A also wishes to create RPKI statements about the resource; however, Transit X (ASN 64496), which announces the aggregate 10.1.0.0/16, has not yet adopted RPKI.
組織（ASN 64511を備えた組織A）はマルチホームであり、その上流（ASN 64496を備えたトランジットX）からプレフィックス10.1.0.0/20が割り当てられています。組織Aは、プレフィックス10.1.0.0/20をASN 64511から他のアップストリームにアナウンスしたいと考えています。組織Aは、リソースに関するRPKIステートメントも作成したいと考えています。ただし、集約10.1.0.0/16を発表するTransit X（ASN 64496）はまだRPKIを採用していません。
The desired announcements (and organization with RPKI adoption) would be:
望ましいアナウンス（およびRPKIを採用している組織）は次のとおりです。
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/20 | AS 64511 | Org A | Yes |
| 10.1.0.0/16 | AS 64496 | Transit X | No |
+----------------------------------------------------+
RPKI is strictly hierarchical; therefore, if Transit X does not participate in RPKI, Org A is unable to validly issue RPKI objects.
RPKIは厳密に階層的です。したがって、Transit XがRPKIに参加しない場合、組織AはRPKIオブジェクトを有効に発行できません。
An organization (Org A with ASN 64496) has been allocated the prefix 10.1.0.0/16 and participates in RPKI; it wishes to announce the more specific prefix 10.1.0.0/20 from ASN 64496. It has further delegated 10.1.16.0/20 and 10.1.32.0/20 to customers Org B with ASN 64511 and Org C with ASN 64502 (respectively), who are multi-homed. Org B (ASN 64511) does not participate in RPKI. Org C (ASN 64502) participates in RPKI.
組織（ASN 64496の組織A）には、プレフィックス10.1.0.0/16が割り当てられ、RPKIに参加しています。 ASN 64496からより具体的なプレフィックス10.1.0.0/20を発表したいと考えています。さらに、10.1.16.0 / 20と10.1.32.0/20を、ASN 64511を使用するOrg BおよびASN 64502を使用するOrg Cにそれぞれ委任しました。マルチホームです。組織B（ASN 64511）はRPKIに参加していません。組織C（ASN 64502）はRPKIに参加しています。
The desired announcements (and organizations with RPKI adoption) would be:
望ましい発表（およびRPKIを採用している組織）は次のとおりです。
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A | Yes |
| 10.1.0.0/20 | AS 64496 | Org A | Yes |
| 10.1.16.0/20 | AS 64511 | Org B | No |
| 10.1.32.0/20 | AS 64502 | Org C | Yes |
+----------------------------------------------------+
The issuing parties should create ROAs containing the following:
発行当事者は、以下を含むROAを作成する必要があります。
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A issues for Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64502 | 10.1.32.0/20 | 20 |
+----------------------------------------------+
Consider the previous example, with an extension by which Org B, who does not participate in RPKI, further allocates 10.1.17.0/24 to Org X with ASN 64505. Org X does not participate in RPKI.
RPKIに参加していないOrg Bがさらに10.1.17.0/24をASN 64505を使用してOrg Xに割り当てる拡張機能を備えた前の例を検討してください。OrgXはRPKIに参加していません。
The desired announcements (and organizations with RPKI adoption) would be:
望ましい発表（およびRPKIを採用している組織）は次のとおりです。
+----------------------------------------------------+
| Prefix | Origin AS |Organization | RPKI |
+----------------------------------------------------+
| 10.1.0.0/16 | AS 64496 | Org A | Yes |
| 10.1.0.0/20 | AS 64496 | Org A | Yes |
| 10.1.16.0/20 | AS 64511 | Org B | No |
| 10.1.32.0/20 | AS 64502 | Org C | Yes |
| 10.1.17.0/24 | AS 64505 | Org X | No |
+----------------------------------------------------+
The issuing parties should create ROAs containing the following:
発行当事者は、以下を含むROAを作成する必要があります。
Org A:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
| | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A issues for Org B:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.16.0/20 | 20 |
+----------------------------------------------+
Org A issues for Org B's customer Org X:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64505 | 10.1.17.0/24 | 24 |
+----------------------------------------------+
Org C:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64502 | 10.1.32.0/20 | 20 |
+----------------------------------------------+
For transfer use cases, based on the preceding sections, it should be easy to deduce what new ROAs need to be created and what existing ROAs need to be maintained (or revoked). The resource transfer and timing of revocation/creation of the ROAs need to be performed based on the make-before-break principle and using suitable Regional Internet Registry (RIR) procedures (see Section 2.1).
転送のユースケースでは、前のセクションに基づいて、作成する必要がある新しいROAと、維持する（または取り消す）必要がある既存のROAを簡単に推測できます。リソース転送およびROAの失効/作成のタイミングは、make-before-break原則に基づいて、適切な地域インターネットレジストリ（RIR）手順を使用して実行する必要があります（セクション2.1を参照）。
Org A holds the resource 10.1.0.0/20, and it is currently in use and originated from AS 64496 with valid RPKI objects in place. Org B has acquired both the prefix and ASN and desires an RPKI transfer on a particular date and time without adversely affecting the operational use of the resource.
組織Aはリソース10.1.0.0/20を保持しており、現在使用されており、有効なRPKIオブジェクトを備えたAS 64496から発信されています。組織BはプレフィックスとASNの両方を取得し、リソースの運用上の使用に悪影響を与えることなく、特定の日時にRPKI転送を希望しています。
The following RPKI objects would be created/revoked:
次のRPKIオブジェクトが作成または取り消されます。
For Org A, revoke the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
For Org B, add the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/20 | 20 |
+----------------------------------------------+
Org A holds the resource 10.1.0.0/16, and it is currently in use and originated from AS 64496 with valid RPKI objects in place. Org A has agreed to transfer the entire /16 address block to Org B and will no longer originate the prefix or more specifics of it. Consequently, Org B desires an RPKI transfer of this resource on a particular date and time. This prefix will be originated by AS 64511 as a result of this transfer.
組織Aはリソース10.1.0.0/16を保持しており、現在使用されており、有効なRPKIオブジェクトを備えたAS 64496から発信されています。組織Aは、/ 16アドレスブロック全体を組織Bに転送することに同意し、プレフィックスまたはそれ以上の詳細を発信しなくなります。したがって、組織Bは、特定の日時にこのリソースのRPKI転送を希望しています。この転送の結果、このプレフィックスはAS 64511によって発信されます。
The following RPKI objects would be created/revoked:
次のRPKIオブジェクトが作成または取り消されます。
For Org A, revoke the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org B, add the following ROA when the resource certificate for 10.1.0.0/16 is issued to them (Org B):
組織Bの場合、10.1.0.0 / 16のリソース証明書が発行されたら、次のROAを追加します（組織B）。
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64511 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
Org A holds the resources 10.1.0.0/16 and AS 64507 (with RPKI objects). Org A currently announces 10.1.0.0/16 from AS 64507. Org B has acquired an unused portion (10.1.4.0/24) of the prefix from Org A and desires an RPKI transfer on a particular date and time. Org B will originate a route 10.1.4.0/24 from AS 64496.
組織Aは、リソース10.1.0.0/16およびAS 64507（RPKIオブジェクトを含む）を保持しています。組織Aは現在、AS 64507から10.1.0.0/16を発表しています。組織Bは、組織Aからプレフィックスの未使用部分（10.1.4.0/24）を取得しており、特定の日時にRPKI転送を希望しています。組織BはAS 64496からルート10.1.4.0/24を発信します。
The following RPKI objects would be created/sustained:
次のRPKIオブジェクトが作成/維持されます。
For Org A, leave the following ROA unchanged:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64507 | 10.1.0.0/16 | 16 |
+----------------------------------------------+
For Org B, add the following ROA when the resource certificate for 10.1.4.0/24 is issued to them (Org B):
組織Bの場合、10.1.4.0 / 24のリソース証明書が発行されたら、次のROAを追加します（組織B）。
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.4.0/24 | 24 |
+----------------------------------------------+
Org A may optionally provide ROA coverage for Org B by creating the following ROA preceding the RPKI transfer. The ROA itself is then naturally revoked when 10.1.4.0/24 is transferred to Org B's resource certificate.
組織Aは、オプションで、RPKI転送の前に次のROAを作成することにより、組織BにROAカバレッジを提供できます。その後、10.1.4.0 / 24が組織Bのリソース証明書に転送されると、ROA自体が自然に取り消されます。
Org A adds the following ROA:
+----------------------------------------------+
| asID | address | maxLength |
+----------------------------------------------+
| 64496 | 10.1.4.0/24 | 24 |
+----------------------------------------------+
These use cases try to systematically enumerate the situations a relying party may encounter while receiving a BGP update and making use of ROA information to interpret the validity of the prefix-origin information in the routes derived from the update. We enumerate the situations or scenarios and include a recommendation for the expected outcome of prefix-origin validation. For a description of prefix-origin validation algorithms, see [RFC6483] and [RFC6811]. We use the terms Valid, Invalid, and NotFound as defined in [RFC6811] and summarized earlier in Section 1.3. Also see [RFC6472] for a recommendation to deprecate AS_SETs in BGP updates. The use cases described here can be potentially used as test cases for testing and evaluation of prefix-origin validation in router implementations; see, for example, [BRITE].
これらの使用例は、BGP更新を受信し、ROA情報を利用して更新から派生したルートのプレフィックス発信元情報の有効性を解釈している間に、依存パーティが遭遇する可能性のある状況を体系的に列挙しようとします。状況またはシナリオを列挙し、プレフィックス発生元検証の予期される結果に対する推奨を含めます。プレフィクスオリジン検証アルゴリズムの説明については、[RFC6483]および[RFC6811]を参照してください。 [RFC6811]で定義され、セクション1.3で前に要約されているように、Valid、Invalid、およびNotFoundという用語を使用します。 BGP更新でAS_SETを廃止するための推奨事項については、[RFC6472]も参照してください。ここで説明する使用例は、ルーター実装での接頭辞の検証をテストおよび評価するためのテストケースとして潜在的に使用できます。たとえば、[BRITE]を参照してください。
ROA: {10.1.0.0/16, maxLength = 20, AS 64496}
Route has {10.1.0.0/17, Origin = AS 64496}
Recommended RPKI prefix-origin validation interpretation: Route is Valid.
推奨されるRPKIプレフィックス起点検証の解釈：ルートは有効です。
Comment: The route prefix has a covering ROA prefix, and the route origin ASN matches the ROA ASN. This is a straightforward prefix-origin validation use case; it follows from the primary intention of creation of the ROA by a prefix holder.
コメント：ルートプレフィックスにはカバーするROAプレフィックスがあり、ルートの起点ASNはROA ASNと一致します。これは、単純なプレフィックスオリジン検証の使用例です。これは、プレフィックスホルダーによるROAの作成を主な目的としています。
ROA: {10.1.0.0/16, maxLength = 20, AS 64496}
Route has {10.1.0.0/22, Origin = AS 64496}
No other covering ROA
他のカバーするROA
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
推奨されるRPKIプレフィックス起点検証の解釈：ルートが無効です。
Comment: In this case, the maxLength specified in the ROA is exceeded by the route prefix.
コメント：この場合、ROAで指定されたmaxLengthがルートプレフィックスを超えています。
ROA: {10.1.0.0/16, maxLength = 24, AS 64496}
Route has {10.1.88.0/24, Origin = AS 64511}
No other covering ROA Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
ROAが推奨するRPKIプレフィクスオリジン検証解釈をカバーする他のものはありません：ルートが無効です。
Comment: In this case, an AS other than the one specified in the ROA is originating the route. This may be a prefix or subprefix hijack situation.
コメント：この場合、ROAで指定されたもの以外のASがルートを発信しています。これは、プレフィックスまたはサブプレフィックスのハイジャックの状況である可能性があります。
ROA: {10.1.0.0/16, maxLength = 22, AS 64496}
Route has {10.1.88.0/24, Origin = AS 64511}
No other covering ROA
他のカバーするROA
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
推奨されるRPKIプレフィックス起点検証の解釈：ルートが無効です。
Comment: In this case, the maxLength specified in the ROA is exceeded by the route prefix, and also an AS other than the one specified in the ROA is originating the route. This may be a subprefix hijack situation.
コメント：この場合、ROAで指定されたmaxLengthがルートプレフィックスを超えており、ROAで指定されたもの以外のASがルートを発信しています。これは、サブプレフィックスハイジャックの状況である可能性があります。
Route has {10.1.3.0/24, Origin = AS 64511}
No covering ROA
ROAをカバーしない
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound.
推奨されるRPKIプレフィックス起点検証の解釈：ルートの検証ステータスはNotFoundです。
Comment: In this case, there is no covering ROA for the route prefix. It could be a prefix or subprefix hijack situation, but this announcement does not contradict any existing ROA. During partial deployment, there would be some legitimate prefix-origin announcements for which ROAs may not have been issued yet.
コメント：この場合、ルートプレフィックスの対象となるROAはありません。プレフィックスまたはサブプレフィックスのハイジャックの状況である可能性がありますが、この発表は既存のROAと矛盾しません。部分的な展開中は、ROAがまだ発行されていない可能性のある正当なプレフィックス発信元のアナウンスがいくつかあります。
ROA: {10.1.0.0/16, maxLength = 32, AS 0}
Route has {10.1.5.0/24, Origin = AS 64511}
Recommended RPKI prefix-origin validation interpretation: Route's validation status is Invalid.
推奨されるRPKIプレフィックス起点検証の解釈：ルートの検証ステータスは無効です。
Comment: An AS 0 ROA implies by definition that the prefix listed in it and all of the more specifics of that prefix should not be used in a routing context [RFC6483] [AS0-PROC]. Also, please see related comments in Section 1.3.
コメント：AS 0 ROAは、定義により、それにリストされているプレフィックスとそのプレフィックスのより詳細なものすべてをルーティングコンテキスト[RFC6483] [AS0-PROC]で使用しないでください。また、セクション1.3の関連コメントも参照してください。
7.1.7. Covering ROA Prefix Not Found but ROAs Exist for a Covering Set of More Specifics
7.1.7. カバーするROAプレフィックスは見つかりませんが、より詳細なカバーセットのROAが存在します
ROA: {10.1.0.0/18, maxLength = 20, AS 64496}
ROA: {10.1.64.0/18, maxLength = 20, AS 64496}
ROA: {10.1.128.0/18, maxLength = 20, AS 64496}
ROA: {10.1.192.0/18, maxLength = 20, AS 64496}
Route has {10.1.0.0/16, Origin = AS 64496}
No covering ROA
ROAをカバーしない
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound.
推奨されるRPKIプレフィックス起点検証の解釈：ルートの検証ステータスはNotFoundです。
Comment: In this case, the route prefix is an aggregate (/16), and it turns out that there exist ROAs for more specifics (/18s) that, if combined, can help support validation of the announced prefix-origin pair. But it is very hard in general to break up an announced prefix into constituent more specifics and check for ROA coverage for those more specifics, and hence this type of accommodation is not recommended.
コメント：この場合、ルートプレフィックスは集約（/ 16）であり、組み合わせた場合、アナウンスされたプレフィックス-起源ペアの検証をサポートするのに役立つ、より詳細な（/ 18s）のROAが存在することがわかります。しかし、一般に、アナウンスされたプレフィックスを構成要素のより具体的なものに分割し、それらのより具体的なROAカバレッジをチェックすることは非常に難しいため、このタイプの宿泊施設は推奨されません。
Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
ルートの{10.1.0.0/16、AS_SET [AS 64496、AS 64497、AS 64498、AS 64499]がAS_PATHの右端に表示されます}
No covering ROA
ROAをカバーしない
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound.
推奨されるRPKIプレフィックス起点検証の解釈：ルートの検証ステータスはNotFoundです。
Comment: An extremely small percentage (~0.1%) of external BGP (eBGP) updates are seen to have an AS_SET in them; this is known as proxy aggregation. In this case, the route with the AS_SET does not conflict with any ROA (i.e., the route prefix has no covering ROA prefix). Therefore, the route gets NotFound validation status.
コメント：外部BGP（eBGP）更新の非常に小さいパーセンテージ（〜0.1％）にAS_SETが含まれているようです。これはプロキシ集約と呼ばれます。この場合、AS_SETを使用したルートはどのROAとも競合しません（つまり、ルートプレフィックスには対象のROAプレフィックスがありません）。したがって、ルートはNotFound検証ステータスを取得します。
7.1.9. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and AS Match
7.1.9. AS_SET内のシングルトンAS（ルート内）、カバーするROAプレフィックス、およびASマッチ
Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost position in the AS_PATH}
ルートには{10.1.0.0/24、AS_SET [AS 64496]がAS_PATHの右端に表示されます}
ROA: {10.1.0.0/22, maxLength = 24, AS 64496}
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
推奨されるRPKIプレフィックス起点検証の解釈：ルートが無効です。
Comment: In the spirit of [RFC6472], any route with an AS_SET in it should not be considered valid (by ROA-based validation). If the route contains an AS_SET and a covering ROA prefix exists for the route prefix, then the route should get an Invalid status. (Note: AS match or mismatch consideration does not apply.)
コメント：[RFC6472]の精神に基づき、AS_SETが含まれているルートは（ROAベースの検証により）有効と見なされるべきではありません。ルートにAS_SETが含まれていて、ルートプレフィックスに対応するROAプレフィックスが存在する場合、ルートは無効なステータスになります。 （注：ASの一致または不一致の考慮事項は適用されません。）
7.1.10. Singleton AS in AS_SET (in the Route), Covering ROA Prefix, and AS Mismatch
7.1.10. AS_SET内のシングルトンAS（ルート内）、ROAプレフィックス、ASミスマッチをカバー
Route has {10.1.0.0/24, AS_SET [AS 64496] appears in the rightmost position in the AS_PATH}
ルートには{10.1.0.0/24、AS_SET [AS 64496]がAS_PATHの右端に表示されます}
ROA: {10.1.0.0/22, maxLength = 24, AS 64511}
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
推奨されるRPKIプレフィックス起点検証の解釈：ルートが無効です。
Comment: If the route contains an AS_SET and a covering ROA prefix exists for the route prefix, then the route should get an Invalid status. (Note: AS match or mismatch consideration does not apply.)
コメント：ルートにAS_SETが含まれ、ルートプレフィックスに対応するROAプレフィックスが存在する場合、ルートは無効なステータスになります。 （注：ASの一致または不一致の考慮事項は適用されません。）
Route has {10.1.0.0/22, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
ルートの{10.1.0.0/22、AS_SET [AS 64496、AS 64497、AS 64498、AS 64499]がAS_PATHの右端に表示されます}
ROA: {10.1.0.0/22, maxLength = 24, AS 64509}
No other covering ROA
他のカバーするROA
Recommended RPKI prefix-origin validation interpretation: Route is Invalid.
推奨されるRPKIプレフィックス起点検証の解釈：ルートが無効です。
Comment: If the route contains an AS_SET and a covering ROA prefix exists for the route prefix, then the route should get an Invalid status.
コメント：ルートにAS_SETが含まれ、ルートプレフィックスに対応するROAプレフィックスが存在する場合、ルートは無効なステータスになります。
7.1.12. Multiple ASs in AS_SET (in the Route) and ROAs Exist for a Covering Set of More Specifics
7.1.12. AS_SET内の複数のAS（ルート内）とROAが存在し、より詳細なセットをカバーする
ROA: {10.1.0.0/18, maxLength = 20, AS 64496}
ROA: {10.1.64.0/18, maxLength = 20, AS 64497}
ROA: {10.1.128.0/18, maxLength = 20, AS 64498}
ROA: {10.1.192.0/18, maxLength = 20, AS 64499}
Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
Route has {10.1.0.0/16, AS_SET [AS 64496, AS 64497, AS 64498, AS 64499] appears in the rightmost position in the AS_PATH}
No covering ROA
ROAをカバーしない
Recommended RPKI prefix-origin validation interpretation: Route's validation status is NotFound.
推奨されるRPKIプレフィックス起点検証の解釈：ルートの検証ステータスはNotFoundです。
Comment: In this case, the aggregate of the prefixes in the ROAs is a covering prefix (i.e., exact match or less specific) relative to the route prefix. The ASs in each of the contributing ROAs together form a set that matches the AS_SET in the route. But it is very hard in general to break up an announced prefix into constituent more specifics and check for ROA coverage for those more specifics. In any case, it may be noted once again that in the spirit of [RFC6472], any route with an AS_SET in it should not be considered valid (by ROA-based validation). In fact, the route under consideration would have received an Invalid status if the route prefix had at least one covering ROA prefix.
Comment: In this case, the aggregate of the prefixes in the ROAs is a covering prefix (i.e., exact match or less specific) relative to the route prefix. The ASs in each of the contributing ROAs together form a set that matches the AS_SET in the route. But it is very hard in general to break up an announced prefix into constituent more specifics and check for ROA coverage for those more specifics. In any case, it may be noted once again that in the spirit of [RFC6472], any route with an AS_SET in it should not be considered valid (by ROA-based validation). In fact, the route under consideration would have received an Invalid status if the route prefix had at least one covering ROA prefix.
Here we enumerate use cases corresponding to router actions when RPKI objects expire or are revoked. In the cases that follow, the terms "expired ROA" or "revoked ROA" are shorthand and describe the expiry or revocation of the End Entity (EE) or resource certificate that causes a relying party to consider the corresponding ROA to have expired or been revoked, respectively.
ここでは、RPKIオブジェクトが期限切れになるか取り消されたときのルーターアクションに対応するユースケースを列挙します。以下の場合、「失効したROA」または「失効したROA」という用語は省略形であり、エンドエンティティ（EE）またはリソース証明書の失効または失効を説明します。これにより、依存パーティは対応するROAが失効または失効したと見なします。それぞれ取り消されました。
A certificate revocation list (CRL) is received that reveals that the ROA {10.1.0.0/22, maxLength = 24, ASN 64496} is revoked. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. In the absence of said revoked ROA, no covering ROA prefix exists for the route prefix (i.e., 10.1.3.0/24).
ROA {10.1.0.0/22、maxLength = 24、ASN 64496}が取り消されていることを示す証明書失効リスト（CRL）を受信しました。さらに、ASN 64496を起点とする10.1.3.0/24のインターネットルーティングシステムには、ルートが存在します。この失効したROAがない場合、ルートプレフィックスのカバーするROAプレフィックスは存在しません（つまり、10.1.3.0 / 24）。
The Relying Party interpretation would be: Route's validation status is NotFound.
The Relying Party interpretation would be: Route's validation status is NotFound.
7.2.2. ROA of Prefix Revoked while Parent Prefix Has Covering ROA Prefix with Different ASN
7.2.2. 親プレフィックスに異なるASNのROAプレフィックスが含まれているときに取り消されたプレフィックスのROA
A CRL is received that reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} is revoked. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64511}. No other covering ROA exists for the 10.1.3.0/24 prefix.
ROA {10.1.3.0/24、maxLength = 24、ASN 64496}が取り消されていることを明らかにするCRLが受信されます。さらに、ASN 64496を起点とする10.1.3.0/24のインターネットルーティングシステムにルートが存在します。さらに、親プレフィックス10.1.0.0/22に有効なROAが存在し、ROAは{10.1.0.0/22、maxLength = 24、ASN 64511}。 10.1.3.0/24プレフィックスには、他のカバーするROAはありません。
The Relying Party interpretation would be: Route is Invalid.
依拠当事者の解釈は次のようになります：ルートが無効です。
A CRL is received that reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} is revoked. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
ROA {10.1.3.0/24、maxLength = 24、ASN 64496}が取り消されていることを明らかにするCRLが受信されます。さらに、ASN 64496から発信された10.1.3.0/24のインターネットルーティングシステムにルートが存在します。さらに、親プレフィックス10.1.0.0/22に有効なROAが存在し、ROAは{10.1.0.0/22、maxLength = 24、ASN 64496}。
The Relying Party interpretation would be: Route is Valid.
The Relying Party interpretation would be: Route is Valid.
(Clarification: Perhaps the revocation of the ROA for prefix 10.1.3.0/24 was initiated just to eliminate redundancy.)
（説明：おそらく、冗長性を排除するためだけに、プレフィックス10.1.3.0/24のROAの取り消しが開始されました。）
7.2.4. ROA of Grandparent Prefix Revoked while That of Parent Prefix Prevails
7.2.4. 親の接頭辞のROAが有効である一方で、祖父母の接頭辞のROAが取り消された
A CRL is received that reveals that the ROA {10.1.0.0/20, maxLength = 24, ASN 64496} is revoked. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
ROA {10.1.0.0/20、maxLength = 24、ASN 64496}が取り消されていることを明らかにするCRLが受信されます。さらに、ASN 64496から発信された10.1.3.0/24のインターネットルーティングシステムにルートが存在します。さらに、親プレフィックス10.1.0.0/22に有効なROAが存在し、ROAは{10.1.0.0/22、maxLength = 24、ASN 64496}。
The Relying Party interpretation would be: Route is Valid.
依拠当事者の解釈は次のようになります：ルートは有効です。
(Clarification: The ROA for less specific grandparent prefix 10.1.0.0/20 was revoked or withdrawn.)
（明確化：より具体的でない祖父母の接頭辞10.1.0.0/20のROAは取り消されるか取り下げられました。）
A scan of the ROA list reveals that the ROA {10.1.0.0/22, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. In the absence of said expired ROA, no covering ROA prefix exists for the route prefix (i.e., 10.1.3.0/24).
ROAリストをスキャンすると、ROA {10.1.0.0/22、maxLength = 24、ASN 64496}の有効期限が切れていることがわかります。さらに、ASN 64496を起点とする10.1.3.0/24のインターネットルーティングシステムには、ルートが存在します。この期限切れのROAがない場合、ルートプレフィックスに対応するROAプレフィックスは存在しません（つまり、10.1.3.0 / 24）。
The Relying Party interpretation would be: Route's validation status is NotFound.
証明書利用者の解釈は次のようになります。ルートの検証ステータスはNotFoundです。
7.2.6. Expiry of ROA of Prefix while Parent Prefix Has Covering ROA with Different ASN
7.2.6. 親プレフィックスに異なるASNのROAが含まれている場合のプレフィックスのROAの期限切れ
A scan of the ROA list reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64511}. No other covering ROA exists for the prefix (i.e., 10.1.3.0/24).
ROAリストをスキャンすると、ROA {10.1.3.0/24、maxLength = 24、ASN 64496}の有効期限が切れていることがわかります。さらに、ASN 64496を起点とする10.1.3.0/24のインターネットルーティングシステムにルートが存在します。さらに、親プレフィックス10.1.0.0/22に有効なROAが存在し、ROAは{10.1.0.0/22、maxLength = 24、ASN 64511}。プレフィックスに他のカバーするROAは存在しません（つまり、10.1.3.0 / 24）。
The Relying Party interpretation would be: Route is Invalid.
依拠当事者の解釈は次のようになります：ルートが無効です。
A scan of the ROA list reveals that the ROA {10.1.3.0/24, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
ROAリストをスキャンすると、ROA {10.1.3.0/24、maxLength = 24、ASN 64496}の有効期限が切れていることがわかります。さらに、ASN 64496から発信された10.1.3.0/24のインターネットルーティングシステムにルートが存在します。さらに、親プレフィックス10.1.0.0/22に有効なROAが存在し、ROAは{10.1.0.0/22、maxLength = 24、ASN 64496}。
The Relying Party interpretation would be: Route is Valid.
依拠当事者の解釈は次のようになります：ルートは有効です。
7.2.8. Expiry of ROA of Grandparent Prefix while That of Parent Prefix Prevails
7.2.8. 祖父母の接頭辞のROAの有効期限が親の接頭辞の有効期限に優先する
A scan of the ROA list reveals that the ROA {10.1.0.0/20, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
A scan of the ROA list reveals that the ROA {10.1.0.0/20, maxLength = 24, ASN 64496} has expired. Further, a route exists in the Internet routing system for 10.1.3.0/24 originated from ASN 64496. Additionally, a valid ROA exists for a parent prefix 10.1.0.0/22, and said ROA is {10.1.0.0/22, maxLength = 24, ASN 64496}.
The Relying Party interpretation would be: Route is Valid.
依拠当事者の解釈は次のようになります：ルートは有効です。
The authors are indebted to both Sandy Murphy and Sam Weiler for their guidance. Further, the authors would like to thank Steve Kent, Warren Kumari, Randy Bush, Curtis Villamizar, and Danny McPherson for their technical insight and review. The authors also wish to thank Elwyn Davies, Stephen Farrell, Barry Leiba, Stewart Bryant, Alexey Melnikov, and Russ Housley for their review and comments during the IESG review process.
著者は、彼らの指導のためにサンディ・マーフィーとサム・ワイラーの両方に感謝しています。さらに、著者は、技術的な洞察とレビューを提供してくれたSteve Kent、Warren Kumari、Randy Bush、Curtis Villamizar、およびDanny McPhersonに感謝します。著者はまた、IESGレビュープロセスでのレビューとコメントについて、Elwyn Davies、Stephen Farrell、Barry Leiba、Stewart Bryant、Alexey Melnikov、およびRuss Housleyに感謝します。
This memo requires no security considerations.
このメモはセキュリティ上の考慮を必要としません。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271] Rekhter、Y.、Li、T。、およびS. Hares、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、2006年1月。
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012.
[RFC6480] Lepinski、M。およびS. Kent、「安全なインターネットルーティングをサポートするインフラストラクチャ」、RFC 6480、2012年2月。
[RFC6482] Lepinski, M., Kent, S., and D. Kong, "A Profile for Route Origin Authorizations (ROAs)", RFC 6482, February 2012.
[RFC6482] Lepinski、M.、Kent、S.、D。Kong、「A Route for Route Origin Authorizations（ROAs）」、RFC 6482、2012年2月。
[RFC6487] Huston, G., Michaelson, G., and R. Loomans, "A Profile for X.509 PKIX Resource Certificates", RFC 6487, February 2012.
[RFC6487] Huston、G.、Michaelson、G。、およびR. Loomans、「X.509 PKIXリソース証明書のプロファイル」、RFC 6487、2012年2月。
[AS0-PROC] Kumari, W., Bush, R., Schiller, H., and K. Patel, "Codification of AS 0 processing", Work in Progress, August 2012.
[AS0-PROC]クマリW.、ブッシュR.、シラーH.、およびK.パテル、「AS 0処理の体系化」、Work in Progress、2012年8月。
[BRITE] NIST, "BRITE - BGPSEC / RPKI Interoperability Test & Evaluation", Developed by the National Institute of Standards and Technology (NIST), Gaithersburg, Maryland, 2011, <http://brite.antd.nist.gov/statics/about>.
[BRITE] NIST、「BRITE-BGPSEC / RPKI相互運用性テストおよび評価」、米国国立標準技術研究所（NIST）、ゲーサーズバーグ、メリーランド、2011年<http://brite.antd.nist.gov/staticsにより開発/ about>。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC3779] Lynn, C., Kent, S., and K. Seo, "X.509 Extensions for IP Addresses and AS Identifiers", RFC 3779, June 2004.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[RFC4632] Fuller、V。およびT. Li、「Classless Inter-domain Routing（CIDR）：the Internet Address Assignment and Aggregation Plan」、BCP 122、RFC 4632、2006年8月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月。
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, January 2010.
[RFC5737] Arkko、J.、Cotton、M。、およびL. Vegoda、「ドキュメント用に予約されたIPv4アドレスブロック」、RFC 5737、2010年1月。
[RFC6472] Kumari, W. and K. Sriram, "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP", BCP 172, RFC 6472, December 2011.
[RFC6472]クマリW.およびK.スリラム、「BGPでAS_SETおよびAS_CONFED_SETを使用しない場合の推奨事項」、BCP 172、RFC 6472、2011年12月
[RFC6483] Huston, G. and G. Michaelson, "Validation of Route Origination Using the Resource Certificate Public Key Infrastructure (PKI) and Route Origin Authorizations (ROAs)", RFC 6483, February 2012.
[RFC6483] Huston、G.およびG. Michaelson、「Validation of Route Origination Using the Resource Certificate Public Key Infrastructure（PKI）and Route Origin Authorizations（ROAs）」、RFC 6483、2012年2月。
[RFC6811] Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R. Austein, "BGP Prefix Origin Validation", RFC 6811, January 2013.
[RFC6811] Mohapatra、P.、Scudder、J.、Ward、D.、Bush、R。、およびR. Austein、「BGP Prefix Origin Validation」、RFC 6811、2013年1月。
Authors' Addresses
著者のアドレス
Terry Manderson ICANN
テリーマンダーソンICANN
EMail: terry.manderson@icann.org
Kotikalapudi Sriram US NIST
コティカラプディスリラムUS NIST
EMail: ksriram@nist.gov
Russ White Verisign
ラスホワイトベリサイン
EMail: russ@riw.us