NERD: A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database
RFC 6837
| Document | Type |
RFC - Experimental
(January 2013; No errata)
Was draft-lear-lisp-nerd (int)
|
|
|---|---|---|---|
| Author | Eliot Lear | ||
| Last updated | 2015-10-14 | ||
| Stream | Independent Submission | ||
| Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
| Stream | ISE state | (None) | |
| Consensus Boilerplate | Unknown | ||
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 6837 (Experimental) | |
| Action Holders |
(None)
|
||
| Telechat date | |||
| Responsible AD | Brian Haberman | ||
| Send notices to | rfc-ise@rfc-editor.org | ||
Independent Submission E. Lear
Request for Comments: 6837 Cisco Systems GmbH
Category: Experimental January 2013
ISSN: 2070-1721
NERD:
A Not-so-novel Endpoint ID (EID) to Routing Locator (RLOC) Database
Abstract
The Locator/ID Separation Protocol (LISP) is a protocol to
encapsulate IP packets in order to allow end sites to route to one
another without injecting routes from one end of the Internet to
another. This memo presents an experimental database and a
discussion of methods to transport the mapping of Endpoint IDs (EIDs)
to Routing Locators (RLOCs) to routers in a reliable, scalable, and
secure manner. Our analysis concludes that transport of all EID-to-
RLOC mappings scales well to at least 10^8 entries.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This is a contribution to the RFC Series, independently
of any other RFC stream. The RFC Editor has chosen to publish this
document at its discretion and makes no statement about its value for
implementation or deployment. Documents approved for publication by
the RFC Editor are not a candidate for any level of Internet
Standard; see Section 2 of RFC 5741.
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/rfc6837.
Lear Experimental [Page 1]
RFC 6837 NERD LISP EID Mapping Transport January 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Lear Experimental [Page 2]
RFC 6837 NERD LISP EID Mapping Transport January 2013
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Base Assumptions . . . . . . . . . . . . . . . . . . . . . 4
1.3. What is NERD? . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Theory of Operation . . . . . . . . . . . . . . . . . . . . . 7
2.1. Database Updates . . . . . . . . . . . . . . . . . . . . . 7
2.2. Communications between ITR and ETR . . . . . . . . . . . . 8
2.3. Who are database authorities? . . . . . . . . . . . . . . 8
3. NERD Format . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. NERD Record Format . . . . . . . . . . . . . . . . . . . . 11
3.2. Database Update Format . . . . . . . . . . . . . . . . . . 12
4. NERD Distribution Mechanism . . . . . . . . . . . . . . . . . 12
4.1. Initial Bootstrap . . . . . . . . . . . . . . . . . . . . 12
4.2. Retrieving Changes . . . . . . . . . . . . . . . . . . . . 12
5. Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Database Size . . . . . . . . . . . . . . . . . . . . . . 14
5.2. Router Throughput versus Time . . . . . . . . . . . . . . 16
5.3. Number of Servers Required . . . . . . . . . . . . . . . . 16
5.4. Security Considerations . . . . . . . . . . . . . . . . . 18
5.4.1. Use of Public Key Infrastructures (PKIs) . . . . . . . 19
5.4.2. Other Risks . . . . . . . . . . . . . . . . . . . . . 21
6. Why not use XML? . . . . . . . . . . . . . . . . . . . . . . . 21
7. Other Distribution Mechanisms . . . . . . . . . . . . . . . . 22
7.1. What about DNS as a mapping retrieval model? . . . . . . . 22
7.2. Use of BGP and LISP+ALT . . . . . . . . . . . . . . . . . 24
7.3. Perhaps use a hybrid model? . . . . . . . . . . . . . . . 24
8. Deployment Issues . . . . . . . . . . . . . . . . . . . . . . 24
8.1. HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
9. Open Questions . . . . . . . . . . . . . . . . . . . . . . . . 25
10. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
Show full document text