[要約] RFC 7955は、LISPエンドポイント識別子（EID）ブロックの管理ガイドラインです。その目的は、LISPネットワークでのEIDブロックの効果的な管理と割り当てを提供することです。
Internet Engineering Task Force (IETF) L. Iannone
Request for Comments: 7955 Telecom ParisTech
Category: Informational R. Jorgensen
ISSN: 2070-1721 Bredbandsfylket Troms
D. Conrad
Virtualized, LLC
G. Huston
APNIC
September 2016
Management Guidelines for the Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
ロケータ/ ID分離プロトコル（LISP）エンドポイント識別子（EID）ブロックの管理ガイドライン
Abstract
概要
This document proposes a framework for the management of the Locator/ ID Separation Protocol (LISP) Endpoint Identifier (EID) address block. The framework described relies on hierarchical distribution of the address space, granting temporary usage of prefixes of such space to requesting organizations.
このドキュメントは、ロケータ/ ID分離プロトコル（LISP）エンドポイント識別子（EID）アドレスブロックの管理のためのフレームワークを提案します。説明されているフレームワークは、アドレススペースの階層的な配布に依存しており、要求する組織にそのようなスペースのプレフィックスの一時的な使用を許可します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7955.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7955で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
4. EID Prefix Registration Policy . . . . . . . . . . . . . . . 3
5. EID Prefixes Registration Requirements . . . . . . . . . . . 4
6. EID Prefix Request Template . . . . . . . . . . . . . . . . . 4
7. Policy Validity Period . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
10. Procedures to be Followed by RIPE NCC . . . . . . . . . . . . 7
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
11.1. Normative References . . . . . . . . . . . . . . . . . . 8
11.2. Informative References . . . . . . . . . . . . . . . . . 8
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
The Locator/ID Separation Protocol (LISP [RFC6830]) and related mechanisms ([RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]) separate the IP addressing space into two logical spaces, the Endpoint Identifier (EID) space and the Routing Locator (RLOC) space. The first space is used to identify communication endpoints, while the second is used to locate EIDs in the Internet routing infrastructure topology.
ロケータ/ ID分離プロトコル（LISP [RFC6830]）および関連するメカニズム（[RFC6831]、[RFC6832]、[RFC6833]、[RFC6834]、[RFC6835]、[RFC6836]、[RFC6837]）は、IPアドレス空間をエンドポイントID（EID）スペースとルーティングロケーター（RLOC）スペースの2つの論理スペース。最初のスペースは通信エンドポイントの識別に使用され、2番目のスペースはインターネットルーティングインフラストラクチャトポロジでEIDを見つけるために使用されます。
[RFC7954] requests an IPv6 address block reservation exclusively for use as EID prefixes in the LISP experiment. The rationale, intent, size, and usage of the EID address block are described in [RFC7954].
[RFC7954]は、LISP実験でEIDプレフィックスとしてのみ使用するIPv6アドレスブロック予約を要求します。 EIDアドレスブロックの理論的根拠、意図、サイズ、および使用法は、[RFC7954]で説明されています。
This document proposes a management framework for the registration of EID prefixes from that block, allowing the requesting organization exclusive use of those EID prefixes limited to the duration of the LISP experiment.
このドキュメントでは、そのブロックからEIDプレフィックスを登録するための管理フレームワークを提案し、要求側組織がLISP実験の期間に限定されたEIDプレフィックスを排他的に使用できるようにします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document does not introduce any new terms related to the set of LISP Specifications ([RFC6830], [RFC6831], [RFC6832], [RFC6833], [RFC6834], [RFC6835], [RFC6836], [RFC6837]), but assumes that the reader is familiar with the LISP terminology. [INTRO] provides an introduction to the LISP technology, including its terminology.
このドキュメントでは、LISP仕様のセット（[RFC6830]、[RFC6831]、[RFC6832]、[RFC6833]、[RFC6834]、[RFC6835]、[RFC6836]、[RFC6837]）に関連する新しい用語は紹介していませんが、読者がLISP用語に精通していることを前提としています。 [INTRO]は、その用語を含むLISPテクノロジーの概要を提供します。
The request for registration of EID prefixes MUST be done under the following policies:
EIDプレフィックスの登録の要求は、次のポリシーの下で実行する必要があります。
1. EID prefixes are made available in the reserved space on a temporary basis and for experimental uses. The requester of an experimental prefix MUST provide a short description of the intended use or experiment that will be carried out (see Section 6). If the prefix will be used for activities not documented in the original description, renewal of the registration may be denied.
1. EIDプレフィックスは、一時的に、実験的な使用のために予約済みスペースで利用可能になります。試験的なプレフィックスのリクエスタは、実行される予定の使用または実験の短い説明を提供する必要があります（セクション6を参照）。プレフィックスが元の説明に記載されていないアクティビティに使用される場合、登録の更新が拒否される場合があります。
2. EID prefix registrations MUST be renewed on a regular basis to ensure their use by active participants in the experiment. The registration period is 12 months. A renewal SHOULD NOT cause a change in the EID prefix registered in the previous request. The conditions of registration renewal are to be the same as the conditions of the first EID prefix registration request.
2. EIDプレフィックス登録は、実験のアクティブな参加者による使用を確実にするために、定期的に更新する必要があります。登録期間は12ヶ月です。更新により、前のリクエストで登録されたEIDプレフィックスが変更されるべきではない（SHOULD NOT）。登録更新の条件は、最初のEIDプレフィックス登録要求の条件と同じです。
3. It is preferable that EID prefixes whose registrations have expired not be reused. When an EID prefix registration is removed from the registry, then the reuse of the EID prefix in a subsequent registration on behalf of a different end user should be avoided where possible. If the considerations of overall usage of the EID block prefix requires reuse of a previously registered EID prefix, then a minimum delay of at least one week between removal and subsequent registration SHOULD be applied by the registry operator.
3. 登録の有効期限が切れたEIDプレフィックスは再利用しないことが望ましいです。 EIDプレフィックス登録がレジストリから削除された場合、別のエンドユーザーに代わって後続の登録でEIDプレフィックスを再利用することは、可能な限り回避する必要があります。 EIDブロックプレフィックスの全体的な使用を考慮するために、以前に登録されたEIDプレフィックスを再利用する必要がある場合、レジストリオペレーターは、削除とその後の登録の間に少なくとも1週間の遅延を適用する必要があります（SHOULD）。
4. When the reserved experimental LISP EID block expires, all EID prefix registrations expire as well. The further disposition of these prefixes and the associated registry entries are to be specified in the announcement of the cessation of this experiment.
4. 予約済みの実験的LISP EIDブロックが期限切れになると、すべてのEIDプレフィックス登録も期限切れになります。これらの接頭辞とそれに関連するレジストリエントリの詳細については、この実験の中止のアナウンスで指定する必要があります。
All EID prefix registrations MUST satisfy the following requirements:
すべてのEIDプレフィックス登録は、次の要件を満たす必要があります。
1. All EID prefix registrations MUST use a globally unique EID prefix.
1. すべてのEIDプレフィックス登録は、グローバルに一意のEIDプレフィックスを使用する必要があります。
2. The EID prefix registration information, as specified in Section 6, MUST be collected upon initial registration and renewal, and made publicly available through interfaces allowing both the retrieval of specific registration details (search) and the enumeration of the entire registry contents (e.g., RDAP ([RFC7481]), WHOIS, HTTP, or similar access methods).
2. セクション6で指定されたEIDプレフィックス登録情報は、初期登録および更新時に収集されなければならず、特定の登録詳細の検索（検索）とレジストリコンテンツ全体の列挙（例：RDAP）の両方を可能にするインターフェースを通じて公開されなければなりません（[RFC7481]）、WHOIS、HTTP、または同様のアクセス方法）。
3. The registry operator MUST permit the delegation of EID prefixes in the reverse DNS space to holders of registered EID prefixes.
3. レジストリオペレーターは、登録されたEIDプレフィックスの所有者への逆DNS空間でのEIDプレフィックスの委任を許可する必要があります。
4. Anyone can obtain an entry in the EID prefix registry, on the understanding that the prefix so registered is for the exclusive use in the LISP experimental network, and that their registration details (as specified in Section 6) are openly published in the EID prefix registry.
4. 登録されたプレフィックスはLISP実験ネットワークで排他的に使用され、その登録の詳細（セクション6で指定）がEIDプレフィックスレジストリに公開されていることを理解すれば、誰でもEIDプレフィックスレジストリのエントリを取得できます。 。
The following is a basic request template for prefix registration to ensure a uniform process. This template is inspired by IANA's online "Private Enterprise Number (PEN) Request" form <http://pen.iana.org/pen/PenApplication.page>.
以下は、プロセスを統一するためのプレフィックス登録の基本的なリクエストテンプレートです。このテンプレートは、IANAのオンライン「Private Enterprise Number（PEN）Request」フォーム<http://pen.iana.org/pen/PenApplication.page>から発想を得ています。
Note that all details in this registration become part of the registry and will be published in the LISP EID Prefix Registry managed by RIPE NCC.
この登録のすべての詳細はレジストリの一部となり、RIPE NCCが管理するLISP EIDプレフィックスレジストリで公開されることに注意してください。
The EID Prefix Request template MUST at a minimum contain:
EIDプレフィックス要求テンプレートには、少なくとも以下が含まれている必要があります。
1. Organization (In the case of individuals requesting an EID prefix, this section can be left empty)
1. 組織（EIDプレフィックスを要求する個人の場合、このセクションは空のままにすることができます）
(a) Organization Name
（a）組織名
(b) Organization Address (c) Organization Phone
（b）組織のアドレス（c）組織の電話
(d) Organization Website
（d）組織のウェブサイト
2. Contact Person (Mandatory)
2. 担当者（必須）
(a) Name
（名前
(b) Address
（b）住所
(c) Phone
（c）電話
(d) Fax (optional)
（d）ファックス（オプション）
(e) Email
（e）メール
3. EID Prefix Request (Mandatory)
3. EIDプレフィックス要求（必須）
(a) Prefix Size
（a）プレフィックスサイズ
+ Expressed as an address prefix length.
+ アドレスプレフィックス長として表されます。
(b) Prefix Size Rationale
（b）プレフィックスサイズの根拠
(c) Lease Period
（c）リース期間
+ Note well: All EID Prefix registrations will be valid until the earlier date of 12 months from the date of registration or August 2019.
+ 注：EIDプレフィックスの登録はすべて、登録日から12か月前の日付または2019年8月まで有効です。
+ All registrations may be renewed by the applicant for further 12-month periods, ending on August 2019.
+ すべての登録は、2019年8月に終了するさらに12か月間、申請者が更新できます。
+ According to the 3+3 year experimentation plan, defined in [RFC7954], all registrations MUST end by August 2019, unless the IETF community decides to grant a permanent LISP EID address block. In the latter case, registrations following the present document policy MUST end by August 2022 and a new policy (to be decided -- see Section 7) will apply thereafter.
+ [RFC7954]で定義されている3 + 3年の実験計画によれば、IETFコミュニティが永続的なLISP EIDアドレスブロックを許可することを決定しない限り、すべての登録は2019年8月までに終了しなければなりません。後者の場合、現在のドキュメントポリシーに従う登録は2022年8月までに終了しなければならず、新しいポリシー（決定される-セクション7を参照）がその後に適用されます。
4. Experiment Description
4. 実験の説明
(a) Experiment and Deployment Description
（a）実験と展開の説明
(b) Interoperability with Existing LISP Deployments
（b）既存のLISP配置との相互運用性
(c) Interoperability with Legacy Internet
（c）従来のインターネットとの相互運用性
5. Reverse DNS Servers (Optional)
5. リバースDNSサーバー（オプション）
(a) Name Server Name
（a）ネームサーバー名
(b) Name Server Address
（b）ネームサーバーアドレス
(c) Name Server Name
（c）ネームサーバー名
(d) Name Server Address
（d）ネームサーバーアドレス
(Repeat if necessary)
（必要に応じて繰り返します）
The policy outlined in the present document is tied to the existence of the experimental LISP EID block requested in [RFC7954] and is valid until August 2019.
このドキュメントで概説されているポリシーは、[RFC7954]で要求されている実験的なLISP EIDブロックの存在に関連付けられており、2019年8月まで有効です。
If the IETF decides to transform the block into a permanent allocation, the usage period reserved for the LISP EID block will be extended for three years (until August 2022) to allow time for the IETF to define, following the policies outlined in [RFC5226], the final size of the EID block and create a transition plan, while the policy in the present document will still apply.
IETFがブロックを永続的な割り当てに変換することを決定した場合、LISP EIDブロック用に予約された使用期間は、[RFC5226]で概説されているポリシーに従って、IETFが定義する時間を許可するために3年間（2022年8月まで）延長されます。 、EIDブロックの最終的なサイズと移行計画を作成しますが、現在のドキュメントのポリシーは引き続き適用されます。
Note that, as stated in [RFC7954], the transition of the EID block into a permanent allocation has the potential to pose policy issues (as recognized in [RFC2860], Section 4.3); hence, discussion with the IANA, the Regional Internet Registry (RIR) communities, and the IETF community will be necessary to determine the appropriate policy for permanent EID prefix management, which will be effective after August 2022.
[RFC7954]で述べられているように、EIDブロックの永続的な割り当てへの移行は、ポリシーの問題を引き起こす可能性があることに注意してください（[RFC2860]のセクション4.3で認識）。したがって、IANA、Regional Internet Registry（RIR）コミュニティ、およびIETFコミュニティとの話し合いは、2022年8月以降に有効になる永続的なEIDプレフィックス管理の適切なポリシーを決定するために必要になります。
This document does not introduce new security threats in the LISP architecture nor in the Legacy Internet architecture.
このドキュメントでは、LISPアーキテクチャやレガシーインターネットアーキテクチャに新しいセキュリティの脅威を紹介していません。
For accountability reasons and in line with the security considerations in [RFC7020], each registration request MUST contain accurate information about the requesting entity (company, institution, individual, etc.) and valid and accurate contact information of a referral person (see Section 6).
説明責任の理由から、[RFC7020]のセキュリティ上の考慮事項に沿って、各登録要求には、要求元エンティティ（会社、機関、個人など）に関する正確な情報と、紹介者の有効かつ正確な連絡先情報が含まれている必要があります（セクション6を参照） ）。
IANA allocated the following IPv6 address block for experimental use as the LISP EID prefix [RFC7954]:
IANAは、LISP EIDプレフィックス[RFC7954]として実験的に使用するために、次のIPv6アドレスブロックを割り当てました。
o Address Block: 2001:5::/32
o アドレスブロック：2001：5 :: / 32
o Name: EID Space for LISP
o 名前：LISPのEIDスペース
o RFC: [RFC7954]
o RFC：[RFC7954]
o Further details are at: www.iana.org/assignments/iana-ipv6- special-registry
o 詳細については、www.iana.org / assignments / iana-ipv6-special-registryをご覧ください。
To grant requesting organizations and individuals exclusive use of EID prefixes out of this reserved block (limited to the duration of the LISP experiment as outlined in Section 7), there is an operational requirement for an EID registration service.
この予約されたブロック（セクション7で概説されているLISP実験の期間に制限されている）からEIDプレフィックスの排他的使用を要求する組織および個人に許可するには、EID登録サービスの運用要件があります。
Provided that the policies and requirements outlined in Sections 4, 5, and 6 are satisfied, EID prefix registration is accorded based on a "First Come First Served" basis.
セクション4、5、および6で概説されているポリシーと要件が満たされている場合、EIDプレフィックスの登録は「先着順」に基づいて行われます。
There is no hard limit to the number of registrations an organization or individual can submit, as long as the information described in Section 6 is provided, in particular point 4: "Experiment Description".
セクション6で説明されている情報、特にポイント4「実験の説明」が提供されている限り、組織または個人が送信できる登録の数に厳しい制限はありません。
For the duration defined in [RFC7954], RIPE NCC will manage the LISP EID prefix as described herein. Therefore, this document has no IANA actions.
[RFC7954]で定義されている期間中、RIPE NCCは、ここで説明するLISP EIDプレフィックスを管理します。したがって、このドキュメントにはIANAアクションはありません。
RIPE NCC will provide the registration service following the EID Prefix Registration Policy (Section 4) and the EID Prefix Registration Requirements (Section 5) provided in this document. The request form provided by RIPE NCC will include at least the information from the template in Section 6. RIPE NCC will make all received requests publicly available. While this document does not suggest any minimum allocation size; RIPE NCC is allowed to introduce such a minimum size for management purposes.
RIPE NCCは、このドキュメントに記載されているEIDプレフィックス登録ポリシー（セクション4）およびEIDプレフィックス登録要件（セクション5）に従って登録サービスを提供します。 RIPE NCCが提供するリクエストフォームには、少なくともセクション6のテンプレートの情報が含まれます。RIPENCCは、受け取ったすべてのリクエストを公開します。このドキュメントでは、最小割り当てサイズは提案されていませんが、 RIPE NCCは、管理目的でこのような最小サイズを導入できます。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 5226、DOI 10.17487 / RFC5226、2008年5月、<http://www.rfc-editor.org / info / rfc5226>。
[RFC7954] Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block", RFC 7954, DOI 10.17487/RFC7954, September 2016, <http://www.rfc-editor.org/info/rfc7954>.
[RFC7954] Iannone、L.、Lewis、D.、Meyer、D。、およびV. Fuller、「Locator / ID Separation Protocol（LISP）Endpoint Identifier（EID）Block」、RFC 7954、DOI 10.17487 / RFC7954、2016年9月、<http://www.rfc-editor.org/info/rfc7954>。
[INTRO] Cabellos-Aparicio, A. and D. Saucez, "An Architectural Introduction to the Locator/ID Separation Protocol (LISP)", Work in Progress, draft-ietf-lisp-introduction-13, April 2015.
[イントロ] Cabellos-Aparicio、A。およびD. Saucez、「ロケータ/ ID分離プロトコル（LISP）のアーキテクチャの紹介」、作業中、draft-ietf-lisp-introduction-13、2015年4月。
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of Understanding Concerning the Technical Work of the Internet Assigned Numbers Authority", RFC 2860, DOI 10.17487/RFC2860, June 2000, <http://www.rfc-editor.org/info/rfc2860>.
[RFC2860] Carpenter、B.、Baker、F。、およびM. Roberts、「Internet Assigned Numbers Authorityの技術的作業に関する覚書」、RFC 2860、DOI 10.17487 / RFC2860、2000年6月、<http：// www.rfc-editor.org/info/rfc2860>。
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, DOI 10.17487/RFC6830, January 2013, <http://www.rfc-editor.org/info/rfc6830>.
[RFC6830] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「The Locator / ID Separation Protocol（LISP）」、RFC 6830、DOI 10.17487 / RFC6830、2013年1月、<http：/ /www.rfc-editor.org/info/rfc6830>。
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The Locator/ID Separation Protocol (LISP) for Multicast Environments", RFC 6831, DOI 10.17487/RFC6831, January 2013, <http://www.rfc-editor.org/info/rfc6831>.
[RFC6831] Farinacci、D.、Meyer、D.、Zwiebel、J。、およびS. Venaas、「マルチキャスト環境用のロケータ/ ID分離プロトコル（LISP）」、RFC 6831、DOI 10.17487 / RFC6831、2013年1月、< http://www.rfc-editor.org/info/rfc6831>。
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/RFC6832, January 2013, <http://www.rfc-editor.org/info/rfc6832>.
[RFC6832]ルイスD.、マイヤーD.、ファリナッチD.、およびV.フラー「ロケータ/ ID分離プロトコル（LISP）サイトと非LISPサイト間のインターワーキング」、RFC 6832、DOI 10.17487 / RFC6832、1月2013、<http://www.rfc-editor.org/info/rfc6832>。
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, DOI 10.17487/RFC6833, January 2013, <http://www.rfc-editor.org/info/rfc6833>.
[RFC6833] Fuller、V。およびD. Farinacci、「Locator / ID Separation Protocol（LISP）Map-Server Interface」、RFC 6833、DOI 10.17487 / RFC6833、2013年1月、<http://www.rfc-editor.org / info / rfc6833>。
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, DOI 10.17487/RFC6834, January 2013, <http://www.rfc-editor.org/info/rfc6834>.
[RFC6834] Iannone、L.、Saucez、D。、およびO. Bonaventure、「Locator / ID Separation Protocol（LISP）Map-Versioning」、RFC 6834、DOI 10.17487 / RFC6834、2013年1月、<http：// www。 rfc-editor.org/info/rfc6834>。
[RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, DOI 10.17487/RFC6835, January 2013, <http://www.rfc-editor.org/info/rfc6835>.
[RFC6835] Farinacci、D。およびD. Meyer、「The Locator / ID Separation Protocol Internet Groper（LIG）」、RFC 6835、DOI 10.17487 / RFC6835、2013年1月、<http://www.rfc-editor.org/ info / rfc6835>。
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, January 2013, <http://www.rfc-editor.org/info/rfc6836>.
[RFC6836] Fuller、V.、Farinacci、D.、Meyer、D。、およびD. Lewis、「Locator / ID Separation Protocol Alternative Logical Topology（LISP + ALT）」、RFC 6836、DOI 10.17487 / RFC6836、2013年1月、 <http://www.rfc-editor.org/info/rfc6836>。
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database", RFC 6837, DOI 10.17487/RFC6837, January 2013, <http://www.rfc-editor.org/info/rfc6837>.
[RFC6837]リア、E。、「NERD：A Not-so-novel Endpoint ID（EID）to Routing Locator（RLOC）Database」、RFC 6837、DOI 10.17487 / RFC6837、2013年1月、<http：//www.rfc -editor.org/info/rfc6837>。
[RFC7020] Housley, R., Curran, J., Huston, G., and D. Conrad, "The Internet Numbers Registry System", RFC 7020, DOI 10.17487/RFC7020, August 2013, <http://www.rfc-editor.org/info/rfc7020>.
[RFC7020] Housley、R.、Curran、J.、Huston、G。、およびD. Conrad、「The Internet Numbers Registry System」、RFC 7020、DOI 10.17487 / RFC7020、2013年8月、<http：//www.rfc -editor.org/info/rfc7020>。
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, DOI 10.17487/RFC7481, March 2015, <http://www.rfc-editor.org/info/rfc7481>.
[RFC7481] Hollenbeck、S. and N. Kong、 "Security Services for the Registration Data Access Protocol（RDAP）"、RFC 7481、DOI 10.17487 / RFC7481、March 2015、<http://www.rfc-editor.org/ info / rfc7481>。
Acknowledgments
謝辞
Thanks to A. Retana, J. Arkko, P. Yee, A. de la Haye, A. Cima, A. Pawlik, J. Curran, A. Severin, B. Haberman, T. Manderson, D. Lewis, D. Farinacci, M. Binderberger, D. Saucez, E. Lear, for their helpful comments.
A. Retana、J。Arkko、P。Yee、A。de la Haye、A。Cima、A。Pawlik、J。Curran、A。Severin、B。Haberman、T。Manderson、D。Lewis、Dに感謝します。役立つコメントを提供してくれたFarinacci、M。Binderberger、D。Saucez、E。Lear。
The work of Luigi Iannone has been partially supported by the ANR-13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC ICT-Labs SOFNETS Project.
Luigi Iannoneの作業は、ANR-13-INFR-0009 LISP-Labプロジェクト<www.lisp-lab.org>とEIT KIC ICT-Labs SOFNETSプロジェクトによって部分的にサポートされています。
Authors' Addresses
著者のアドレス
Luigi Iannone Telecom ParisTech France
Luigi Iannone Telecom ParisTech France
Email: ggx@gigix.net
Roger Jorgensen Bredbandsfylket Troms Norway
Roger Jorgensen Bredbandsfylket Tromsノルウェー
Email: rogerj@gmail.com
David Conrad Virtualized, LLC United States
David Conrad Virtualized、LLCアメリカ合衆国
Email: drc@virtualized.org
Geoff Huston Asia Pacific Network Information Centre (APNIC) Australia
ジェフヒューストンアジア太平洋ネットワーク情報センター（APNIC）オーストラリア
Email: gih@apnic.net