[要約] RFC 2725は、ルーティングポリシーシステムのセキュリティに関するガイドラインであり、ルーティングポリシーの実装と管理のセキュリティを向上させることを目的としています。
Network Working Group C. Villamizar
Request for Comments: 2725 Avici
Category: Standards Track C. Alaettinoglu
ISI
D. Meyer
Cisco
S. Murphy
TIS
December 1999
Routing Policy System Security
ルーティングポリシーシステムのセキュリティ
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
Abstract
概要
The RIPE database specifications and RPSL language define languages used as the basis for representing information in a routing policy system. A repository for routing policy system information is known as a routing registry. A routing registry provides a means of exchanging information needed to address many issues of importance to the operation of the Internet. The implementation and deployment of a routing policy system must maintain some degree of integrity to be of any operational use. This document addresses the need to assure integrity of the data by providing an authentication and authorization model.
熟したデータベース仕様とRPSL言語は、ルーティングポリシーシステムで情報を表現するための基礎として使用される言語を定義します。ルーティングポリシーシステム情報のリポジトリは、ルーティングレジストリとして知られています。ルーティングレジストリは、インターネットの運用にとって重要な多くの問題に対処するために必要な情報を交換する手段を提供します。ルーティングポリシーシステムの実装と展開は、運用上の使用のためにある程度の整合性を維持する必要があります。このドキュメントは、認証と承認モデルを提供することにより、データの整合性を保証する必要性に対応しています。
Table of Contents
目次
1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Background . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Implicit Policy Assumptions . . . . . . . . . . . . . . . . 5
4 Scope of Security Coverage . . . . . . . . . . . . . . . . 5
5 Organization of this Document . . . . . . . . . . . . . . 6
6 Goals and Requirements . . . . . . . . . . . . . . . . . . 6
7 Data Representation . . . . . . . . . . . . . . . . . . . . 10
8 Authentication Model . . . . . . . . . . . . . . . . . . . 10
9 Authorization Model . . . . . . . . . . . . . . . . . . . . 12
9.1 Maintainer Objects . . . . . . . . . . . . . . . . . . 12
9.2 as-block and aut-num objects . . . . . . . . . . . . . 13
9.3 inetnum objects . . . . . . . . . . . . . . . . . . . 13
9.4 route objects . . . . . . . . . . . . . . . . . . . . 14
9.5 reclaim and no-reclaim attributes . . . . . . . . . . 14
9.6 Other Objects . . . . . . . . . . . . . . . . . . . . 15
9.7 Objects with AS Hierarchical Names . . . . . . . . . . 16
9.8 Query Processing . . . . . . . . . . . . . . . . . . . 16
9.9 Adding to the Database . . . . . . . . . . . . . . . . 17
9.10 Modifying or Deleting Database Objects . . . . . . . . 19
10 Data Format Summaries . . . . . . . . . . . . . . . . . . 20
10.1 Changes to the RIPE/RPSL Schema . . . . . . . . . . . 20
Appendicies
A Core and Non-Core Functionality . . . . . . . . . . . . . . 23
B Examples . . . . . . . . . . . . . . . . . . . . . . . . . 23
C Technical Discussion . . . . . . . . . . . . . . . . . . . 26
C.1 Relaxing requirements for ease of registry . . . . . 27
C.2 The address lending issue . . . . . . . . . . . . . . 28
C.3 Dealing with non-conformant or questionable older
data . . . . . . . . . . . . . . . . . . . . . . . . . 29
D Common Operational Cases . . . . . . . . . . . . . . . . . 30
D.1 simple hierarchical address allocation and route
allocation . . . . . . . . . . . . . . . . . . . . . . 31
D.2 aggregation and multihomed more specific routes . . . 32
D.3 provider independent addresses and multiple origin
AS . . . . . . . . . . . . . . . . . . . . . . . . . . 32
D.4 change in Internet service provider . . . . . . . . . 32
D.5 renumbering grace periods . . . . . . . . . . . . . . 32
E Deployment Considerations . . . . . . . . . . . . . . . . . 33
F Route Object Authorization Pseudocode . . . . . . . . . . . 35
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property Notice . . . . . . . . . . . . . . . . . 38
References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Security Considerations . . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 40
Full Copyright Statement . . . . . . . . . . . . . . . . . . 41
1 Overview
1。概要
The Internet Routing Registry (IRR) has evolved to meet a need for Internet-wide coordination. This need was described in RFC-1787, an informational RFC prepared on behalf of the IAB [14]. The following summary appears in Section 7 of RFC-1787.
インターネットルーティングレジストリ（IRR）は、インターネット全体の調整の必要性を満たすために進化しました。このニーズは、IABに代わって準備された情報RFCであるRFC-1787で説明されています[14]。次の要約は、RFC-1787のセクション7に表示されます。
While ensuring Internet-wide coordination may be more and more difficult, as the Internet continues to grow, stability and consistency of the Internet-wide routing could significantly benefit if the information about routing requirements of various organizations could be shared across organizational boundaries. Such information could be used in a wide variety of situations ranging from troubleshooting to detecting and eliminating conflicting routing requirements. The scale of the Internet implies that the information should be distributed. Work is currently underway to establish depositories of this information (Routing Registries), as well as to develop tools that analyze, as well as utilize this information.
インターネット全体の調整を確保することはますます困難になる可能性がありますが、インターネットが成長し続けるにつれて、インターネット全体のルーティングの安定性と一貫性は、さまざまな組織のルーティング要件に関する情報を組織の境界を越えて共有できる場合に大きな利益をもたらす可能性があります。このような情報は、トラブルシューティングから競合するルーティング要件の検出と排除まで、さまざまな状況で使用できます。インターネットの規模は、情報を配布する必要があることを意味します。現在、この情報（ルーティングレジストリ）の預託機関を確立し、分析するツールを開発し、この情報を利用するための作業が進行中です。
A routing registry must maintain some degree of integrity to be of any use. The degree of integrity required depends on the usage of the routing policy system.
ルーティングレジストリは、ある程度の整合性を維持するためにある程度の整合性を維持する必要があります。必要な整合性の程度は、ルーティングポリシーシステムの使用によって異なります。
An initial intended usage of routing policy systems such as the RIPE database had been in an advisory capacity, documenting the intended routing policies for the purpose of debugging. In this role a very weak form of authentication was deemed sufficient.
RIPEデータベースなどのルーティングポリシーシステムの最初の意図された使用は、デバッグを目的とした意図したルーティングポリシーを文書化するアドバイザリー能力であっていました。この役割では、非常に弱い形式の認証が十分であると見なされました。
The IRR is increasingly used for purposes that have a stronger requirement for data integrity and security. This document addresses issues of data integrity and security that is consistent with the usage of the IRR and which avoids compromising data integrity and security even if the IRR is distributed among less trusted repositories.
IRRは、データの整合性とセキュリティのより強い要件を持つ目的でますます使用されています。このドキュメントは、IRRの使用と一致し、IRRが信頼性の低いリポジトリに分配されていても、データの整合性とセキュリティの侵害を回避するデータの整合性とセキュリティの問題に対処します。
2 Background
2背景
An early routing policy system used in the NSFNET, the policy routing database (PRDB), provided a means of determining who was authorized to announce specific prefixes to the NSFNET backbone. The need for a policy database was recognized as far back as 1989 [6, 4]. By 1991 the database was in place [5]. Authentication was accomplished by requiring confirmation and was a manually intensive process. This solved the problem for the NSFNET, but was oriented toward holding the routing policy of a single organization.
NSFNETで使用される初期のルーティングポリシーシステムであるポリシールーティングデータベース（PRDB）は、NSFNETバックボーンに特定のプレフィックスを発表する権限を与えられた人を決定する手段を提供しました。ポリシーデータベースの必要性は、1989年までさかのぼって認識されていました[6、4]。1991年までにデータベースが導入されました[5]。認証は確認を必要とすることで達成され、手動で集中的なプロセスでした。これにより、NSFNETの問題は解決されましたが、単一の組織のルーティングポリシーを保持することに向けられていました。
The problem since has become more difficult. New requirements have emerged.
それ以来の問題はより困難になりました。新しい要件が明らかになりました。
1. There is a need to represent the routing policies of many organizations.
1. 多くの組織のルーティングポリシーを表す必要があります。
2. CIDR and overlapping prefixes and the increasing complexity of routing policies and the needs of aggregation have introduced new requirements.
2. CIDRと重複プレフィックス、およびルーティングポリシーの複雑さの増加と集約のニーズにより、新しい要件が導入されました。
3. There is a need to assure integrity of the data and delegate authority for the data representing specifically allocated resources to multiple persons or organizations.
3. データの整合性を保証する必要があり、複数の人または組織に特別に割り当てられたリソースを表すデータのデータの整合性を保証する必要があります。
4. There is a need to assure integrity of the data and distribute the storage of data subsets to multiple repositories.
4. データの整合性を保証し、データサブセットのストレージを複数のリポジトリに配布する必要があります。
The RIPE effort specificly focused on the first issue and needs of the European community. Its predecessor, the PRDB, addressed the needs of a single organization, the NSF. The RIPE database formats as described in [2] were the basis of the original IRR.
熟した努力は、欧州共同体の最初の問題とニーズに特に焦点を合わせました。その前身であるPRDBは、単一の組織であるNSFのニーズに対処しました。[2]で説明されている熟したデータベース形式は、元のIRRの基礎でした。
Routing protocols themselves provide no assurance that the origination of a route is legitimate and can actually reach the stated destination. The nature of CIDR allows more specific prefixes to override less specific prefixes [9, 15, 8]. Even with signed route origination, there is no way to determine if a more specific prefix is legitimate and should override a less specific route announcement without a means of determining who is authorized to announce specific prefixes. Failing to do so places no assurance of integrity of global routing information and leaves an opportunity for a very effective form of denial of service attack.
ルーティングプロトコル自体は、ルートの起源が合法であり、実際に指定された目的地に到達できるという保証を提供しません。CIDRの性質により、より具体的なプレフィックスがあまり特定のプレフィックスをオーバーライドすることができます[9、15、8]。署名されたルートのオリジネーションを使用しても、より具体的なプレフィックスが合法であるかどうかを判断する方法はありません。特定のプレフィックスを発表する権限を与えられる手段を決定することなく、より特定のルートアナウンスをオーバーライドする必要があります。そうしないと、グローバルなルーティング情報の完全性の保証がなく、非常に効果的なサービス拒否攻撃の機会を残します。
The Routing Policy System Language (RPSL) [1, 13] was a fairly substantial evolutionary step in the data representation which was largely targeted at addressing the second group of needs. The PRDB accommodated CIDR in 1993 [12] and the RIPE database accommodated the entry of CIDR prefixes from inception, but RPSL provides many needed improvements including explicit support for aggregation.
ルーティングポリシーシステム言語（RPSL）[1、13]は、主に2番目のニーズグループに対処することを目的としたデータ表現におけるかなり実質的な進化のステップでした。PRDBは1993年にCIDRに対応し[12]、熟したデータベースは開始からCIDRプレフィックスのエントリに対応しましたが、RPSLは集約の明示的なサポートを含む多くの必要な改善を提供します。
This document addresses the third group of needs identified above.
このドキュメントでは、上記で特定された3番目のニーズグループに対応しています。
While the current implementation supporting weak authentication doesn't guarantee integrity of the data, it does provide extensive mechanisms to make sure that all involved parties get notified when a change is made to the database, whether the change was malicious or intended. This provides inadequate protection against additions. Since the software is increasingly used to configure the major parts of the Internet infrastructure, it is not considered to be adequate anymore to know about and have the ability roll back unintended changes. Therefore, more active security mechanisms need to be developed to prevent such problems before they happen.
弱い認証をサポートする現在の実装は、データの整合性を保証するものではありませんが、変更が悪意があったか意図されているかにかかわらず、データベースに変更が加えられたときにすべての関係者が通知されることを確認するための広範なメカニズムを提供します。これは、追加に対する不十分な保護を提供します。ソフトウェアは、インターネットインフラストラクチャの主要部分を構成するためにますます使用されているため、意図しない変更を知り、機能をロールバックするのはもはや適切であるとは考えられていません。したがって、このような問題が発生する前に、よりアクティブなセキュリティメカニズムを開発する必要があります。
A separate document will be needed to address the fourth group of needs.
ニーズの4番目のグループに対処するには、別のドキュメントが必要になります。
3 Implicit Policy Assumptions
3暗黙のポリシーの仮定
The authorization model encodes certain policies for allocation of address numbers, AS numbers, and for the announcement of routes. Implicit to the authorization model is a very limited number of policy assumptions.
承認モデルは、アドレス番号の割り当て、数字として、およびルートの発表のための特定のポリシーをエンコードします。承認モデルに暗黙的には、非常に限られた数のポリシーの仮定です。
1. Address numbers are allocated hierarchically. The IANA delegates portions of the address space to the regional registries (currently ARIN, APNIC and RIPE), which in turn delegate address space to their members, who can assign addresses to their customers.
1. アドレス番号は階層的に割り当てられます。IANAは、住所スペースの一部を地域のレジストリ（現在はArin、Apnic、Ripe）に委任し、その結果、住所を顧客に割り当てることができるメンバーに住所スペースを委任します。
2. AS numbers are allocated either singly or in small blocks by registries. Registries are allocated blocks of AS numbers, thereby making the allocation hierarchical.
2. 数字は、レジストリによって単独でまたは小さなブロックで割り当てられます。レジストリはAS番号のブロックを割り当てられているため、割り当て階層が作成されます。
3. Routes should only be announced with the consent of the holder of the origin AS number of the announcement and with the consent of the holder of the address space.
3. ルートは、起源の所有者の発表の数として、また住所スペースの所有者の同意を得てのみ発表する必要があります。
4. AS numbers and IP address registries may be different entities from routing registries.
4. 数字とIPアドレスレジストリは、ルーティングレジストリとは異なるエンティティになる可能性があります。
For subsets of any of these three allocation spaces, network addresses, AS numbers, and routes, these restrictions may be loosened or disabled by specifying a very weak authorization method or an authentication method of "none". However, even when no authentication mechanism is used, all involved parties can be notified about the changes that occurred through use of the existing "notify" attribute.
これら3つの割り当てスペース、ネットワークアドレス、数字、およびルートのいずれかのサブセットの場合、これらの制限は、非常に弱い承認方法または「なし」の認証方法を指定することにより、緩めまたは無効にされる場合があります。ただし、認証メカニズムが使用されていない場合でも、既存の「通知」属性を使用して発生した変更について、すべての関係者に通知することができます。
4 Scope of Security Coverage
4セキュリティカバレッジの範囲
This document is intended only to provide an authentication and authorization model to insure the integrity of the policy data in a registry. Only authetication and authorization of additions, deletions, and changes to the database are within the scope of this document. Authentication and authorization of database queries is explicitly out of scope. Mutual authentication of queries, that is authenticating both the origin of the query and the repository from which query results are obtained, is also out of scope.
このドキュメントは、レジストリ内のポリシーデータの整合性を保証するための認証と承認モデルを提供することのみを目的としています。データベースの追加、削除、および変更の認証と承認のみが、このドキュメントの範囲内にあります。データベースクエリの認証と承認は、明示的に範囲外です。クエリの相互認証は、クエリの起源とクエリの結果が得られるリポジトリの両方を認証することも、範囲外です。
5 Organization of this Document
5このドキュメントの組織
Familiarity with RIPE-181 [2] and RPSL [1] is assumed throughout this document. Goals are described in Section 6. Section 7 through Section 9 provide descriptions of the changes and discussion. Section 10 provides a concise summary of data formats and semantics. Appendix C through Appendix E provide additional technical discussion, examples, and deployment considerations.
Ripe-181 [2]およびRPSL [1]に精通していることは、このドキュメント全体で想定されています。目標については、セクション6で説明します。セクション7からセクション9では、変更と議論の説明を示します。セクション10では、データ形式とセマンティクスの簡潔な要約を提供します。付録Eからの付録Cは、追加の技術的な議論、例、および展開の考慮事項を提供します。
Goals and Requirements Section 6 provides a more detailed description of the issues and identifies specific problems that need to be solved, some of which require a degree of cooperation in the Internet community.
目標と要件セクション6では、問題のより詳細な説明を提供し、解決する必要がある特定の問題を特定します。その一部には、インターネットコミュニティである程度の協力が必要です。
Data Representation Section 7 provides some characteristics of RPSL and formats for external representations of information.
データ表現セクション7では、情報の外部表現のためのRPSLのいくつかの特性と形式を提供します。
Authentication Model Section 8 describes current practice, proposes additional authentication methods, and describes the extension mechanism if additional methods are needed in the future.
認証モデルセクション8では、現在の慣行を説明し、追加の認証方法を提案し、将来追加の方法が必要な場合は拡張メカニズムを説明します。
Authorization Model Section 9 describes the means of determining whether a transaction contains the authorization needed to add, modify, or delete specific data objects, based on stated authentication requirements in related data objects.
承認モデルセクション9では、関連するデータオブジェクトの指定された認証要件に基づいて、特定のデータオブジェクトを追加、変更、または削除するために必要なトランザクションが含まれるかどうかを判断する手段を説明します。
Data Format Summaries Section 10 provides a concise reference to the data formats and steps in transaction processing.
データ形式の概要セクション10では、データ形式への簡潔な参照とトランザクション処理の手順を示します。
Technical Discussion Section C contains some discussion of technical tradeoffs.
技術的な議論セクションCには、技術的なトレードオフの議論が含まれています。
Common Operational Cases Section D provides some examples drawn from past operational experience with the IRR.
一般的な運用ケースセクションDは、IRRで過去の運用経験から描かれたいくつかの例を示しています。
Deployment Considerations Section E describes some deployment issues and discusses possible means of resolution.
展開の考慮事項セクションE展開の問題について説明し、解決の可能な手段について説明します。
6 Goals and Requirements
6つの目標と要件
The Internet is an open network. This openness and the large scale of the Internet can present operational problems. Technical weaknesses that allow misconfiguration or errant operation in part of the network to propagate globally or which provide potentials for simple denial of service attacks should be eliminated to the extent that it is practical. The integrity of routing information is critical in assuring that traffic goes where it is supposed to.
インターネットはオープンネットワークです。このオープン性とインターネットの大規模は、運用上の問題を提示することができます。ネットワークの一部でグローバルに伝播したり、単純なサービス拒否攻撃の可能性を提供することを可能にする誤った構成または誤った操作を可能にする技術的な弱点は、それが実用的である限り排除されるべきです。ルーティング情報の整合性は、トラフィックが想定される場所に行くことを保証する上で重要です。
An accidental misconfiguration can direct traffic toward routers that cannot reach a destination for which they are advertising reachability. This is commonly caused by misconfigured static routes though there are numerous other potential causes. Static routes are often used to provide constant apparent reachability to single homed destinations. Some of the largest ISPs literally have thousands of static routes in their networks. These are often entered manually by operators. Mistyping can divert traffic from a completely unrelated destination to a router with no actual reachability to the advertised destination. This can happen and does happen somewhat regularly. In addition, implementation bugs or severe misconfigurations that result in the loss of BGP AS path information or alteration of prefix length can result in the advertisement of large sets of routes. Though considerably more rare, on a few occasions where this has occurred the results were catastrophic.
偶発的な誤解は、広告の到達可能性である目的地に到達できないルーターにトラフィックを向けることができます。これは一般に、誤解された静的ルートによって引き起こされますが、他にも多くの潜在的な原因があります。静的ルートは、多くの場合、単一の家庭用目的地に一定の見かけの到達可能性を提供するために使用されます。最大のISPの一部は、文字通り、ネットワークに数千の静的ルートを持っています。これらはしばしばオペレーターによって手動で入力されます。間違いは、広告された目的地に実際の到達可能性がないまったく関係のない目的地からルーターにトラフィックを迂回させる可能性があります。これは発生する可能性があり、多少定期的に行われます。さらに、パス情報またはプレフィックス長の変更としてBGPの損失をもたらす実装バグまたは深刻な誤解により、大きなルートセットの広告が生じる可能性があります。かなりまれですが、これが発生した数回で結果は壊滅的でした。
Where there is the potential for an accidental misconfiguration in a remote part of the Internet affecting the global Internet there is also the potential for malice. For example, it has been demonstrated by accident that multiple hour outages at a major institution can be caused by a laptop and a dial account if proper precautions are not taken. The dial account need not be with the same provider used by the major institution.
グローバルなインターネットに影響を与えるインターネットの遠隔地で偶発的な誤解の可能性がある場合、悪意の可能性もあります。たとえば、適切な予防措置が取られない場合は、主要機関での複数時間の停止がラップトップとダイヤルアカウントによって引き起こされる可能性があることが偶然に実証されています。ダイヤルアカウントは、主要機関が使用する同じプロバイダーと一緒にいる必要はありません。
The potential for error is increased by the CIDR preference for more specific routes [8]. If an institution advertises a single route of a given length and a distant router advertises a more specific route covering critical hosts, the more specific route, if accepted at all, is preferred regardless of administrative weighting or any routing protocol attributes.
より具体的なルートに対するCIDRの好みにより、エラーの可能性が増加します[8]。機関が特定の長さの単一のルートを宣伝し、遠くのルーターが重要なホストをカバーするより具体的なルートを宣伝する場合、管理の重み付けやルーティングプロトコル属性に関係なく、より具体的なルートが優先されます。
There is a need to provide some form of checks on whether a route advertisement is valid. Today checks are typically made against the border AS advertising the route. This prevents accepting routes from the set of border AS that could not legitimately advertise the route. Theses checks rely on the use of information registered in the IRR to generate lists of prefixes that could be advertised by a specific border AS. Checks can also be made against the origin AS. If policy information were sufficiently populated, checks could be made against the entire AS path, but this is not yet feasible.
ルート広告が有効かどうかを何らかの形でチェックする必要があります。今日、今日のチェックは、ルートを宣伝する際に国境に対して行われます。これは、ルートを合法的に宣伝できなかったため、国境のセットからルートを受け入れることを防ぎます。これらのチェックは、IRRに登録されている情報の使用に依存して、特定の境界線によって宣伝できる接頭辞のリストを生成します。起源に対してチェックを作成することもできます。ポリシー情報が十分に人口がかかっている場合、ASパス全体に対してチェックを行うことができますが、これはまだ実行可能ではありません。
The use of a routing registry can also make it more difficult for prefixes to be used without authorization such as unallocated prefixes or prefixes allocated to another party.
ルーティングレジストリを使用すると、別の当事者に割り当てられた未割り当てのプレフィックスや接頭辞などの許可なしに、プレフィックスをより困難にすることもできます。
In summary, some of the problems being addressed are:
要約すると、対処されている問題のいくつかは次のとおりです。
o Localizing the impact of accidental misconfiguration made by Internet Providers to that provider's networks only.
o インターネットプロバイダーによる偶発的な誤解の影響を、そのプロバイダーのネットワークのみにローカライズします。
o Eliminating the potential for an Internet provider's customer to use malicious misconfiguration of routing as a denial of service attack if the provider route filters their customers. Localizing the denial of service to that Internet provider only if the immediate Internet service provider does not route filter their customers but other providers route filter the route exchange at the interprovider peering.
o プロバイダールートが顧客をフィルタリングする場合、インターネットプロバイダーの顧客が悪意のあるサービス攻撃としてルーティングの悪意のある誤解を使用する可能性を排除します。インターネットプロバイダーへのサービスの拒否をローカライズすると、即時のインターネットサービスプロバイダーが顧客をルートフィルタリングしない場合にのみ、他のプロバイダーが介入されたピアリングでルート交換をルートフィルタリングします。
o Eliminating the unauthorized use of address space.
o アドレススペースの不正使用を排除します。
If the data within a routing registry is critical, then the ability to change the data must be controlled. Centralized authorities can provide control but centralization can lead to scaling problems (and is politically distasteful).
ルーティングレジストリ内のデータが重要な場合、データを変更する機能を制御する必要があります。中央集権的な当局は制御を提供できますが、集中化はスケーリングの問題につながる可能性があります（そして政治的に不快です）。
Address allocation and name allocation is already delegated. Since delegation can be to outside registries it is at least somewhat distributed [11]. Autonomous System (AS) numbers are allocated by the same authorities. It makes sense to delegate the routing number space in a manner similar to the address allocation and AS number allocation. The need for this delegation of authority to numerous registries increases the difficulty of maintaining the integrity of the body of information as a whole.
アドレス割り当てと名前の割り当てはすでに委任されています。委任は外部レジストリに存在する可能性があるため、少なくともある程度分布しています[11]。自律システム（AS）数は同じ当局によって割り当てられます。アドレス割り当てと同様の方法で、および数値割り当てとして、ルーティング番号スペースを委任することは理にかなっています。この権限を多数のレジストリに委任する必要性は、情報体全体の完全性を維持することの難しさを高めます。
As a first step, the database can be somewhat centrally administered with authority granted to many parties to change the information. This is the case with the current IRR. There are a very small number of well trusted repositories and a very large number of parties authorized to make changes. Control must be exercised over who can make changes and what changes they can make. The distinction of who vs what separates authentication from authorization.
最初のステップとして、データベースは、情報を変更するために多くの当事者に付与された権限で多少中心に管理できます。これは、現在のIRRの場合です。非常に少数の信頼できるリポジトリと、変更を行うことを許可された非常に多数の当事者があります。誰が変更を加え、どのような変更を加えることができるかを制御する必要があります。認証と認証を区別するものとWHOの区別。
o Authentication is the means to determine who is attempting to make a change.
o 認証とは、誰が変更を加えようとしているかを判断する手段です。
o Authorization is the determination of whether a transaction passing a specific authentication check is allowed to perform a given operation.
o 承認とは、特定の認証チェックに合格するトランザクションが特定の操作を実行できるかどうかを決定することです。
Different portions of the database will require different methods of authentication. Some applications will require authentication based on strong encryption. In other cases software supporting strong encryption may not be necessary or may not be legally available. For this reason multiple authentication methods must be supported, selected on a per object basis through the specification of authentication methods in the maintainer object "auth" attribute. The authentication methods may range from very weak data integrity checks to cryptographicly strong signatures. The authorization model must sure that the use of weak integrity checks in parts of the database does not compromise the overall integrity of the database.
データベースのさまざまな部分には、異なる認証方法が必要になります。一部のアプリケーションでは、強力な暗号化に基づいて認証が必要です。それ以外の場合は、強力な暗号化をサポートするソフトウェアが必要ではないか、法的に利用できない場合があります。このため、メンテナーオブジェクト「AUTH」属性の認証方法の仕様を通じて、オブジェクトごとに選択された複数の認証メソッドをサポートする必要があります。認証方法は、非常に弱いデータの整合性チェックから暗号化的に強い署名にまで及ぶ可能性があります。承認モデルは、データベースの一部での弱い整合性チェックの使用がデータベースの全体的な整合性を損なうものではないことを確認する必要があります。
Additional requirements are placed on the authorization model if the database is widely distributed with delegations made to parties that may not be trustworthy or whose security practices may be lacking. This problem must be addressed in the authorization model in order to enable later evolution to a more distributed routing registry.
データベースが信頼できない可能性のある当事者に行われた代表団で広く配布されている場合、またはセキュリティ慣行が不足している可能性のある委任状で広く配布されている場合、追加の要件が承認モデルに配置されます。この問題は、より分散したルーティングレジストリへの後の進化を可能にするために、承認モデルで対処する必要があります。
Autonomous system numbers can be delegated in blocks and subdelegated as needed and then individual AS numbers assigned. Address allocation is a simple numeric hierarchy. Route allocation is somewhat more complicated. The key attributes in a route object (key with regard to making it unique) contain both an address prefix and an AS number, known as the origin AS. The addition of a route object must be validated against the authorization criteria for both the AS and the address prefix. Route objects may exist for the same prefix with multiple origin AS values due to a common multihoming practice that does not require a unique origin AS. There is often no correlation between the origin AS of a prefix and the origin AS of overlapping more specific prefixes.
自律システム番号はブロックに委任され、必要に応じてサブディレージされ、その後個々の数字が割り当てられます。アドレス割り当ては、単純な数値階層です。ルートの割り当てはやや複雑です。ルートオブジェクトのキー属性（一意にすることに関するキー）には、アドレスのプレフィックスと原点として知られるAS番号の両方が含まれています。ルートオブジェクトの追加は、ASとアドレスプレフィックスの両方の承認基準に対して検証する必要があります。ルートオブジェクトは、一意の起源を必要としない一般的なマルチホームプラクティスのために、値として複数の原点を持つ同じプレフィックスに対して存在する場合があります。多くの場合、プレフィックスの原点と、より具体的なプレフィックスが重複する原点との間に相関はありません。
There are numerous operational cases that must be accommodated. Some of the more common are listed below. These are explored in greater detail in Appendix D with discussion of technical tradeoffs in Appendix C.
収容する必要がある多くの運用上のケースがあります。より一般的なもののいくつかは以下にリストされています。これらについては、付録Dでの技術的なトレードオフの議論を含む付録Dで詳細に検討されています。
o simple hierarchical address allocation and route allocation
o 単純な階層アドレスの割り当てとルート割り当て
o aggregation and multihomed more specific routes
o 集約とマルチホームのより具体的なルート
o provider independent addresses and multiple origin AS
o プロバイダー独立したアドレスと複数の起源として
o changing Internet service providers
o インターネットサービスプロバイダーの変更
o renumbering grace periods The authorization model must accommodate a variety of policies regarding the allocation of address space and cannot mandate the use of any one model. There is no standardization of address allocation policies though guidelines do exist [11, 16]. Whether authorization allows the recovery of address space must be selectable on a per object basis and may differ in parts of the database. This issue is discussed further in Appendix C.
o 恵み期間の変更承認モデルは、アドレス空間の割り当てに関するさまざまなポリシーに対応する必要があり、1つのモデルの使用を義務付けることはできません。ガイドラインは存在しますが、アドレス割り当てポリシーの標準化はありません[11、16]。許可により、アドレススペースの回復を許可するかどうかは、オブジェクトごとに選択可能でなければならず、データベースの一部で異なる場合があります。この問題については、付録Cでさらに説明します。
7 Data Representation
7データ表現
RPSL provides a complete description of the contents of a routing repository [1]. Many RPSL data objects remain unchanged from the RIPE specifications and RPSL references the RIPE-181 specification as recorded in RFC-1786 [2]. RPSL provides external data representation. Data may be stored differently internal to a routing registry.
RPSLは、ルーティングリポジトリの内容の完全な説明を提供します[1]。多くのRPSLデータオブジェクトは、RFC-1786 [2]に記録されているように、RPSLが熟した仕様から変更されず、RPSLはRPIPE-181仕様を参照しています。RPSLは外部データ表現を提供します。データは、ルーティングレジストリの内部に異なる方法で保存される場合があります。
Some database object types or database attributes must be added to RPSL to record the delegation of authority and to improve the authentication and authorization mechanisms. These additions are very few and are described in Section 8 and Section 9.
一部のデータベースオブジェクトタイプまたはデータベース属性をRPSLに追加して、権限の委任を記録し、認証と承認のメカニズムを改善する必要があります。これらの追加は非常に少なく、セクション8およびセクション9で説明されています。
Some form of encapsulation must be used to exchange data. The defacto encapsulation has been the one which the RIPE tools accept, a plain text file or plain text in the body of an RFC-822 formatted mail message with information needed for authentication derived from the mail headers or the body of the message. Merit has slightly modified this using the PGP signed portion of a plain text file or PGP signed portion of the body of a mail message. These very simple forms of encapsulation are suitable for the initial submission of a database transaction.
データを交換するために、何らかの形のカプセル化を使用する必要があります。fipe Toolsが受け入れるもの、rfc-822フォーマットされたメールメッセージ、およびメッセージのヘッダーまたはメッセージの本文から派生した認証に必要な情報を使用した、RFC-822のフォーマットされたメールメッセージ、fipeのカプセル化は、compactoのカプセル化です。Meritは、プレーンテキストファイルのPGP署名部分またはメールメッセージの本文の署名された部分を使用して、これをわずかに変更しました。これらの非常にシンプルな形式のカプセル化は、データベーストランザクションの最初の提出に適しています。
The encapsulation of registry transaction submissions, registry queries and registry responses and exchanges between registries is outside the scope of this document. The encapsulation of registry transaction submissions and exchanges between registries is outside the scope of this document.
レジストリトランザクションの提出、レジストリクエリ、レジストリ応答とレジストリ間の交換のカプセル化は、このドキュメントの範囲外です。レジストリトランザクションの提出とレジストリ間の交換のカプセル化は、このドキュメントの範囲外です。
8 Authentication Model
8認証モデル
The maintainer objects serve as a container to hold authentication filters. A reference to a maintainer within another object defines authorization to perform operations on the object or on a set of related objects. The maintainer is typically referenced by name in mnt-by attributes of objects. Further details on the use of maintainers are provided in Section 9.1.
メンテナーオブジェクトは、認証フィルターを保持するためのコンテナとして機能します。別のオブジェクト内のメンテナーへの参照は、オブジェクトまたは関連するオブジェクトのセットで操作を実行する許可を定義します。メンダーは通常、オブジェクトのMNT-by属性の名前で参照されます。メンテナーの使用に関する詳細については、セクション9.1に記載されています。
The maintainer contains one or more "auth" attributes. Each "auth" attribute begins with a keyword identifying the authentication method followed by the authentication information needed to enforce that method. The PGPKEY method is slightly syntactically different in that the method PGPKEY is a substring.
メンテナーには、1つ以上の「AUTH」属性が含まれています。各「auth」属性は、認証方法を識別するキーワードから始まり、その後にその方法を実施するために必要な認証情報が続きます。PGPKEYメソッドは、メソッドPGPKEYがサブストリングであるという点で、わずかに構文的に異なります。
Authentication methods currently supported include the following. Note that pgp-from is being replaced by the pgpkey (see Section 10 and [18]).
現在サポートされている認証方法には、以下が含まれます。PGP-FROMはPGPKEYに置き換えられていることに注意してください（セクション10および[18]を参照）。
mail-from This is a very weak authentication check and is discouraged. The authentication information is a regular expression over ASCII characters. The maintainer is authenticated if the from or reply-to fields in RFC-822 mail headers are matched by this regular expression. Since mail forgery is quite easy, this is a very weak form of authentication.
これは非常に弱い認証チェックであり、落胆しています。認証情報は、ASCII文字に対する正規表現です。RFC-822メールヘッダーのFromまたはReply-to Fieldsがこの正規表現と一致する場合、メンテナーは認証されます。Mail Forgeryは非常に簡単なので、これは非常に弱い形式の認証です。
crypt-pw This is another weak form of authentication. The authentication information is a fixed encrypted password in UNIX crypt format. The maintainer is authenticated if the transaction contains the clear text password of the maintainer. Since the password is in clear text in transactions, it can be captured by snooping. Since the encrypted form of the password is exposed, it is subject to password guessing attacks.
crypt-pwこれは別の弱い形式の認証です。認証情報は、UNIX Crypt形式の固定暗号化されたパスワードです。トランザクションにメンテナーの明確なテキストパスワードが含まれている場合、メンテナーは認証されます。パスワードはトランザクションでは明確なテキストであるため、スヌーピングによってキャプチャできます。パスワードの暗号化された形式が公開されるため、パスワード推測攻撃の対象となります。
pgp-from This format is being replaced by the "pgpkey" so that the public key certificate will be available to remote repositories. This is Merit's PGP extension. The authentication information is a signature identity pointing to an external public key ring. The maintainer is authenticated if the transaction (currently PGP signed portion of a mail message) is signed by the corresponding private key.
PGP-FROMこの形式は「PGPKEY」に置き換えられているため、公開キー証明書はリモートリポジトリで利用可能になります。これはMeritのPGP拡張機能です。認証情報は、外部の公開キーリングを指す署名IDです。メンテナーは、対応する秘密鍵によってトランザクション（現在PGP署名された部分）が署名されている場合、認証されます。
pgpkey This keyword takes the form "PGPKEY-hhhhhhhh", where "hhhhhhhh" is the hex representation of the four byte id of the PGP public key used for authentication. The public key certificate is stored in a separate object as described in [18].
pgpkeyこのキーワードは、「pgpkey-hhhhhhhhh」の形式を取ります。ここで、「hhhhhhhhh」は、認証に使用されるPGP公開キーの4バイトIDの16進表現です。[18]に記載されているように、公開キーの証明書は別のオブジェクトに保存されます。
Repositories may elect to disallow the addition of "auth" attributes specifying weaker forms of authentication and/or disallow their use in local transaction submissions. Repositories are encouraged to disallow the addition of "auth" attributes with the deprecated "pgp-from" method.
リポジトリは、より弱い形式の認証および/またはローカルトランザクション提出での使用を禁止する「認証」属性の追加を許可することを選択する場合があります。リポジトリは、非推奨の「PGP-FROM」メソッドを使用して「認証」属性の追加を許可することをお勧めします。
Any digital signature technique can in principle be used for authentication. Transactions should be signed using multiple digital signature techniques to allow repositories or mirrors that only use a subset of the techniques to verify at least one of the signatures. The selection of digital signature techniques is not within the scope of this document.
デジタル署名手法は、原則として認証に使用できます。トランザクションは、複数のデジタル署名手法を使用して署名する必要があります。これは、テクニックのサブセットのみを使用して署名の少なくとも1つを検証するリポジトリまたはミラーを許可する必要があります。デジタル署名技術の選択は、このドキュメントの範囲内ではありません。
9 Authorization Model
9認可モデル
The authorization model must accommodate the requirements outlined in Section 6. A key feature of the authorization model is the recognition that authorization for the addition of certain types of data objects must be derived from related data objects.
承認モデルは、セクション6で概説されている要件に対応する必要があります。承認モデルの重要な機能は、特定のタイプのデータオブジェクトを追加するための承認が関連データオブジェクトから導き出される必要があるという認識です。
With multiple repositories, objects not found in RPSL are needed to control AS delegations and new attributes are needed in existing objects to control subdelegation. The definition of RPSL objects used to implement a distrubuted routing registry system is not within the scope of this document.
複数のリポジトリを使用すると、既存のオブジェクトでは、既存のオブジェクトでサブデールジュテーションを制御する必要があるため、RPSLにはオブジェクトが見つかりません。分散ルーティングレジストリシステムの実装に使用されるRPSLオブジェクトの定義は、このドキュメントの範囲内ではありません。
The maintainer objects serve as a container to hold authentication filters. The authentication methods are described in Section 8. The maintainer can be referenced by name in other objects, most notably in the mnt-by attributes of those objects.
メンテナーオブジェクトは、認証フィルターを保持するためのコンテナとして機能します。認証方法はセクション8で説明されています。メンサーは、他のオブジェクト、特にそれらのオブジェクトのMNT属性で名前で参照できます。
Maintainers themselves contain mnt-by attributes. In some cases the mnt-by in a maintainer will reference the maintainer itself. In this case, authorization to modify the maintainer is provided to a (usually very limited) set of identities. A good practice is to create a maintainer containing a long list of identities authorized to make specific types of changes but have the maintainer's mnt-by attribute reference a far more restrictive maintainer more tightly controlling changes to the maintainer object itself.
メンテナー自体には、MNT-by属性が含まれています。場合によっては、メンテナーのMNT-byがメンテナー自体を参照します。この場合、メンテナーを変更する許可は、（通常は非常に限られた）アイデンティティに提供されます。良い習慣は、特定の種類の変更を行うことを許可された長いアイデンティティのリストを含むメンテナーを作成することですが、メンテナーのMNT属性参照は、メンテナーオブジェクト自体の変更をより厳密に制御するメンテナーをはるかに制限的なメンテナーにすることです。
The mnt-by attribute is mandatory in all objects. Some data already exists without mnt-by attributes. A missing mnt-by attribute is interpreted as the absence of any control over changes. This is highly inadvisable and most repositories will no longer allow this.
MNT-by属性は、すべてのオブジェクトで必須です。一部のデータは、MNT-by属性なしですでに存在しています。欠落しているMNT-by属性は、変更に対する制御がないと解釈されます。これは非常に控えめであり、ほとんどのリポジトリはこれを許可しなくなります。
An additional maintainer reference can occur through a new attribute, "mnt-routes", and is used in aut-num, inetnum and route objects. The "mnt-routes" attribute is an extension to RPSL and is described in detail in Section 10.
追加のメンテナー参照は、新しい属性「MNT-Routes」を介して発生する可能性があり、Aut-Num、Inetnum、およびルートオブジェクトで使用されます。「MNT-routes」属性はRPSLの拡張機能であり、セクション10で詳しく説明されています。
A mnt-routes attribute in an aut-num object allows addition of route objects with that AS number as the origin to the maintainers listed. A mnt-routes attribute in an inetnum object allows addition of route objects with exact matching or more specific prefixes. A mnt-routes attribute in a route object allows addition of route objects with exact matching or more specific prefixes. A mnt-routes attribute does not allow changes to the aut-num, inetnum, or route object where it appears. A mnt-routes may optionally be constrained to only apply to a subset of more specific routes.
Aut-NumオブジェクトのMNT-routes属性により、リストされているメンテナーの原点として数字としてルートオブジェクトを追加することができます。INETNUMオブジェクトのMNT-Routes属性により、正確な一致またはより特定のプレフィックスを備えたルートオブジェクトを追加できます。ルートオブジェクトのMNT-Routes属性により、正確な一致またはより特定のプレフィックスを備えたルートオブジェクトを追加できます。MNT-routes属性は、表示されている場合のAut-Num、inetnum、またはルートオブジェクトの変更を許可しません。MNT-Routesは、オプションで、より特定のルートのサブセットにのみ適用するように制約される場合があります。
Where "mnt-routes" or "mnt-lower" are applicable, any maintainer referenced in the "mnt-by" still apply. The set of applicable maintainers for whatever check is being made is the union of the "mnt-routes" or "mnt-lower" and the "mnt-by". For example, when authorizing a route object software would look at "mnt-routes", if it does not exist, look at "mnt-lower", if that does not exist look at "mnt-by".
「MNT-Routes」または「MNT-lower」が適用される場合、「MNT-BY」で参照されているメンテナーはまだ適用されます。行われているチェックに適用可能なメンテナーのセットは、「MNT-Routes」または「Mnt-lower」と「MNT-BY」の結合です。たとえば、ルートオブジェクトソフトウェアを承認する場合、「Mnt-routes」を確認すると、存在しない場合は「MNT-lower」を確認します。
An "as-block" object is needed to delegate a range of AS numbers to a given repository. This is needed for authorization and it is needed to avoid having to make an exhaustive search of all repositories to find a specific AS. This search would not be an issue now but would be if a more distributed routing repository is used. Distributed registry issues are not within the scope of this document.
特定のリポジトリにASの範囲を委任するためには、「ブロックとして」オブジェクトが必要です。これは承認に必要であり、特定のASを見つけるためにすべてのリポジトリを徹底的に検索する必要がないようにするために必要です。この検索は現在の問題ではありませんが、より分散したルーティングリポジトリが使用されている場合です。分散レジストリの問題は、このドキュメントの範囲内ではありません。
The "as-block" object also makes it possible to separate AS number allocation from registration of AS routing policy.
「as-block」オブジェクトは、ルーティングポリシーの登録から番号割り当てとして分離することも可能にします。
as-block: AS1321 - AS1335
as -block：as1321 -as1335
The "aut-num" describes the routing policy for an AS and is critical for router configuration of that AS and for analysis performed by another AS. For the purpose of this document it is sufficient to consider the aut-num solely as a place holder identifying the existence of an AS and providing a means to associate authorization with that AS when adding "route" objects.
「Aut-Num」は、ASのルーティングポリシーを説明し、ASのRouter構成と別のASによって実行される分析にとって重要です。このドキュメントの目的のために、Aut-NumをASの存在を識別する場所ホルダーとしてのみ考慮し、「ルート」オブジェクトを追加するときのように認証を関連付ける手段を提供するだけで十分です。
The "as-block" object is proposed here solely as a means of recording the delegation of blocks of AS numbers to alternate registries and in doing so providing a means to direct queries and a means to support hierarchical authorization across multiple repositories.
「As-block」オブジェクトは、AS数のブロックの委任を代替レジストリに記録する手段としてのみ提案されており、その際に、クエリを指示する手段と複数のリポジトリにわたって階層的な承認をサポートする手段を提供します。
The "inetnum" exists to support address allocation. For external number registries, such as those using "[r]whoisd[++]" the "inet-num" can serve as a secondary record that is added when an address allocation is made in the authoritative database. Such records could be added by a address registry such as ARIN as a courtesy to the corresponding routing registry.
「inetnum」は、アドレス割り当てをサポートするために存在します。「[r] whoisd []」を使用しているものなどの外部番号レジストリの場合、「inet-num」は、権威あるデータベースでアドレス割り当てが行われたときに追加される二次レコードとして機能します。このようなレコードは、対応するルーティングレジストリの礼儀としてARINなどのアドレスレジストリによって追加できます。
inetnum: 193.0.0.0 - 193.0.0.255 source: IANA
inetnum：193.0.0.0-193.0.0.255出典：IANA
Currently there are a quite few route objects in more than one registry. Quite a few are registered with an origin AS for which they have never been announced. There is a legitimate reason to be in more than one origin AS.
現在、複数のレジストリにはかなり少ないルートオブジェクトがあります。発表されたことのない起源でかなりの数が登録されています。複数の起源としてあるという正当な理由があります。
The "route" object is used to record routes which may appear in the global routing table. Explicit support for aggregation is provided. Route objects exist both for the configuration of routing information filters used to isolate incidents of erroneous route announcements (Section 6) and to support network problem diagnosis.
「ルート」オブジェクトは、グローバルルーティングテーブルに表示される可能性のあるルートを記録するために使用されます。集約の明示的なサポートが提供されます。ルートオブジェクトは、誤ったルートアナウンスのインシデントを分離するために使用されるルーティング情報フィルター（セクション6）の構成と、ネットワークの問題診断をサポートするために存在します。
A reclaim attribute is needed in as-block, inetnum and route objects. The reclaim attribute allows a control to be retained over more specific AS, IP address or route space by allowing modify and delete privileges regardless of the mnt-by in the object itself.
asブロック、inetnum、およびルートオブジェクトでは、再生属性が必要です。Reclaim属性により、オブジェクト自体のMNT-byに関係なく修正および削除特権を許可することにより、IPアドレスまたはルートスペースのように、より具体的にコントロールを保持できます。
The reclaim attribute provides the means to enforce address lending. It allows cleanup in cases where entities cease to exist or as a last presort means to correct errors such as parties locking themselves out of access to their own objects. To specify all more specific objects the reclaim attribute value should be "ALL". To allow finer control a set of prefixes can be specified.
Reclaim属性は、アドレス貸出を実施する手段を提供します。エンティティが存在しなくなった場合、または最後の阻止事項として、当事者が自分のオブジェクトへのアクセスからロックするなどのエラーを修正するためのクリーンアップを可能にします。より具体的なオブジェクトをすべて指定するには、Reclaim属性値は「すべて」でなければなりません。より細かい制御を許可するには、プレフィックスのセットを指定できます。
A no-reclaim attribute can be used to provide explicit exceptions. A reclaim attribute can only be added to an existing object if the addition of the reclaim attribute does not remove autonomy of existing more specific objects that are covered by the new reclaim attribute.
明示的な例外を提供するために、非回復属性を使用できます。Reclaim属性は、Reclaim属性の追加が新しいReclaim属性でカバーされている既存のより具体的なオブジェクトの自律性を削除しない場合にのみ、既存のオブジェクトに追加できます。
1. A reclaim attribute can be added to an existing object if there are no existing exact matches or more specific objects overlapped by the new reclaim attribute, or
1. 既存の正確な一致がなく、新しいReclaim属性によって重複したより特定のオブジェクトがない場合、既存のオブジェクトにreclaim属性を追加できます。
2. if the submitter is listed in the maintainer pointed to by the mnt-by of the objects which are overlapped, or
2. 提出者がメンテナーにリストされている場合、重複するオブジェクトのMNTによって指摘された場合、または
3. if any overlapped object is listed in a no-reclaim attribute in the object where the reclaim is being added.
3. 重複したオブジェクトが、回収が追加されているオブジェクトのノーリクアリアン属性にリストされている場合。
Similarly, a submitter may delete a no-reclaim attribute from an object only when that submitter is the only maintainer listed in the mnt-by attributes of any overlapped objects. If the submitter is not listed in any of the maintainers pointed to by the mnt-by attributes for one or more overlapped object, then the submitter is not permitted to delete the no-reclaim attribute.
同様に、送信者は、その送信者が重複するオブジェクトのMNT属性にリストされている唯一のメンテナーである場合にのみ、オブジェクトからノーリリール属性を削除することができます。提出者が、1つ以上のオーバーラップオブジェクトのMNTバイ属性によって指摘されたメンテナーのいずれかにリストされていない場合、送信者はノーリリール属性を削除することは許可されません。
If neither a reclaim or no-reclaim attribute is present, then more specific objects of a given object cannot be modified by the maintainer of the less specified object unless the maintainer is also listed as a maintainer in the more specific object. However, the addition of a new route or inetnum object must pass authentication of the largest less specific prefix as part of the authentication check described in Section 9.9.
再laimまたは非回復属性が存在しない場合、メンテナーがより具体的なオブジェクトのメンテナーとしてもリストされていない限り、特定のオブジェクトのより具体的なオブジェクトを、指定されていないオブジェクトのメンテナーによって変更することはできません。ただし、新しいルートまたはINETNUMオブジェクトの追加は、セクション9.9で説明されている認証チェックの一部として、最大のあまり特定のプレフィックスの認証を渡す必要があります。
See Section 10 for a full description of the reclaim and no-reclaim attributes.
回収属性と非回復属性の完全な説明については、セクション10を参照してください。
Many of the RPSL ancillary objects have no natural hierarchy the way AS numbers, Internet addresses and routes do have a numeric hierarchy. Some examples are "maintainers", "people" and "role" objects. For these objects, lack of any hierarchy leads to two problems.
RPSL補助オブジェクトの多くには、数字、インターネットアドレス、ルートには数値階層があるように、自然な階層がありません。いくつかの例は、「メンテナー」、「人」、「役割」オブジェクトです。これらのオブジェクトの場合、階層の欠如は2つの問題につながります。
1. There is no hierarchy that can be exploited to direct queries to alternate registries. At some point the query strategy of searching all known registries becomes impractical.
1. 代替レジストリへの直接クエリに悪用できる階層はありません。ある時点で、すべての既知のレジストリを検索するクエリ戦略は非現実的になります。
2. There is no hierarchy on which authorizations of additions can be based.
2. 追加の承認が基づいている階層はありません。
The first problem can be addressed by considering the name space for each of the ancillary objects to be unique only within the local database and to use explicit references to an external repository where needed. To specify an external repository reference, the object key is preceded by the name of the repository and the delimiter "::". For example a NIC handle may take the form "RIPE::CO19". Currently there is a desire to keep NIC handles unique so the naming convention of appending a dash and the repository name is used. Prepending the repository name provides the unique name space since an object in the RIPE database referencing "CO19" would be interpreted as "RIPE::CO19" by default, but it would still be possible to query or reference "IANA::CO19". There is no possibility of accidentally forgetting to adhere to the conventions when making an addition and the existing objects are accommodated, including cases where name conflicts have already occurred.
最初の問題は、各補助オブジェクトの名前空間をローカルデータベース内でのみ一意にすることを検討し、必要に応じて外部リポジトリに明示的な参照を使用することで対処できます。外部リポジトリリファレンスを指定するには、オブジェクトキーの前にリポジトリの名前と区切り文字 "::"があります。たとえば、NICハンドルは「Ripe :: Co19」という形式を取ることができます。現在、NICハンドルをユニークに保ちたいので、ダッシュを追加するという命名規則とリポジトリ名が使用されています。リポジトリ名を準備することは、「CO19」を参照するRIPEデータベース内のオブジェクトがデフォルトで「RIPE :: CO19」と解釈されるため、一意の名前空間を提供しますが、「IANA :: CO19」をクエリまたは参照することが可能です。名前の競合がすでに発生している場合を含め、追加を行うときに慣習を遵守することを誤って慣れさせない可能性はありません。
The second problem can be partially addressed by using a referral system for the addition of maintainers and requiring that any other object be submitted by a registered maintainer or by IANA. The referral system would allow any existing maintainer to add another maintainer. This can be used in parallel with the addition of other object types to support the maintenance of those objects. For example, when adding a subdomain to the "domain" hierarchy (in the RIPE repository where domains are also handled), even when adding a new domain to a relatively flat domain such as "com", there is already a maintainer for the existing domain. The existing maintainer can add the maintainer that will be needed for the new domain in addition to adding the new domain and giving the new maintainer the right to modify it.
2番目の問題は、メンテナーを追加するために紹介システムを使用し、登録されたメンテナーまたはIANAによって他のオブジェクトを提出することを要求することにより、部分的に対処できます。紹介システムにより、既存のメンテナーが別のメンテナーを追加できるようになります。これは、これらのオブジェクトのメンテナンスをサポートするために、他のオブジェクトタイプの追加と並行して使用できます。たとえば、「ドメイン」階層にサブドメインを追加する場合（ドメインも処理される熟したリポジトリで）、「com」などの比較的フラットドメインに新しいドメインを追加する場合でも、既存のメンテナーが既にメンテナを持っています。ドメイン。既存のメンテナーは、新しいドメインを追加し、新しいメンテナーに変更する権利を提供することに加えて、新しいドメインに必要なメンテナーを追加できます。
An organization gaining a presence on the Internet for the first time would be given a maintainer. This maintainer may list a small number of very trusted employees that are authorized to modify the maintainer itself. The organization itself can then add another maintainer listing a larger set of employees but listing the more restrictive maintainer in the mnt-by attributes of the maintainers themselves. The organization can then add people and role objects as needed and any other objects as needed and as authorization permits.
インターネット上で初めて存在する組織にメンテナーが与えられます。このメンテナーは、メンテナー自体を変更することが許可されている非常に信頼できる少数の従業員をリストする場合があります。組織自体は、より多くの従業員をリストする別のメンテナーを追加できますが、メンテナー自身のMNT属性において、より制限的なメンテナーをリストすることができます。その後、組織は、必要に応じて、必要に応じて、必要に応じて、認可許可として人と役割を追加することができます。
Many RPSL objects do not have a natural hierarchy of their own but allow hierarchical names. Some examples are the object types "as-set" and "route-set". An as-set may have a name corresponding to no naming hierarchy such as "AS-Foo" or it may have a hierarchical name of the form "AS1:AS-Bar".
多くのRPSLオブジェクトには、独自の自然な階層がありませんが、階層名を許可しています。いくつかの例は、オブジェクトタイプ「ASセット」および「ルートセット」です。ASセットには、「As-Foo」などの命名階層に対応する名前があるか、「AS1：AS-BAR」というフォームの階層名がある場合があります。
When a hierarchical name is not used, authorization for objects such as "as-set" and "route-set" correspond to the rules for objects with no hierarchy described in Section 9.6.
階層名が使用されていない場合、「As-Set」や「ルートセット」などのオブジェクトの承認は、セクション9.6に記載されている階層のないオブジェクトのルールに対応しています。
If hierarchical names are used, then the addition of an object must be authorized by the aut-num whose key is named by everything to the left of the rightmost colon in the name of the object being added. Authorization is determined by first using the mnt-lower maintainer reference, or if absent, using the mnt-by reference.
階層名が使用されている場合、オブジェクトの追加は、追加されるオブジェクトの名前で右端のコロンの左側にキーが命名されているAut-Numによって承認されなければなりません。承認は、最初にMNT-lowerメンテナーリファレンスを使用するか、存在しない場合はMNTバイ参照を使用することにより決定されます。
A query may have to span multiple repositories. All queries should be directed toward a local repository which may mirror the root repository and others. Currently each IRR repository mirrors all other repositories. In this way, the query may be answered by the local repository but draw data from others.
クエリは複数のリポジトリにまたがる必要がある場合があります。すべてのクエリは、ルートリポジトリなどを反映する可能性のあるローカルリポジトリに向ける必要があります。現在、各IRRリポジトリは他のすべてのリポジトリを反映しています。このようにして、クエリはローカルリポジトリによって回答されますが、他の人からデータを描画できます。
The mechanism below when applied to multiple repositories assumes the existence of an attribute for traversal of the repositories. The definition of this attribute is considered a distributed registry issue and is out of scope of this document.
以下のメカニズムは、複数のリポジトリに適用された場合、リポジトリの移動の属性の存在を想定しています。この属性の定義は、分散レジストリの問題と見なされ、このドキュメントの範囲外です。
For object types that have a natural hierarchy, such as aut-num, inet-num, and route, the search begins at the root database and follows the hierarchy. For objects types that have no natural hierarchy, such as maintainer, person, and role objects, the search is confined to a default database unless a database is specified. The default database is the same database as an object from which a reference is made if the query is launched through the need to follow a reference. Otherwise the default is generally the local database or a default set by the repository. The default can be specified in the query itself as described in Section 9.7.
Aut-Num、Inet-Num、Routeなどの自然な階層を持つオブジェクトタイプの場合、検索はルートデータベースで始まり、階層に従います。メンテナー、個人、ロールオブジェクトなどの自然な階層を持たないオブジェクトタイプの場合、検索はデータベースが指定されていない限り、デフォルトのデータベースに限定されます。デフォルトのデータベースは、参照に従う必要があることからクエリが起動された場合に参照が行われるオブジェクトと同じデータベースです。それ以外の場合、デフォルトは通常、ローカルデータベースまたはリポジトリによってデフォルト設定されます。デフォルトは、セクション9.7で説明されているように、クエリ自体で指定できます。
In the absense of attributes to traverse multiple registries a search of all repositories is needed. With such attributes the search would proceed as follows. In searching for an AS, the delegation attribute in AS blocks can be consulted, moving the search to data from other repositories. Eventually the AS is either found or the search fails. The search for an inetnum is similar. Less specific inetnums may refer the search to other databases. Eventually the most specific inetnum is found and its status (assigned or not assigned) can be determined. The definition of attributes for traversal of repositories is considered a distrbiuted registry issue and is not within the scope of this document.
複数のレジストリをトラバースするための属性の不在では、すべてのリポジトリの検索が必要です。このような属性により、検索は次のように進行します。ASを検索する際に、ASブロックの委任属性を参照して、検索を他のリポジトリからのデータに移動できます。最終的には、見つかったか、検索が失敗します。inetnumの検索は似ています。あまり具体的ではないInetNumsは、検索を他のデータベースに参照できます。最終的に最も具体的なinetnumが見つかり、そのステータス（割り当てまたは割り当てられていない）を決定できます。リポジトリの移動のための属性の定義は、分布レジストリの問題と見なされ、このドキュメントの範囲内ではありません。
The search for a route in the presence of attributes for the traversal of multiple registries is similar except the search may branch to more than one repository. The most specific route in one repository may be more specific than the most specific in another. In looking for a route object it makes sense to return the most specific route that is not more specific than the query requests regardless of which repository that route is in rather than return one route from each repository that contains a less specific overlap.
検索が複数のリポジトリに分岐する場合を除き、複数のレジストリのトラバーサルの属性の存在下でのルートの検索は類似しています。あるリポジトリの最も具体的なルートは、別のリポジトリで最も具体的なルートよりも具体的なルートです。ルートオブジェクトを探す際には、あまり特定の重複を含む各リポジトリから1つのルートを返すのではなく、どのリポジトリにあるかに関係なく、クエリ要求よりも具体的ではない最も具体的なルートを返すことは理にかなっています。
The mechanism below when applied to multiple repositories assumes the existence of an attribute for traversal of the repositories. The definition of this attribute is considered a distributed registry issue and is out of scope of this document.
以下のメカニズムは、複数のリポジトリに適用された場合、リポジトリの移動の属性の存在を想定しています。この属性の定義は、分散レジストリの問題と見なされ、このドキュメントの範囲外です。
The root repository must be initially populated at some epoch with a few entries. An initial maintainer is needed to add more maintainers. The referral-by attribute can be set to refer to itself in this special case (Section 10 describes the referral-by). When adding an inetnum or a route object an existing exact match or a less specific overlap must exist. A route object may be added based on an exact match or a less specific inetnum. The root repository must be initially populated with the allocation of an inetnum covering the prefix 0/0, indicating that some address allocation authority exists. Similarly an initial as-block is needed covering the full AS number range.
ルートリポジトリは、最初にいくつかのエポックにいくつかのエントリを備えている必要があります。メンテナーを追加するには、初期メンテナーが必要です。紹介ごとの属性は、この特別なケースでそれ自体を参照するように設定できます（セクション10で紹介ごとに説明します）。inetnumまたはルートオブジェクトを追加する場合、既存の正確な一致または特定のあまり特定のオーバーラップが存在する必要があります。ルートオブジェクトは、正確な一致またはそれほど特定のInetnumに基づいて追加される場合があります。ルートリポジトリは、最初にプレフィックス0/0をカバーするINETNUMの割り当てを入力する必要があります。同様に、As数の範囲をカバーする最初のAsブロックが必要です。
When adding an object with no natural hierarchy, the search for an existing object follows the procedure outlined in Section 9.8.
自然な階層のないオブジェクトを追加すると、既存のオブジェクトの検索は、セクション9.8で概説されている手順に従います。
When adding an aut-num (an AS), the same procedure used in a query is used to determine the appropriate repository for the addition and to determine which maintainer applies. The sequence of AS-block objects and repository delegations is followed. If the aut-num does not exist, then the submission must match the authentication specified in the maintainer for the most specific AS-block in order to be added.
Aut-Num（AS）を追加する場合、クエリで使用されるのと同じ手順を使用して、追加の適切なリポジトリを決定し、どのメンテナーが適用されるかを決定します。As-Blockオブジェクトとリポジトリの代表団のシーケンスが続きます。Aut-Numが存在しない場合、送信は、追加するために最も具体的なASブロックについて、メンテナーで指定された認証と一致する必要があります。
The procedure for adding an inetnum is similar. The sequence of inet-num blocks is followed until the most specific is found. The submission must match the authentication specified in the maintainer for the most specific inetnum overlapping the addition.
Inetnumを追加する手順は似ています。INET-NUMブロックのシーケンスは、最も具体的なものが見つかるまで続きます。提出は、追加と重複する最も具体的なInetnumのために、メンテナーで指定された認証と一致する必要があります。
Adding a route object is somewhat more complicated. The route object submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num and the authentication specified in either a route object or if no applicable route object is found, then an inetnum.
ルートオブジェクトを追加することはやや複雑です。ルートオブジェクトの送信は、2つの認証基準を満たす必要があります。Aut-Numで指定された認証と、ルートオブジェクトで指定された認証と一致する必要があります。
An addition is submitted with an AS number and prefix as its key. If the object already exists, then the submission is treated as a modify (see Section 9.10). If the aut-num does not exist on a route add, then the addition is rejected (see Section C for further discussion of tradeoffs). If the aut-num exists then the submission is checked against the applicable maintainer. A search is then done for the prefix first looking for an exact match. If the search for an exact match fails, a search is made for the longest prefix match that is less specific than the prefix specified. If this search succeeds it will return one or more route objects. The submission must match an applicable maintainer in at least one of these route objects for the addition to succeed. If the search for a route object fails, then a search is performed for an inetnum that exactly matches the prefix or for the most specific inetnum that is less specific than the route object submission. The search for an inetnum should never fail but it may return an unallocated or reserved range. The inetnum status must be "allocated" and the submission must match the maintainer.
AS番号とプレフィックスがキーとして追加されます。オブジェクトが既に存在する場合、提出物は変更として扱われます（セクション9.10を参照）。ルート追加にAut-Numが存在しない場合、追加は拒否されます（トレードオフの詳細については、セクションCを参照）。Aut-Numが存在する場合、該当するメンテナーに対して提出がチェックされます。次に、最初に正確な一致を探しているプレフィックスの検索が行われます。正確な一致の検索が失敗した場合、指定されたプレフィックスよりも具体的ではない最長のプレフィックスマッチに対して検索が行われます。この検索が成功した場合、1つ以上のルートオブジェクトを返します。提出は、これらのルートオブジェクトの少なくとも1つで該当するメンテナーと一致して、成功するために追加する必要があります。ルートオブジェクトの検索が失敗した場合、プレフィックスと正確に一致するinetnumまたはルートオブジェクトの提出よりも具体的ではない最も具体的なinetnumに対して検索が実行されます。inetnumの検索は決して失敗することはありませんが、未割り当てまたは予約範囲を返す場合があります。INETNUMのステータスは「割り当てられ」、提出物はメンテナーと一致する必要があります。
Having found the AS and either a route object or inetnum, the authorization is taken from these two objects. The applicable maintainer object is any referenced by the mnt-routes attributes. If one or more mnt-routes attributes are present in an object, the mnt-by attributes are not considered. In the absence of a mnt-routes attribute in a given object, the mnt-by attributes are used for that object. The authentication must match one of the authorizations in each of the two objects.
ASおよびRouteオブジェクトまたはInetnumのいずれかを見つけたため、これらの2つのオブジェクトから承認が取得されます。該当するメンテナーオブジェクトは、MNT-Routes属性によって参照されます。1つ以上のMNT-Routes属性がオブジェクトに存在する場合、MNT-by属性は考慮されません。特定のオブジェクトにMNT-routes属性がない場合、そのオブジェクトにMNT-by属性が使用されます。認証は、2つのオブジェクトのそれぞれの承認の1つと一致する必要があります。
If the addition of a route object or inetnum contains a reclaim attribute, then any more specific objects of the same type must be examined. The reclaim attribute can only be added if there are no more specific overlaps or if the authentication on the addition is present in the authorization of a less specific object that already has a reclaim attribute covering the prefix range, or if the authentication on the addition is authorized for the modification of all existing more specific prefixes covered by the addition.
ルートオブジェクトまたはinetnumの追加に再生属性が含まれている場合、同じタイプのこれ以上の特定のオブジェクトを調べる必要があります。Reclaim属性は、特定のオーバーラップがなく、追加の認証がプレフィックス範囲をカバーするReclaim属性を既に持っている特定のオブジェクトの承認に存在する場合、または追加の認証が追加の認証がある場合にのみ追加できます。追加でカバーされているすべての既存のより具体的な接頭辞の変更が許可されています。
When modifying or deleting any existing object a search for the object is performed as described in Section 9.8. If the submission matches an applicable maintainer for the object, then the operation can proceed. An applicable maintainer for a modification is any maintainer referenced by the mnt-by attribute in the object. For route and inet-num objects an applicable maintainer may be listed in a less specific object with a reclaim attribute.
既存のオブジェクトを変更または削除する場合、セクション9.8で説明されているように、オブジェクトの検索が実行されます。提出物がオブジェクトの該当するメンテナーと一致する場合、操作が続行できます。変更に該当するメンテナーは、オブジェクト内のMNT-by属性によって参照されるメンテナーです。RouteおよびINET-NUMオブジェクトの場合、該当するメンテナーは、Reclaim属性を備えたあまり特定のオブジェクトにリストできます。
If the submission is for a route object, a search is done for all less specific route objects and inetnums. If the submission is for an inetnum, a search is done for all less specific inetnums. If the submission fails the authorization in the object itself but matches the reclaim attribute in any of the less specific objects, then the operation can proceed. Section C contains discussion of the rationale behind the use of the reclaim attribute.
送信がルートオブジェクトの場合、あまり特定のルートオブジェクトとinetnumsのすべての検索が行われます。提出がinetnumの場合、あまり具体的ではないInetnumsに対して検索が行われます。提出がオブジェクト自体の承認に失敗したが、あまり特定のオブジェクトのいずれかの再生属性と一致する場合、操作を続行できます。セクションCには、Reclaim属性の使用の背後にある理論的根拠の議論が含まれています。
A modification to an inetnum object that adds a reclaim attribute or removes a no-reclaim attribute must be checked against all existing inetnums that are more specific. The same check of the reclaim attribute that is made during addition must be made when a reclaim attribute is added by a modification (see Section 9.9).
Reclaim属性を追加または削除するINETNUMオブジェクトの変更は、より具体的なすべての既存のInetNumsに対してチェックする必要があります。変更中に加えられた再生属性の同じチェックは、修正によって再生属性が追加されたときに行う必要があります（セクション9.9を参照）。
A deletion is considered a special case of the modify operation. The deleted object may remain in the database with a "deleted" attribute in which case the mnt-by can still be consulted to remove the "deleted" attribute.
削除は、修正操作の特殊なケースと見なされます。削除されたオブジェクトは、「削除された」属性を持つデータベースに残っている場合があります。この場合、MNT-byを参照して、「削除された」属性を削除することができます。
10 Data Format Summaries
10のデータ形式の概要
RIPE-181 [2] and RPSL [1] data is represented externally as ASCII text. Objects consist of a set of attributes. Attributes are name value pairs. A single attribute is represented as a single line with the name followed by a colon followed by whitespace characters (space, tab, or line continuation) and followed by the value. Within a value all whitespace is equivalent to a single space. Line continuation is supported by a backslash at the end of a line or the following line beginning with whitespace. When transferred, externally attributes are generally broken into shorter lines using line continuation though this is not a requirement. An object is externally represented as a series of attributes. Objects are separated by blank lines.
RIPE-181 [2]およびRPSL [1]データは、ASCIIテキストとして外部から表されます。オブジェクトは、一連の属性で構成されています。属性は名前値ペアです。単一の属性は、名前が付いた単一の行として表され、その後にコロンが続いてホワイトスペースの文字（スペース、タブ、または線の継続）が続き、値が続きます。値内で、すべての空白は単一のスペースに相当します。ラインの継続は、線の終わりにバックスラッシュまたは白人から始まる次の線によってサポートされています。転送されると、外部属性は通常、ラインの継続を使用して短い線に分割されますが、これは要件ではありません。オブジェクトは、一連の属性として外部的に表されます。オブジェクトは空白線で区切られています。
There are about 80 attribute types in the current RIPE schema and about 15 object types. Some of the attributes are mandatory in certain objects. Some attributes may appear multiple times. One or more attributes may form a key. Some attributes or sets of attributes may be required to be unique across all repositories. Some of the attributes may reference a key field in an object type and may be required to be a valid reference. Some attributes may be used in inverse lookups.
現在の熟したスキーマには約80の属性タイプがあり、約15のオブジェクトタイプがあります。一部の属性は、特定のオブジェクトで必須です。一部の属性が複数回表示される場合があります。1つ以上の属性がキーを形成する場合があります。一部の属性または一連の属性は、すべてのリポジトリで一意であることが必要になる場合があります。一部の属性は、オブジェクトタイプのキーフィールドを参照する場合があり、有効な参照を必要とする場合があります。一部の属性は、逆検索で使用される場合があります。
A review of the entire RIPE or RPSL schema would be too lengthy to include here. Only the differences in the schema are described.
RIPEまたはRPSLスキーマ全体のレビューは、ここに含めるには長すぎます。スキーマの違いのみが説明されています。
One new object type and several attributes are added to the RIPE/RPSL schema. There are significant changes to the rules which determine if the addition of an object is authorized.
Ripe/RPSLスキーマに1つの新しいオブジェクトタイプといくつかの属性が追加されます。オブジェクトの追加が承認されているかどうかを判断するルールには大きな変更があります。
The new object type is listed below. The first attribute listed is the key attribute and also serves as the name of the object type.
新しいオブジェクトタイプを以下に示します。リストされている最初の属性は重要な属性であり、オブジェクトタイプの名前としても機能します。
as-block key mandatory single unique
descr optional multiple
remarks optional multiple
admin-c mandatory multiple
tech-c mandatory multiple
notify optional multiple
mnt-by mandatory multiple
changed mandatory multiple
source mandatory single
In the above object type only the key attribute "as-block" is new:
as-block This attribute provides the AS number range for an "as-block" object. The format is two AS numbers including the sub-string "AS" separated by a "-" delimiter and optional whitespace before and after the delimiter.
ASブロックこの属性は、「Asブロック」オブジェクトのAS番号範囲を提供します。この形式は、「「 - 」 - 「デリミッター」とデリミッターの前後のオプションの白人によって区切られたサブストリング「As」を含む2つの数字です。
In order to support stronger authentication, the following keywords are added to the "auth" attribute:
より強力な認証をサポートするために、次のキーワードが「auth」属性に追加されます。
pgp-from The remainder of the attribute gives the string identifying a PGP identity whose public key is held in an external keyring. The use of this method is deprecated in favor of the "pgpkey" method.
属性の残りの部分からPGPは、公開キーが外部キーリングに保持されているPGPアイデンティティを識別する文字列に与えられます。この方法の使用は、「PGPKEY」メソッドを支持して廃止されます。
pgpkey See [18].
pgpkey [18]を参照してください。
In order to disable authentication and give permission to anyone, the authentication method "none" is added. It has no arguments.
認証を無効にし、誰にでも許可を与えるために、認証方法「なし」が追加されます。議論はありません。
An additional change is the "auth" attribute is allowed to exist in a "person" or "role" object. The "auth" method "role" or "person" can be used to refer to a role or person object and take the "auth" fields from those objects. Care must be taken in implementations to detect circular references and terminate expansion or the references already visited.
追加の変更は、「Auth」属性が「人」または「役割」オブジェクトに存在することを許可されています。「auth」メソッド「役割」または「人」を使用して、役割または個人のオブジェクトを参照し、それらのオブジェクトから「auth」フィールドを取得できます。循環参照を検出し、拡張を終了するか、すでに訪問された参照を終了するために、実装に注意する必要があります。
A few attributes are added to the schema. These are:
スキーマにいくつかの属性が追加されます。これらは：
mnt-routes The mnt-routes attribute may appear in an aut-num, inet-num, or route object. This attribute references a maintainer object which is used in determining authorization for the addition of route objects. After the reference to the maintainer, an optional list of prefix ranges (as defined in RPSL) inside of curly braces or the keyword "ANY" may follow. The default, when no additional set items are specified is "ANY" or all more specifics. The mnt-routes attribute is optional and multiple. See usage details in Section 9.1.
MNT-routes MNT-Routes属性は、Aut-Num、Inet-Num、またはRouteオブジェクトに表示される場合があります。この属性は、ルートオブジェクトの追加の許可を決定する際に使用されるメンテナーオブジェクトを参照します。メンテナーへの参照の後、Curly Bracesまたはキーワード「任意の」の内側のプレフィックス範囲（RPSLで定義されている）のオプションのリストが続く場合があります。デフォルトは、追加のセットアイテムが指定されていない場合、「任意」またはその他すべての詳細です。MNT-Routes属性はオプションで複数です。セクション9.1の使用法の詳細を参照してください。
mnt-lower The mnt-lower attribute may appear in an inetnum, route, as-block or aut-num object. This attribute references a maintainer object. When used in an inetnum or route object the effect is the same as a "mnt-routes" but applies only to prefixes more specific than the prefix of the object in which it is contained. In an as block object, mnt-lower allows addition of more specific as-block objects or aut-num objects. In an aut-num object the mnt-lower attribute specifies a maintainer that can be used to add objects with hierarchical names as described in Section 9.7.
MNT-lower MNT-lower属性は、inetnum、route、as blockまたはaut-numオブジェクトに表示される場合があります。この属性は、メンテナーオブジェクトを参照します。inetnumまたはルートオブジェクトで使用する場合、効果は「mnt-routes」と同じですが、それが含まれているオブジェクトの接頭辞よりも特定の接頭辞にのみ適用されます。ASブロックオブジェクトでは、MNT-lowerを使用すると、より具体的なブロックオブジェクトまたはAut-Numオブジェクトを追加できます。Aut-Numオブジェクトでは、MNT-lower属性は、セクション9.7で説明されているように、階層名を持つオブジェクトを追加するために使用できるメンテナーを指定します。
reclaim The reclaim attribute may appear in as-block, aut-num, inet-num, or route objects. Any object of the same type below in the hierarchy may be modified or deleted by the maintainer of the object containing a reclaim attribute. The value of the attribute is a set or range of objects of the same type where the syntax of the set or range is as defined in RPSL. See Section 9.5 for restrictions on adding reclaim attributes.
Reclaimは、再生属性がブロック、Aut-Num、INET-NUM、またはルートオブジェクトに表示される場合があります。階層内の下の同じタイプのオブジェクトは、再生属性を含むオブジェクトの保守者によって変更または削除される場合があります。属性の値は、セットまたは範囲の構文がRPSLで定義されているのと同じタイプのオブジェクトのセットまたは範囲です。再生属性の追加に関する制限については、セクション9.5を参照してください。
no-reclaim The no-reclaim attribute is used with the reclaim attribute. The no-reclaim attribute negates any reclaim attribute it overlaps. See Section 9.5 for restrictions on deleting no-reclaim attributes.
NO-Reclaim recraim属性は、Reclaim属性とともに使用されます。非回復属性は、それが重複する任意のReclaim属性を否定します。非回復属性の削除に関する制限については、セクション9.5を参照してください。
referral-by This attribute is required in the maintainer object. It may never be altered after the addition of the maintainer. This attribute refers to the maintainer that created this maintainer. It may be multiple if more than one signature appeared on the transaction creating the object.
紹介この属性は、メンテナーオブジェクトに必要です。メンテナーの追加後に変更されることはありません。この属性とは、このメンテナーを作成したメンテナーを指します。オブジェクトを作成するトランザクションに複数の署名が表示された場合、複数の場合があります。
auth-override An auth-override attribute can be added, deleted, or changed by a transaction submitted by maintainer listed in the referral-by. An auth-override can only be added to a maintainer if that maintainer has been inactive for the prior 60 days. The auth-override attribute itself contains only the date when the attribute will go into effect which must be at least 60 days from the current date unless there is already authorization to modify the maintainer. After the date in the auth-override is reached, those identified by the maintainer in the referral-by have authorization to modify the maintainer. This attribute exists as a means to clean up should the holder of a maintainer become unresponsive and can only take effect if that maintainer does not remove the auth-override in response to the automatic notification that occurs on changes.
AUTHORRIDE AUTH-OVERRIDE属性は、紹介者にリストされているメンテナーが提出したトランザクションによって追加、削除、または変更できます。Auth-Overrideは、そのメンテナーが過去60日間非アクティブであった場合にのみメンテナーに追加できます。Auth-Override属性自体には、メンテナーを変更する許可が既にない場合を除き、属性が有効になる日付のみが現在の日付から60日でなければなりません。Auth-Overrideの日付に到達した後、紹介者のメンテナーによって識別されたものは、メンテナーを変更する許可を持っています。この属性は、メンテナーの所有者が反応しなくなった場合にクリーンアップする手段として存在し、そのメンテナーが変化に発生する自動通知に応じて認証を除去しない場合にのみ有効になります。
The existing "mnt-by" attribute references the "maintainer" object type. The "mnt-by" attribute is now mandatory in all object types. A new maintainer may be added by any existing maintainer. The "referral-by" attribute is now mandatory in the "maintainer" object to keep a record of which maintainer made the addition and can never be changed. Maintainers cannot be deleted as long as they are referenced by a "referral-by" attribute elsewhere.
既存の「MNT-by」属性は、「メンテナー」オブジェクトタイプを参照します。「MNT-by」属性は、すべてのオブジェクトタイプで必須になりました。既存のメンテナーによって新しいメンテナーが追加される場合があります。「メンテナー」オブジェクトには、「メンテナー」オブジェクトに「紹介」属性が必須であり、メンテナーが追加され、決して変更できない記録を保持します。メンテナーは、他の場所の「紹介」属性によって参照されている限り、削除することはできません。
A Core and Non-Core Functionality
コアおよび非コア機能
Most of the objects and attributes described in this document are essential to the authorization framework. These are referred to as being part of the "core" functionality. A few attributes listed here are considered "non-core".
このドキュメントで説明されているオブジェクトと属性のほとんどは、承認フレームワークにとって不可欠です。これらは、「コア」機能の一部と呼ばれます。ここにリストされているいくつかの属性は、「非コア」と見なされます。
The "reclaim" and "no-reclaim" attributes are a convenience to support flexibility in the implementation of address lending.
「回復」と「ノーリファイル」属性は、アドレス貸付の実装における柔軟性をサポートするための利便性です。
The "auth-override" attribute is a convenience to facilitate recovery in an environment where repository data is redistributed in any way.
「Auth-Override」属性は、リポジトリデータが何らかの形で再配布される環境での回復を促進するための便利さです。
The "referal-by" attribute is a "core" feature. An individual registry may express its sutonomy by creating a self-referencing maintainer, one whose "referal-by" points to itslef. Other registries can decide on a case by case basis whether to consider such an entry valid. A registry may only allow the "referal-by" to refer to a specific maintainer under the control of the registry. This further restriction is an issue that is purely local to the registry.
「参照」属性は「コア」機能です。個々のレジストリは、自己参照メンテナーを作成することにより、そのスーターを表現することができます。他のレジストリは、そのようなエントリを有効なものと見なすかどうかをケースごとに決定できます。レジストリは、「参照」のみがレジストリの制御下にある特定のメンテナーを指すことを許可する場合があります。このさらなる制限は、レジストリに純粋にローカルな問題です。
B Examples
b例
The examples below leave out some required attributes that are not needed to illustrate the use of the objects and attributes described in this document. Missing are admin-c, tech-c, changed, source. Also missing are attributes such as mnt-nfy, whose use are a good practice but are not strictly required.
以下の例では、このドキュメントで説明されているオブジェクトと属性の使用を説明するために必要ではないいくつかの必要な属性を除外します。行方不明は、admin-c、tech-c、変更、ソースです。また、MNT-NFYなどの属性も欠落しています。
To do anything at all a maintainer is needed. At some epoch a a single maintainer is populated in one repository and that maintianer has a referal-by pointing to itself. All others referal-by references can be traced back to that maintainer. At the epoch the as-block AS0- AS65535 and the inetnum 0.0.0.0-255.255.255.255 are also allocated. Other ancilliary object may also be needed to bootstrap.
何でもするには、メンテナーが必要です。いくつかの時代では、1つのメンテナーが1つのリポジトリに入力されており、そのメンテナーはそれ自体を指し示す紹介を持っています。他のすべての参照参照は、そのメンテナーにまでさかのぼることができます。エポックでは、As-Block AS0-AS65535およびINETNUM 0.0.0.0-255.255.255.255も割り当てられています。ブートストラップには、他の補助オブジェクトも必要になる場合があります。
mntner: ROOT-MAINTAINER auth: pgpkey-12345678
MNTNER：root-maintainer auth：pgpkey-12345678
mnt-by: ROOT-MAINTAINER referal-by: ROOT-MAINTAINER
Mnt-by：root-maintainer referal-by：root-maintainer
This root maintainer might add a top level maintainer for some organization.
このルートメンテナーは、一部の組織にトップレベルのメンテナーを追加する場合があります。
mntner: WIZARDS descr: High level Technical Folks auth: pgpkey-23456789 auth: pgpkey-3456789a mnt-by: WIZARDS referal-by: ROOT-MAINTAINER
MNTNER：Wizards Descr：高レベルの技術的な人々AUTH：PGPKEY-23456789 AUTH：PGPKEY-3456789A MNT-by：Wizards参照-by：root-maintainer
That maintainer might add another who have more limited capabilities.
そのメンテナーは、より限られた機能を持つ別のものを追加するかもしれません。
mntner: MORTALS descr: Maintain day to day operations auth: pgpkey-456789ab auth: pgpkey-56789abc auth: pgpkey-6789abcd mnt-by: WIZARDS referal-by: WIZARDS
MNTNER：MOTALS DESCR：日常業務を維持する認証：PGPKEY-456789AB AUTH：PGPKEY-56789ABC AUTH：PGPKEY-6789ABCD MNT-BY：ウィザード参照
Note that the WIZARDS can change their own maintainer object and the MORTALS maintainer object but MORTALS cannot.
ウィザードは独自のメンテナーオブジェクトと人間のメンテナーオブジェクトを変更できますが、モルタルはできないことに注意してください。
At some point an as-block is allocated and broken down. In the example below, private number space is used.
ある時点で、ASブロックが割り当てられ、分解されます。以下の例では、プライベート番号スペースが使用されています。
as-block: AS65500-AS65510 mnt-by: SOME-REGISTRY mnt-lower: WIZARDS
as-block：as65500-as65510 mnt-by：some-registry mnt-lower：wizards
Note that a registry has control over the object that they have created representing the allocation, but have given the party to which the allocation was made the ability to create more specific objects. Below this as-block, an aut-num is added. Note that import and export are normally required for a aut-num but are not shown here.
レジストリは、割り当てを表して作成したオブジェクトを制御しているが、割り当てがより具体的なオブジェクトを作成する能力を与えられた当事者を与えたことに注意してください。このようにブロックの下に、自動番号が追加されます。通常、Aut-Numにはインポートとエクスポートが必要ですが、ここには表示されないことに注意してください。
aut-num: AS65501 mnt-by: WIZARDS mnt-lower: MORTALS
Aut-Num：AS65501 MNT-by：Wizards MNT-lower：Mortals
In aut-num above the WIZARDS maintainer can modify the aut-num itself. The MORTALS maintainer can add route objects using this AS as the origin if they also have authorization for the IP number space in a less specific route or inetnum.
Wizardsメンテナーの上のAut-Numでは、Aut-Num自体を変更できます。Mortalsメンテナーは、それほど特定のルートまたはInetnumのIP番号スペースの許可もある場合、これを起源として使用してルートオブジェクトを追加できます。
We also need an inetnum allocation. In this example the inetnum is allocated to a completely different organization. Again attributes are omited which would normally be needed in an inetnum.
また、inetnum割り当ても必要です。この例では、Inetnumはまったく異なる組織に割り当てられます。繰り返しますが、通常はinetnumで必要な属性が省略されています。
inetnum: 192.168.144.0-192.168.151.255 mnt-by: SOME-REGISTRY mnt-lower: ISP reclaim: ALL
inetnum：192.168.144.0-192.168.151.255 Mnt-by：some-registry mnt-lower：isp reclaim：all
The maintainer ISP can add more specific inetnums or routes with this address space. Note that the registry has declared their ability to reclaim the address space.
メンテナーISPは、このアドレススペースを使用して、より具体的なInetNumsまたはルートを追加できます。レジストリは、アドレス空間を取り戻す能力を宣言したことに注意してください。
If ISP wished to reclaim all allocations but some suballocation of theirs resisted, we might get something like the following in which they will reclaim only the top half of an allocation (possibly if it remains unused).
ISPがすべての割り当てを取り戻したいが、それらのいくつかの断熱が抵抗した場合、割り当ての上半分のみを取り戻す以下のようなものを得るかもしれません（おそらく未使用のままであれば）。
inetnum: 192.168.144.0-192.168.147.255 mnt-by: ISP mnt-lower: EBG-COM reclaim: 192.168.146/23+
inetnum：192.168.144.0-192.168.147.255 Mnt-by：ISP MNT-lower：EBG-COM Reclaim：192.168.146/23
If we assume that the maintainer EBG-COM and the maintainer MORTALS want to add a route object, one way to do it is for both parties to sign. If EBG-COM for some reason couldn't aggregate an allocate a single top level route (which is inexcusable these days) or there was a preference for some reason to avoid the joint signature approach on a submission either party could give the other permission to make the addition. A mnt-routes could be added to the aut-num or a mnt-lower could be added to an inetnum.
メンテナーEBG-COMとメンテナーモルタルがルートオブジェクトを追加したいと仮定した場合、それを行う1つの方法は、両当事者が署名することです。何らかの理由でEBG-COMが単一のトップレベルルートを割り当てることができなかった場合（最近は許されない）、または提出の共同署名アプローチを回避するために何らかの理由で好みがありました。追加します。Mnt-routesをAut-Numに追加したり、MNT-lowerをINETNUMに追加できます。
aut-num: AS65501
mnt-by: WIZARDS
mnt-lower: MORTALS
mnt-routes: EBG-COM {192.168.144/23}
With this change to the aut-num the maintainer EBG-COM could add a route with origin AS65501, but only with a limited address range.
この変更により、Aut-Numに変更されると、メンテナーEBG-COMはOrigin AS65501のルートを追加できますが、アドレス範囲は限られています。
route: 192.168.144/24
origin: AS65501
descr: These boneheads don't aggregate
mnt-by: EBG-COM
mnt-by: FICTION::MORTALS
Note that while the maintainer EBG-COM added the object they allowed the maintainer MORTALS the ability to modify it.
メンテナーEBG-COMがオブジェクトを追加している間、メンテナーモルタルにそれを変更する能力を許可することに注意してください。
If an object ended up in another repository, a single maintainer could still be used. In the example above the notation FICTION::MORTALS indicates that the route object is in a different repository and rather than duplicate the maintainer, a reference is made to the repository in which the MORTALS object resides.
オブジェクトが別のリポジトリで終わった場合、単一のメンテナーを使用することができます。上記の例では、表記フィクション::人間は、ルートオブジェクトが別のリポジトリにあり、メンテナーを複製するのではなく、Mortalsオブジェクトが存在するリポジトリを参照していることを示しています。
In the example below, a pair of route-sets are added and hierarchical names are used.
以下の例では、ルートセットのペアが追加され、階層名が使用されます。
route-set: AS65501:Customers mnt-by: WIZARDS mnt-lower: MORTALS
ルートセット：AS65501：顧客MNT-by：Wizards MNT-lower：MORTALS
route-set: AS65501:Customers:EBG-COM
mnt-by: MORTALS
mnt-lower: EBG-COM
Suppose in the 192.168.144/24 object above, only the EBG-COM maintainer is listed. If EBG-COM goes bankrupt, no longer needs address space, and stops responding, it could be difficult to delete this object. The maintainer listed in the EBG-COM referral-by attribute could be contacted. They could add a auth-override attribute to the EBG-COM object. Later they could modify the EBG-COM object and then any objects with EBG-COM in the mnt-by.
上記の192.168.144/24オブジェクトでは、EBG-COMメンテナーのみがリストされているとします。EBG-COMが破産し、アドレススペースを必要とせず、応答を停止する場合、このオブジェクトを削除することは難しい場合があります。EBG-COM紹介属性にリストされているメンテナーに連絡することができます。EBG-COMオブジェクトにAuth-Override属性を追加できます。その後、EBG-COMオブジェクトを変更でき、次にMNT-byにEBG-COMを持つオブジェクトを変更できました。
mntner: EBG-COM mnt-by: EBG-COM auth-override: 19990401
MNTNER：EBG-COM MNT-BY：EBG-COM AUTH-OVERRIDE：19990401
The examples above stray significantly from realism. They do provide simple illustrations of the usage of the objects type and attributes described in this document and hopefully in doing some are of some value.
上記の例は、リアリズムから大きく迷います。彼らは、このドキュメントで説明されているオブジェクトのタイプと属性の使用法の簡単なイラストを提供します。
C Technical Discussion
C技術的な議論
A few design tradeoffs exist. Some of these tradeoffs, the selected solution, and the alternatives are discussed here. Some of the issues are listed below.
いくつかのデザイントレードオフが存在します。これらのトレードオフ、選択されたソリューション、および代替案については、ここで説明します。問題の一部は以下にリストされています。
1. Whether to err on the side of permissiveness and weaken authorization controls or risk the possibility of erecting barriers to registering information.
1. 許容性の側で誤りを犯し、認可の管理を弱めるか、情報を登録するための障壁を立てる可能性を危険にさらすか。
2. Whether to support enforcible address lending or provide the smaller or end user with ultimate control over the registration of the prefixes they are using.
2. 強制的なアドレス貸出をサポートするか、小規模またはエンドユーザーに使用しているプレフィックスの登録を最終的に制御するか。
3. What to do with older objects that either don't conform to newer requirements regarding minimum authorization, authentication, and accountability, or are of questionable validity.
3. 最小許可、認証、説明責任に関する新しい要件に準拠していない古いオブジェクトをどうするか、疑わしい妥当性です。
If the requirement that an aut-num exists is relaxed, then it is possible for anyone to make use of an unassigned AS number or make use of an assigned AS number for which the aut-num has not been entered. Placing requirements on the entry of aut-num presumes cooperation of the Internet address allocation authority (if separate from the routing registry). The address allocation authority must be willing to field requests to populate skeleton aut-nums from the party for which the allocation has been made. These aut-num must include a reference to a maintainer. A request to the address allocation authority must therefore include a reference to an existing maintainer.
Aut-Numが存在するという要件が緩和されている場合、誰もが番号として割り当てられていないものを使用したり、Aut-Numが入力されていない番号として割り当てられたものを使用することができます。Aut-Numの入力に要件を配置すると、インターネットアドレス配分局の協力が想定されます（ルーティングレジストリとは別に）。住所配分機関は、割り当てが行われた当事者からのスケルトンオートナムに登録するために、フィールドリクエストを喜んでリクエストする必要があります。これらのAut-Numには、メンテナーへの参照を含める必要があります。したがって、アドレス配分局への要求には、既存のメンテナーへの参照を含める必要があります。
The ability to add route objects is also tied to the existence of less specific route objects or inetnums. The Internet address allocation authority (if separate from the routing registry) must also be willing to field requests to add inetnum records for the party already allocated the address space.
ルートオブジェクトを追加する機能は、あまり特定のルートオブジェクトまたはinetnumsの存在にも結び付けられています。インターネットアドレス配分局（ルーティングレジストリとは別の場合）は、すでに住所スペースを割り当てられた当事者にINETNUMレコードを追加するためにリクエストをフィールドに導く必要があります。
The Internet address allocation authority should also add inetnums and aut-nums for new allocations. In order to do so, a maintainer must exist. If a party is going to connect to the Internet, they can get a maintainer by making a request to the Internet service provider they will be connecting to. Once they have a maintainer they can make a request for address space or an AS number. The maintainer can contain a public key for a cryptographicly strong authorization method or could contain a "crypt-key" or "mail-to" authorization check if that is considered adequate by the registering party. Furthermore an address allocation authority should verify that the request for an AS number or for address space matches the authorization criteria in the maintainer.
インターネットアドレス配分局は、新しい割り当てのためにInetNumsとAut-Numsを追加する必要があります。そのためには、メンテナーが存在する必要があります。当事者がインターネットに接続する場合、接続するインターネットサービスプロバイダーにリクエストすることでメンテナーを獲得できます。メンダーができたら、アドレススペースまたはAS番号をリクエストすることができます。メンテナーは、暗号化的に強力な承認方法のための公開鍵を含めることができます。または、登録当事者によって適切と見なされる場合は、「暗号」または「メールツー」許可チェックを含めることができます。さらに、住所配分局は、AS番号または住所スペースの要求がメンテナーの承認基準と一致することを確認する必要があります。
Currently only the registries themselves may add maintainers. This becomes a problem for the registry, particularly in verifying public keys. This requirement is relaxed by allowing existing maintainers to add maintainers. Unfortunately the accountability trail does not exist for existing maintainers. The requirement then should be relaxed such that existing maintainers may remain but only existing maintainers that have a "referral-by" attribute can add maintainers. The "referral-by" cannot be modified. This requirement can be relaxed slightly so that a "referral-by" can be added to a maintainer by an existing maintainer with a "referral-by". This will allow the accountability trail to be added to existing maintainers and these maintainers can then add new maintainers.
現在、レジストリ自体のみがメンテナーを追加することができます。これは、特にパブリックキーの検証において、レジストリにとって問題になります。この要件は、既存のメンテナーにメンテナーを追加できるようにすることで緩和されます。残念ながら、既存のメンテナーには説明責任のトレイルは存在しません。その場合、既存のメンテナーが残るように要件を緩和する必要がありますが、「紹介」属性を持つ既存のメンテナーのみがメンテナーを追加できます。「紹介」を変更することはできません。この要件は、「紹介」を備えた既存のメンテナーが「紹介者」に追加できるように、この要件をわずかに緩和できます。これにより、説明責任のトレイルを既存のメンテナーに追加することができ、これらのメンテナーは新しいメンテナーを追加できます。
Verifying that a party is who they claim to be on initial addition, is one of the problems that currently falls upon the AS number and address registry. This problem is reduced by allowing existing maintainers to add maintainers. This may actually make it easier to get maintainers and therefore easier to register. The number authority still must verify that the AS or address space is actually needed by the party making a request.
当事者が最初の追加であると主張する人であることを確認することは、現在AS番号と住所レジストリに該当する問題の1つです。この問題は、既存のメンテナーがメンテナーを追加できるようにすることで削減されます。これにより、実際にメンテナーを簡単に入手できるため、登録が容易になる可能性があります。番号当局は、ASまたは住所スペースが実際に要求をすることで実際に必要であることを確認する必要があります。
Authorization checks made during the addition of route objects that refer to AS objects and inetnums strongly rely on the cooperation of the Internet address allocation authorities. The number authorities must register as-blocks, aut-nums, or inetnums as AS numbers or address space is allocated. If only a subset of the number authorities cooperate, then either an inetnum or as-block can be created covering the space that registry allocates and essentially requiring null allocation (for example a "crypt-pw" authentication where the password is given in the remarks in the object or its maintainer) or those obtaining addresses from that number authority will have trouble registering in the routing registry. The authorization model supports either option, though it would be preferable if the number authorities cooperated and the issue never surfaced in practice.
オブジェクトとInetnumsと呼ばれるルートオブジェクトの追加中に行われた認可チェックは、インターネットアドレスの割り当て当局の協力に強く依存しています。番号当局は、ブロック、autnums、またはinetnumsを数字または住所スペースとして登録する必要があります。番号当局のサブセットのみが協力する場合、レジストリが割り当てるスペースをカバーし、基本的にnull割り当てを必要とするInetnumまたはas-blockを作成できます（たとえば、パスワードが備考に与えられる場合の「Crypt-PW」認証オブジェクトまたはそのメンテナー）またはその番号当局から住所を取得するものは、ルーティングレジストリに登録するのに苦労します。許可モデルはどちらのオプションをサポートしていますが、番号当局が協力していて、問題が実際に表面化しなかった場合は望ましいことです。
The maintainer requirements can be relaxed slightly for existing maintainers making it easier to register. Relaxing requirements on other objects may defeat the authorization model, hence is not an option.
メンテナーの要件は、既存のメンテナーのために少し緩和することができ、登録が容易になります。他のオブジェクトのリラックス要件は、承認モデルを無効にする可能性があるため、選択肢ではありません。
The issue of whether lending contracts should be enforcible is an issue of who should ultimately be able to exercise control over allocations of address space. The routing registry would be wise to stay as neutral as possible with regard to disputes between third parties. The "reclaim" and "no-reclaim" are designed to allow either outcome to the decision as to whether the holder of a less specific inetnum or route object can exercise control over suballocations in the registry. The routing registry itself must decide whether to retain control themselves and if so, should very clearly state under what conditions the registry would intervene. A registry could even go to the extreme of stating that they will intervene in such a dispute only after the dispute has been resolved in court and a court order has been issued.
貸付契約が施行されるべきかどうかの問題は、最終的に誰がアドレス空間の割り当てを制御できるかという問題です。ルーティングレジストリは、第三者間の紛争に関して可能な限り中立にとどまることが賢明です。「回収」と「ノー・リクリテーション」は、あまり具体的ではないINETNUMまたはルートオブジェクトの所有者がレジストリの隔離を制御できるかどうかについての決定のいずれかの結果を可能にするように設計されています。ルーティングレジストリ自体は、自分で制御を保持するかどうかを決定する必要があり、もしそうなら、レジストリが介入する条件下で非常に明確に述べなければなりません。レジストリは、紛争が法廷で解決され、裁判所命令が発行された後にのみ、そのような紛争に介入すると述べるという極端に進むことさえできます。
When an allocation is made by a registry, the registry should keep a "reclaim" attribute in the less specific object and make a strong policy statement that the reclaim privilege will not be used except under very clearly defined special circumstances (which at the very minimum would include a court order). If the allocation is further subdivided the party subdividing the allocation and the party accepting the suballocation must decide whether a "reclaim" can be kept by the holder of the less specific allocation or whether a "no-reclaim" must be added transferring control to the holder of the more specific. The registry is not involved in that decision. Different pairs of third parties may reach different decisions regarding the "reclaim" and any contractual restrictions on its use that may be expressed outside of the registry in the form of a legal contract and ultimately resolved by the courts in the event of a bitter dispute.
レジストリによって割り当てが行われる場合、レジストリは、あまり特定のオブジェクトに「回収」属性を維持し、非常に明確に定義された特別な状況（非常に最小限に抑えられている場合を除き、回収特権は使用されないという強力なポリシーステートメントを作成する必要があります。裁判所命令が含まれます）。割り当てがさらに細分化された場合、割り当てを細分化する当事者と、隔離を受け入れる当事者は、「回収」を具体的ではない配分の所有者が保持できるかどうか、または「修復なし」を追加する必要があるかどうかを決定する必要があります。より具体的な保有者。レジストリはその決定に関与していません。第三者のさまざまなペアは、「回収」と、登録契約の形でレジストリの外で表明され、激しい紛争が発生した場合に最終的に裁判所によって解決される可能性のあるその使用に関する契約上の制限に関するさまざまな決定に達する可能性があります。
By retaining "reclaim" rights the registry retains the ability to abide by a court order. This may only truly become an issue in a distributed registry environment where registries will be rechecking the authorization of transactions made elsewhere and may fail to process the attempt of another registry to abide by a court order by overriding normal authorization to change the registry contents if a reclaim is not present.
「回収」権利を保持することにより、登録は裁判所の命令を遵守する能力を維持します。これは、レジストリが他の場所で行われたトランザクションの許可を再確認する分散レジストリ環境で本当に問題になる可能性があり、別のレジストリの試みを処理できない可能性があります。回収は存在しません。
Some of the newer requirements include requiring that all objects reference a maintainer object responsible for the integrity of the object and requiring accountability for the creation of maintainers to be recorded in the maintainer objects so that accountability can be traced back from an unresponsive maintainer. In the event that contact information is absent or incorrect from objects and there is any question regarding the validity of the objects, the maintainer can be contacted. If the maintainer is unresponsive, the maintainer that authorized the addition of that maintainer can be contacted to either update the contact information on the maintainer or confirm that the entity no longer exists or is no longer actively using the Internet or the registry.
新しい要件の一部には、すべてのオブジェクトがオブジェクトの整合性を担当するメンテナーオブジェクトを参照することを要求し、メンテナーの作成に説明責任をメンテナーオブジェクトに記録することを要求して、説明責任を無反応のメンテナーから追跡できるようにすることが含まれます。連絡先情報がオブジェクトに欠けている、または間違っている場合、オブジェクトの有効性に関する質問がある場合、メンテナーに連絡することができます。メンテナーが反応しない場合、メンテナーの追加を許可したメンテナーは、メンテナーの連絡先情報を更新するか、エンティティが存在しなくなったか、インターネットまたはレジストリを使用していないことを確認することができます。
Many route objects exist for which there are no maintainers and for which inetnum and AS objects do not exist. Some contain the now obsoleted guardian attribute rather than a mnt-by.
メンテナーがなく、オブジェクトが存在しないメンテナーが存在しない多くのルートオブジェクトが存在します。いくつかは、MNT-byではなく、現在廃止されたガーディアン属性を含んでいます。
It is not practical to unconditionally purge old data that does not have maintainers or does not conform to the authorization hierarchy. New additions must be required to conform to the new requirements (otherwise the requirements are meaningless). New requirements can be phased in by requiring modifications to conform to the new requirements.
メンテナーを持たない、または承認階層に準拠していない古いデータを無条件にパージすることは実用的ではありません。新しい要件に準拠するには、新しい追加が必要です（そうでなければ、要件は無意味です）。新しい要件は、新しい要件に準拠するための変更を要求することにより、段階的に段階的に導入できます。
A great deal of questionable data exists in the current registry. The requirement that all objects have maintainers and the requirements for improved accountability in the maintainers themselves may make it easier to determine contact information even where the objects are not updated to reflect contact information changes.
現在のレジストリには、多くの疑わしいデータが存在します。すべてのオブジェクトにメンテナーを備えているという要件と、メンテナー自体の説明責任を改善するための要件により、連絡先情報の変更を反映するためにオブジェクトが更新されない場合でも、連絡先情報を簡単に判断できるようになります。
It is not unreasonable to require valid contact information on existing data. A great deal of data appears to be unused, such as route objects for which no announcement has been seen in many months or years. An attempt should be made to contact the listed contacts in the object, in the maintainer if there is one, then up the maintainer referral-by chain if there is one, and using the number registry or origin AS contact information if there is no maintainer accountability trail to follow. Experience so far indicates that the vast majority of deletions identified by comparing registered prefixes against route dumps will be positively confirmed (allowing the deletion) or there will be no response due to invalid contact information (in many cases the IRR contact information points to nsfnet-admin@merit.edu).
既存のデータに関する有効な連絡先情報を要求することは不合理ではありません。何ヶ月もまたは数年で発表が見られなかったルートオブジェクトなど、多くのデータが使用されていないようです。オブジェクトのリストされた連絡先、メンテナーがある場合はメンテナーに連絡し、メンテナーがある場合はメンテナーの紹介に連絡し、メンテナーがない場合は連絡先情報として番号レジストリまたはオリジンを使用することを試みる必要があります。説明責任のトレイルは続く。これまでの経験は、登録されたプレフィックスをルートダンプと比較することによって特定された削除の大部分が積極的に確認されること（削除を許可する）または無効な連絡先情報のために応答がないことを示しています（多くの場合、IRR連絡先情報はNSFNETにポイントします。admin@merit.edu）。
By allowing the registry to modify (or delete) any objects which are disconnected from the maintainer accountability trail, cleanup can be made possible (though mail header forging could in many cases have the same effect it is preferable to record the fact that the registry itself made the cleanup). Similarly, a mechanism may be needed in the future to allow the maintainer in the referral-by to override maintainer privileges in a referred maintainer if all contacts have become unresponsive for a maintainer. The referral-by maintainer is allowed to add an "auth-override" attribute which becomes usable as an "auth" within 60 days from the time of addition. The maintainer themselves would be notified of the change and could remove the "auth-override" attribute before it becomes effective and inquire as to why it was added and correct whatever problem existed. This can be supported immediately or added later if needed.
メンテナーの説明責任トレイルから切断されたオブジェクトをレジストリに変更（または削除）できるようにすることにより、クリーンアップを可能にすることができます（ただし、メールヘッダーの鍛造は、多くの場合、レジストリ自体がレジストリ自体を記録することが望ましい場合があります。クリーンアップを行いました）。同様に、すべての連絡先がメンテナーに反応しなくなった場合、紹介メンテナーのメンテナーの特権をオーバーライドすることができるように、メンダーが紹介者にメンテナーがオーバーライドできるようにするために、将来的にメカニズムが必要になる場合があります。紹介によるメンテナーは、追加時から60日以内に「認証」として使用可能になる「認証」属性を追加することができます。メンテナー自体に変更が通知され、効果的になる前に「Auth-override」属性を削除し、存在する問題が追加されて修正された理由を尋ねることができます。これは、すぐにサポートすることも、必要に応じて後で追加することもできます。
D Common Operational Cases
d一般的な運用ケース
In principle, address allocation and route allocation should be hierarchical with the hierarchy corresponding to the physical topology. In practice, this is often not the case for numerous reasons. The primary reasons are the topology is not strictly tree structured and the topology can change. More specificly: 1. The Internet topology is not strictly tree structured.
原則として、アドレスの割り当てとルートの割り当ては、物理トポロジに対応する階層を使用して階層的でなければなりません。実際には、これは多くの理由でそうではないことがよくあります。主な理由は、トポロジーが厳密に樹木構造ではなく、トポロジが変化する可能性があることです。より具体的に：1。インターネットトポロジーは、厳密にツリー構造ではありません。
o At the top level the network more closely resembles a moderately dense mesh.
o トップレベルでは、ネットワークは中程度に密なメッシュに似ています。
o Near the bottom level many attachments to the Internet are multi-homed to more than one Internet provider.
o ボトムレベルに近いインターネットへの多くの添付ファイルは、複数のインターネットプロバイダーにマルチホームされています。
2. The Internet topology can and does change.
2. インターネットトポロジは変更できます。
o Many attachments switch providers to obtain better service or terms.
o 多くの添付ファイルは、より良いサービスまたは条件を取得するためにプロバイダーを切り替えます。
o Service providers may modify adjacencies to obtain better transit service or terms.
o サービスプロバイダーは、隣接を変更して、より良い輸送サービスまたは条件を取得する場合があります。
o Service providers may disappear completely scattering attachments or they may merge.
o サービスプロバイダーは、添付ファイルを完全に散乱させるか、融合する場合があります。
Renumbering is viewed as a practical means to maintain a strict numeric hierarchy [16]. It is also acknowledged that renumbering IPv4 networks can be difficult [16, 3, 17]. We examine first the simple case where hierarchy still exists. We then examine the operational cases where either initial topology is not tree structured or cases where topology changes.
変更は、厳密な数値階層を維持するための実用的な手段と見なされています[16]。また、IPv4ネットワークの変更が難しい場合があることも認められています[16、3、17]。最初に、階層がまだ存在する単純なケースを調べます。次に、初期トポロジーがツリー構造ではないか、トポロジが変化する場合の運用上のケースを調べます。
This is the simplest case. Large ranges of inetnums are assigned to address registries. These registries in turn assign smaller ranges for direct use or to topologically large entities where allocations according to topology can reduce the amount of routing information needed (promote better route aggregation).
これは最も単純なケースです。Inetnumsの大きな範囲は、レジストリにアドレス指定するために割り当てられています。これらのレジストリは、トポロジーに従って配分が必要なルーティング情報の量を減らすことができる（より良いルート集約を促進する）、直接使用するために、または直接使用するために、またはトポロジカルな大規模なエンティティに順番に割り当てられます。
AS objects are allocated as topology dictates the need for additional AS [10]. Route objects can be registered by those with authorization given by the AS and by the address owner. This is never an issue where the maintainer of the AS and the inetnum are the same. Where they differ, either the provider can give permission to add route objects for their AS, or the party allocated the address space can give the provider permission to add route objects for their address space, or both parties can sign the transaction. Permission is provided by adding to maintainer attributes.
トポロジーとしてオブジェクトが割り当てられているため、AS [10]の追加の必要性が決定されます。ルートオブジェクトは、ASおよびアドレス所有者によって与えられた許可を持つ人によって登録できます。これは、ASのメンテナーとinetnumが同じである問題ではありません。それらが異なる場合、プロバイダーはASにルートオブジェクトを追加する許可を与えることができます。または、アドレススペースを割り当てる当事者は、プロバイダーにアドレススペースにルートオブジェクトを追加する許可を与えることができます。メンテナー属性に追加することにより、許可が提供されます。
Aggregation is normally not a problem if a provider is aggregating address space allocated to the provider and then suballocated internally and/or to customers. In fact, the provider would be expected to do so. This is not a problem even if the route object for the aggregation is added after the more specific route objects since only less specific objects are considered.
プロバイダーがプロバイダーに割り当てられ、内部および/または顧客に隔離されたアドレススペースを集約している場合、集約は通常問題ではありません。実際、プロバイダーはそうすることが期待されます。これは、より特定のオブジェクトのみが考慮されるため、より特定のルートオブジェクトの後に集約のルートオブジェクトが追加されても問題ではありません。
Aggregation is potentially a problem if a provider or a set of providers plan to aggregate address space that was never explicitly allocated as a block to those providers but rather remains the allocation of a address registry. These large aggregations can be expected to be uncommon, but relatively easily dealt with. Superaggregates of this type will generally be formed by topologically close entities who have also managed to draw adjacent address allocations. In effect, the registry must give permission to form such a superaggregate by either giving permission to do so in the mnt-routes of an inetnum or by signing the submission along with the other parties.
プロバイダーまたはプロバイダーのセットが、これらのプロバイダーにブロックとして明示的に割り当てられていないが、アドレスレジストリの割り当てのままであることを明示的に割り当てられないアドレス空間を集約することを計画している場合、集約は潜在的に問題になります。これらの大きな集計は珍しいことが予想されますが、比較的簡単に対処できます。このタイプの超凝集は、一般に、隣接するアドレスの割り当てを描くことができたトポロジーに近いエンティティによって形成されます。実際、レジストリは、InetnumのMNTルートで許可を与えるか、他の当事者と一緒に提出物に署名することにより、そのような超凝集を形成する許可を与えなければなりません。
Provider independent addresses and multihoming arrangement using multiple origin AS present a similar problem to multihoming. The maintainer of the address space and the maintainer of the AS is not the same. Permission can be granted using mnt-routes or multiple signatures can appear on the submission.
プロバイダーの独立したアドレスとマルチオリジンを使用したマルチホーム配置は、マルチホームと同様の問題を提示します。アドレス空間のメンテナーとASのメンテナーは同じではありません。MNT-Routesを使用して許可を付けることができます。または、提出時に複数の署名が表示される可能性があります。
A change in Internet service providers is similar to multihoming. A minor difference is that the AS for the more specific route will be the AS of the new provider rather than the AS of the multihomed customer. Permission can be granted using mnt-routes or multiple signatures can appear on the submission.
インターネットサービスプロバイダーの変更は、マルチホームに似ています。わずかな違いは、より具体的なルートに関しては、マルチホームの顧客ではなく、新しいプロバイダーのASになることです。MNT-Routesを使用して許可を付けることができます。または、提出時に複数の署名が表示される可能性があります。
Renumbering grace periods allow a provider who wants to keep an address allocation intact to allow a customer who has chosen to go to another provider to renumber their network gradually and then return the address space after renumbering is completed. The issue of whether to require immediate renumbering or offer renumbering grace periods and how long they should be or whether they should be indefinite has been topic of bitter disputes. The authorization model can support no renumbering grace period, a finite renumbering grace period, or an indefinite renumbering grace period. The "reclaim" attribute described in Section 9.1 provides a means to end the grace period.
猶予期間の変更を加えることで、住所配分を無傷に保ち、別のプロバイダーに行くことを選択した顧客がネットワークを徐々に変更してから、変更が完了した後にアドレススペースを返すことができるようにするプロバイダーを使用することができます。即時の名前を要求するか、恵み期間を変更するか、どのくらいの期間であるべきか、またはそれらが無期限であるべきかどうかの問題は、激しい紛争のトピックでした。承認モデルは、名誉ある恵み期間、有限の名誉ある恵みの期間、または無期限の名誉ある恵み期間をサポートすることはできません。セクション9.1で説明されている「再生」属性は、恵み期間を終了する手段を提供します。
E Deployment Considerations
e展開に関する考慮事項
This section describes deployment considerations. The intention is to raise issues and discuss approaches rather than to provide a deployment plan.
このセクションでは、展開の考慮事項について説明します。意図は、展開計画を提供するのではなく、問題を提起し、アプローチについて議論することです。
The use of routing registries is not yet universally accepted. There still remain Internet providers who see no reason to provide the added assurance of accurate routing information described in Section 6. More accurately, these benefits are viewed as being insufficient to justify the cost. This has been largely caused an inability of a very major router vendor up until recently to handle prefix lists of the size needed to specify routing policy on a per prefix basis.
ルーティングレジストリの使用はまだ普遍的に受け入れられていません。セクション6で説明されている正確なルーティング情報の追加の保証を提供する理由がないと考えているインターネットプロバイダーはまだ残っています。より正確には、これらの利点はコストを正当化するには不十分であると見なされます。これは、最近まで、非常に主要なルーターベンダーが、プレフィックスごとにルーティングポリシーを指定するために必要なサイズのプレフィックスリストを処理することができないことを主に引き起こしています。
Another reason cited is that filtering on a prefix basis in an environment where routing registry information is incomplete or inaccurate can interfere with connectivity.
引用されたもう1つの理由は、ルーティングレジストリ情報が不完全または不正確である環境でプレフィックスベースでフィルタリングすることが、接続性を妨げる可能性があることです。
There clearly is a critical mass issue with regard to the use of routing registries. A minority of providers use the existing IRR to filter on a per prefix basis. Another minority of providers do not support the IRR and generally fail to register prefixes until connectivity problems are reported. The majority of providers register prefixes but do not implement strict prefix filtering.
ルーティングレジストリの使用に関して、明らかに重大な大量の問題があります。少数のプロバイダーが既存のIRRを使用して、プレフィックスごとにフィルタリングします。別の少数のプロバイダーはIRRをサポートせず、通常、接続の問題が報告されるまでプレフィックスを登録できません。プロバイダーの大部分はプレフィックスを登録しますが、厳密なプレフィックスフィルタリングを実装していません。
Deploying new authentication mechanisms has no adverse consequences. This has been proven with Merit's deployment of PGP.
新しい認証メカニズムを展開するには、悪影響はありません。これは、MeritのPGPの展開で証明されています。
In deploying new authorization mechanisms, a major issue is dealing with existing data of very questionable origin. A very large number of route objects refer to prefixes that have not been announced for many years. Other route objects refer to prefixes that are no longer announced with the origin AS that they are registered with (some were incorrectly registered to start with). There are many causes for this.
新しい認証メカニズムを展開する際に、主要な問題は、非常に疑わしい起源の既存のデータを扱うことです。非常に多数のルートオブジェクトは、長年発表されていないプレフィックスを指します。他のルートオブジェクトは、登録されているように原点とはもう発表されていないプレフィックスを指します（一部は誤って登録されています）。これには多くの原因があります。
1. During the transition from the NSFNET PRDB to the RADB a large number of prefixes were registered with an origin AS corresponding to the border AS at which the NSFNET had once heard the route announcements. The PRDB did not support origin AS, so border AS was used. Many of these routes were no longer in use at the time and are now routed with a submitter listed as "nsfnet-admin@merit.edu".
1. NSFNET PRDBからRADBへの移行中、NSFNETがかつてルートの発表を聞いたように、境界に対応するように、多数のプレフィックスが境界に対応する原点に登録されました。PRDBは原点としてサポートされていなかったため、使用されたように境界線。これらのルートの多くは当時使用されなくなり、現在「nsfnet-admin@merit.edu」としてリストされている提出者とルーティングされています。
2. As CIDR was deployed, aggregates replaced previously separately announced more specific prefixes. The route objects for the more specific prefixes were never withdrawn from the routing registries.
2. CIDRが展開されると、Aggregatesが以前に交換され、より具体的な接頭辞を別々に発表しました。より具体的なプレフィックスのルートオブジェクトは、ルーティングレジストリから撤回されることはありませんでした。
3. Some prefixes are simply no longer in use. Some networks have been renumbered. Some network no longer exist. Often the routing registry information is not withdrawn.
3. 一部のプレフィックスは、単に使用されなくなりました。一部のネットワークには変更されています。一部のネットワークはもう存在しません。多くの場合、ルーティングレジストリ情報は撤回されません。
4. As provider AS adjacencies changed and as end customers switched providers often the actual origin AS changed. This was often not reflected by a change in the routing registry.
4. プロバイダーが隣接するにつれて変更され、エンド顧客がプロバイダーを切り替えるにつれて、多くの場合、実際の起源が変更されます。これは、ルーティングレジストリの変更に反映されなかったことがよくありました。
Inaccuracies will continue to occur due to the reasons above, except the first. The hierarchical authorization provides greater accountability. In the event that the contacts for specific objects become unresponsive traversal up the authorization hierarchy should help identify the parties having previous provided authorization. These contacts may still have sufficient authorization to perform the necessary cleanup. This issue is discussed in Section C.
上記の理由を除いて、上記の理由により、不正確さが引き続き発生します。階層的な承認は、より大きな説明責任を提供します。特定のオブジェクトの連絡先が承認階層の反応しない走査になった場合、以前に提供された承認がある当事者を特定するのに役立つはずです。これらの連絡先は、必要なクリーンアップを実行するのに十分な許可を依然として持っている場合があります。この問題については、セクションCで説明します。
A great deal of information is currently missing in the IRR. Quite a few AS have no aut-num. Quite a lot of data has no maintainer and the vast majority of maintainers use only the weakest of authentication methods. Very little can be done by the registries to correct this. The defaults in the cases of missing objects needed for authorization has to be to make no authentication checks at all.
現在、IRRには多くの情報がありません。Aut-Numがないのでかなりの数があります。かなり多くのデータにはメンテナーがなく、メンテナーの大多数は最も弱い認証方法のみを使用しています。これを修正するために、レジストリによってほとんど実行できません。許可に必要なオブジェクトが不足している場合のデフォルトは、認証チェックをまったく行わないことである必要があります。
The transition can be staged as follows:
遷移は次のようにステージングできます。
1. Add and make use of stronger authorization models.
1. より強力な承認モデルを追加して使用します。
2. Make schema modifications necessary to support delegations.
2. 代表団をサポートするために必要なスキーマ変更を行います。
3. Add delegation attributes needed for query traversal. 4. Base query traversal on delegations rather than a search of all known registries.
3. クエリトラバーサルに必要な委任属性を追加します。4.すべての既知のレジストリの検索ではなく、代表団の基本クエリトラバーサル。
5. Obtain the cooperation of the address registries for the purpose of populating the "inetnum" entries on an ongoing basis.
5. 継続的に「inetnum」エントリに登録する目的で、住所レジストリの協力を取得します。
6. Add hierarchical authorization support for critical object types, "aut-num", "inetnum" and "route".
6. クリティカルオブジェクトタイプの「Aut-Num」、「Inetnum」、および「Route」の階層認証サポートを追加します。
7. Add the requirement that database object either be in use or have valid contact information and if queries are made by the registry a response from a contact indicating that the object serves a purpose if it is not clear what its use is.
7. データベースオブジェクトが使用されているか有効な連絡先情報があるという要件を追加し、クエリがレジストリによって行われた場合、その使用が何であるかが明確でない場合、オブジェクトが目的に役立つことを示す連絡先からの応答を追加します。
8. Begin to purge data which is clearly not in use and for which there is no valid contact information or no response from the contacts.
8. 明らかに使用されておらず、有効な連絡先情報がない、または連絡先からの応答がないデータをパージし始めます。
Deployment of hierarchical authorization requires cooperation among the existing routing registries. New code will have to be deployed. In some cases minimal development resources are available and substantial inertia exists due to the reliance on the current repository and the need to avoid disruption.
階層的な承認の展開には、既存のルーティングレジストリ間の協力が必要です。新しいコードを展開する必要があります。場合によっては、最小限の開発リソースが利用可能であり、現在のリポジトリへの依存と混乱を避ける必要性により、実質的な慣性が存在します。
If hierarchical authorization of route objects depends on the existence of address registration information, minimal cooperation of the currently separate address registries is required. The extent of the cooperation amounts to sending cryptographically signed transactions from the address registry to the number registry as address allocations are made or providing equivalent access to new address allocations.
ルートオブジェクトの階層的承認が住所登録情報の存在に依存する場合、現在別々の住所登録の最小限の協力が必要です。協力の範囲は、アドレスの割り当てが行われたり、新しいアドレス割り当てへの同等のアクセスを提供するため、暗号化された署名されたトランザクションをアドレスレジストリから番号レジストリに送信することにかかっています。
Currently most registries return query results from all of the known repositories using their mirrored copies. Cross registry authorizations are not yet implemented. Minimal schema changes have to be made to support the ability to delegate objects for which there is an authorization hierarchy and to support queries and references to other repositories. In the case of AS delegations, "as-block" need to be created solely for the purpose of traversal.
現在、ほとんどのレジストリは、ミラー化されたコピーを使用して、既知のすべてのリポジトリからクエリの結果を返します。クロスレジストリ認可はまだ実装されていません。承認階層があるオブジェクトを委任する能力をサポートし、他のリポジトリへのクエリと参照をサポートするために、最小限のスキーマ変更を行う必要があります。AS代表団の場合、「As-Block」は、トラバーサルの目的のためだけに作成する必要があります。
F Route Object Authorization Pseudocode
fルートオブジェクト認証擬似コード
The following list provides a brief review of basic concepts.
次のリストは、基本概念の簡単なレビューを提供します。
1. The route object submission must satisfy two authentication criteria. It must match the authentication specified in the aut-num and the authentication specified in either a route object or if no applicable route object is found, then an inetnum.
1. ルートオブジェクトの送信は、2つの認証基準を満たす必要があります。Aut-Numで指定された認証と、ルートオブジェクトで指定された認証と一致する必要があります。
2. When checking for prefix authorization, an exact route object prefix match is checked for first. If there is not an exact match then a longest prefix match that is less specific than the prefix is searched for. If the route prefix search fails, then a search is performed for an inetnum that exactly matches the prefix or for the most specific inetnum that is less specific than the route object submission.
2. プレフィックスの承認をチェックするとき、正確なルートオブジェクトプレフィックスマッチが最初にチェックされます。正確な一致がない場合は、プレフィックスが検索されるよりも具体的ではない最長のプレフィックスマッチがあります。ルートのプレフィックス検索が失敗した場合、プレフィックスと正確に一致するinetnumまたはルートオブジェクトの提出よりも具体的ではない最も具体的なinetnumに対して検索が実行されます。
The search for an inetnum should never fail but it may return an unallocated or reserved range. The inetnum status must be "allocated" and the submission must pass it's maintainer authorization in order to get authorization from an inetnum. So an unallocated or reserved range inetnum will cause the route object submission to fail.
inetnumの検索は決して失敗することはありませんが、未割り当てまたは予約範囲を返す場合があります。INETNUMステータスは「割り当て」する必要があり、提出物は、INETNUMから承認を得るためにメンテナーの承認を渡す必要があります。したがって、未割り当てまたは予約範囲のinetnumにより、ルートオブジェクトの提出が失敗します。
3. A route object must pass authorization from both the referenced aut-num object and the route or inetnum object. Authorization shall be tested using the maintainer(s) referenced in the "mnt-routes" attribute(s) first. If that check fails, the "mnt-lower" attributes are checked. If that check fails the "mnt-by" attributes are used for the authorization check.
3. ルートオブジェクトは、参照されたAut-NumオブジェクトとルートまたはINETNUMオブジェクトの両方から承認を渡す必要があります。承認は、最初に「MNT-Routes」属性で参照されているメンテナーを使用してテストするものとします。そのチェックが失敗した場合、「MNT-lower」属性がチェックされます。そのチェックが失敗した場合、承認チェックには「MNT-by」属性が使用されます。
4. The "reclaim" attribute can appear in inetnum, route and as-block objects and provides a means to support address lending. "reclaim" gives authorization over more specific objects, regardless of the "mnt-by" in the object. The value of a "reclaim" attribute can be a list or set of objects to provide finer grain control.
4. 「Reclaim」属性は、Inetnum、Route、Asブロックオブジェクトに表示され、アドレス貸出をサポートする手段を提供できます。「Reclaim」は、オブジェクトの「MNT-by」に関係なく、より具体的なオブジェクトよりも許可を与えます。「Reclaim」属性の値は、より細かい穀物制御を提供するためのオブジェクトのリストまたはセットにすることができます。
The "reclaim" attribute is important to this discussion since it affects prefix/origin authentication when a new route object is submitted.
新しいルートオブジェクトが送信されたときにプレフィックス/オリジン認証に影響するため、「recaim」属性はこの議論にとって重要です。
The "no-reclaim" attribute is used to provide explicit exceptions.
「非回復」属性は、明示的な例外を提供するために使用されます。
The following pseudocode outlines the algorithm used to check for proper authorization of a route object submission.
次の仮名コードは、ルートオブジェクトの提出の適切な承認をチェックするために使用されるアルゴリズムの概要を示しています。
Case #1. Route object add (ie, no exact prefix/origin match exists).
ケース＃1。ルートオブジェクトの追加（つまり、正確なプレフィックス/オリジンマッチは存在しません）。
/* first check the aut-num authorization */
if ( the referenced aut-num object does not exist or the aut-num authorization fails ) authorization fails
（参照されたAut-Numオブジェクトが存在しないか、Aut-Num Authorizationが失敗する）承認が失敗した場合
/* next we check for prefix authorization */
if ( a less specific route(s) with the longest prefix is found ) [ if ( authorization does not pass for at least one of the less specific route(s) ) authorization fails
if（最長のプレフィックスを持つより具体的ではないルートが見つかりました）
/* now check for a "reclaim" attr */
if ( the object has a "reclaim" attribute ) [ if ( no more-specifics exist OR a less specific exists which passes authorization and has a "reclaim" attribute
if（オブジェクトには「再laim」属性があります）
OR all more specifics routess pass modify authorization ) authorization passes else authorization fails ] else authorization passes ]
またはその他のすべての詳細routessパス修正承認）承認の合格
/* there are no less specific routes to check for prefix
authentication, so we need to try and get authorization from an
inetnum object */
if ( ( an inetnum is found that is an exact match OR is less specific and it's status is "allocated" ) AND a maintainer referenced by the inetnum passes authorization ) authorization succeeds
if（（正確な一致またはそれほど具体的ではなく、そのステータスが「割り当てられている」）と、inetnum passes承認によって参照されるメンテナー）認証が成功します
/* if there is no inetnum or route object then then
authorization fails. This should never happen if
the DB is initialized properly. */
authorization fails.
承認は失敗します。
Case #2. Route object modify/delete (ie, exact prefix/origin match exists).
ケース＃2。ルートオブジェクトの変更/削除（つまり、正確なプレフィックス/オリジンマッチが存在します）。
if ( the mnt-by passes authorization ) authorization succeeds
if（MNT-byが承認に合格）認可が成功します
/* if the authorization did not pass from the matched object,
we can still get authorization from a less specific route if it
has a "reclaim" attribute and we pass authorization */
if ( a less specific route or inetnum object passes authorization AND has a "reclaim" attribute applicable to the object to be modified ) authorization succeeds else authorization fails
（特定のルートまたはINETNUMオブジェクトが承認を渡し、変更するオブジェクトに適用可能な「回収」属性を持っている場合）認可が成功する場合、他の認可が失敗します
Acknowledgments
謝辞
This document draws ideas from numerous discussions and contributions of the IETF Routing Policy System Work Group and RIPE Routing Work Group. Earlier drafts of this document listed Carol Orange as a co-author. Carol Orange made contributions to this document while at RIPE.
このドキュメントは、IETFルーティングポリシーシステムワークグループと熟したルーティングワークグループの多数の議論と貢献からアイデアを導き出します。この文書の以前のドラフトは、キャロルオレンジが共著者としてリストされていました。キャロルオレンジは、Ripeにいる間、この文書に貢献しました。
Gerald Winters provided the pseudocode in an email message to the RIPE dbsec mailing list that was the basis of the pseudocode found in appendix F. Susan Harris provided comments and numerous editorial corrections.
ジェラルド・ウィンターズは、付録Fに見られる擬似コードの基礎である熟したDBSECメーリングリストへの電子メールメッセージで擬似コードを提供しました。
Intellectual Property Notice
知的財産通知
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連のドキュメントの権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
References
参考文献
[1] Alaettinoglu, C., Bates, T., Gerich, E., Karrenberg, D., Meyer, D., Terpstra M. and C. Villamizar, "Routing Policy Specification Language (RPSL)", RFC 2280, January 1998.
[1] Alaettinoglu、C.、Bates、T.、Gerich、E.、Karrenberg、D.、Meyer、D.、Terpsstra M. and C. Villamizar、「ルーティングポリシー仕様言語（RPSL）」、RFC 2280、1998年1月。
[2] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J-M., Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, March 1995.
[2] Bates、T.、Gerich、E.、Joncheray、L.、Jouanigot、J-M.、Karrenberg、D.、Terpsstra、M。and J. Yu、「ルーティングレジストリにおけるIPルーティングポリシーの表現（RIPE-81）」、RFC 1786、1995年3月。
[3] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[3] Berkowitz、H。、「ルーターのレニンバーガイド」、RFC 2072、1997年1月。
[4] Braun, H-W., "Models of policy based routing", RFC 1104, June 1989.
[4] Braun、H-W。、「ポリシーベースのルーティングのモデル」、RFC 1104、1989年6月。
[5] Braun, H-W. and Y. Rekhter, "Advancing the NSFNET routing architecture", RFC 1222, May 1991.
[5] ブラウン、H-W。Y. Rekhter、「NSFNETルーティングアーキテクチャの前進」、RFC 1222、1991年5月。
[6] Clark, D., "Policy routing in Internet protocols", RFC 1102, May 1989.
[6] クラーク、D。、「インターネットプロトコルにおけるポリシールーティング」、RFC 1102、1989年5月。
[7] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[7] Crocker、D。、「ARPAインターネットテキストメッセージの形式の標準」、STD 11、RFC 822、1982年8月。
[8] Fuller, V., Li, T., Yu, J. and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, September 1993.
[8] Fuller、V.、Li、T.、Yu、J。、およびK. Varadhan、「クラスレスインタードメインルーティング（CIDR）：アドレス割り当てと集約戦略」、RFC 1519、1993年9月。
[9] Internet Engineering Steering Group and R. Hinden, "Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR)", RFC 1517, September 1993.
[9] インターネットエンジニアリングステアリンググループとR.ヒンデン、「クラスレス間ドメインルーティング（CIDR）の実装に関するアプリケーションステートメント」、RFC 1517、1993年9月。
[10] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
[10] Hawkinson、J。およびT. Bates、「自律システムの作成、選択、登録に関するガイドライン（AS）」、RFC 1930、1996年3月。
[11] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D. and J. Postel, "Internet Registry IP Allocation Guidelines", BCP 12, RFC 2050, November 1996.
[11] Hubbard、K.、Kosters、M.、Conrad、D.、Karrenberg、D。、およびJ. Postel、「インターネットレジストリIP割り当てガイドライン」、BCP 12、RFC 2050、1996年11月。
[12] Knopper, M. and S. Richardson, "Aggregation Support in the NSFNET Policy-Based Routing Database", RFC 1482, June 1993.
[12] Knopper、M。およびS. Richardson、「NSFNETポリシーベースのルーティングデータベースにおける集約サポート」、RFC 1482、1993年6月。
[13] Meyer, D., Prior, M., Alaettinoglu, C., Schmitz, J. and Carol Orange, "Using RPSL in Practice", RFC 2650, August 1999.
[13] Meyer、D.、Prior、M.、Alaettinoglu、C.、Schmitz、J。、およびCarol Orange、「RPSLを実際に使用」、RFC 2650、1999年8月。
[14] Rekhter, Y., "Routing in a Multi-provider Internet", RFC 1787, April 1995.
[14] Rekhter、Y。、「マルチプロバイダーインターネットでのルーティング」、RFC 1787、1995年4月。
[15] Rekhter Y. and T. Li, "An Architecture for IP Address Allocation with CIDR", RFC 1518, September 1993.
[15] Rekhter Y.およびT. Li、「CIDRによるIPアドレス割り当てのアーキテクチャ」、RFC 1518、1993年9月。
[16] Rekhter Y. and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", RFC 2008, October 1996.
[16] Rekhter Y.およびT. Li、「インターネットルーティングのさまざまな住所配分ポリシーの影響」、RFC 2008、1996年10月。
[17] Rekhter, Y., Lothberg, P., Hinden, R., Deering, S. and J. Postel, "An IPv6 Provider-Based Unicast Address Format", RFC 2073, January 1997.
[17] Rekhter、Y.、Lothberg、P.、Hinden、R.、Deering、S.、J。Postel、「IPv6プロバイダーベースのユニキャストアドレス形式」、RFC 2073、1997年1月。
[18] Zsako, J., "PGP Authentication for RIPE Database Updates", RFC 2726, December 1999.
[18] Zsako、J。、「RIPEデータベース更新用のPGP認証」、RFC 2726、1999年12月。
Security Considerations
セキュリティに関する考慮事項
This document primarily addresses authorization rules for making additions, deletions, and changes to routing policy information repositories. The authentication of these transactions through strong cryptographic means are addressed by [18], referenced thorughout this document. The authorization rules are designed such that the integrity of any transaction can be verified independently by any party mirroring a repository to insure that rules are adhered to. To accomplish this the mirror must contain data already known to be properly authorized. In other words, the mirror must be complete and authentication and authorization checks must be made continuously as changes to the repository are recieved and processed in order.
このドキュメントは、主に、追加、削除、およびルーティングポリシー情報リポジトリの変更を作成するための認可ルールに対処しています。強力な暗号化手段によるこれらのトランザクションの認証は、[18]によって対処され、このドキュメントを参照してください。承認ルールは、ルールが順守されていることを保証するために、リポジトリを反映した当事者によって、任意の取引の整合性を個別に検証できるように設計されています。これを達成するには、ミラーには適切に承認されていることが既に知られているデータが含まれている必要があります。言い換えれば、ミラーは完全でなければならず、リポジトリの変更が順番に受信され処理されるため、鏡は継続的に認証と承認チェックを行う必要があります。
Authentication alone does not provide a complete security model. Current practice specifies authorization for deletions and changes only, not for additions. The authorization rules provide here complete the security model for additions, deletions, and changes by very explicitly defining rules for addition and clarifying procedures for handling exception cases such as organizations which have ceased to exist and therefore become entirely unresponsive.
認証だけでは、完全なセキュリティモデルは提供されません。現在の慣行は、追加ではなく、削除と変更のみの承認を指定します。認可規則は、ここで、追加、削除、および変更のセキュリティモデルを完成させ、存在しなくなり、したがって完全に反応するようになった組織などの例外ケースを処理するための手順を非常に明確に定義し、明確にすることにより、変更、削除、および変更を完了します。
Authentication and authorization of queries is explicitly stated to be out of scope of this document.
クエリの認証と承認は、このドキュメントの範囲外であると明示的に述べられています。
Authors' Addresses
著者のアドレス
Curtis Villamizar Avici Systems EMail: curtis@avici.com
Curtis Villamizar Avici Systems Email：curtis@avici.com
Cengiz Alaettinoglu ISI EMail: cengiz@ISI.EDU
Cengiz alaettinoglu isiメール：cengiz@isi.edu
David M. Meyer Cisco EMail: dmm@cisco.com
David M. Meyer Cisco Email：dmm@cisco.com
Sandy Murphy Trusted Information Systems EMail: sandy@tis.com
Sandy Murphy Trusted Information Systems Email：sandy@tis.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（1999）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。