rfc7954v2.txt   rfc7954.txt 
Internet Engineering Task Force (IETF) L. Iannone Internet Engineering Task Force (IETF) L. Iannone
Request for Comments: 7954 Telecom ParisTech Request for Comments: 7954 Telecom ParisTech
Category: Experimental D. Lewis Category: Experimental D. Lewis
ISSN: 2070-1721 Cisco Systems, Inc. ISSN: 2070-1721 Cisco Systems, Inc.
D. Meyer D. Meyer
Brocade Brocade
V. Fuller V. Fuller
August 2016 September 2016
Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block Locator/ID Separation Protocol (LISP) Endpoint Identifier (EID) Block
Abstract Abstract
This document directs IANA to allocate a /32 IPv6 prefix for use with This document directs IANA to allocate a /32 IPv6 prefix for use with
the Locator/ID Separation Protocol (LISP). The prefix will be used the Locator/ID Separation Protocol (LISP). The prefix will be used
for local intra-domain routing and global endpoint identification, by for local intra-domain routing and global endpoint identification, by
sites deploying LISP as Endpoint Identifier (EID) addressing space. sites deploying LISP as Endpoint Identifier (EID) addressing space.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
This document is not an Internet Standards Track specification; it is This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and published for examination, experimental implementation, and
evaluation. evaluation.
This document defines an Experimental Protocol for the Internet This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741. Internet Standard; see Section 2 of RFC 7841.
Information about the current status of this document, any errata, Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7954. http://www.rfc-editor.org/info/rfc7954.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
skipping to change at page 2, line 10 skipping to change at page 2, line 22
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 2 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . 2 3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . 3
4. Expected Use . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Expected Use . . . . . . . . . . . . . . . . . . . . . . . . 5
5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 5 5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 5
6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 5 6. 3+3 Allocation Plan . . . . . . . . . . . . . . . . . . . . . 6
7. Allocation Lifetime . . . . . . . . . . . . . . . . . . . . . 6 7. Allocation Lifetime . . . . . . . . . . . . . . . . . . . . . 7
8. Routing Considerations . . . . . . . . . . . . . . . . . . . 6 8. Routing Considerations . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document directs the IANA to allocate a /32 IPv6 prefix for use This document directs the IANA to allocate a /32 IPv6 prefix for use
with the Locator/ID Separation Protocol (LISP [RFC6830]), LISP Map- with the Locator/ID Separation Protocol (LISP [RFC6830]), LISP Map-
Server ([RFC6833]), LISP Alternative Topology (LISP+ALT [RFC6836]) Server ([RFC6833]), LISP Alternative Topology (LISP+ALT [RFC6836])
(or other) mapping systems, and LISP Interworking ([RFC6832]). (or other) mapping systems, and LISP Interworking ([RFC6832]).
This block will be used as global Endpoint Identifier (EID) space. This block will be used as global Endpoint Identifier (EID) space.
skipping to change at page 5, line 41 skipping to change at page 6, line 24
but may as well boost LISP experimentation and deployment. but may as well boost LISP experimentation and deployment.
o The use of a /32 prefix is in line with previous similar prefix o The use of a /32 prefix is in line with previous similar prefix
allocation for tunneling protocols ([RFC3056]). allocation for tunneling protocols ([RFC3056]).
6. 3+3 Allocation Plan 6. 3+3 Allocation Plan
Per this document, IANA has initially assigned a /32 prefix out of Per this document, IANA has initially assigned a /32 prefix out of
the IPv6 addressing space for use as EID in LISP. the IPv6 addressing space for use as EID in LISP.
IANA allocated the requested address space in August 2016 for a IANA allocated the requested address space in September 2016 for a
duration of 3 (three) years (through August 2019), with an option to duration of 3 (three) years (through September 2019), with an option
extend this period by 3 (three) more years (until August 2022). By to extend this period by 3 (three) more years (until September 2022).
the end of the first period, the IETF will provide a decision on By the end of the first period, the IETF will provide a decision on
whether to transform the prefix into a permanent assignment or to put whether to transform the prefix into a permanent assignment or to put
it back in the free pool (see Section 7 for more information). it back in the free pool (see Section 7 for more information).
In the first case, i.e., if the IETF decides to transform the block In the first case, i.e., if the IETF decides to transform the block
into a permanent allocation, the EID block allocation period will be into a permanent allocation, the EID block allocation period will be
extended for three years (until August 2022) to give the IETF time to extended for three years (until September 2022) to give the IETF time
define the final size of the EID block and create a transition plan. to define the final size of the EID block and create a transition
plan. The transition of the EID block into a permanent allocation
The transition of the EID block into a permanent allocation might might pose policy issues (as recognized in [RFC2860], Section 4.3);
pose policy issues (as recognized in [RFC2860], Section 4.3);
therefore, discussion with the IANA, the RIR communities, and the therefore, discussion with the IANA, the RIR communities, and the
IETF community will be necessary to determine the appropriate policy IETF community will be necessary to determine the appropriate policy
for permanent EID-block allocation and management. Note as well that for permanent EID-block allocation and management. Note as well that
the final permanent allocation may differ from the initial the final permanent allocation may differ from the initial
experimental assignment; hence, it is recommended not to hard-code experimental assignment; hence, it is recommended not to hard-code
the experimental EID block on LISP-capable devices in any way. the experimental EID block on LISP-capable devices in any way.
In the latter case, i.e., if the IETF decides to terminate the In the latter case, i.e., if the IETF decides to terminate the
experimental-use EID block, all temporary prefix allocations in this experimental-use EID block, all temporary prefix allocations in this
address range must expire and be released by August 2019, so that the address range must expire and be released by September 2019, so that
entire /32 is returned to the free pool. the entire /32 is returned to the free pool.
The allocation and management of the EID block for the initial 3-year The allocation and management of the EID block for the initial 3-year
period (and the optional 3 more years) is detailed in [RFC7955]. period (and the optional 3 more years) is detailed in [RFC7955].
7. Allocation Lifetime 7. Allocation Lifetime
If no explicit action is carried out by the end of the experiment (by If no explicit action is carried out by the end of the experiment (by
August 2019), it is automatically considered that there was not September 2019), it is automatically considered that there was not
sufficient interest in having a permanent allocation; therefore, the sufficient interest in having a permanent allocation; therefore, the
address block will be returned to the free pool. address block will be returned to the free pool.
Otherwise, if the LISP working group recognizes that there is value Otherwise, if the LISP working group recognizes that there is value
in having a permanent allocation, then explicit action is needed. in having a permanent allocation, then explicit action is needed.
In order to trigger the process for a permanent allocation, a In order to trigger the process for a permanent allocation, a
document is required. Such a document has to articulate the document is required. Such a document has to articulate the
rationale for why a permanent allocation would be beneficial. More rationale for why a permanent allocation would be beneficial. More
specifically, the document has to detail the experience gained during specifically, the document has to detail the experience gained during
skipping to change at page 8, line 12 skipping to change at page 8, line 28
[RFC6491]), because the global EID space is be used for routing [RFC6491]), because the global EID space is be used for routing
purposes. purposes.
+----------------------+--------------------+ +----------------------+--------------------+
| Attribute | Value | | Attribute | Value |
+----------------------+--------------------+ +----------------------+--------------------+
| Address Block | 2001:5::/32 | | Address Block | 2001:5::/32 |
| Name | EID Space for LISP | | Name | EID Space for LISP |
| RFC | RFC 7954 | | RFC | RFC 7954 |
| Allocation Date | 2015 | | Allocation Date | 2015 |
| Termination Date | August 2019 [1] | | Termination Date | September 2019 [1] |
| Source | True [2] | | Source | True [2] |
| Destination | True | | Destination | True |
| Forwardable | True | | Forwardable | True |
| Global | True | | Global | True |
| Reserved-by-protocol | True [3] | | Reserved-by-protocol | True [3] |
+----------------------+--------------------+ +----------------------+--------------------+
[1] According to the 3+3 Plan outlined in this document, the [1] According to the 3+3 Plan outlined in this document, the
termination date can be postponed to August 2022. [2] Can be used as termination date can be postponed to September 2022.
a multicast source as well. [3] To be used as EID space by routers [2] Can be used as a multicast source as well.
enabled by LISP [RFC6830]. [3] To be used as EID space by routers enabled by LISP [RFC6830].
Table 1: Global EID Space Table 1: Global EID Space
The reserved address space is requested for an initial 3-year period The reserved address space is requested for an initial 3-year period
starting in August 2016 (until August 2019), with an option to extend starting in September 2016 (until September 2019), with an option to
it by three years (until August 2022) upon the decision of the IETF extend it by three years (until September 2022) upon the decision of
(see Sections 6 and 7). Following the policies outlined in the IETF (see Sections 6 and 7). Following the policies outlined in
[RFC5226], upon IETF Review, the decision should be made on whether [RFC5226], upon IETF Review, the decision should be made on whether
to have a permanent EID block assignment by August 2019. If no to have a permanent EID block assignment by September 2019. If no
explicit action is taken or, if the IETF Review outcome is that it is explicit action is taken or, if the IETF Review outcome is that it is
not worth having a reserved prefix as a global EID space, the whole not worth having a reserved prefix as a global EID space, the whole
/32 will be taken out from the "IANA IPv6 Special-Purpose Address /32 will be taken out from the "IANA IPv6 Special-Purpose Address
Registry" and put back in the free pool managed by IANA. Registry" and put back in the free pool managed by IANA.
Allocation and management of the global EID space is detailed in Allocation and management of the global EID space is detailed in
[RFC7955]. Nevertheless, all prefix allocations out of this space [RFC7955]. Nevertheless, all prefix allocations out of this space
must be temporary and no allocation must go beyond August 2019 unless must be temporary and no allocation must go beyond September 2019
the IETF Review decides for a permanent global EID space assignment. unless the IETF Review decides for a permanent global EID space
assignment.
11. References 11. References
11.1. Normative References 11.1. Normative References
[RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of
Understanding Concerning the Technical Work of the Understanding Concerning the Technical Work of the
Internet Assigned Numbers Authority", RFC 2860, Internet Assigned Numbers Authority", RFC 2860,
DOI 10.17487/RFC2860, June 2000, DOI 10.17487/RFC2860, June 2000,
<http://www.rfc-editor.org/info/rfc2860>. <http://www.rfc-editor.org/info/rfc2860>.
skipping to change at page 10, line 13 skipping to change at page 10, line 28
January 2013, <http://www.rfc-editor.org/info/rfc6836>. January 2013, <http://www.rfc-editor.org/info/rfc6836>.
[RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to [RFC6837] Lear, E., "NERD: A Not-so-novel Endpoint ID (EID) to
Routing Locator (RLOC) Database", RFC 6837, Routing Locator (RLOC) Database", RFC 6837,
DOI 10.17487/RFC6837, January 2013, DOI 10.17487/RFC6837, January 2013,
<http://www.rfc-editor.org/info/rfc6837>. <http://www.rfc-editor.org/info/rfc6837>.
[RFC7955] Iannone, L., Jorgensen, R., Conrad, D., and G. Huston, [RFC7955] Iannone, L., Jorgensen, R., Conrad, D., and G. Huston,
"Locator/ID Separation Protocol (LISP) Endpoint Identifier "Locator/ID Separation Protocol (LISP) Endpoint Identifier
(EID) Block Management Guidelines", RFC 7955, (EID) Block Management Guidelines", RFC 7955,
DOI 10.17487/RFC7955, August 2016, DOI 10.17487/RFC7955, September 2016,
<http://www.rfc-editor.org/info/rfc7955>. <http://www.rfc-editor.org/info/rfc7955>.
11.2. Informative References 11.2. Informative References
[BETA] LISP Beta Network, "Locator/ID Separation Protocol", [BETA] LISP Beta Network, "Locator/ID Separation Protocol",
<http://www.lisp4.net>. <http://www.lisp4.net>.
[FIABook2010] [FIABook2010]
Iannone, L. and T. Leva, "Modeling the economics of Loc/ID Iannone, L. and T. Leva, "Modeling the economics of Loc/ID
Separation for the Future Internet", Towards the Future Separation for the Future Internet", Towards the Future
skipping to change at page 11, line 22 skipping to change at page 11, line 39
Special thanks to Roque Gagliano for his suggestions and pointers. Special thanks to Roque Gagliano for his suggestions and pointers.
Thanks to Alvaro Retana, Deborah Brungard, Ron Bonica, Damien Saucez, Thanks to Alvaro Retana, Deborah Brungard, Ron Bonica, Damien Saucez,
David Conrad, Scott Bradner, John Curran, Paul Wilson, Geoff Huston, David Conrad, Scott Bradner, John Curran, Paul Wilson, Geoff Huston,
Wes George, Arturo Servin, Sander Steffann, Brian Carpenter, Roger Wes George, Arturo Servin, Sander Steffann, Brian Carpenter, Roger
Jorgensen, Terry Manderson, Brian Haberman, Adrian Farrel, Job Jorgensen, Terry Manderson, Brian Haberman, Adrian Farrel, Job
Snijders, Marla Azinger, Chris Morrow, and Peter Schoenmaker for Snijders, Marla Azinger, Chris Morrow, and Peter Schoenmaker for
their insightful comments. Thanks as well to all participants for their insightful comments. Thanks as well to all participants for
the fruitful discussions on the IETF mailing list. the fruitful discussions on the IETF mailing list.
The work of Luigi Iannone has been partially supported by the ANR- The work of Luigi Iannone has been partially supported by the
13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC ICT- ANR-13-INFR-0009 LISP-Lab Project <www.lisp-lab.org> and the EIT KIC
Labs SOFNETS Project. ICT-Labs SOFNETS Project.
Authors' Addresses Authors' Addresses
Luigi Iannone Luigi Iannone
Telecom ParisTech Telecom ParisTech
Email: ggx@gigix.net Email: ggx@gigix.net
Darrel Lewis Darrel Lewis
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 17 change blocks. 
42 lines changed or deleted 42 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/