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.
著作権（C）インターネット協会（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.
RIPEデータベース仕様と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）は、インターネット全体のコーディネートの必要性を満たすために進化してきました。この必要性は、RFC-1787に記載された、情報のRFCはIAB [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.
RIPE努力がspecificly最初の問題とヨーロッパコミュニティのニーズに焦点を当てました。前身、PRDBは、単一の組織、NSFのニーズを取り上げました。 [2]で説明されるようにRIPEデータベース形式は、元の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は[12]、1993年にCIDRを収容し、RIPEデータベースは、当初からCIDRプレフィクスのエントリを収容するが、RPSLは、凝集のために明示的なサポートを含む多くの必要な改善を提供します。
This document addresses the third group of needs identified above.
この文書では、上記特定されたニーズの第三のグループに対応しています。
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.
別の文書には、ニーズの四群に対処するために必要とされるであろう。
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.
認可モデルはAS番号、およびルートの発表のために、アドレス番号の割り当てのための特定のポリシーを符号化します。認可モデルへの暗黙のは、政策の前提条件の非常に限られた数です。
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.アドレス番号は階層的に割り当てられています。そのメンバーにターン委任アドレス空間で、顧客にアドレスを割り当てることができる地域レジストリ（現在はARIN、APNICとRIPE）、へのアドレス空間のIANA委譲部分。
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.
AS番号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.ルートは唯一の発表の数AS起源の所有者の同意を得て、アドレススペースの所有者の同意を得て発表される必要があります。
4. AS numbers and IP address registries may be different entities from routing registries.
番号とIPアドレスレジストリAS 4.ルーティングレジストリは異なる構成要素であってもよいです。
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.
これら三つの割り当てスペース、ネットワークアドレス、AS番号、および経路のいずれかのサブセットのために、これらの制限は非常に弱い認証方法または「なし」の認証方法を指定することにより、緩めたり無効にしたりすることができます。しかし、何の認証メカニズムが使用されていない場合でも、すべての関係者は、既存の「通知」属性を使用して発生した変更について通知することができます。
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.
この文書は、レジストリのポリシーデータの整合性を保証する認証および承認モデルを提供するだけのものです。追加、削除、およびデータベースへの変更だけautheticationと承認は、このドキュメントの範囲内です。データベースクエリの認証と承認は、スコープの外に、明示的です。クエリの原点とクエリ結果が得られるからリポジトリの両方を認証しているクエリの相互認証は、範囲外でもあります。
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]は、この文書全体にわたって仮定されます。目標は、セクション9を介して第6項7に記載されている変更と説明の記述を提供します。セクション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のいくつかは、文字通り自分のネットワークにスタティックルートの数千を持っています。これらは、多くの場合、オペレータが手動で入力されています。タイプミスが広告を出して目的地への到達性がない、実際にルータに完全に無関係先からのトラフィックをそらすことができます。これが発生する可能性があり、やや定期的に起こるん。また、経路情報またはプレフィックス長の変更AS 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.
ルート広告が有効であるかどうかのチェックのいくつかのフォームを提供する必要があります。今日のチェックは、通常のルートを広告するAS境界線に対して作られています。これは、それが合法的ルートをアドバタイズしませんでしたAS国境のセットからのルートを受け入れないようにします。論文のチェックは特定のASボーダーによってアドバタイズすることができプレフィックスのリストを生成するためにIRRに登録されている情報の使用に依存しています。小切手は、AS、原点に対して行うことができます。ポリシー情報が十分に取り込まれた場合は、チェックはパス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。即時のインターネットサービスプロバイダは、ルートが顧客をフィルタリングしませんが、他のプロバイダのルートがinterproviderピアリングでの経路交換をフィルタリングする場合にのみ、そのインターネットプロバイダへのサービス拒否のローカライズ。
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番号の割り当てと同様にルーティング番号空間を委任することは理にかなって。数多くのレジストリへの権限委譲、この必要性は、全体としての情報の体の健全性を維持することの難しさを増します。
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の場合です。十分信頼できるリポジトリの非常に小さな数や変更を行う権限当事者の非常に多くがあります。コントロールは変更を加えることができ、彼らが作ることができるどのような変更、誰の上に行使しなければなりません。承認から認証を分離するもの対の区別。
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.
データベースの異なる部分は、認証の異なる方法が必要になります。一部のアプリケーションでは、強力な暗号化に基づく認証が必要になります。他の例では、強力な暗号化をサポートするソフトウェアは必要ではないかもしれないか、法的に利用できない場合があります。複数の認証方式をサポートしなければならない。このような理由から、メンテナオブジェクト内の認証方式「認証」属性の仕様によってオブジェクトごとに選択しました。認証方法は、強力な署名をcryptographiclyすることは非常に弱いデータの整合性チェックの範囲であってよいです。認可モデルは、データベースの一部で弱い整合性チェックを使用すると、データベースの全体的な整合性を損なわないことを確認しなければなりません。
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.
自律システム番号は、ブロックに委任し、subdelegated必要に応じて割り当てられた番号AS、個々のことができます。アドレス割り当ては、単純な数値の階層です。ルートの割り当てはやや複雑です。 （それはユニークな作りに関してキー）ルート・オブジェクトのキー属性はアドレスプレフィックスとAS原点として知られているAS番号、両方が含まれています。ルートオブジェクトの追加は、ASとアドレスプレフィックスの両方の許可基準に照らして検証する必要があります。ルートオブジェクトが原因ASユニークな起源を必要としない一般的なマルチホーミングの練習に値AS複数の原点と同じプレフィックスのために存在してもよいです。より具体的な接頭辞を重ねるの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.
対応しなければならない数多くの運用例があります。より一般的なのいくつかを以下に記載されています。これらは、付録Cの技術的なトレードオフの議論を付録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
AS Oプロバイダ独立したアドレスと複数の起源
o changing Internet service providers
インターネットサービスプロバイダを変更するO
o renumbering grace periods
Oリナンバリング猶予期間
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.
認可モデルは、アドレス空間の割り当てに関する方針の多様に対応しなければならないし、いずれかのモデルの使用を強制することはできません。ガイドラインは存在しないもののアドレス割り当てポリシーのない標準化はありません[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]ルーティングリポジトリの内容の完全な説明を提供します。 [2]多くのRPSLデータオブジェクトは、RIPE仕様から変更されないままとRFC-1786に記録されRPSLは、RIPE-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.
カプセル化のいくつかの形式は、データを交換するために使用する必要があります。事実上のカプセル化は、RIPEツールは、メールヘッダ又はメッセージ本文に由来する認証に必要な情報をRFC-822形式のメールメッセージの本文にテキストファイルまたはプレーンテキストを受け入れる一つとなっています。メリットは、わずかにメールメッセージの本文の一部に署名したテキストファイルまたはPGPの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-によってオブジェクトの属性で名前によって参照されます。メンテナの使い方に関する詳細については、セクション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つ以上の「認証」属性が含まれています。それぞれの「認証」属性は、その方法を実施するために必要な認証情報に続いて認証方法を特定するキーワードで始まります。 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-から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メールヘッダのフィールド返信には、この正規表現にマッチしている場合はメンテナが認証されます。メール偽造は非常に簡単ですので、これは認証の非常に弱い形です。
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.
暗号-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-からこの形式は、「pgpkey」に置き換えられています。これはメリットのPGP拡張機能です。認証情報は、外部の公開鍵リングを指す署名のアイデンティティです。トランザクションは、対応する秘密鍵によって署名され（現在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このキーワードは、「HHHHHHHH」認証に使用するPGP公開鍵の4バイトのIDの16進数表現であるフォーム「PGPKEY-HHHHHHHH」を、取ります。 [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.
リポジトリは、認証の弱い形式を指定する属性「AUTH」の追加を許可しないことを選択および/またはローカルトランザクションの提出での使用を許可しないことがあります。リポジトリは、「認証」の追加は廃止「PGP-から」メソッドで属性を禁止することをお勧めします。
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.
任意のデジタル署名技術は、原理的には、認証のために使用することができます。トランザクションは、署名のうち少なくとも一つを確認するための技法のサブセットを使用するリポジトリまたはミラーを可能にするために、複数のデジタル署名技術を使用して署名されなければなりません。デジタル署名技術の選択は、この文書の範囲外です。
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で見つかっていないオブジェクトは、代表団と新しい属性がsubdelegationを制御するために、既存のオブジェクトで必要とされているように、制御するために必要とされます。 distrubutedルーティングレジストリシステムを実装するために使用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.
メンテナのオブジェクトは、認証フィルタを保持するためのコンテナとして機能します。認証方法は、保守が最も顕著MNT-によって、これらのオブジェクトの属性で、他のオブジェクトに名前で参照することができ、セクション8に記載されています。
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を-によって属性が含まれています。いくつかの場合においてMNT-による保守には、保守自体を参照します。この場合は、メンテナを変更する権限は、アイデンティティの（通常は非常に限られた）セットに提供されます。良い習慣は変化し、特定の種類を作ることが、メンテナのMNT-によって属性がより緊密にメンテナオブジェクト自体への変更を制御するはるかに制限メンテナを参照している許可IDの長いリストを含むメンテナを作成することです。
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-によって属性は、すべてのオブジェクトで必須です。一部のデータがすでにMNT-によって属性なしで存在します。欠落MNT-によって属性が変更上の任意のコントロールの欠如と解釈されます。これは非常にお勧めできません、ほとんどのリポジトリはもはや、これを許可しません。
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-経路」を介して発生することができ、及びAUT-NUM、のinetnumおよびルートオブジェクトで使用されています。 「MNT-ルート」属性は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.
MNT-ルートがAUT-NUMオブジェクトの属性は、経路の添加が記載されている保守の原点として、そのAS番号を持つオブジェクトができます。 MNT-ルートがのinetnumオブジェクトの属性は、完全一致または複数の特定のプレフィックスのルート・オブジェクトの追加を可能にします。 MNT-ルートがルート・オブジェクトの属性は、完全一致または複数の特定のプレフィックスのルート・オブジェクトの追加を可能にします。 MNT-ルートは、それが表示されますAUT-NUM、のinetnum、またはルートオブジェクトへの変更を許可していません属性。 MNT-経路は、必要に応じてのみ、より具体的なルートのサブセットに適用するように制約されてもよいです。
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-経路」または「MNTバイ」で参照される「MNT - 低級」適用可能である、任意の保守依然として当てはまります。行われているどのような検査に適用保守のセットは、「MNT-経路」または「MNT低級」および「MNTバイ」の和集合です。それは、「MNT・バイ」を見て存在しない場合、それは、「MNT-下」を見て、存在しない場合たとえば、ルートオブジェクトのソフトウェアを許可する場合は、「MNT-ルート」になります。
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番号の範囲を委任するために必要とされます。これは、認可のために必要とされ、特定のASを見つけるために、すべてのリポジトリの徹底的な検索を行うことを避けるために必要とされています。この検索は、今問題にならないだろうが、より多くの分散ルーティングリポジトリが使用されている場合だろう。分散レジストリの問題は、この文書の範囲内ではありません。
The "as-block" object also makes it possible to separate AS number allocation from registration of AS routing policy.
「AS-ブロック」オブジェクトはまた、ルーティングポリシーの登録から数割り振りとして分離することができます。
as-block: AS1321 - AS1335
AS-ブロック：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および分析のために、別のASによって実行されるのルータ設定のために重要です。このドキュメントの目的のために、単にプレースホルダーとしての存在を確認し、「ルート」オブジェクトを追加するときのようにそれと承認を関連付けるための手段を提供するものとしてAUT-NUMを考慮すれば十分です。
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-ブロック」オブジェクトは、単に別のレジストリに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は、」アドレスの割り当てをサポートするために存在しています。例えば使用するもののような外部の数レジストリは、「INET-numは」アドレス割り当てが権威あるデータベースで行われたとき付加される二次レコードとして働くことができる「[++] whoisd [R]」。そのようなレコードは、対応するルーティングレジストリに礼儀など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.
現在、複数のレジストリ内のかなりの数のルートオブジェクトがあります。かなりの数は、彼らが発表されていなかったASいる原点に登録されています。 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およびルートオブジェクトで必要とされます。再利用属性は、コントロールに関係なくMNT-によって、オブジェクト自体での権限を変更および削除できるようにすることによりIPアドレスまたはルートスペース、ASより具体的なオーバー保持することができます。
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.
再利用属性は、アドレス貸与を強制する手段を提供します。これは、エンティティが存在しなくなるか、最後プリソートは、そのような当事者が自分自身のオブジェクトへのアクセスのうち、自分自身をロックなどのエラーを訂正することを意味するような場合にクリーンアップすることができます。すべてのより特定のオブジェクトを指定するには再利用属性値が「ALL」でなければなりません。より細かい制御を可能にするにはプレフィックスのセットを指定することができます。
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.
無再利用属性が明示的に例外を提供するために使用することができます。再利用属性の追加は、新たな再利用属性によって覆われている既存のより特定のオブジェクトの自律性を削除しない場合は再利用属性は、既存のオブジェクトに追加することができます。
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. A新しい再利用属性と重なる既存の正確な一致以上の特定のオブジェクトが存在しない場合、属性は、既存のオブジェクトに追加することができる再利用、または
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-によって任意重複オブジェクトの属性に記載されている唯一の保守である場合にのみ、オブジェクトから無解放属性を削除してもよいです。提出者は、メンテナのいずれかに記載されていない場合によって、一つ以上の重複オブジェクトの属性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.
再利用または無再利用も属性が存在する場合、保守もより具体的な目的で保守としてリストされていない限り、その後、指定されたオブジェクトのより具体的な目的は、以下指定されたオブジェクトの保守によって変更することができません。しかし、新しいルートやの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補助的なオブジェクトの多くには、自然の階層に番号、インターネットアドレスとルートが数値階層を持っていそうであるように方法がありません。いくつかの例は、「メンテナ」、「人」と「役割」オブジェクトです。これらのオブジェクトのために、あらゆる階層の欠如は二つの問題につながります。
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は独自のハンドルを維持することが望まれています。 RIPEデータベース参照「CO19」内のオブジェクトは、デフォルトでは「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.
第二の問題は、部分的に保守の付加のための照会システムを使用して、他のオブジェクトが登録保守によって、またはIANAによって提出することを要求することによって対処することができます。紹介システムは、既存のメンテナが、他のメンテナを追加することができます。これは、これらのオブジェクトのメンテナンスをサポートするために、他のオブジェクトタイプの添加と平行して使用することができます。例えば、そのような「COM」として比較的平坦なドメインに新しいドメインを追加する、既存の保守が既に存在する場合でも、（ドメインも処理されるRIPEリポジトリ内の）「ドメイン」階層にサブドメインを追加しますドメイン。既存のメンテナは、新しいドメインを追加し、新しいメンテナにそれを変更する権利を与えることに加えて、新しいドメインのために必要とされるであろうメンテナを追加することができます。
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-バーAS1」としてセット名など、「AS-フー」として無命名階層に対応するか、フォームの階層的な名前を持っていることを有することができます。
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-セット」などのオブジェクトの権限と「ルートセット」のセクション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 - 低級保守基準を使用して、または存在しない場合は、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、及び経路などの天然階層を有するオブジェクトタイプについては、検索は、ルートデータベースから始まり、階層をたどります。データベースが指定されていない限り、このようなメンテナ、人物、およびロールオブジェクトとして全く自然な階層構造を持たないオブジェクトの種類については、検索はデフォルトのデータベースに限定されています。デフォルトのデータベースは、クエリが参照を追跡する必要性から起動された場合、参照が作られているオブジェクトと同じデータベースです。そうしないと、デフォルトでは、一般的に、ローカルデータベースまたはリポジトリで設定されたデフォルトです。セクション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ブロックにおける委任属性は、他のリポジトリからのデータの検索を移動し、相談することができます。最終的にASが発見されたいずれか、または検索が失敗します。 inetnumの検索も同様です。あまり具体的なinetnumsは、他のデータベースへの検索を参照することができます。最終的に最も特定のinetnumが発見され、その状態（割り当てまたは割り当てられていない）を決定することができます。リポジトリのトラバーサルのための属性の定義がdistrbiutedレジストリの問題と考えると、この文書の範囲内ではありません。
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つのリポジトリ内の最も具体的な経路は、他のほとんどの特定よりも特異的であってもよいです。ルートオブジェクトを探して、それはルートが少なく、特定の重複を含む各リポジトリから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
ルートリポジトリは、最初にいくつかのエントリを持ついくつかのエポックで埋めなければなりません。最初のメンテナは、より多くのメンテナを追加するために必要とされます。紹介-によって属性は、この特殊な場合には、それ自体を参照するように設定することができます（セクション10は、紹介-によって記述します）。いつ
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.
inetnumまたは既存の完全一致以下の特定のオーバーラップが存在している必要があり、ルートオブジェクトを追加します。ルートオブジェクトは、正確に一致する以下の特定のinetnumに基づいて添加してもよいです。ルート・リポジトリは、最初にいくつかのアドレス割当機関が存在することを示す、接頭0/0をカバーするのinetnumの割り当てで埋めなければなりません。同様に、初期には、のようにブロック番号の範囲として完全に覆う必要とされています。
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-ブロックオブジェクトとリポジトリ委任のシーケンスが続きます。 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、次いでルートオブジェクトまたは該当ルートオブジェクトが見つからない場合、のinetnumのいずれかで指定された認証で指定された認証が一致しなければなりません。
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が存在する場合、申請は適用メンテナに対してチェックされます。検索は、最初の完全な一致を探している接頭語のために行われます。完全一致の検索が失敗した場合、検索では、指定した接頭辞よりも小さい固有の最長プレフィックス一致のために作られています。この検索が成功した場合には、一個の以上のルートオブジェクトを返します。提出は、成功するために追加のためにこれらのルートオブジェクトの少なくとも一つに該当するメンテナと一致する必要があります。ルートオブジェクトの検索が失敗した場合、検索は正確にプレフィックスに一致するの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とルートオブジェクトかのinetnumのいずれかを発見した、承認は、これら二つのオブジェクトから取得されます。適用可能な保守オブジェクトは、任意のMNT-ルート属性によって参照されます。一つ以上のMNT-ルート属性がオブジェクトに存在する場合、MNT-によって属性が考慮されていません。指定されたオブジェクトの属性MNT-経路の非存在下で、MNT-によって属性は、そのオブジェクトのために使用されます。認証は、2つのオブジェクトのそれぞれにおける権限のいずれかと一致しなければなりません。
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の添加は再利用属性が含まれている場合、同じタイプのいずれかより特定のオブジェクトを検査しなければなりません。それ以上の特定の重複が存在しない場合、または添加の認証が既にプレフィックス範囲をカバーする再利用属性を持つ以下の特定のオブジェクトの許可に存在する場合、または添加の認証であれば再利用属性のみを添加することができます添加することにより、対象となるすべての既存のより具体的なプレフィックスの変更を許可。
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-によって属性オブジェクト内で参照される任意のメンテナです。ルートとINET-NUMに適用保守が再利用属性を持つ以下の特定のオブジェクトにリストされていることができるオブジェクト。
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は、再利用属性の使用の背後にある論理的根拠の議論が含まれています。
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).
再利用属性を追加したり、無再利用属性を削除するの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-によってはまだ属性を「削除」を除去するために調べることができ、その場合、属性を「削除」してデータベースに残り得ます。
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.
現在RIPEスキーマ内の約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スキーマに追加されます。オブジェクトの追加が許可されているかどうかを判断ルールに大幅な変更があります。
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
ブロックキー必須単一一意DESCR任意複数の発言は、オプションの複数の管理-C必須複数ハイテクC必須複数の通知オプション複数MNT-によって必須複数は、単一の必須の必須の複数のソースを変更しました
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:
強力な認証をサポートするために、以下のキーワードは、「認証」属性に追加されます。
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 IDを識別する文字列を与えます。この方法の使用は「pgpkey」方式を支持して廃止されました。
pgpkey See [18].
PGPキーは[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」フィールドを取るために使用することができます。ケアは、循環参照を検出し、拡張や、既に訪問した参照を終了するための実装に注意する必要があります。
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-ルートMNT-経路属性は、AUT-NUM、INET-NUM、またはルートオブジェクトに表示されてもよいです。この属性は、ルートオブジェクトを追加するための許可を決定する際に使用されているメンテナのオブジェクトを参照します。中括弧やキーワードの内部保守、（RPSLで定義）プレフィックス範囲のオプションのリストを参照した後に「ANY」に従うことができます。追加の設定項目が指定されていないデフォルトでは、「ANY」または全てより具体的です。 MNT-ルートはオプションで、複数の属性。 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 - 低級属性としてブロック又はAUT-NUMオブジェクト、ルート、のinetnumに表示されることがMNT-下げます。この属性は、メンテナのオブジェクトを参照します。 inetnumまたはルートオブジェクトで使用される場合の効果は、「MNT-経路」と同じであるが、それだけが含まれているオブジェクトの接頭辞より特定のプレフィックスに適用されます。ブロックオブジェクト内、MNT - 低級としてブロックオブジェクトまたはAUT-NUMオブジェクトより特定の添加が可能となります。 AUT-NUMオブジェクトにMNT - 低級属性は、セクション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.
、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.
無再利用属性は再利用の属性で使用されている無取り戻します。無再利用属性は、任意の再利用は、それが重なっている属性を否定します。無再利用属性の削除に関する制限については、セクション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.
auth-上書きのauth-override属性は、追加、削除、または照会ごとにリストされているメンテナから提出されたトランザクションによって変更することができます。そのメンテナ前60日間非アクティブになっている場合のauth-オーバーライドはメンテナに追加することができます。属性がすでにメンテナを変更する権限がない限り、少なくとも60日、現在の日付からでなければなりません施行される際のauth-override属性自体は日付のみが含まれています。 auth-オーバーライドの日付に達した後、紹介・バイでメンテナによって特定されたものはメンテナを変更する権限を持っています。この属性は、メンテナの所有者が応答しなくなるはずですクリーンアップするための手段として存在し、そのメンテナが変更に発生した自動通知に応じてのauth-オーバーライドを削除しない場合にのみ効果を取ることができます。
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バイ」属性が「メンテナ」オブジェクト・タイプを参照します。 「MNT-による」属性は、すべてのオブジェクトタイプになりまし必須です。新しいメンテナは、既存のメンテナで添加してもよいです。 「紹介・バイ」属性は、メンテナが加算を行い、変更することはできませんその記録を維持するために、「メンテナ」オブジェクトで今必須です。メンテナは限り彼らは「紹介・バイ」の別の場所属性によって参照されているとして削除することはできません。
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-オーバーライド」属性は、リポジトリデータはどのような方法で再配布された環境での回復を容易にするための便利です。
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.
「referalバイ」属性が「コア」機能です。個々のレジストリは、その「referalバイ」点itslefに自己参照保守、いずれかを作成することによって、そのsutonomyを発現し得ます。他のレジストリは、そのようなエントリが有効かどうかを検討するケースバイケースで決定することができます。レジストリは、「referalバイ」はレジストリの制御の下で特定の保守を参照することを可能にし得ます。このさらなる制限は、レジストリに純粋にローカルな問題です。
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.
以下の例は、本文書に記述されたオブジェクトと属性の使用を説明するために必要とされていないいくつかの必要な属性を除外します。行方不明、ソース管理-C、ハイテク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つのリポジトリに移入され、そのmaintianerはreferalバイ自体を指すを有しています。 referal-による参照他のすべては、そのメンテナまでさかのぼることができます。エポックでAS-ブロックAS0-のAS65535とのinetnum 0.0.0.0〜255.255.255.255も割り当てられます。その他ancilliaryオブジェクトは、ブートストラップするために必要とすることができます。
mntner: ROOT-MAINTAINER auth: pgpkey-12345678
mntner：ROOT-MAINTAINER払い：pgpkey-12345678
mnt-by: ROOT-MAINTAINER referal-by: ROOT-MAINTAINER
MNT-によって：ROOT-MAINTAINERの紹介・バイ：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-によって：WIZARDS referalバイ：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：人間はDESCR：日常業務払いに一日を維持：pgpkey-456789ab払い：pgpkey-56789abc AUTH：pgpkey-6789abcdのMNT-によって：WIZARDS referalバイ：WIZARDS
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-block: AS65500-AS65510 mnt-by: SOME-REGISTRY mnt-lower: WIZARDS
AS-ブロック：AS65500-AS65510 MNTバイ：SOME-REGISTRY MNT - 低級：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のために必要とされるが、ここでは示されていないことに注意してください。
aut-num: AS65501 mnt-by: WIZARDS mnt-lower: MORTALS
AUT-NUM：AS65501のMNT-によって：WIZARDS MNT-下：人間
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自体を変更することができます。彼らはまた、より少ない特定のルートまたはの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で必要とされるであろうomitedされています。
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-によって：SOME-REGISTRY MNT-下：ISPの再利用：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バイ：ISP MNT - 低級：EBG-COMの再利用：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-ルートはAUT-NUMまたはMNT - 低級に加えることができるのinetnumに加えることができます。
aut-num: AS65501 mnt-by: WIZARDS mnt-lower: MORTALS mnt-routes: EBG-COM {192.168.144/23}
AUT-NUM：AS65501のMNTバイ：WIZARDS MNT - 低級：人間MNT-経路：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はなく、限られたアドレス範囲を持つ、原点AS65501のルートを追加することができます。
route: 192.168.144/24 origin: AS65501 descr: These boneheads don't aggregate mnt-by: EBG-COM mnt-by: FICTION::MORTALS
ルート：192.168.144 / 24原産地：AS65501のDESCR：これらboneheadsはない集約MNT-によって：EBG-COM MNT-によって：FICTION ::人間
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.
オブジェクトが別のリポジトリに終わった場合は、1つのメンテナはまだ使用することができます。表記フィクション::人間上記の例では、ルート・オブジェクトが別のリポジトリにあり、かなり保守を複製するよりも、基準が人間の存在をどのオブジェクトリポジトリになることを示しています。
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-によって：WIZARDS MNT-下：人間
route-set: AS65501:Customers:EBG-COM mnt-by: MORTALS mnt-lower: EBG-COM
ルート設定：AS65501：お客様は、EBG-COMのMNT-によって：人間MNT-下：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-によるにおけるEBG-COMとの任意のオブジェクトを変更することができます。
mntner: EBG-COM mnt-by: EBG-COM auth-override: 19990401
mntner：EBG-COM MNT-によって：EBG-COMのAUTH-オーバーライド：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. enforcibleアドレス貸与をサポートしたり、彼らが使用しているプレフィックスの登録を超える究極のコントロールと小さいか、またはエンドユーザーに提供するかどうか。
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.どちらかが最低限の認可、認証、および説明責任に関する新しい要件に適合し、または疑わしい妥当性のあるいない古いオブジェクトをどうしますか。
C.1 Relaxing requirements for ease of registry
レジストリを簡単にするための要件を緩和C.1
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が存在する要件が緩和された場合、誰もが数AS割り当てられていないのを利用したり、AUT-numが入力されていないためにAS番号割り当てを利用することが可能です。 AUT-NUMのエントリに要件を置くことは、インターネットのアドレス割り当て機関（ルーティングレジストリから独立している場合）の協力を前提としています。アドレス割り当て権限は割り当てが行われたために相手からスケルトンAUT-NUMSを移入するための要求をフィールドに喜んでなければなりません。これらの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番号の要求を行うことができます。メンテナはcryptographicly強い認証方式のための公開鍵を含めることができるか、それは登録パーティで十分な考慮されている場合、「暗号キー」または「メールへ」の認証チェックを含めることができます。さらに、アドレス割り当て権限は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番号とアドレス登録時に落ちる問題の一つです。この問題は、既存のメンテナがメンテナを追加できるようにすることで軽減されます。これは実際にそれが簡単にメンテナので、登録が容易に取得することがあります。数の権威はまだ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が強く、インターネットアドレス配分当局の協力に依存していると呼ぶルートオブジェクトの追加中に行われた認証チェック。数当局は、番号やアドレス空間として確保されると、ブロック、AUT-NUMS、またはinetnumsを登録する必要があります。数当局のサブセットのみが協力した場合、その後のinetnum又はブロックのいずれかが割り当てをレジストリ空間をカバー作成し、基本的にパスワードが備考欄に与えられるヌル割り当て（例えば、「陰窩-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.
メンテナの要件は、それが簡単に登録すること、既存のメンテナのために、わずかに緩和することができます。他のオブジェクト上の要件を緩和するオプションではありませんため、承認モデルを打ち負かすことがあります。
C.2 The address lending issue
C.2アドレス貸与の問題
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.
貸付契約がenforcibleするかどうかの問題は、最終的には、アドレス空間の割り当て支配力を行使することができるはず誰の問題です。ルーティングレジストリは、第三者間の紛争に関して、できるだけニュートラルに滞在するのが賢明だろう。 「再利用」と「ノーが-取り戻す」以下の特定のinetnumまたはルートオブジェクトの所有者は、レジストリ内suballocationsを支配できるかどうかを判断するのいずれかの結果を許可するように設計されています。ルーティングレジストリ自体が自分自身を制御し、そうならば、非常に明確にレジストリが介入するだろうどのような条件の下で述べるべきで保持するかどうかを決定する必要があります。レジストリも、彼らは紛争が裁判所で解決されたと裁判所の命令が発行された後にのみ、このような紛争に介入することを知らせるの極端に行くことができます。
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.
「再利用」の権利を保持することにより、レジストリは、裁判所の命令を遵守する能力を保持しています。これが唯一の真レジストリが他の場所で行われた取引の承認を再チェックされ、場合、レジストリの内容を変更する通常の許可をオーバーライドすることにより、裁判所の命令を遵守するために、別のレジストリの試みを処理するために失敗することがあり、分散レジストリ環境では問題になるかもしれません再利用存在しません。
C.3 Dealing with non-conformant or questionable older data
非適合または疑わしい古いデータを扱うC.3
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.
多くのルートオブジェクトは、そのため何のメンテナとそのためのinetnumおよびASオブジェクトが存在しない存在しない存在します。一部は現在、廃止守護属性ではなく、MNT-によって含まれています。
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).
既存のデータの有効な連絡先情報を必要とするのは無理ではありません。大量のデータは、このような何の発表は何ヶ月または数年に見られないされたルートオブジェクトとして、未使用のように見えます。何のメンテナがない場合は、連絡先情報AS番号のレジストリや起源を使用してそこに一つであり、かつならば、メンテナアップチェーン紹介-によって、存在する場合試みはメンテナで、対象物に記載された連絡先に連絡するためになされるべきですフォローする責任トレイル。経験は、これまでのルートダンプに対して登録されたプレフィックスを比較することによって同定欠失の大部分が正（削除を可能にする）が確認されるか、または（多くの場合、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-オーバーライド」属性を追加することが許可されています。メンテナ自体は変更が通知されるだろうし、それが有効になる前に「のauth-オーバーライド」属性を削除し、それが存在していたものは何でも問題を追加し、正しいた理由を尋ねることができます。これはすぐにサポートしたり、必要に応じて後から追加することができます。
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:
原理的には、アドレス割り当ておよび経路の割り当ては階層は、物理トポロジーに対応した階層的であるべきです。実際には、これは多くの場合、多くの理由の場合はそうではありません。主な理由は、トポロジーは厳密には木構造ではなく、トポロジーが変更することができます。もっとspecificly：
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をインターネットには多くの添付ファイルは、複数のインターネットプロバイダにマルチホームです。
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]。私たちは、最初の階層がまだ存在している単純なケースを検討します。私たちは、初期トポロジーがツリー構造または例トポロジの変更ではないのいずれかの操作例を調べます。
D.1 simple hierarchical address allocation and route allocation
D.1シンプルな階層的なアドレス割り当ておよび経路配分
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のルートオブジェクトを追加する権限を与えることができ、あるいは当事者がそのアドレス空間のルートオブジェクトを追加するには、プロバイダのアクセス許可を与えることができ、または両方の当事者が取引に署名することができ、アドレス空間を割り当てられた。どこに許可はメンテナの属性に追加することにより提供されます。
D.2 aggregation and multihomed more specific routes
D.2の集約は、より具体的なルートをマルチホーム
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.
プロバイダは、プロバイダに割り当てられた後、および/または顧客への内部suballocatedアドレス空間を集約した場合の集約は、通常は問題ではありません。実際には、プロバイダは、そうすることが期待されます。これは、集約のためのルートオブジェクトのみが少なく、特定のオブジェクトが考慮されているので、より特定のルートオブジェクトの後に追加されても問題ありません。
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.
プロバイダまたはプロバイダのセットが明示的にこれらのプロバイダにブロックとして割り当てられていないのではなく、アドレスレジストリの割り当てのままでしたアドレス空間を集約することを計画している場合の集約は、潜在的な問題です。これらの大規模な集計は珍しいが、比較的容易に対応することが期待できます。このタイプのSuperaggregatesは、一般的にも、隣接するアドレス割り当てを引き出すために管理している位相幾何学的に近いエンティティによって形成されることになります。実際には、レジストリはのinetnumのMNT-ルートや他の関係者と一緒に提出を署名することによってそうするためのいずれかを与える許可を得て、このような超集合を形成するための権限を与える必要があります。
D.3 provider independent addresses and multiple origin AS
D.3プロバイダ独立したアドレスとAS複数の起源
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-ルートまたは複数の署名を使用して付与することができます。
D.4 change in Internet service provider
インターネットサービスプロバイダに変更D.4
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ではなく、マルチホーム顧客のASより新しいプロバイダーのASになるということです。許可は、送信時に表示されることがMNT-ルートまたは複数の署名を使用して付与することができます。
D.5 renumbering grace periods
D.5リナンバリングの猶予期間
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.
引用された別の理由は、ルーティングレジストリ情報が不完全または不正確である環境でプレフィックスに基づいてフィルタリングする接続を妨害することができるということです。
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.
新しい認証メカニズムを展開すると、有害な影響を持っていません。これは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".
RADBにNSFNET PRDBから遷移プレフィックス多数の中1. NSFNETが一旦経路アナウンスを聞いていた時との境界に対応するものとして原点に登録しました。 PRDBはAS起源をサポートしていませんでしたので、国境ASを使用しました。これらの経路の多くは、一度使用されなくなっなかったと今「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がデプロイされたとして、凝集体は以前に別途発表し、より具体的な接頭辞を置き換えます。より具体的なプレフィックスのルートオブジェクトは、ルーティング登録から撤退されませんでした。
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.
隣接ASプロバイダーとして4.変更と変更ASエンドとしての顧客は、多くの場合、実際の起源をプロバイダを切り替えます。これは、多くの場合、ルーティングレジストリの変更により反映されませんでした。
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にありません。かなりの数のASにはAUT-NUMを持っていません。データのかなり多くは、何のメンテナを持っていないとメンテナの大半は唯一の認証方法の最も弱いを使用しています。これを修正するために、レジストリではほとんど行うことができます。承認のために必要な不足しているオブジェクトの場合のデフォルトはまったく認証チェックをしないためにである必要があります。
The transition can be staged as follows:
次のように遷移が上演することができます。
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」と「ルート」。
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の代表団の場合は、「としてブロック」トラバーサルのためだけに作成する必要があります。
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、次いでルートオブジェクトまたは該当ルートオブジェクトが見つからない場合、のinetnumのいずれかで指定された認証で指定された認証が一致しなければなりません。
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-ルート」属性（S）で参照保守（複数可）を使用して試験しなければなりません。そのチェックが失敗した場合、「MNT-下」属性がチェックされます。そのチェックが「によりMNT-」失敗した場合の属性は、許可チェックのために使用されています。
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.「再利用」属性は、オブジェクトのinetnum、ルート内としてブロック表示され、アドレス貸与をサポートするための手段を提供することができます。 「再利用する」にかかわらず、「MNT-による」オブジェクト内の、より特定のオブジェクト上の権限を与えます。 「再利用」属性の値は、リストやきめ細かい制御を提供するために、オブジェクトに設定することができます。
The "reclaim" attribute is important to this discussion since it affects prefix/origin authentication when a new route object is submitted.
新しいルートオブジェクトが送信されたときに、それが接頭辞/元の認証に影響するため、「再利用」属性は、この議論に重要です。
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の認証に失敗した）場合
/* 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
認証に失敗した（認可は以下の特定の経路（単数または複数）の少なくとも一方のために通過しない）場合は、[（最も長い接頭辞を有する以下の特定の経路（単数または複数）が発見された）場合
/* 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
（これ以上、具体的には存在しない場合は、[（オブジェクト属性を「解放」を有する）以下、特定の認証を通過し、「再利用」属性を有する存在する場合
OR all more specifics routess pass modify authorization ) authorization passes else authorization fails ] else authorization passes ]
ORすべてのより多くの詳細は失敗し、他の許可が経過]の権限が他の承認を渡す）の認可を修正渡し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
（（のinetnumが完全に一致する以下の特定であり、それはステータスが「割り当てられた」さ）ANDのinetnumによって参照メンテナが承認を渡すだと発見された）場合、許可は成功します
/* 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
（MNT-によっては承認を渡す）場合、許可は成功します
/* 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ルーティングワーク・グループの拠出金からのアイデアを描画します。このドキュメントの以前のドラフトは共著者としてキャロルオレンジ記載されています。キャロルオレンジは、しばらく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.スーザンハリスで見つかった擬似コードの基本は、コメントと多数の編集上の訂正を提供されたRIPE 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.
[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]ベイツ、T.、Gerich、E.、Joncheray、L.、Jouanigot、JM。、Karrenberg、D.、テルプストラ、M.及びJ.優、「ルーティングレジストリにIPルーティングポリシーの表現（ripe- 81 ++）」、RFC 1786、1995年3月。
[3] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[3]バーコウィッツ、H.、 "ルータリナンバリングガイド"、RFC 2072、1997年1月。
[4] Braun, H-W., "Models of policy based routing", RFC 1104, June 1989.
[4]ブラウン、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、RFC 1222、1991年5月 "NSFNETルーティングアーキテクチャを進めます"。
[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]クロッカー、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]フラー、V.、李、T.、ゆう、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. Hindenと、RFC 1517、1993年9月「クラスレスドメイン間ルーティング（CIDR）の実装のための適用性に関する声明」。
[10] Hawkinson, J. and T. Bates, "Guidelines for creation, selection, and registration of an Autonomous System (AS)", RFC 1930, March 1996.
[10]ホーキンソン、J.およびT.ベイツ、 "自律システム（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]ハバード、K.、Kosters、M.、コンラッド、D.、Karrenberg、D.およびJ.ポステル、 "インターネット登録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.リチャードソン、 "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]マイヤー、D.、前、M.、Alaettinoglu、C.、シュミッツ、J.およびキャロルオレンジ、 "実践において使用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.李、 "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.李、 "インターネットルーティングのための様々なアドレス割り当てポリシーの影響"、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.、デアリング、S.およびJ.ポステル、 "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.
この文書では、主に、ポリシー情報リポジトリのルーティングに追加、削除、および変更を行うための認可ルールに対応しています。強力な暗号化手段を介してこれらのトランザクションの認証は、この文書thorughout参照、[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
カーティスVillamizar Aviciシステムズ電子メール：curtis@avici.com
Cengiz Alaettinoglu ISI EMail: cengiz@ISI.EDU
チンギスメールAlaettinogl HEAT：cengiz@ısı.e
David M. Meyer Cisco EMail: dmm@cisco.com
デイビッドM.マイヤーシスコのEメール：dmm@cisco.com
Sandy Murphy Trusted Information Systems EMail: sandy@tis.com
サンディマーフィーは、情報システムの電子メールを信頼：sandy@tis.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。