draft-ietf-lisp-eid-block-03.txt | draft-ietf-lisp-eid-block-04.txt | |||
---|---|---|---|---|
Network Working Group L. Iannone | Network Working Group L. Iannone | |||
Internet-Draft Telecom ParisTech | Internet-Draft Telecom ParisTech | |||
Intended status: Informational D. Lewis | Intended status: Informational D. Lewis | |||
Expires: May 11, 2013 Cisco Systems, Inc. | Expires: August 29, 2013 Cisco Systems, Inc. | |||
D. Meyer | D. Meyer | |||
Brocade | Brocade | |||
V. Fuller | V. Fuller | |||
Cisco Systems, Inc. | February 25, 2013 | |||
November 7, 2012 | ||||
LISP EID Block | LISP EID Block | |||
draft-ietf-lisp-eid-block-03.txt | draft-ietf-lisp-eid-block-04.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 for local intra-domain routing and global endpoint | used for local intra-domain routing and global endpoint | |||
identification, by sites deploying LISP as EID (Endpoint IDentifier) | identification, by sites deploying LISP as EID (Endpoint IDentifier) | |||
addressing space. | addressing space. | |||
Status of this Memo | Status of this Memo | |||
skipping to change at page 1, line 39 | skipping to change at page 1, line 38 | |||
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 May 11, 2013. | This Internet-Draft will expire on August 29, 2013. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2012 IETF Trust and the persons identified as the | Copyright (c) 2013 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 | 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 | |||
3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5 | 3. Rationale and Intent . . . . . . . . . . . . . . . . . . . . . 5 | |||
4. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Expected use . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 6 | 5. Block Dimension . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
6. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6. Action Plan . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 7 | 7. Routing Considerations . . . . . . . . . . . . . . . . . . . . 8 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 | |||
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 | 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 | |||
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 11 | |||
11.2. Informative References . . . . . . . . . . . . . . . . . 9 | 11.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 9 | Appendix A. Document Change Log . . . . . . . . . . . . . . . . . 12 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
1. Introduction | 1. 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 | |||
with the Locator/ID Separation Protocol (LISP - [I-D.ietf-lisp]), | with the Locator/ID Separation Protocol (LISP - [RFC6830]), LISP Map | |||
LISP Map Server ([I-D.ietf-lisp-ms]), LISP Alternative Topology | Server ([RFC6833]), LISP Alternative Topology (LISP+ALT - [RFC6836]) | |||
(LISP+ALT - [I-D.ietf-lisp-alt]) (or other) mapping system, and LISP | (or other) mapping system, and LISP Interworking ([RFC6832]). | |||
Interworking ([I-D.ietf-lisp-interworking]). | ||||
This block will be used as global Endpoint IDentifier (EID) space | This block will be used as global Endpoint IDentifier (EID) space | |||
(Section 2). | (Section 2). | |||
2. Definition of Terms | 2. Definition of Terms | |||
LISP operates on two name spaces and introduces several new network | LISP operates on two name spaces and introduces several new network | |||
elements. This section provides high-level definitions of the LISP | elements. This section provides high-level definitions of the LISP | |||
name spaces and network elements and as such, it must not be | name spaces and network elements and as such, it must not be | |||
considered as an authoritative source. The reference to the | considered as an authoritative source. The reference to the | |||
authoritative document for each term is included in every term | authoritative document for each term is included in every term | |||
description. | description. | |||
Legacy Internet: The portion of the Internet that 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. | 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 | LISP site: A LISP site is a set of routers in an edge network that | |||
are under a single technical administration. LISP routers that | are under a single technical administration. LISP routers that | |||
reside in the edge network are the demarcation points to separate | reside in the edge network are the demarcation points to separate | |||
the edge network from the core network. See [I-D.ietf-lisp] for | the edge network from the core network. See [RFC6830] for more | |||
more details. | details. | |||
Endpoint ID (EID): An EID is a 32-bit (for IPv4) or 128-bit (for | 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 | IPv6) value used in the source and destination address fields of | |||
the first (most inner) LISP header of a packet. A packet that is | the first (most inner) LISP header of a packet. A packet that is | |||
emitted by a system contains EIDs in its headers and LISP headers | emitted by a system contains EIDs in its headers and LISP headers | |||
are prepended only when the packet reaches an Ingress Tunnel | are prepended only when the packet reaches an Ingress Tunnel | |||
Router (ITR) on the data path to the destination EID. The source | Router (ITR) on the data path to the destination EID. The source | |||
EID is obtained via existing mechanisms used to set a host's | EID is obtained via existing mechanisms used to set a host's | |||
"local" IP address. An EID is allocated to a host from an EID- | "local" IP address. An EID is allocated to a host from an EID- | |||
prefix block associated with the site where the host is located. | prefix block associated with the site where the host is located. | |||
See [I-D.ietf-lisp] for more details. | See [RFC6830] for more details. | |||
EID-prefix: A power-of-two block of EIDs that are allocated to a | 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 | site by an address allocation authority. See [RFC6830] for more | |||
more details. | details. | |||
EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable | EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable | |||
in the [RFC4632] sense. That is, an EID-Prefix aggregate is | in the [RFC4632] sense. That is, an EID-Prefix aggregate is | |||
defined to be a single contiguous power-of-two EID-prefix block. | defined to be a single contiguous power-of-two EID-prefix block. | |||
A prefix and a length characterize such a block. See | A prefix and a length characterize such a block. See [RFC6830] | |||
[I-D.ietf-lisp] for more details. | for more details. | |||
Routing LOCator (RLOC): A RLOC is an IPv4 or IPv6 address of an | 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- | egress tunnel router (ETR). A RLOC is the output of an EID-to- | |||
RLOC mapping lookup. An EID maps to one or more RLOCs. | RLOC mapping lookup. An EID maps to one or more RLOCs. | |||
Typically, RLOCs are numbered from topologically aggregatable | Typically, RLOCs are numbered from topologically aggregatable | |||
blocks that are assigned to a site at each point to which it | blocks that are assigned to a site at each point to which it | |||
attaches to the global Internet; where the topology is defined by | attaches to the global Internet; where the topology is defined by | |||
the connectivity of provider networks, RLOCs can be thought of as | the connectivity of provider networks, RLOCs can be thought of as | |||
Provider Aggregatable (PA) addresses. See [I-D.ietf-lisp] for | Provider Aggregatable (PA) addresses. See [RFC6830] for more | |||
more details. | details. | |||
EID-to-RLOC Mapping: A binding between an EID-Prefix and the RLOC- | EID-to-RLOC Mapping: A binding between an EID-Prefix and the RLOC- | |||
set that can be used to reach the EID-Prefix. The general term | set that can be used to reach the EID-Prefix. The general term | |||
"mapping" always refers to an EID-to-RLOC mapping. See | "mapping" always refers to an EID-to-RLOC mapping. See [RFC6830] | |||
[I-D.ietf-lisp] for more details. | for more details. | |||
Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a | Ingress Tunnel Router (ITR): An Ingress Tunnel Router (ITR) is a | |||
router that accepts receives IP packets from site end-systems on | router that accepts receives IP packets from site end-systems on | |||
one side and sends LISP-encapsulated IP packets toward the | one side and sends LISP-encapsulated IP packets toward the | |||
Internet on the other side. The router treats the "inner" IP | Internet on the other side. The router treats the "inner" IP | |||
destination address as an EID and performs an EID-to-RLOC mapping | destination address as an EID and performs an EID-to-RLOC mapping | |||
lookup. The router then prepends an "outer" IP header with one of | 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. | result of the mapping lookup in the destination address field. | |||
See [I-D.ietf-lisp] for more details. | See [RFC6830] for more details. | |||
Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives | Egress Tunnel Router (ETR): An Egress Tunnel Router (ETR) receives | |||
LISP-encapsulated IP packets from the Internet on one side and | LISP-encapsulated IP packets from the Internet on one side and | |||
sends decapsulated IP packets to site end-systems on the other | sends decapsulated IP packets to site end-systems on the other | |||
side. An ETR router accepts an IP packet where the destination | side. An ETR router accepts an IP packet where the destination | |||
address in the "outer" IP header is one of its own RLOCs. The | address in the "outer" IP header is one of its own RLOCs. The | |||
router strips the "outer" header and forwards the packet based on | router strips the "outer" header and forwards the packet based on | |||
the next IP header found. See [I-D.ietf-lisp] for more details. | the next IP header found. See [RFC6830] for more details. | |||
Proxy ITR (PITR): A Proxy-ITR (PITR) acts like an ITR but does so on | Proxy ITR (PITR): A Proxy-ITR (PITR) acts like an ITR but does so on | |||
behalf of non-LISP sites which send packets to destinations at | behalf of non-LISP sites which send packets to destinations at | |||
LISP sites. See [I-D.ietf-lisp-interworking] for more details. | LISP sites. See [RFC6832] for more details. | |||
Proxy ETR (PETR): A Proxy-ETR (PETR) acts like an ETR but does so on | Proxy ETR (PETR): A Proxy-ETR (PETR) acts like an ETR but does so on | |||
behalf of LISP sites which send packets to destinations at non- | behalf of LISP sites which send packets to destinations at non- | |||
LISP sites. See [I-D.ietf-lisp-interworking] for more details. | LISP sites. See [RFC6832] for more details. | |||
Map Server (MS): A network infrastructure component that learns EID- | Map Server (MS): A network infrastructure component that learns EID- | |||
to-RLOC mapping entries from an authoritative source (typically an | to-RLOC mapping entries from an authoritative source (typically an | |||
ETR). A Map Server publishes these mappings in the distributed | ETR). A Map Server publishes these mappings in the distributed | |||
mapping system. See [I-D.ietf-lisp-ms] for more details. | mapping system. See [RFC6833] for more details. | |||
Map Resolver (MR): A network infrastructure component that accepts | Map Resolver (MR): A network infrastructure component that accepts | |||
LISP Encapsulated Map-Requests, typically from an ITR, quickly | LISP Encapsulated Map-Requests, typically from an ITR, quickly | |||
determines whether or not the destination IP address is part of | determines whether or not the destination IP address is part of | |||
the EID namespace; if it is not, a Negative Map-Reply is | the EID namespace; if it is not, a Negative Map-Reply is | |||
immediately returned. Otherwise, the Map Resolver finds the | immediately returned. Otherwise, the Map Resolver finds the | |||
appropriate EID-to-RLOC mapping by consulting the distributed | appropriate EID-to-RLOC mapping by consulting the distributed | |||
mapping database system. See [I-D.ietf-lisp-ms] for more details. | mapping database system. See [RFC6833] for more details. | |||
The LISP Alternative Logical Topology (ALT): The virtual overlay | The LISP Alternative Logical Topology (ALT): The virtual overlay | |||
network made up of tunnels between LISP+ALT Routers. The Border | network made up of tunnels between LISP+ALT Routers. The Border | |||
Gateway Protocol (BGP) runs between ALT Routers and is used to | Gateway Protocol (BGP) runs between ALT Routers and is used to | |||
carry reachability information for EID-prefixes. The ALT provides | carry reachability information for EID-prefixes. The ALT provides | |||
a way to forward Map-Requests toward the ETR that "owns" an EID- | a way to forward Map-Requests toward the ETR that "owns" an EID- | |||
prefix. See [I-D.ietf-lisp-alt] for more details. | prefix. See [RFC6836] for more details. | |||
ALT Router: The device on which runs the ALT. The ALT is a static | ALT Router: The device on which runs the ALT. The ALT is a static | |||
network built using tunnels between ALT Routers. These routers | network built using tunnels between ALT Routers. These routers | |||
are deployed in a roughly-hierarchical mesh in which routers at | are deployed in a roughly-hierarchical mesh in which routers at | |||
each level in the topology are responsible for aggregating EID- | each level in the topology are responsible for aggregating EID- | |||
Prefixes learned from those logically "below" them and advertising | Prefixes learned from those logically "below" them and advertising | |||
summary prefixes to those logically "above" them. Prefix learning | summary prefixes to those logically "above" them. Prefix learning | |||
and propagation between ALT Routers is done using BGP. When an | and propagation between ALT Routers is done using BGP. When an | |||
ALT Router receives an ALT Datagram, it looks up the destination | ALT Router receives an ALT Datagram, it looks up the destination | |||
EID in its forwarding table (composed of EID-Prefix routes it | EID in its forwarding table (composed of EID-Prefix routes it | |||
learned from neighboring ALT Routers) and forwards it to the | learned from neighboring ALT Routers) and forwards it to the | |||
logical next-hop on the overlay network. The primary function of | logical next-hop on the overlay network. The primary function of | |||
LISP+ALT routers is to provide a lightweight forwarding | LISP+ALT routers is to provide a lightweight forwarding | |||
infrastructure for LISP control-plane messages (Map-Request and | infrastructure for LISP control-plane messages (Map-Request and | |||
Map-Reply), and to transport data packets when the packet has the | Map-Reply), and to transport data packets when the packet has the | |||
same destination address in both the inner (encapsulating) | same destination address in both the inner (encapsulating) | |||
destination and outer destination addresses ((i.e., a Data Probe | destination and outer destination addresses ((i.e., a Data Probe | |||
packet). See [I-D.ietf-lisp-alt] for more details. | packet). See [RFC6836] for more details. | |||
3. Rationale and Intent | 3. Rationale and Intent | |||
With the current specifications, if an ITR is sending to all types of | With the current specifications, if an ITR is sending to all types of | |||
destinations (i.e., non-LISP destinations, LISP destinations not in | destinations (i.e., non-LISP destinations, LISP destinations not in | |||
the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the | the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the | |||
only way to understand whether or not to encapsulate the traffic is | only way to understand whether or not to encapsulate the traffic is | |||
to perform a cache lookup and, in case of cache-miss, send a Map- | to perform a cache lookup and, in case of cache-miss, send a Map- | |||
Request to the mapping system. In the meanwhile, packets can be | Request to the mapping system. In the meanwhile, packets may be | |||
dropped. | dropped. | |||
By defining an IPv6 EID Block is possible to configure the router so | There are several use cases for this address block, for instance: | |||
to natively forward all packets that have not a destination address | ||||
in the block, without performing any lookup whatsoever. This will | o In certain circumstances it is possible to configure the router so | |||
give a tighter control over the traffic in the initial experimental | to natively forward all packets that have not a destination | |||
phase, while facilitating its large-scale deployment. | address in the block, without performing any lookup whatsoever. | |||
o In some scenarios, in case of cache-miss packets, are routed | ||||
toward a PETR until a mapping is obtained, if the destination is | ||||
in a specific EID space packets may be dropped in order to avoid | ||||
forwarding paths like ITR->PETR->PITR->ETR, avoiding the related | ||||
overhead. | ||||
o Improved traffic engineering capabilities with respect to LISP vs. | ||||
non-LISP traffic. | ||||
Is worth to mention that new use cases can arise in the future, due | ||||
to new and unforeseen scenarios. furthermore, 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 | 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 | recommended not to hard-code in any way the IPv6 EID Block in the | |||
router hardware. This allows avoiding 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 | want to switch to LISP while keeping their own IPv6 prefix, which is | |||
not in the IPv6 EID Block. | not in the IPv6 EID Block. | |||
4. Expected use | 4. Expected use | |||
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 | ||||
To 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). The use of PxTRs allow to aggregate several prefixes; the | |||
prefixes of several sites. | deployment model for this element is described in [RFC6832] and | |||
[I-D.ietf-lisp-deployment]. | ||||
As the LISP adoption progress, the EID prefix space will potentially | ||||
help in reducing the impact on the BGP routing infrastructure with | ||||
respect to the case of the same number of adopters using global | ||||
unicast space allocated by RIRs ([MobiArch2007]). From a short-term | ||||
perspective, the EID space offers potentially large aggregation | ||||
capabilities since it is announced by PxTRs possibly concentrating | ||||
several contiguous prefixes. Such trend should continue with even | ||||
lower impact from a long-term perspective, since more aggressive | ||||
aggregation can be used, potentially leading at using few PxTRs | ||||
announcing the whole EID space ([FIABook2010]). | ||||
The prefix is not supposed to be used as normal prefix announced in | ||||
the BGP routing infrastructure without the use of LISP. | ||||
5. Block Dimension | 5. Block Dimension | |||
The working group reached consensus on an initial allocation of a /16 | 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 | prefix out of a /12 block which is asked to remain reserved for | |||
future use as EID space. The reason of such consensus is manifold: | future use as EID space. The reason of such consensus is manifold: | |||
o The working group agreed that /16 prefix is sufficiently large to | o The working group agreed that /16 prefix is sufficiently large to | |||
cover initial allocation and requests for prefixes in the EID | cover initial allocation and requests for prefixes in the EID | |||
space in the next few years for very large-scale experimentation | space in the next few years for very large-scale experimentation | |||
skipping to change at page 7, line 20 | skipping to change at page 7, line 45 | |||
In particular, reverse DNS for IPv6 in the special ip6.arpa domain | In particular, reverse DNS for IPv6 in the special ip6.arpa domain | |||
is represented as sequence of nibbles. A different alignment | is represented as sequence of nibbles. A different alignment | |||
would force to a binary representation. | would force to a binary representation. | |||
o The use of a /16 prefix is in line with previous similar prefix | o The use of a /16 prefix is in line with previous similar prefix | |||
allocation for tunnelling protocols ([RFC3056]) and is considered | allocation for tunnelling protocols ([RFC3056]) and is considered | |||
a useful practice ([RFC3692]). | a useful practice ([RFC3692]). | |||
6. Action Plan | 6. Action Plan | |||
This document requests IANA to initially allocate a /16 prefix out of | This document requests IANA to initially assign 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). | |||
allocating any other address block the same /12 prefix the EID /16 | ||||
prefix belongs to. This is to accommodate future requests of EID | ||||
space without fragmenting the EID addressing space. This will also | ||||
help from an operational point of view, since it will be sufficient | ||||
to change the subnet mask length in existing deployments. | ||||
If in the future there will be need for a larger EID Block the | It is suggested to IANA to temporarily avoid allocating any other | |||
address space adjacent the EID Block could be allocate by IANA | address block the same /12 prefix the EID /16 prefix belongs to. | |||
according to the current policies. | ||||
This is to accommodate future requests of EID space without | ||||
fragmenting the EID addressing space. This will also help from an | ||||
operational point of view, since it will be sufficient to change the | ||||
subnet mask length in existing deployments. 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 according to the current | ||||
policies. | ||||
IANA should assign the requested address space by September 2013 for | ||||
a duration of 10 (ten) years (through September 2023). By the end of | ||||
this period, the IETF will provide a decision on whether to transform | ||||
the prefix in a permanent assignment or to put it back in the free | ||||
pool. | ||||
The allocation and management of the Global EID Space will be | ||||
detailed in a separate document. | ||||
7. Routing Considerations | 7. 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 | |||
skipping to change at page 8, line 19 | skipping to change at page 9, line 8 | |||
domain connectivity. | domain connectivity. | |||
8. Security Considerations | 8. 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 | 9. Acknowledgments | |||
Special thanks to Roque Gagliano for his suggestions and pointers. | Special thanks to Roque Gagliano for his suggestions and pointers. | |||
Thanks to Marla Azinger, Chris Morrow, and Peter Schoenmaker, all | Thanks to Brian Carpenter, Roger Jorgensen, Terry Manderson, Brian | |||
made insightful comments on early versions of this draft. | Haberman, Adrian Farrel, Job Snijders, Marla Azinger, Chris Morrow, | |||
and Peter Schoenmaker, for their insightful comments. Thanks as well | ||||
John Curran, Paul Wilson, Geoff Huston, Wes George, Arturo Servin, | ||||
Sander Steffann, and to all participants to the fruitful discussion | ||||
on the IETF mailing list. | ||||
10. IANA Considerations | 10. 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 a hierarchical allocation as | as the global LISP EID space using a hierarchical allocation as | |||
outlined in [RFC5226]. During the discussion related to this | outlined in [RFC5226] and summarized in Table 1. | |||
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 [RFC5226], such space | ||||
will be assigned only upon IETF Review. This document does not | ||||
specify any specific value for the requested address block. | ||||
11. References | +----------------------+--------------------+ | |||
| Attribute | Value | | ||||
+----------------------+--------------------+ | ||||
| Address Block | XXX0::/16 [1] | | ||||
| Name | EID Space for LISP | | ||||
| RFC | [This Document] | | ||||
| Allocation Date | September 2013 | | ||||
| Termination Date | September 2023 | | ||||
| Source | True [2] | | ||||
| Destination | True | | ||||
| Forwardable | True | | ||||
| Global | True | | ||||
| Reserved-by-protocol | True [3] | | ||||
+----------------------+--------------------+ | ||||
11.1. Normative References | [1] XXX value to be provided by IANA before published as RFC. [2] Can | |||
be used as a multicast source as well. [3] To be used as EID space by | ||||
LISP [RFC6830] enabled routers. | ||||
[I-D.ietf-lisp] | Table 1: Global EID Space | |||
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, | ||||
"Locator/ID Separation Protocol (LISP)", | ||||
draft-ietf-lisp-23 (work in progress), May 2012. | ||||
[I-D.ietf-lisp-alt] | During the discussion related to this document, the LISP Working | |||
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP | Group agreed in suggesting to IANA to reserve adjacent addressing | |||
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10 | space, more specifically the /12 covering the assigned /16 prefix, | |||
(work in progress), December 2011. | for future use as EID space if needs come. Table 2 summarizes the | |||
request. Following the policies outlined in [RFC5226], such space | ||||
will be assigned only upon IETF Review. | ||||
[I-D.ietf-lisp-interworking] | +----------------------+----------------------+ | |||
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, | | Attribute | Value | | |||
"Interworking LISP with IPv4 and IPv6", | +----------------------+----------------------+ | |||
draft-ietf-lisp-interworking-06 (work in progress), | | Address Block | XXX0::/12 [1] | | |||
March 2012. | | Name | ) EID Space for LISP | | |||
| RFC | [This Document] | | ||||
| Allocation Date | September 2013 | | ||||
| Termination Date | September 2023 | | ||||
| Source | False | | ||||
| Destination | False | | ||||
| Forwardable | False | | ||||
| Global | False | | ||||
| Reserved-by-protocol | True [2] | | ||||
+----------------------+----------------------+ | ||||
[I-D.ietf-lisp-ms] | [1] XXX value to be provided by IANA before published as RFC. [2] To | |||
Fuller, V. and D. Farinacci, "LISP Map Server Interface", | be used as EID space by LISP [RFC6830] enabled routers. | |||
draft-ietf-lisp-ms-16 (work in progress), March 2012. | ||||
Table 2: Reserved for Future Use as Global EID Space | ||||
This document does not specify any specific value for the requested | ||||
address block but suggests that should come from the 2000::/3 Global | ||||
Unicast Space. Furthermore, it is suggested to assign the /16 prefix | ||||
from the first /16 block out of the reserved /12 prefix. IANA is not | ||||
requested to issue a AS0 ROA, since the Global EID Space will be used | ||||
for routing purposes. | ||||
The reserved address space is requested for a period of time of ten | ||||
years starting in September 2013 and ending in September 2023. | ||||
Following the policies outlined in [RFC5226], upon IETF Review, by | ||||
September 2023 decision should be made on whether to keep the | ||||
assignment making the reserved prefix assignment permanent (this | ||||
includes final decision on the size of the prefix). If the IETF | ||||
review outcome will be that is not worth to have a reserved prefix as | ||||
global EID space, the whole /12 (and all sub-block assigned out of | ||||
it) will be took out from the IPv6 Special Purpose Address Registry | ||||
and put back in the free pool managed by IANA. | ||||
Allocation and management of the Global EID Space is detailed in a | ||||
different document. Nevertheless, all prefix allocations out this | ||||
space must be temporary and no allocation must go beyond September | ||||
2023 unless the upon IETF Review the GLobal EID Space is permanently | ||||
assigned. | ||||
11. References | ||||
11.1. Normative References | ||||
[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. | |||
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
May 2008. | May 2008. | |||
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The | ||||
Locator/ID Separation Protocol (LISP)", RFC 6830, | ||||
January 2013. | ||||
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, | ||||
"Interworking between Locator/ID Separation Protocol | ||||
(LISP) and Non-LISP Sites", RFC 6832, January 2013. | ||||
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation | ||||
Protocol (LISP) Map-Server Interface", RFC 6833, | ||||
January 2013. | ||||
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, | ||||
"Locator/ID Separation Protocol Alternative Logical | ||||
Topology (LISP+ALT)", RFC 6836, January 2013. | ||||
11.2. Informative References | 11.2. Informative References | |||
[BETA] LISP Beta Network, "http://www.lisp4.net", 2008-2011. | [BETA] LISP Beta Network, "http://www.lisp4.net", 2008-2011. | |||
[FIABook2010] | ||||
L. Iannone, T. Leva, "Modeling the economics of Loc/ID | ||||
Separation for the Future Internet.", Towards the Future | ||||
Internet - Emerging Trends from the European Research, | ||||
Pages 11-20, ISBN: 9781607505389, IOS Press , May 2010. | ||||
[I-D.ietf-lisp-deployment] | ||||
Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- | ||||
Pascual, J., and D. Lewis, "LISP Network Element | ||||
Deployment Considerations", draft-ietf-lisp-deployment-06 | ||||
(work in progress), January 2013. | ||||
[MobiArch2007] | ||||
B. Quoitin, L. Iannone, C. de Launois, O. Bonaventure, | ||||
"Evaluating the Benefits of the Locator/Identifier | ||||
Separation", The 2nd ACM-SIGCOMM International Workshop on | ||||
Mobility in the Evolving Internet Architecture | ||||
(MobiArch'07) , August 2007. | ||||
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains | [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains | |||
via IPv4 Clouds", RFC 3056, February 2001. | via IPv4 Clouds", RFC 3056, February 2001. | |||
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers | [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers | |||
Considered Useful", BCP 82, RFC 3692, January 2004. | Considered Useful", BCP 82, RFC 3692, January 2004. | |||
Appendix A. Document Change Log | Appendix A. Document Change Log | |||
Version 04 Posted February 2013. | ||||
o Added Table 1 and Table 2 as requested by IANA. | ||||
o Transformed the prefix request in a temporary request as suggested | ||||
by various comments during IETF Last Call. | ||||
o Added discussion about short/long term impact on BGP in Section 4 | ||||
as requested by B. Carpenter. | ||||
Version 03 Posted November 2012. | Version 03 Posted November 2012. | |||
o General review of Section 5 as requested by T. Manderson and B. | o General review of Section 5 as requested by T. Manderson and B. | |||
Haberman. | Haberman. | |||
o Dropped RFC 2119 Notation, as requested by A. Farrel and B. | o Dropped RFC 2119 Notation, as requested by A. Farrel and B. | |||
Haberman. | Haberman. | |||
o Changed "IETF Consensus" to "IETF Review" as pointed out by Roque | o Changed "IETF Consensus" to "IETF Review" as pointed out by Roque | |||
Gagliano. | Gagliano. | |||
o Changed every occurrence of "Map-Server" and "Map-Resolver" with | o Changed every occurrence of "Map-Server" and "Map-Resolver" with | |||
"Map Server" and "Map Resolver" to make the document consistent | "Map Server" and "Map Resolver" to make the document consistent | |||
with [I-D.ietf-lisp-ms]. Thanks to Job Snijders for pointing out | with [RFC6833]. Thanks to Job Snijders for pointing out the | |||
the issue. | issue. | |||
Version 02 Posted April 2012. | Version 02 Posted April 2012. | |||
o Fixed typos, nits, references. | o Fixed typos, nits, references. | |||
o Deleted reference to IANA allocation policies. | o Deleted reference to IANA allocation policies. | |||
Version 01 Posted October 2011. | Version 01 Posted October 2011. | |||
o Added Section 5. | o Added Section 5. | |||
skipping to change at page 11, line 4 | skipping to change at page 13, line 35 | |||
Luigi Iannone | Luigi Iannone | |||
Telecom ParisTech | Telecom ParisTech | |||
Email: luigi.iannone@telecom-paristech.fr | Email: luigi.iannone@telecom-paristech.fr | |||
Darrel Lewis | Darrel Lewis | |||
Cisco Systems, Inc. | Cisco Systems, Inc. | |||
Email: darlewis@cisco.com | Email: darlewis@cisco.com | |||
David Meyer | David Meyer | |||
Brocade | Brocade | |||
Email: dmm@1-4-5.net | Email: dmm@1-4-5.net | |||
Vince Fuller | Vince Fuller | |||
Cisco Systems, Inc. | ||||
Email: vaf@cisco.com | Email: vaf@vaf.net | |||
End of changes. 45 change blocks. | ||||
86 lines changed or deleted | 220 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/ |