draft-ietf-lisp-eid-block-00.txt   draft-ietf-lisp-eid-block-01.txt 
Network Working Group L. Iannone Network Working Group L. Iannone
Internet-Draft Deutsche Telekom Laboratories Internet-Draft Telekom Innovation Laboratories
Intended status: Informational D. Lewis Intended status: Informational D. Lewis
Expires: January 3, 2012 D. Meyer Expires: May 3, 2012 D. Meyer
V. Fuller V. Fuller
Cisco Systems, Inc. Cisco Systems, Inc.
July 2, 2011 October 31, 2011
LISP EID Block LISP EID Block
draft-ietf-lisp-eid-block-00.txt draft-ietf-lisp-eid-block-01.txt
Abstract Abstract
This is a direction to IANA to allocate a /16 IPv6 prefix for use This is a direction to IANA to allocate a /16 IPv6 prefix for use
with the Locator/ID Separation Protocol (LISP). The prefix will be with the Locator/ID Separation Protocol (LISP). The prefix will be
used by sites deploying LISP as EID (Endpoint IDentifier) addressing used by sites deploying LISP as EID (Endpoint IDentifier) addressing
space for local intra-domain routing and global endpoint space for local intra-domain routing and global endpoint
identification. identification.
Status of this Memo Status of this Memo
skipping to change at page 1, line 37 skipping to change at page 1, line 37
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 3, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(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. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . . 3 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
4. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5 4. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5
5. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 6
7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
11. Normative References . . . . . . . . . . . . . . . . . . . . . 8 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 12.1. Normative References . . . . . . . . . . . . . . . . . . 8
12.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document directs the IANA to allocate a /16 IPv6 prefix for use This document directs the IANA to allocate a /16 IPv6 prefix for use
skipping to change at page 6, line 33 skipping to change at page 6, line 33
Sites planning to deploy LISP may request a prefix in the IPv6 EID Sites planning to deploy LISP may request a prefix in the IPv6 EID
Block. Such prefix will be used for routing and endpoint Block. Such prefix will be used for routing and endpoint
identification inside the site requesting it. Mappings related to identification inside the site requesting it. Mappings related to
such prefix, or part of it, will be made available through the such prefix, or part of it, will be made available through the
mapping system in use or registered to one or more Map-Server(s). mapping system in use or registered to one or more Map-Server(s).
Too guarantee reachability from the Legacy Internet the prefix could Too guarantee reachability from the Legacy Internet the prefix could
be announced in the BGP routing infrastructure by one or more be announced in the BGP routing infrastructure by one or more
PITR(s), possibly as part of a larger prefix, aggregating several PITR(s), possibly as part of a larger prefix, aggregating several
prefixes of several sites. prefixes of several sites.
6. Action Plan 6. Block Dimension
The working group reached consensus on an initial allocation of a /16
prefix out of a /12 block which is asked to remain reserved for
future use as EID b space. The reason of such consensus is manifold:
o A /16 prefix is suffiently large to cover initial allocation and
requests for prefoxes in the EID space in the next few years for
very large scale experimentation and deployment. As a comparison
is worth to mention that the current LISP Beta Network ([BETA]) is
using a /32 prefix, hence a /16 should be sufficiently large to
accomodate growth in the near future.
o The request to reserve the /12 prefix covering the initial /16
allocation is in line with IANA policies that fix to /12 the
minimum IPv6 allocation.
o The proposed alignment provides as well a natural support for DNS.
In particular, reverse DNS for IPv6 in the special ip6.arpa domain
is represented as sequence of nibbles. A different alignment
would force to a binary representation.
7. Action Plan
This document requests IANA to initially allocate a /16 prefix out of This document requests IANA to initially allocate a /16 prefix out of
the IPv6 addressing space for use as EID in LISP (Locator/ID the IPv6 addressing space for use as EID in LISP (Locator/ID
Separation protocol). It is suggested to IANA to temporarily avoid Separation protocol). It is suggested to IANA to temporarily avoid
allocating any other address block the same /12 prefix the EID /16 allocating any other address block the same /12 prefix the EID /16
prefix belongs to. This is to accommodate future requests of EID prefix belongs to. This is to accommodate future requests of EID
space without fragmenting the EID addressing space. This will also space without fragmenting the EID addressing space. This will also
help from an operational point of view, since it will be sufficient help from an operational point of view, since it will be sufficient
to change the subnet mask length in existing deployments. to change the subnet mask length in existing deployments.
If in the future there will be need for a larger EID Block the If in the future there will be need for a larger EID Block the
address space adjacent the EID Block could be allocate by IANA address space adjacent the EID Block could be allocate by IANA
according to the current policies. according to the current policies.
7. Routing Considerations 8. Routing Considerations
In order to provide connectivity between the Legacy Internet and LISP In order to provide connectivity between the Legacy Internet and LISP
sites, PITRs announcing large aggregates of the IPv6 EID Block could sites, PITRs announcing large aggregates of the IPv6 EID Block could
be deployed. By doing so, PITRs will attract traffic destined to be deployed. By doing so, PITRs will attract traffic destined to
LISP sites in order to encapsulate and forward it toward the specific LISP sites in order to encapsulate and forward it toward the specific
destination LISP site. Routers in the Legacy Internet MUST treat destination LISP site. Routers in the Legacy Internet MUST treat
announcements of prefixes from the IPv6 EID Block as normal announcements of prefixes from the IPv6 EID Block as normal
announcements, applying best current practice for traffic engineering announcements, applying best current practice for traffic engineering
and security. and security.
skipping to change at page 7, line 30 skipping to change at page 8, line 5
addresses in the IPv6 EID Block. addresses in the IPv6 EID Block.
For the above-mentioned reasons, routers that do not run any LISP For the above-mentioned reasons, routers that do not run any LISP
element, MUST NOT include any special handling code or hardware for element, MUST NOT include any special handling code or hardware for
addresses in the IPv6 EID Block. In particular, it is RECOMMENDED addresses in the IPv6 EID Block. In particular, it is RECOMMENDED
that the default router configuration does not handle such addresses that the default router configuration does not handle such addresses
in any special way. Doing differently could prevent communication in any special way. Doing differently could prevent communication
between the Legacy Internet and LISP sites or even break local intra- between the Legacy Internet and LISP sites or even break local intra-
domain connectivity. domain connectivity.
8. Security Considerations 9. Security Considerations
This document does not introduce new security threats in the LISP This document does not introduce new security threats in the LISP
architecture nor in the Legacy Internet architecture. architecture nor in the Legacy Internet architecture.
9. Acknowledgments 10. Acknowledgments
Marla Azinger, Chris Morrow, Peter Schoenmaker all made insightful Special thanks to Roque Gagliano for his suggestions and pointers to
comments on early versions of this draft. the IANA allocation policies. Thanks to Marla Azinger, Chris Morrow,
and Peter Schoenmaker, all made insightful comments on early versions
of this draft.
10. IANA Considerations 11. IANA Considerations
This document instructs the IANA to assign a /16 IPv6 prefix for use This document instructs the IANA to assign a /16 IPv6 prefix for use
as the global LISP EID space using an hierarchical allocation as as the global LISP EID space using an hierarchical allocation as
outlined in [RFC2434]. During the discussion related to this outlined in [RFC2434]. During the discussion related to this
document, the LISP Working Group agreed in suggesting to IANA to document, the LISP Working Group agreed in suggesting to IANA to
reserve adjacent addressing space for future use as EID space if reserve adjacent addressing space for future use as EID space if
needs come. Following the policies outlined in [RFC2434], such space needs come. Following the policies outlined in [RFC2434], such space
will be assigned only upon IETF Consensus. This document does not will be assigned only upon IETF Consensus. This document does not
specify any specific value for the requested address block. specify any specific value for the requested address block.
11. Normative References 12. References
12.1. Normative References
[I-D.ietf-lisp] [I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-14 (work in progress), June 2011. draft-ietf-lisp-15 (work in progress), July 2011.
[I-D.ietf-lisp-alt] [I-D.ietf-lisp-alt]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06
(work in progress), June 2011. (work in progress), March 2011.
[I-D.ietf-lisp-interworking] [I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", "Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-02 (work in progress), draft-ietf-lisp-interworking-02 (work in progress),
June 2011. June 2011.
[I-D.ietf-lisp-ms] [I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server", Fuller, V. and D. Farinacci, "LISP Map Server Interface",
draft-ietf-lisp-ms-09 (work in progress), June 2011. draft-ietf-lisp-ms-12 (work in progress), October 2011.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
12.2. Informative References
[BETA] LISP Beta Network, "http://www.lisp4.net", 2008-2011.
Appendix A. Document Change Log Appendix A. Document Change Log
Version 01 Posted October 2011.
o Added Section 6.
Version 00 Posted July 2011. Version 00 Posted July 2011.
o Updated section "IANA Considerations" o Updated section "IANA Considerations"
o Added section "Rationale and Intent" explaining why the EID block o Added section "Rationale and Intent" explaining why the EID block
allocation is useful. allocation is useful.
o Added section "Expected Use" explaining how sites can request and o Added section "Expected Use" explaining how sites can request and
use a prefix in the IPv6 EID Block. use a prefix in the IPv6 EID Block.
skipping to change at page 9, line 16 skipping to change at page 10, line 8
o Added section "Routing Consideration" describing how routers not o Added section "Routing Consideration" describing how routers not
running LISP deal with the requested address block. running LISP deal with the requested address block.
o Added the present section to keep track of changes. o Added the present section to keep track of changes.
o Rename of draft-meyer-lisp-eid-block-02.txt. o Rename of draft-meyer-lisp-eid-block-02.txt.
Authors' Addresses Authors' Addresses
Luigi Iannone Luigi Iannone
Deutsche Telekom Laboratories Telekom Innovation Laboratories
Email: luigi@net.t-labs.tu-berlin.de Email: luigi@net.t-labs.tu-berlin.de
Darrel Lewis Darrel Lewis
Cisco Systems, Inc. Cisco Systems, Inc.
Email: darlewis@cisco.com Email: darlewis@cisco.com
David Meyer David Meyer
Cisco Systems, Inc. Cisco Systems, Inc.
 End of changes. 19 change blocks. 
32 lines changed or deleted 69 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/