--- 1/draft-ietf-lisp-eid-block-01.txt 2012-04-24 17:14:02.146671436 +0200 +++ 2/draft-ietf-lisp-eid-block-02.txt 2012-04-24 17:14:02.166673210 +0200 @@ -1,80 +1,80 @@ Network Working Group L. Iannone -Internet-Draft Telekom Innovation Laboratories +Internet-Draft Telecom ParisTech Intended status: Informational D. Lewis -Expires: May 3, 2012 D. Meyer +Expires: October 26, 2012 D. Meyer V. Fuller Cisco Systems, Inc. - October 31, 2011 + April 24, 2012 LISP EID Block - draft-ietf-lisp-eid-block-01.txt + draft-ietf-lisp-eid-block-02.txt Abstract 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 - used by sites deploying LISP as EID (Endpoint IDentifier) addressing - space for local intra-domain routing and global endpoint - identification. + used for local intra-domain routing and global endpoint + identification, by sites deploying LISP as EID (Endpoint IDentifier) + addressing space. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 3, 2012. + This Internet-Draft will expire on October 26, 2012. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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. 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. Table of Contents - 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 + 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 + 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . . 3 4. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5 5. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 6. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 6 - 7. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 6. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . . 6 + 7. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 8 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 8 - 12.2. Informative References . . . . . . . . . . . . . . . . . 9 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 8 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 9 Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 9 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Requirements Notation 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]. 2. Introduction This document directs the IANA to allocate a /16 IPv6 prefix for use @@ -88,21 +88,21 @@ 3. Definition of Terms LISP operates on two name spaces and introduces several new network elements. This section provides high-level definitions of the LISP name spaces and network elements and as such, it MUST NOT be considered as an authoritative source. The reference to the authoritative document for each term is included in every term description. - Legacy Internet: The portion of the Internet which does not run LISP + Legacy Internet: The portion of the Internet that does not run LISP and does not participate in LISP+ALT or any other mapping system. LISP site: A LISP site is a set of routers in an edge network that are under a single technical administration. LISP routers that reside in the edge network are the demarcation points to separate the edge network from the core network. See [I-D.ietf-lisp] for more details. Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for IPv6) value used in the source and destination address fields of @@ -115,21 +115,21 @@ prefix block associated with the site where the host is located. See [I-D.ietf-lisp] for more details. EID-prefix: A power-of-two block of EIDs that are allocated to a site by an address allocation authority. See [I-D.ietf-lisp] for more details. EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable in the [RFC4632] sense. That is, an EID-Prefix aggregate is defined to be a single contiguous power-of-two EID-prefix block. - Such a block is characterized by a prefix and a length. See + A prefix and a length characterize such a block. See [I-D.ietf-lisp] for more details. Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an egress tunnel router (ETR). A RLOC is the output of an EID-to- RLOC mapping lookup. An EID maps to one or more RLOCs. Typically, RLOCs are numbered from topologically aggregatable blocks that are assigned to a site at each point to which it attaches to the global Internet; where the topology is defined by the connectivity of provider networks, RLOCs can be thought of as Provider Aggregatable (PA) addresses. See [I-D.ietf-lisp] for @@ -139,21 +139,21 @@ set that can be used to reach the EID-Prefix. The general term "mapping" always refers to an EID-to-RLOC mapping. See [I-D.ietf-lisp] for more details. Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a router that accepts receives IP packets from site end-systems on one side and sends LISP-encapsulated IP packets toward the Internet on the other side. The router treats the "inner" IP destination address as an EID and performs an EID-to-RLOC mapping lookup. The router then prepends an "outer" IP header with one of - its globally-routable RLOCs in the source address field and the + its globally routable RLOCs in the source address field and the result of the mapping lookup in the destination address field. See [I-D.ietf-lisp] for more details. Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives LISP-encapsulated IP packets from the Internet on one side and sends decapsulated IP packets to site end-systems on the other side. An ETR router accepts an IP packet where the destination address in the "outer" IP header is one of its own RLOCs. The router strips the "outer" header and forwards the packet based on the next IP header found. See [I-D.ietf-lisp] for more details. @@ -215,52 +215,48 @@ dropped. By defining an IPv6 EID Block is possible to configure the router so to natively forward all packets that have not a destination address in the block, without performing any lookup whatsoever. This will give a tighter control over the traffic in the initial experimental phase, while facilitating its large-scale deployment. The EID Block will be used only at configuration level, it is RECOMMENDED not to hard-code in any way the IPv6 EID Block in the - router hardware. This allows to avoid locking out sites that may + router hardware. This allows avoiding locking out sites that may want to switch to LISP while keeping their own IPv6 prefix, which is not in the IPv6 EID Block. 5. Expected use Sites planning to deploy LISP may request a prefix in the IPv6 EID Block. Such prefix will be used for routing and endpoint identification inside the site requesting it. Mappings related to 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). Too guarantee reachability from the Legacy Internet the prefix could be announced in the BGP routing infrastructure by one or more PITR(s), possibly as part of a larger prefix, aggregating several prefixes of several sites. 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: + future use as EID 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 + o A /16 prefix is sufficiently large to cover initial allocation and + requests for prefixes 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. + accommodate growth in the near future. 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 the IPv6 addressing space for use as EID in LISP (Locator/ID @@ -300,77 +296,82 @@ between the Legacy Internet and LISP sites or even break local intra- domain connectivity. 9. Security Considerations This document does not introduce new security threats in the LISP architecture nor in the Legacy Internet architecture. 10. Acknowledgments - Special thanks to Roque Gagliano for his suggestions and pointers to - the IANA allocation policies. Thanks to Marla Azinger, Chris Morrow, - and Peter Schoenmaker, all made insightful comments on early versions - of this draft. + Special thanks to Roque Gagliano for his suggestions and pointers. + Thanks to Marla Azinger, Chris Morrow, and Peter Schoenmaker, all + made insightful comments on early versions of this draft. 11. IANA Considerations This document instructs the IANA to assign a /16 IPv6 prefix for use - as the global LISP EID space using an hierarchical allocation as - outlined in [RFC2434]. During the discussion related to this + as the global LISP EID space using a hierarchical allocation as + outlined in [RFC5226]. During the discussion related to this document, the LISP Working Group agreed in suggesting to IANA to 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 [RFC5226], such space will be assigned only upon IETF Consensus. This document does not specify any specific value for the requested address block. 12. References 12.1. Normative References [I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", - draft-ietf-lisp-15 (work in progress), July 2011. + draft-ietf-lisp-22 (work in progress), February 2012. [I-D.ietf-lisp-alt] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP - Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06 - (work in progress), March 2011. + Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10 + (work in progress), December 2011. [I-D.ietf-lisp-interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", - draft-ietf-lisp-interworking-02 (work in progress), - June 2011. + draft-ietf-lisp-interworking-06 (work in progress), + March 2012. [I-D.ietf-lisp-ms] Fuller, V. and D. Farinacci, "LISP Map Server Interface", - draft-ietf-lisp-ms-12 (work in progress), October 2011. + draft-ietf-lisp-ms-16 (work in progress), March 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + 12.2. Informative References [BETA] LISP Beta Network, "http://www.lisp4.net", 2008-2011. Appendix A. Document Change Log + Version 02 Posted April 2012. + + o Fixed typos, nits, references. + + o Deleted reference to IANA allocation policies. + Version 01 Posted October 2011. o Added Section 6. Version 00 Posted July 2011. o Updated section "IANA Considerations" o Added section "Rationale and Intent" explaining why the EID block allocation is useful. @@ -385,23 +386,23 @@ o Added section "Routing Consideration" describing how routers not running LISP deal with the requested address block. o Added the present section to keep track of changes. o Rename of draft-meyer-lisp-eid-block-02.txt. Authors' Addresses Luigi Iannone - Telekom Innovation Laboratories + Telecom ParisTech - Email: luigi@net.t-labs.tu-berlin.de + Email: ggx@gigix.net Darrel Lewis Cisco Systems, Inc. Email: darlewis@cisco.com David Meyer Cisco Systems, Inc. Email: dmm@cisco.com