draft-ietf-lisp-16.txt   draft-ietf-lisp-17.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft V. Fuller Internet-Draft V. Fuller
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: May 3, 2012 D. Lewis Expires: June 8, 2012 D. Lewis
cisco Systems cisco Systems
October 31, 2011 December 6, 2011
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-16 draft-ietf-lisp-17
Abstract Abstract
This draft describes a network-based protocol that enables separation This draft describes a network layer based protocol that enables
of IP addresses into two new numbering spaces: Endpoint Identifiers separation of IP addresses into two new numbering spaces: Endpoint
(EIDs) and Routing Locators (RLOCs). No changes are required to Identifiers (EIDs) and Routing Locators (RLOCs). No changes are
either host protocol stacks or to the "core" of the Internet required to either host protocol stacks or to the "core" of the
infrastructure. LISP can be incrementally deployed, without a "flag Internet infrastructure. LISP can be incrementally deployed, without
day", and offers traffic engineering, multi-homing, and mobility a "flag day", and offers traffic engineering, multi-homing, and
benefits to early adopters, even when there are relatively few LISP- mobility benefits to early adopters, even when there are relatively
capable sites. few LISP-capable sites.
Design and development of LISP was largely motivated by the problem Design and development of LISP was largely motivated by the problem
statement produced by the October 2006 IAB Routing and Addressing statement produced by the October 2006 IAB Routing and Addressing
Workshop. Workshop.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 3, 2012. This Internet-Draft will expire on June 8, 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
skipping to change at page 3, line 28 skipping to change at page 3, line 28
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67
12. Security Considerations . . . . . . . . . . . . . . . . . . . 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 68
13. Network Management Considerations . . . . . . . . . . . . . . 70 13. Network Management Considerations . . . . . . . . . . . . . . 70
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
14.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . . 71 14.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . . 71
14.2. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71 14.2. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71
14.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71 14.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71
14.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . . 72 14.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . . 72
15. Known Open Issues and Areas of Future Work . . . . . . . . . . 73 15. Known Open Issues and Areas of Future Work . . . . . . . . . . 73
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 75
16.1. Normative References . . . . . . . . . . . . . . . . . . . 74 16.1. Normative References . . . . . . . . . . . . . . . . . . . 75
16.2. Informative References . . . . . . . . . . . . . . . . . . 75 16.2. Informative References . . . . . . . . . . . . . . . . . . 76
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 78 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 80
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 79 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 81
B.1. Changes to draft-ietf-lisp-16.txt . . . . . . . . . . . . 79 B.1. Changes to draft-ietf-lisp-17.txt . . . . . . . . . . . . 81
B.2. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 79 B.2. Changes to draft-ietf-lisp-16.txt . . . . . . . . . . . . 81
B.3. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 79 B.3. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 81
B.4. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 80 B.4. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 81
B.5. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 80 B.5. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 82
B.6. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 82 B.6. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 82
B.7. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 82 B.7. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 84
B.8. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 83 B.8. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 85
B.9. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 83 B.9. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 85
B.10. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 85 B.10. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 85
B.11. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 87 B.11. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 87
B.12. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 88 B.12. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 89
B.13. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 88 B.13. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 90
B.14. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 90 B.14. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 90
B.15. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 90 B.15. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 92
B.16. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 91 B.16. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 92
B.17. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 91 B.17. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 92 B.18. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 93
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 94
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 describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier Separation Protocol
(LISP), which provides a set of functions for routers to exchange (LISP), which provides a set of functions for routers to exchange
information used to map from non-routeable Endpoint Identifiers information used to map from non globally routeable Endpoint
(EIDs) to routeable Routing Locators (RLOCs). It also defines a Identifiers (EIDs) to routeable Routing Locators (RLOCs). It also
mechanism for these LISP routers to encapsulate IP packets addressed defines a mechanism for these LISP routers to encapsulate IP packets
with EIDs for transmission across an Internet that uses RLOCs for addressed with EIDs for transmission across the< Internet that uses
routing and forwarding. RLOCs for routing and forwarding.
Creation of LISP was initially motivated by discussions during the Creation of LISP was initially motivated by discussions during the
IAB-sponsored Routing and Addressing Workshop held in Amsterdam in IAB-sponsored Routing and Addressing Workshop held in Amsterdam in
October, 2006 (see [RFC4984]). A key conclusion of the workshop was October, 2006 (see [RFC4984]). A key conclusion of the workshop was
that the Internet routing and addressing system was not scaling well that the Internet routing and addressing system was not scaling well
in the face of the explosive growth of new sites; one reason for this in the face of the explosive growth of new sites; one reason for this
poor scaling is the increasing number of multi-homed and other sites poor scaling is the increasing number of multi-homed and other sites
that cannot be addressed as part of topologically- or provider-based that cannot be addressed as part of topologically- or provider-based
aggregated prefixes. Additional work that more completely described aggregated prefixes. Additional work that more completely described
the problem statement may be found in [RADIR]. the problem statement may be found in [RADIR].
skipping to change at page 6, line 8 skipping to change at page 6, line 8
forwards using RLOCs. Both RLOCs and EIDs are syntactically- forwards using RLOCs. Both RLOCs and EIDs are syntactically-
identical to IP addresses; it is the semantics of how they are used identical to IP addresses; it is the semantics of how they are used
that differs. that differs.
This document describes the protocol that implements these functions. This document describes the protocol that implements these functions.
The database which stores the mappings between EIDs and RLOCs is The database which stores the mappings between EIDs and RLOCs is
explicitly a separate "module" to facilitate experimentation with a explicitly a separate "module" to facilitate experimentation with a
variety of approaches. One database design that is being developed variety of approaches. One database design that is being developed
and prototyped as part of the LISP working group work is [ALT]. and prototyped as part of the LISP working group work is [ALT].
Others that have been described but not implemented include [CONS], Others that have been described but not implemented include [CONS],
[EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general- [EMACS], [NERD]. Finally, [LISP-MS], documents a general-purpose
purpose service interface for accessing a mapping database; this service interface for accessing a mapping database; this interface is
interface is intended to make the mapping database modular so that intended to make the mapping database modular so that different
different approaches can be tried without the need to modify approaches can be tried without the need to modify installed LISP
installed xTRs. capable devices in LISP sites.
This experimental specification has areas that require additional This experimental specification has areas that require additional
experience and measurement. Results of such work may lead to experience and measurement. Results of such work may lead to
modifications and enhancements of protocol mechanisms defined in this modifications and enhancements of protocol mechanisms defined in this
document. See Section 15 for specific, known issues that are in need document. See Section 15 for specific, known issues that are in need
of further work during development, implementation, and prototype of further work during development, implementation, and prototype
deployment. deployment.
3. Definition of Terms 3. Definition of Terms
Provider Independent (PI) Addresses: PI addresses are an address Provider Independent (PI) Addresses: PI addresses are an address
block assigned from a pool where blocks are not associated with block assigned from a pool where blocks are not associated with
any particular location in the network (e.g. from a particular any particular location in the network (e.g. from a particular
service provider), and is therefore not topologically aggregatable service provider), and is therefore not topologically aggregatable
in the routing system. in the routing system.
Provider Assigned (PA) Addresses: PA addresses are an a address Provider Assigned (PA) Addresses: PA addresses are an an address
block assigned to a site by each service provider to which a site block assigned to a site by each service provider to which a site
connects. Typically, each block is sub-block of a service connects. Typically, each block is sub-block of a service
provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
is aggregated into the larger block before being advertised into is aggregated into the larger block before being advertised into
the global Internet. Traditionally, IP multihoming has been the global Internet. Traditionally, IP multihoming has been
implemented by each multi-homed site acquiring its own, globally- implemented by each multi-homed site acquiring its own, globally-
visible prefix. LISP uses only topologically-assigned and visible prefix. LISP uses only topologically-assigned and
aggregatable address blocks for RLOCs, eliminating this aggregatable address blocks for RLOCs, eliminating this
demonstrably non-scalable practice. demonstrably non-scalable practice.
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 a EID-to-RLOC egress tunnel router (ETR). A RLOC is the output of an EID-to-
mapping lookup. An EID maps to one or more RLOCs. Typically, RLOC mapping lookup. An EID maps to one or more RLOCs.
RLOCs are numbered from topologically-aggregatable blocks that are Typically, RLOCs are numbered from topologically-aggregatable
assigned to a site at each point to which it attaches to the blocks that are assigned to a site at each point to which it
global Internet; where the topology is defined by the connectivity attaches to the global Internet; where the topology is defined by
of provider networks, RLOCs can be thought of as PA addresses. the connectivity of provider networks, RLOCs can be thought of as
Multiple RLOCs can be assigned to the same ETR device or to PA addresses. Multiple RLOCs can be assigned to the same ETR
multiple ETR devices at a site. device or to multiple ETR devices at a site.
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. The host obtains the first (most inner) LISP header of a packet. The host obtains
a destination EID the same way it obtains an destination address a destination EID the same way it obtains an destination address
today, for example through a Domain Name System (DNS) [RFC1034] today, for example through a Domain Name System (DNS) [RFC1034]
lookup or Session Invitation Protocol (SIP) [RFC3261] exchange. lookup or Session Invitation Protocol (SIP) [RFC3261] exchange.
The source EID is obtained via existing mechanisms used to set a The source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID is allocated to a host from an host's "local" IP address. An EID is allocated to a host from an
EID-prefix block associated with the site where the host is EID-prefix block associated with the site where the host is
located. An EID can be used by a host to refer to other hosts. located. An EID can be used by a host to refer to other hosts.
EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks MAY be
assigned in a hierarchical manner, independent of the network assigned in a hierarchical manner, independent of the network
topology, to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping database. In
addition, an EID block assigned to a site may have site-local addition, an EID block assigned to a site may have site-local
structure (subnetting) for routing within the site; this structure structure (subnetting) for routing within the site; this structure
is not visible to the global routing system. In theory, the bit is not visible to the global routing system. In theory, the bit
string that represents an EID for one device can represent an RLOC string that represents an EID for one device can represent an RLOC
for a different device. As the architecture is realized, if a for a different device. As the architecture is realized, if a
given bit string is both an RLOC and an EID, it must refer to the given bit string is both an RLOC and an EID, it must refer to the
same entity in both cases. When used in discussions with other same entity in both cases. When used in discussions with other
Locator/ID separation proposals, a LISP EID will be called a Locator/ID separation proposals, a LISP EID will be called a
"LEID". Throughout this document, any references to "EID" refers "LEID". Throughout this document, any references to "EID" refers
to an LEID. to an LEID.
EID-prefix: An EID-prefix is a power-of-two block of EIDs which are EID-prefix: An EID-prefix is a power-of-two block of EIDs which are
allocated to a site by an address allocation authority. EID- allocated to a site by an address allocation authority. EID-
prefixes are associated with a set of RLOC addresses which make up prefixes are associated with a set of RLOC addresses which make up
a "database mapping". EID-prefix allocations can be broken up a "database mapping". EID-prefix allocations can be broken up
into smaller blocks when an RLOC set is to be associated with the into smaller blocks when an RLOC set is to be associated with the
smaller EID-prefix. A globally routed address block (whether PI larger EID-prefix block. A globally routed address block (whether
or PA) is not inherently an EID-prefix. A globally routed address PI or PA) is not inherently an EID-prefix. A globally routed
block may be used by its assignee as an EID block. The converse address block MAY be used by its assignee as an EID block. The
is not supported. That is, a site which receives an explicitly converse is not supported. That is, a site which receives an
allocated EID-prefix may not use that EID-prefix as a globally explicitly allocated EID-prefix may not use that EID-prefix as a
prefix. This would require coordination and cooperation with the globally routed prefix. This would require coordination and
entities managing the mapping infrastructure. Once this has been cooperation with the entities managing the mapping infrastructure.
done, that block could be removed from the globally routed IP Once this has been done, that block could be removed from the
system, if other suitable transition and access mechanisms are in globally routed IP system, if other suitable transition and access
place. Discussion of such transition and access mechanisms can be mechanisms are in place. Discussion of such transition and access
found in [INTERWORK] and [LISP-DEPLOY]. mechanisms can be found in [INTERWORK] and [LISP-DEPLOY].
End-system: An end-system is an IPv4 or IPv6 device that originates End-system: An end-system is an IPv4 or IPv6 device that originates
packets with a single IPv4 or IPv6 header. The end-system packets with a single IPv4 or IPv6 header. The end-system
supplies an EID value for the destination address field of the IP supplies an EID value for the destination address field of the IP
header when communicating globally (i.e. outside of its routing header when communicating globally (i.e. outside of its routing
domain). An end-system can be a host computer, a switch or router domain). An end-system can be a host computer, a switch or router
device, or any network appliance. device, or any network appliance.
Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP
packet with a single IP header (more precisely, an IP packet that packet with a single IP header (more precisely, an IP packet that
does not contain a LISP header). The router treats this "inner" does not contain a LISP header). The router treats this "inner"
IP destination address as an EID and performs an EID-to-RLOC IP destination address as an EID and performs an EID-to-RLOC
mapping lookup. The router then prepends an "outer" IP header mapping lookup. The router then prepends an "outer" IP header
with one of its globally-routable RLOCs in the source address with one of its globally-routable RLOCs in the source address
field and the result of the mapping lookup in the destination field and the result of the mapping lookup in the destination
address field. Note that this destination RLOC may be an address field. Note that this destination RLOC MAY be an
intermediate, proxy device that has better knowledge of the EID- intermediate, proxy device that has better knowledge of the EID-
to-RLOC mapping closer to the destination EID. In general, an ITR to-RLOC mapping closer to the destination EID. In general, an ITR
receives IP packets from site end-systems on one side and sends receives IP packets from site end-systems on one side and sends
LISP-encapsulated IP packets toward the Internet on the other LISP-encapsulated IP packets toward the Internet on the other
side. side.
Specifically, when a service provider prepends a LISP header for Specifically, when a service provider prepends a LISP header for
Traffic Engineering purposes, the router that does this is also Traffic Engineering purposes, the router that does this is also
regarded as an ITR. The outer RLOC the ISP ITR uses can be based regarded as an ITR. The outer RLOC the ISP ITR uses can be based
on the outer destination address (the originating ITR's supplied on the outer destination address (the originating ITR's supplied
skipping to change at page 9, line 31 skipping to change at page 9, line 31
network that strips an outer LISP header for Traffic Engineering network that strips an outer LISP header for Traffic Engineering
purposes. purposes.
xTR: A xTR is a reference to an ITR or ETR when direction of data xTR: A xTR is a reference to an ITR or ETR when direction of data
flow is not part of the context description. xTR refers to the flow is not part of the context description. xTR refers to the
router that is the tunnel endpoint. Used synonymously with the router that is the tunnel endpoint. Used synonymously with the
term "Tunnel Router". For example, "An xTR can be located at the term "Tunnel Router". For example, "An xTR can be located at the
Customer Edge (CE) router", meaning both ITR and ETR functionality Customer Edge (CE) router", meaning both ITR and ETR functionality
is at the CE router. is at the CE router.
LISP Router: A LISP router is a router that performs the functions
of any or all of ITR, ETR, PITR, or PETR.
EID-to-RLOC Cache: The EID-to-RLOC cache is a short-lived, on- EID-to-RLOC Cache: The EID-to-RLOC cache is a short-lived, on-
demand table in an ITR that stores, tracks, and is responsible for demand table in an ITR that stores, tracks, and is responsible for
timing-out and otherwise validating EID-to-RLOC mappings. This timing-out and otherwise validating EID-to-RLOC mappings. This
cache is distinct from the full "database" of EID-to-RLOC cache is distinct from the full "database" of EID-to-RLOC
mappings, it is dynamic, local to the ITR(s), and relatively small mappings, it is dynamic, local to the ITR(s), and relatively small
while the database is distributed, relatively static, and much while the database is distributed, relatively static, and much
more global in scope. more global in scope.
EID-to-RLOC Database: The EID-to-RLOC database is a global EID-to-RLOC Database: The EID-to-RLOC database is a global
distributed database that contains all known EID-prefix to RLOC distributed database that contains all known EID-prefix to RLOC
mappings. Each potential ETR typically contains a small piece of mappings. Each potential ETR typically contains a small piece of
the database: the EID-to-RLOC mappings for the EID prefixes the database: the EID-to-RLOC mappings for the EID prefixes
"behind" the router. These map to one of the router's own, "behind" the router. These map to one of the router's own,
globally-visible, IP addresses. The same database mapping entries globally-visible, IP addresses. The same database mapping entries
MUST be configured on all ETRs for a given site. In a steady MUST be configured on all ETRs for a given site. In a steady
state the EID-prefixes for the site and the locator-set for each state the EID-prefixes for the site and the locator-set for each
EID-prefix MUST be the same on all ETRs. Procedures to enforce EID-prefix MUST be the same on all ETRs. Procedures to enforce
and/or verify this are outside the scope of this document. Note and/or verify this are outside the scope of this document. Note
that there may be transient conditions when the EID-prefix for the that there MAY be transient conditions when the EID-prefix for the
site and locator-set for each EID-prefix may not be the same on site and locator-set for each EID-prefix may not be the same on
all ETRs. This has no negative implications. all ETRs. This has no negative implications.
Recursive Tunneling: Recursive tunneling occurs when a packet has Recursive Tunneling: Recursive tunneling occurs when a packet has
more than one LISP IP header. Additional layers of tunneling may more than one LISP IP header. Additional layers of tunneling MAY
be employed to implement traffic engineering or other re-routing be employed to implement traffic engineering or other re-routing
as needed. When this is done, an additional "outer" LISP header as needed. When this is done, an additional "outer" LISP header
is added and the original RLOCs are preserved in the "inner" is added and the original RLOCs are preserved in the "inner"
header. Any references to tunnels in this specification refers to header. Any references to tunnels in this specification refers to
dynamic encapsulating tunnels and never are they statically dynamic encapsulating tunnels and they are never statically
configured. configured.
Reencapsulating Tunnels: Reencapsulating tunneling occurs when an Reencapsulating Tunnels: Reencapsulating tunneling occurs when an
ETR removes a LISP header, then acts as an ITR to prepend another ETR removes a LISP header, then acts as an ITR to prepend another
LISP header. Doing this allows a packet to be re-routed by the LISP header. Doing this allows a packet to be re-routed by the
re-encapsulating router without adding the overhead of additional re-encapsulating router without adding the overhead of additional
tunnel headers. Any references to tunnels in this specification tunnel headers. Any references to tunnels in this specification
refers to dynamic encapsulating tunnels and never are they refers to dynamic encapsulating tunnels and they are never
statically configured. When using multiple mapping database statically configured. When using multiple mapping database
systems, care must be taken to not create reencapsulation loops. systems, care must be taken to not create reencapsulation loops.
LISP Header: a term used in this document to refer to the outer LISP Header: a term used in this document to refer to the outer
IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
header that follows the UDP header, an ITR prepends or an ETR header that follows the UDP header, an ITR prepends or an ETR
strips. strips.
Address Family Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to describe an address
encoding in a packet. An address family currently pertains to an encoding in a packet. An address family currently pertains to an
skipping to change at page 11, line 18 skipping to change at page 11, line 22
behalf of non-LISP sites which send packets to destinations at behalf of non-LISP sites which send packets to destinations at
LISP sites. LISP sites.
Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a Proxy ETR (PETR): A PETR is defined and described in [INTERWORK], a
PETR acts like an ETR but does so on behalf of LISP sites which PETR acts like an ETR but does so on behalf of LISP sites which
send packets to destinations at non-LISP sites. send packets to destinations at non-LISP sites.
Route-returnability: is an assumption that the underlying routing Route-returnability: is an assumption that the underlying routing
system will deliver packets to the destination. When combined system will deliver packets to the destination. When combined
with a nonce that is provided by a sender and returned by a with a nonce that is provided by a sender and returned by a
receiver limits off-path data insertion. receiver, this limits off-path data insertion.
LISP site: is a set of routers in an edge network that are under a LISP site: is a set of routers in an edge network that are under a
single technical administration. LISP routers which reside in the single technical administration. LISP routers which reside in the
edge network are the demarcation points to separate the edge edge network are the demarcation points to separate the edge
network from the core network. network from the core network.
Client-side: a term used in this document to indicate a connection Client-side: a term used in this document to indicate a connection
initiation attempt by an EID. The ITR(s) at the LISP site are the initiation attempt by an EID. The ITR(s) at the LISP site are the
first to get involved in obtaining database map cache entries by first to get involved in obtaining database map cache entries by
sending Map-Request messages. sending Map-Request messages.
skipping to change at page 12, line 23 skipping to change at page 12, line 23
Routers continue to forward packets based on IP destination Routers continue to forward packets based on IP destination
addresses. When a packet is LISP encapsulated, these addresses are addresses. When a packet is LISP encapsulated, these addresses are
referred to as Routing Locators (RLOCs). Most routers along a path referred to as Routing Locators (RLOCs). Most routers along a path
between two hosts will not change; they continue to perform routing/ between two hosts will not change; they continue to perform routing/
forwarding lookups on the destination addresses. For routers between forwarding lookups on the destination addresses. For routers between
the source host and the ITR as well as routers from the ETR to the the source host and the ITR as well as routers from the ETR to the
destination host, the destination address is an EID. For the routers destination host, the destination address is an EID. For the routers
between the ITR and the ETR, the destination address is an RLOC. between the ITR and the ETR, the destination address is an RLOC.
Another key LISP concept is the "Tunnel Router". A tunnel router Another key LISP concept is the "Tunnel Router". A tunnel router
prepends LISP headers on host-originated packets and strip them prior prepends LISP headers on host-originated packets and strips them
to final delivery to their destination. The IP addresses in this prior to final delivery to their destination. The IP addresses in
"outer header" are RLOCs. During end-to-end packet exchange between this "outer header" are RLOCs. During end-to-end packet exchange
two Internet hosts, an ITR prepends a new LISP header to each packet between two Internet hosts, an ITR prepends a new LISP header to each
and an egress tunnel router strips the new header. The ITR performs packet and an egress tunnel router strips the new header. The ITR
EID-to-RLOC lookups to determine the routing path to the ETR, which performs EID-to-RLOC lookups to determine the routing path to the
has the RLOC as one of its IP addresses. ETR, which has the RLOC as one of its IP addresses.
Some basic rules governing LISP are: Some basic rules governing LISP are:
o End-systems (hosts) only send to addresses which are EIDs. They o End-systems (hosts) only send to addresses which are EIDs. They
don't know addresses are EIDs versus RLOCs but assume packets get don't know addresses are EIDs versus RLOCs but assume packets get
to LISP routers, which in turn, deliver packets to the destination to destinations, which in turn, LISP routers deliver packets to
the end-system has specified. The procedure a host uses to send the destination the end-system has specified. The procedure a
IP packets does not change. host uses to send IP packets does not change.
o EIDs are always IP addresses assigned to hosts. o EIDs are always IP addresses assigned to hosts.
o LISP routers mostly deal with Routing Locator addresses. See o LISP routers mostly deal with Routing Locator addresses. See
details later in Section 4.1 to clarify what is meant by "mostly". details later in Section 4.1 to clarify what is meant by "mostly".
o RLOCs are always IP addresses assigned to routers; preferably, o RLOCs are always IP addresses assigned to routers; preferably,
topologically-oriented addresses from provider CIDR blocks. topologically-oriented addresses from provider CIDR (Classless
Inter-Domain Routing) blocks.
o When a router originates packets it may use as a source address o When a router originates packets it may use as a source address
either an EID or RLOC. When acting as a host (e.g. when either an EID or RLOC. When acting as a host (e.g. when
terminating a transport session such as SSH, TELNET, or SNMP), it terminating a transport session such as SSH, TELNET, or SNMP), it
may use an EID that is explicitly assigned for that purpose. An may use an EID that is explicitly assigned for that purpose. An
EID that identifies the router as a host MUST NOT be used as an EID that identifies the router as a host MUST NOT be used as an
RLOC; an EID is only routable within the scope of a site. A RLOC; an EID is only routable within the scope of a site. A
typical BGP configuration might demonstrate this "hybrid" EID/RLOC typical BGP configuration might demonstrate this "hybrid" EID/RLOC
usage where a router could use its "host-like" EID to terminate usage where a router could use its "host-like" EID to terminate
iBGP sessions to other routers in a site while at the same time iBGP sessions to other routers in a site while at the same time
using RLOCs to terminate eBGP sessions to routers outside the using RLOCs to terminate eBGP sessions to routers outside the
site. site.
o EIDs are not expected to be usable for global end-to-end o Packets with EIDs in them are not expected to be delivered end-to-
communication in the absence of an EID-to-RLOC mapping operation. end in the absence of an EID-to-RLOC mapping operation. They are
They are expected to be used locally for intra-site communication. expected to be used locally for intra-site communication or to be
encapsulated for inter-site communication.
o EID prefixes are likely to be hierarchically assigned in a manner o EID prefixes are likely to be hierarchically assigned in a manner
which is optimized for administrative convenience and to which is optimized for administrative convenience and to
facilitate scaling of the EID-to-RLOC mapping database. The facilitate scaling of the EID-to-RLOC mapping database. The
hierarchy is based on a address allocation hierarchy which is hierarchy is based on a address allocation hierarchy which is
independent of the network topology. independent of the network topology.
o EIDs may also be structured (subnetted) in a manner suitable for o EIDs may also be structured (subnetted) in a manner suitable for
local routing within an autonomous system. local routing within an autonomous system.
An additional LISP header may be prepended to packets by a TE-ITR An additional LISP header MAY be prepended to packets by a TE-ITR
when re-routing of the path for a packet is desired. A potential when re-routing of the path for a packet is desired. A potential
use-case for this would be an ISP router that needs to perform use-case for this would be an ISP router that needs to perform
traffic engineering for packets flowing through its network. In such traffic engineering for packets flowing through its network. In such
a situation, termed Recursive Tunneling, an ISP transit acts as an a situation, termed Recursive Tunneling, an ISP transit acts as an
additional ingress tunnel router and the RLOC it uses for the new additional ingress tunnel router and the RLOC it uses for the new
prepended header would be either a TE-ETR within the ISP (along prepended header would be either a TE-ETR within the ISP (along
intra-ISP traffic engineered path) or a TE-ETR within another ISP (an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an
inter-ISP traffic engineered path, where an agreement to build such a inter-ISP traffic engineered path, where an agreement to build such a
path exists). path exists).
skipping to change at page 14, line 22 skipping to change at page 14, line 24
was not using LISP. was not using LISP.
o Each site is multi-homed, so each tunnel router has an address o Each site is multi-homed, so each tunnel router has an address
(RLOC) assigned from the service provider address block for each (RLOC) assigned from the service provider address block for each
provider to which that particular tunnel router is attached. provider to which that particular tunnel router is attached.
o The ITR(s) and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to the source and
destination, respectively, but the source and destination can be destination, respectively, but the source and destination can be
located anywhere in LISP site. located anywhere in LISP site.
o Map-Requests can be sent on the underlying routing system topology o Map-Requests can be sent on the underlying routing system
or over an alternative topology [ALT]. topology, to a mapping database system, or directly over an
alternative topology [ALT].
o Map-Replies are sent on the underlying routing system topology. o Map-Replies are sent on the underlying routing system topology.
Client host1.abc.example.com wants to communicate with server Client host1.abc.example.com wants to communicate with server
host2.xyz.example.com: host2.xyz.example.com:
1. host1.abc.example.com wants to open a TCP connection to 1. host1.abc.example.com wants to open a TCP connection to
host2.xyz.example.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup on
host2.xyz.example.com. An A/AAAA record is returned. This host2.xyz.example.com. An A/AAAA record is returned. This
address is the destination EID. The locally-assigned address of address is the destination EID. The locally-assigned address of
host1.abc.example.com is used as the source EID. An IPv4 or IPv6 host1.abc.example.com is used as the source EID. An IPv4 or IPv6
packet is built and forwarded through the LISP site as a normal packet is built and forwarded through the LISP site as a normal
IP packet until it reaches a LISP ITR. IP packet until it reaches a LISP ITR.
2. The LISP ITR must be able to map the EID destination to an RLOC 2. The LISP ITR must be able to map the destination EID to an RLOC
of one of the ETRs at the destination site. The specific method of one of the ETRs at the destination site. The specific method
used to do this is not described in this example. See [ALT] or used to do this is not described in this example. See [ALT] or
[CONS] for possible solutions. [CONS] for possible solutions.
3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be
rate-limited. rate-limited.
4. When an alternate mapping system is not in use, the Map-Request 4. When an alternate mapping system is not in use, the Map-Request
packet is routed through the underlying routing system. packet is routed through the underlying routing system.
Otherwise, the Map-Request packet is routed on an alternate Otherwise, the Map-Request packet is routed on an alternate
skipping to change at page 15, line 22 skipping to change at page 15, line 26
6. The ITR receives the Map-Reply message, parses the message (to 6. The ITR receives the Map-Reply message, parses the message (to
check for format validity) and stores the mapping information check for format validity) and stores the mapping information
from the packet. This information is stored in the ITR's EID-to- from the packet. This information is stored in the ITR's EID-to-
RLOC mapping cache. Note that the map cache is an on-demand RLOC mapping cache. Note that the map cache is an on-demand
cache. An ITR will manage its map cache in such a way that cache. An ITR will manage its map cache in such a way that
optimizes for its resource constraints. optimizes for its resource constraints.
7. Subsequent packets from host1.abc.example.com to 7. Subsequent packets from host1.abc.example.com to
host2.xyz.example.com will have a LISP header prepended by the host2.xyz.example.com will have a LISP header prepended by the
ITR using the appropriate RLOC as the LISP header destination ITR using the appropriate RLOC as the LISP header destination
address learned from the ETR. Note the packet may be sent to a address learned from the ETR. Note the packet MAY be sent to a
different ETR than the one which returned the Map-Reply due to different ETR than the one which returned the Map-Reply due to
the source site's hashing policy or the destination site's the source site's hashing policy or the destination site's
locator-set policy. locator-set policy.
8. The ETR receives these packets directly (since the destination 8. The ETR receives these packets directly (since the destination
address is one of its assigned IP addresses), checks the validity address is one of its assigned IP addresses), checks the validity
of the addresses, strips the LISP header, and forwards packets to of the addresses, strips the LISP header, and forwards packets to
the attached destination host. the attached destination host.
In order to defer the need for a mapping lookup in the reverse In order to defer the need for a mapping lookup in the reverse
skipping to change at page 16, line 9 skipping to change at page 16, line 9
termed a "gleaned" mapping and only contains a single RLOC for the termed a "gleaned" mapping and only contains a single RLOC for the
EID in question. More complete information about additional RLOCs EID in question. More complete information about additional RLOCs
SHOULD be verified by sending a LISP Map-Request for that EID. Both SHOULD be verified by sending a LISP Map-Request for that EID. Both
ITR and the ETR may also influence the decision the other makes in ITR and the ETR may also influence the decision the other makes in
selecting an RLOC. See Section 6 for more details. selecting an RLOC. See Section 6 for more details.
5. LISP Encapsulation Details 5. LISP Encapsulation Details
Since additional tunnel headers are prepended, the packet becomes Since additional tunnel headers are prepended, the packet becomes
larger and can exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed from the ITR to
the ETR. It is recommended in IPv4 that packets do not get the ETR. It is RECOMMENDED in IPv4 that packets do not get
fragmented as they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. Instead, the packet
is dropped and an ICMP Too Big message is returned to the source. is dropped and an ICMP Too Big message is returned to the source.
This specification recommends that implementations support for one of This specification RECOMMENDS that implementations provide support
the proposed fragmentation and reassembly schemes. These two for one of the proposed fragmentation and reassembly schemes. Two
existing schemes are detailed in Section 5.4. existing schemes are detailed in Section 5.4.
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP
architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner
header is in IPv4 packet format and the other header is in IPv6 header is in IPv4 packet format and the other header is in IPv6
packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
is in IPv6 packet format and the other header is in IPv4 packet is in IPv6 packet format and the other header is in IPv4 packet
format). The next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet formats for the
homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
combinations MUST be supported. combinations MUST be supported.
skipping to change at page 19, line 9 skipping to change at page 19, line 9
^ + Destination EID + ^ + Destination EID +
\ | | \ | |
\ + + \ + +
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. Tunnel Header Field Descriptions 5.3. Tunnel Header Field Descriptions
Inner Header: The inner header is the header on the datagram Inner Header: The inner header is the header on the datagram
received from the originating host. The source and destination IP received from the originating host. The source and destination IP
addresses are EIDs. addresses are EIDs, [RFC0791], [RFC2460].
Outer Header: The outer header is a new header prepended by an ITR. Outer Header: The outer header is a new header prepended by an ITR.
The address fields contain RLOCs obtained from the ingress The address fields contain RLOCs obtained from the ingress
router's EID-to-RLOC cache. The IP protocol number is "UDP (17)" router's EID-to-RLOC cache. The IP protocol number is "UDP (17)"
from [RFC0768]. The DF bit of the Flags field is set to 0 when from [RFC0768]. The DF bit of the Flags field is set to 0 when
the method in Section 5.4.1 is used and set to 1 when the method the method in Section 5.4.1 is used and set to 1 when the method
in Section 5.4.2 is used. in Section 5.4.2 is used.
UDP Header: The UDP header contains a ITR selected source port when UDP Header: The UDP header contains an ITR selected source port when
encapsulating a packet. See Section 6.5 for details on the hash encapsulating a packet. See Section 6.5 for details on the hash
algorithm used to select a source port based on the 5-tuple of the algorithm used to select a source port based on the 5-tuple of the
inner header. The destination port MUST be set to the well-known inner header. The destination port MUST be set to the well-known
IANA assigned port value 4341. IANA assigned port value 4341.
UDP Checksum: The UDP checksum field SHOULD be transmitted as zero UDP Checksum: The UDP checksum field SHOULD be transmitted as zero
by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation by an ITR for either IPv4 [RFC0768] or IPv6 encapsulation
[UDP-TUNNELS]. When a packet with a zero UDP checksum is received [UDP-TUNNELS] [UDP-ZERO]. When a packet with a zero UDP checksum
by an ETR, the ETR MUST accept the packet for decapsulation. When is received by an ETR, the ETR MUST accept the packet for
an ITR transmits a non-zero value for the UDP checksum, it MUST decapsulation. When an ITR transmits a non-zero value for the UDP
send a correctly computed value in this field. When an ETR checksum, it MUST send a correctly computed value in this field.
receives a packet with a non-zero UDP checksum, it MAY choose to When an ETR receives a packet with a non-zero UDP checksum, it MAY
verify the checksum value. If it chooses to perform such choose to verify the checksum value. If it chooses to perform
verification, and the verification fails, the packet MUST be such verification, and the verification fails, the packet MUST be
silently dropped. If the ETR chooses not to perform the silently dropped. If the ETR chooses not to perform the
verification, or performs the verification successfully, the verification, or performs the verification successfully, the
packet MUST be accepted for decapsulation. The handling of UDP packet MUST be accepted for decapsulation. The handling of UDP
checksums for all tunneling protocols, including LISP, is under checksums for all tunneling protocols, including LISP, is under
active discussion within the IETF. When that discussion active discussion within the IETF. When that discussion
concludes, any necessary changes will be made to align LISP with concludes, any necessary changes will be made to align LISP with
the outcome of the broader discussion. the outcome of the broader discussion.
UDP Length: The UDP length field is set for an IPv4 encapsulated UDP Length: The UDP length field is set for an IPv4 encapsulated
packet to be the sum of the inner header IPv4 Total Length plus packet to be the sum of the inner header IPv4 Total Length plus
skipping to change at page 20, line 17 skipping to change at page 20, line 17
bit is set to 1, the Locator Status Bits in the second 32-bits of bit is set to 1, the Locator Status Bits in the second 32-bits of
the LISP header are in use. the LISP header are in use.
x 1 x x 0 x x x x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version | |N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Status Bits | | Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E bit is the echo-nonce-request bit. When this bit is set to E: The E bit is the echo-nonce-request bit. This bit MUST be ignored
1, the N bit MUST be 1. This bit SHOULD be ignored and has no and has no meaning when the N bit is set to 0. When the N bit is
meaning when the N bit is set to 0. See Section 6.3.1 for set to 1 and this bit is set to 1, means an ITR is requesting for
details. the nonce value in the Nonce field to be echoed back in LISP
encapsulated packets when the ITR is also an ETR. See
Section 6.3.1 for details.
V: The V bit is the Map-Version present bit. When this bit is set to V: The V bit is the Map-Version present bit. When this bit is set to
1, the N bit MUST be 0. Refer to Section 6.6.3 for more details. 1, the N bit MUST be 0. Refer to Section 6.6.3 for more details.
This bit indicates that the LISP header is encoded as: This bit indicates that the LISP header is encoded in this case
as:
0 x 0 1 x x x x 0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator Status Bits | | Instance ID/Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: The I bit is the Instance ID bit. See Section 5.5 for more I: The I bit is the Instance ID bit. See Section 5.5 for more
details. When this bit is set to 1, the Locator Status Bits field details. When this bit is set to 1, the Locator Status Bits field
is reduced to 8-bits and the high-order 24-bits are used as an is reduced to 8-bits and the high-order 24-bits are used as an
Instance ID. If the L-bit is set to 0, then the low-order 8 bits Instance ID. If the L-bit is set to 0, then the low-order 8 bits
are transmitted as zero and ignored on receipt. The format of the are transmitted as zero and ignored on receipt. The format of the
LISP header would look like: LISP header would look like in this case:
x x x x 1 x x x x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version | |N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs | | Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags: The flags field is a 3-bit field is reserved for future flag flags: The flags field is a 3-bit field is reserved for future flag
use. It MUST be set to 0 on transmit and MUST be ignored on use. It MUST be set to 0 on transmit and MUST be ignored on
skipping to change at page 21, line 28 skipping to change at page 21, line 28
algorithms are an implementation matter but are required to algorithms are an implementation matter but are required to
generate different nonces when sending to different destinations. generate different nonces when sending to different destinations.
However, the same nonce can be used for a period of time to the However, the same nonce can be used for a period of time to the
same destination. The nonce is also used when the E-bit is set to same destination. The nonce is also used when the E-bit is set to
request the nonce value to be echoed by the other side when request the nonce value to be echoed by the other side when
packets are returned. When the E-bit is clear but the N-bit is packets are returned. When the E-bit is clear but the N-bit is
set, a remote ITR is either echoing a previously requested echo- set, a remote ITR is either echoing a previously requested echo-
nonce or providing a random nonce. See Section 6.3.1 for more nonce or providing a random nonce. See Section 6.3.1 for more
details. details.
LISP Locator Status Bits: The locator status bits field in the LISP LISP Locator Status Bits (LSBs): When the L-bit is also set, the
header is set by an ITR to indicate to an ETR the up/down status locator status bits field in the LISP header is set by an ITR to
of the Locators in the source site. Each RLOC in a Map-Reply is indicate to an ETR the up/down status of the Locators in the
assigned an ordinal value from 0 to n-1 (when there are n RLOCs in source site. Each RLOC in a Map-Reply is assigned an ordinal
a mapping entry). The Locator Status Bits are numbered from 0 to value from 0 to n-1 (when there are n RLOCs in a mapping entry).
n-1 from the least significant bit of field. The field is 32-bits The Locator Status Bits are numbered from 0 to n-1 from the least
when the I-bit is set to 0 and is 8 bits when the I-bit is set to significant bit of field. The field is 32-bits when the I-bit is
1. When a Locator Status Bit is set to 1, the ITR is indicating set to 0 and is 8 bits when the I-bit is set to 1. When a Locator
to the ETR the RLOC associated with the bit ordinal has up status. Status Bit is set to 1, the ITR is indicating to the ETR the RLOC
See Section 6.3 for details on how an ITR can determine the status associated with the bit ordinal has up status. See Section 6.3
of the ETRs at the same site. When a site has multiple EID- for details on how an ITR can determine the status of the ETRs at
prefixes which result in multiple mappings (where each could have the same site. When a site has multiple EID-prefixes which result
a different locator-set), the Locator Status Bits setting in an in multiple mappings (where each could have a different locator-
encapsulated packet MUST reflect the mapping for the EID-prefix set), the Locator Status Bits setting in an encapsulated packet
that the inner-header source EID address matches. If the LSB for MUST reflect the mapping for the EID-prefix that the inner-header
an anycast locator is set to 1, then there is at least one RLOC source EID address matches. If the LSB for an anycast locator is
with that address the ETR is considered 'up'. set to 1, then there is at least one RLOC with that address the
ETR is considered 'up'.
When doing ITR/PITR encapsulation: When doing ITR/PITR encapsulation:
o The outer header Time to Live field (or Hop Limit field, in case o The outer header Time to Live field (or Hop Limit field, in case
of IPv6) SHOULD be copied from the inner header Time to Live of IPv6) SHOULD be copied from the inner header Time to Live
field. field.
o The outer header Type of Service field (or the Traffic Class o The outer header Type of Service field (or the Traffic Class
field, in the case of IPv6) SHOULD be copied from the inner header field, in the case of IPv6) SHOULD be copied from the inner header
Type of Service field (with one caveat, see below). Type of Service field (with one caveat, see below).
skipping to change at page 23, line 30 skipping to change at page 23, line 30
An ITR stateless solution to handle MTU issues is described as An ITR stateless solution to handle MTU issues is described as
follows: follows:
1. Define an architectural constant S for the maximum size of a 1. Define an architectural constant S for the maximum size of a
packet, in bytes, an ITR would like to receive from a source packet, in bytes, an ITR would like to receive from a source
inside of its site. inside of its site.
2. Define L to be the maximum size, in bytes, a packet of size S 2. Define L to be the maximum size, in bytes, a packet of size S
would be after the ITR prepends the LISP header, UDP header, and would be after the ITR prepends the LISP header, UDP header, and
outer network layer header of size H. outer network layer header of size H. Therefore, S + H = L.
3. Calculate: S + H = L.
When an ITR receives a packet from a site-facing interface and adds H When an ITR receives a packet from a site-facing interface and adds H
bytes worth of encapsulation to yield a packet size greater than L bytes worth of encapsulation to yield a packet size greater than L
bytes, it resolves the MTU issue by first splitting the original bytes, it resolves the MTU issue by first splitting the original
packet into 2 equal-sized fragments. A LISP header is then prepended packet into 2 equal-sized fragments. A LISP header is then prepended
to each fragment. The size of the encapsulated fragments is then to each fragment. The size of the encapsulated fragments is then
(S/2 + H), which is less than the ITR's estimate of the path MTU (S/2 + H), which is less than the ITR's estimate of the path MTU
between the ITR and its correspondent ETR. between the ITR and its correspondent ETR.
When an ETR receives encapsulated fragments, it treats them as two When an ETR receives encapsulated fragments, it treats them as two
skipping to change at page 24, line 12 skipping to change at page 24, line 11
originated by the source host, the ITR will drop the packet when the originated by the source host, the ITR will drop the packet when the
size is greater than L, and sends an ICMP Too Big message to the size is greater than L, and sends an ICMP Too Big message to the
source with a value of S, where S is (L - H). source with a value of S, where S is (L - H).
When the outer header encapsulation uses an IPv4 header, an When the outer header encapsulation uses an IPv4 header, an
implementation SHOULD set the DF bit to 1 so ETR fragment reassembly implementation SHOULD set the DF bit to 1 so ETR fragment reassembly
can be avoided. An implementation MAY set the DF bit in such headers can be avoided. An implementation MAY set the DF bit in such headers
to 0 if it has good reason to believe there are unresolvable path MTU to 0 if it has good reason to believe there are unresolvable path MTU
issues between the sending ITR and the receiving ETR. issues between the sending ITR and the receiving ETR.
This specification recommends that L be defined as 1500. This specification RECOMMENDS that L be defined as 1500.
5.4.2. A Stateful Solution to MTU Handling 5.4.2. A Stateful Solution to MTU Handling
An ITR stateful solution to handle MTU issues is described as follows An ITR stateful solution to handle MTU issues is described as follows
and was first introduced in [OPENLISP]: and was first introduced in [OPENLISP]:
1. The ITR will keep state of the effective MTU for each locator per 1. The ITR will keep state of the effective MTU for each locator per
mapping cache entry. The effective MTU is what the core network mapping cache entry. The effective MTU is what the core network
can deliver along the path between ITR and ETR. can deliver along the path between ITR and ETR.
skipping to change at page 27, line 35 skipping to change at page 27, line 35
source port or destination UDP port is set to 4342 due to NATs source port or destination UDP port is set to 4342 due to NATs
changing port number values. changing port number values.
The UDP Length field will reflect the length of the UDP header and The UDP Length field will reflect the length of the UDP header and
the LISP Message payload. the LISP Message payload.
The UDP Checksum is computed and set to non-zero for Map-Request, The UDP Checksum is computed and set to non-zero for Map-Request,
Map-Reply, Map-Register and ECM control messages. It MUST be checked Map-Reply, Map-Register and ECM control messages. It MUST be checked
on receipt and if the checksum fails, the packet MUST be dropped. on receipt and if the checksum fails, the packet MUST be dropped.
LISP-CONS [CONS] uses TCP to send LISP control messages. The format The format of control messages includes the UDP header so the
of control messages includes the UDP header so the checksum and checksum and length fields can be used to protect and delimit message
length fields can be used to protect and delimit message boundaries. boundaries.
This main LISP specification is the authoritative source for message This main LISP specification is the authoritative source for message
format definitions for the Map-Request and Map-Reply messages. format definitions for the Map-Request and Map-Reply messages.
6.1.1. LISP Packet Type Allocations 6.1.1. LISP Packet Type Allocations
This section will be the authoritative source for allocating LISP This section will be the authoritative source for allocating LISP
Type values. Current allocations are: Type values. Current allocations are:
Reserved: 0 b'0000' Reserved: 0 b'0000'
skipping to change at page 29, line 8 skipping to change at page 29, line 8
| Map-Reply Record ... | | Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data | | Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 1 (Map-Request) Type: 1 (Map-Request)
A: This is an authoritative bit, which is set to 0 for UDP-based Map- A: This is an authoritative bit, which is set to 0 for UDP-based Map-
Requests sent by an ITR. Requests sent by an ITR. Set to 1 when an ITR wants the
destination site to return the Map-Reply rather than the mapping
database system.
M: This is the map-data-present bit, when set, it indicates a Map- M: This is the map-data-present bit, when set, it indicates a Map-
Reply Record segment is included in the Map-Request. Reply Record segment is included in the Map-Request.
P: This is the probe-bit which indicates that a Map-Request SHOULD be P: This is the probe-bit which indicates that a Map-Request SHOULD be
treated as a locator reachability probe. The receiver SHOULD treated as a locator reachability probe. The receiver SHOULD
respond with a Map-Reply with the probe-bit set, indicating the respond with a Map-Reply with the probe-bit set, indicating the
Map-Reply is a locator reachability probe reply, with the nonce Map-Reply is a locator reachability probe reply, with the nonce
copied from the Map-Request. See Section 6.3.2 for more details. copied from the Map-Request. See Section 6.3.2 for more details.
skipping to change at page 29, line 35 skipping to change at page 29, line 37
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is
sending a Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received SMR-based Map-
Request. Request.
Reserved: It MUST be set to 0 on transmit and MUST be ignored on Reserved: It MUST be set to 0 on transmit and MUST be ignored on
receipt. receipt.
IRC: This 5-bit field is the ITR-RLOC Count which encodes the IRC: This 5-bit field is the ITR-RLOC Count which encodes the
additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-
Address) pair must always be encoded. Multiple ITR-RLOC Address Address) pair MUST be encoded. Multiple ITR-RLOC Address fields
fields are used so a Map-Replier can select which destination are used so a Map-Replier can select which destination address to
address to use for a Map-Reply. The IRC value ranges from 0 to use for a Map-Reply. The IRC value ranges from 0 to 31. For a
31. For a value of 0, there is 1 ITR-RLOC address encoded, and value of 0, there is 1 ITR-RLOC address encoded, and for a value
for a value of 1, there are 2 ITR-RLOC addresses encoded and so on of 1, there are 2 ITR-RLOC addresses encoded and so on up to 31
up to 31 which encodes a total of 32 ITR-RLOC addresses. which encodes a total of 32 ITR-RLOC addresses.
Record Count: The number of records in this Map-Request message. A Record Count: The number of records in this Map-Request message. A
record is comprised of the portion of the packet that is labeled record is comprised of the portion of the packet that is labeled
'Rec' above and occurs the number of times equal to Record Count. 'Rec' above and occurs the number of times equal to Record Count.
For this version of the protocol, a receiver MUST accept and For this version of the protocol, a receiver MUST accept and
process Map-Requests that contain one or more records, but a process Map-Requests that contain one or more records, but a
sender MUST only send Map-Requests containing one record. Support sender MUST only send Map-Requests containing one record. Support
for requesting multiple EIDs in a single Map-Request message will for requesting multiple EIDs in a single Map-Request message will
be specified in a future version of the protocol. be specified in a future version of the protocol.
skipping to change at page 30, line 16 skipping to change at page 30, line 16
Request. This nonce will be returned in the Map-Reply. The Request. This nonce will be returned in the Map-Reply. The
security of the LISP mapping protocol depends critically on the security of the LISP mapping protocol depends critically on the
strength of the nonce in the Map-Request message. The nonce strength of the nonce in the Map-Request message. The nonce
SHOULD be generated by a properly seeded pseudo-random (or strong SHOULD be generated by a properly seeded pseudo-random (or strong
random) source. See [RFC4086] for advice on generating security- random) source. See [RFC4086] for advice on generating security-
sensitive random data. sensitive random data.
Source-EID-AFI: Address family of the "Source EID Address" field. Source-EID-AFI: Address family of the "Source EID Address" field.
Source EID Address: This is the EID of the source host which Source EID Address: This is the EID of the source host which
originated the packet which is invoking this Map-Request. When originated the packet which is caused the Map-Request. When Map-
Map-Requests are used for refreshing a map-cache entry or for Requests are used for refreshing a map-cache entry or for RLOC-
RLOC-probing, an AFI value 0 is used and this field is of zero probing, an AFI value 0 is used and this field is of zero length.
length.
ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that
follows this field. follows this field.
ITR-RLOC Address: Used to give the ETR the option of selecting the ITR-RLOC Address: Used to give the ETR the option of selecting the
destination address from any address family for the Map-Reply destination address from any address family for the Map-Reply
message. This address MUST be a routable RLOC address of the message. This address MUST be a routable RLOC address of the
sender of the Map-Request message. sender of the Map-Request message.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
skipping to change at page 31, line 5 skipping to change at page 30, line 49
prefix used in the Map-Request has the same mask-length as the prefix used in the Map-Request has the same mask-length as the
EID-prefix returned from the site when it sent a Map-Reply EID-prefix returned from the site when it sent a Map-Reply
message. message.
Map-Reply Record: When the M bit is set, this field is the size of a Map-Reply Record: When the M bit is set, this field is the size of a
single "Record" in the Map-Reply format. This Map-Reply record single "Record" in the Map-Reply format. This Map-Reply record
contains the EID-to-RLOC mapping entry associated with the Source contains the EID-to-RLOC mapping entry associated with the Source
EID. This allows the ETR which will receive this Map-Request to EID. This allows the ETR which will receive this Map-Request to
cache the data if it chooses to do so. cache the data if it chooses to do so.
Mapping Protocol Data: See [CONS] for details. This field is Mapping Protocol Data: This field is optional and present when the
optional and present when the UDP length indicates there is enough UDP length indicates there is enough space in the packet to
space in the packet to include it. include it.
6.1.3. EID-to-RLOC UDP Map-Request Message 6.1.3. EID-to-RLOC UDP Map-Request Message
A Map-Request is sent from an ITR when it needs a mapping for an EID, A Map-Request is sent from an ITR when it needs a mapping for an EID,
wants to test an RLOC for reachability, or wants to refresh a mapping wants to test an RLOC for reachability, or wants to refresh a mapping
before TTL expiration. For the initial case, the destination IP before TTL expiration. For the initial case, the destination IP
address used for the Map-Request is the destination-EID from the address used for the Map-Request is the destination-EID from the
packet which had a mapping cache lookup failure. For the latter two packet which had a mapping cache lookup failure. For the latter two
cases, the destination IP address used for the Map-Request is one of cases, the destination IP address used for the Map-Request is one of
the RLOC addresses from the locator-set of the map cache entry. The the RLOC addresses from the locator-set of the map cache entry. The
skipping to change at page 31, line 42 skipping to change at page 31, line 38
provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
Request. Request.
Map-Requests can also be LISP encapsulated using UDP destination port Map-Requests can also be LISP encapsulated using UDP destination port
4342 with a LISP type value set to "Encapsulated Control Message", 4342 with a LISP type value set to "Encapsulated Control Message",
when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are when sent from an ITR to a Map-Resolver. Likewise, Map-Requests are
LISP encapsulated the same way from a Map-Server to an ETR. Details LISP encapsulated the same way from a Map-Server to an ETR. Details
on encapsulated Map-Requests and Map-Resolvers can be found in on encapsulated Map-Requests and Map-Resolvers can be found in
[LISP-MS]. [LISP-MS].
Map-Requests MUST be rate-limited. It is recommended that a Map- Map-Requests MUST be rate-limited. It is RECOMMENDED that a Map-
Request for the same EID-prefix be sent no more than once per second. Request for the same EID-prefix be sent no more than once per second.
An ITR that is configured with mapping database information (i.e. it An ITR that is configured with mapping database information (i.e. it
is also an ETR) may optionally include those mappings in a Map- is also an ETR) MAY optionally include those mappings in a Map-
Request. When an ETR configured to accept and verify such Request. When an ETR configured to accept and verify such
"piggybacked" mapping data receives such a Map-Request and it does "piggybacked" mapping data receives such a Map-Request and it does
not have this mapping in the map-cache, it may originate a "verifying not have this mapping in the map-cache, it may originate a "verifying
Map-Request", addressed to the map-requesting ITR. If the ETR has a Map-Request", addressed to the map-requesting ITR. If the ETR has a
map-cache entry that matches the "piggybacked" EID and the RLOC is in map-cache entry that matches the "piggybacked" EID and the RLOC is in
the locator-set for the entry, then it may send the "verifying Map- the locator-set for the entry, then it may send the "verifying Map-
Request" directly to the originating Map-Request source. If the RLOC Request" directly to the originating Map-Request source. If the RLOC
is not in the locator-set, then the ETR MUST send the "verifying Map- is not in the locator-set, then the ETR MUST send the "verifying Map-
Request" to the "piggybacked" EID. Doing this forces the "verifying Request" to the "piggybacked" EID. Doing this forces the "verifying
Map-Request" to go through the mapping database system to reach the Map-Request" to go through the mapping database system to reach the
skipping to change at page 33, line 29 skipping to change at page 33, line 25
Reserved: It MUST be set to 0 on transmit and MUST be ignored on Reserved: It MUST be set to 0 on transmit and MUST be ignored on
receipt. receipt.
Record Count: The number of records in this reply message. A record Record Count: The number of records in this reply message. A record
is comprised of that portion of the packet labeled 'Record' above is comprised of that portion of the packet labeled 'Record' above
and occurs the number of times equal to Record count. and occurs the number of times equal to Record count.
Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value
from the Map-Request is echoed in this Nonce field of the Map- from the Map-Request is echoed in this Nonce field of the Map-
Reply. Reply. When a 24-bit value is supplied, it resides in the low-
order 64 bits of the nonce field.
Record TTL: The time in minutes the recipient of the Map-Reply will Record TTL: The time in minutes the recipient of the Map-Reply will
store the mapping. If the TTL is 0, the entry SHOULD be removed store the mapping. If the TTL is 0, the entry SHOULD be removed
from the cache immediately. If the value is 0xffffffff, the from the cache immediately. If the value is 0xffffffff, the
recipient can decide locally how long to store the mapping. recipient can decide locally how long to store the mapping.
Locator Count: The number of Locator entries. A locator entry Locator Count: The number of Locator entries. A locator entry
comprises what is labeled above as 'Loc'. The locator count can comprises what is labeled above as 'Loc'. The locator count can
be 0 indicating there are no locators for the EID-prefix. be 0 indicating there are no locators for the EID-prefix.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
ACT: This 3-bit field describes negative Map-Reply actions. These ACT: This 3-bit field describes negative Map-Reply actions. In any
bits are used only when the 'Locator Count' field is set to 0. other message type, these bits are set to 0 and ignored on
The action bits are encoded only in Map-Reply messages. The receipt. These bits are used only when the 'Locator Count' field
actions defined are used by an ITR or PTR when a destination EID is set to 0. The action bits are encoded only in Map-Reply
matches a negative mapping cache entry. Unassigned values should messages. The actions defined are used by an ITR or PITR when a
cause a map-cache entry to be created and, when packets match this destination EID matches a negative mapping cache entry.
negative cache entry, they will be dropped. The current assigned Unassigned values should cause a map-cache entry to be created
values are: and, when packets match this negative cache entry, they will be
dropped. The current assigned values are:
(0) No-Action: The map-cache is kept alive and no packet (0) No-Action: The map-cache is kept alive and no packet
encapsulation occurs. encapsulation occurs.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Send-Map-Request: The packet invokes sending a Map-Request. (2) Send-Map-Request: The packet invokes sending a Map-Request.
(3) Drop: A packet that matches this map-cache entry is dropped. (3) Drop: A packet that matches this map-cache entry is dropped.
An ICMP Unreachable message SHOULD be sent. An ICMP Unreachable message SHOULD be sent.
A: The Authoritative bit, when sent by a UDP-based message is always A: The Authoritative bit, when sent is always set to 1 by an ETR.
set to 1 by an ETR. See [CONS] for TCP-based Map-Replies. When a When a Map-Server is proxy Map-Replying [LISP-MS] for a LISP site,
Map-Server is proxy Map-Replying [LISP-MS] for a LISP site, the the Authoritative bit is set to 0. This indicates to requesting
Authoritative bit is set to 0. This indicates to requesting ITRs ITRs that the Map-Reply was not originated by a LISP node managed
that the Map-Reply was not originated by a LISP node managed at at the site that owns the EID-prefix.
the site that owns the EID-prefix.
Map-Version Number: When this 12-bit value is non-zero the Map-Reply Map-Version Number: When this 12-bit value is non-zero the Map-Reply
sender is informing the ITR what the version number is for the sender is informing the ITR what the version number is for the
EID-record contained in the Map-Reply. The ETR can allocate this EID-record contained in the Map-Reply. The ETR can allocate this
number internally but MUST coordinate this value with other ETRs number internally but MUST coordinate this value with other ETRs
for the site. When this value is 0, there is no versioning for the site. When this value is 0, there is no versioning
information conveyed. The Map-Version Number can be included in information conveyed. The Map-Version Number can be included in
Map-Request and Map-Register messages. See Section 6.6.3 for more Map-Request and Map-Register messages. See Section 6.6.3 for more
details. details.
EID-prefix-AFI: Address family of EID-prefix according to [AFI]. EID-prefix-AFI: Address family of EID-prefix according to [AFI].
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family. address-family.
Priority: each RLOC is assigned a unicast priority. Lower values Priority: each RLOC is assigned a unicast priority. Lower values
are more preferable. When multiple RLOCs have the same priority, are more preferable. When multiple RLOCs have the same priority,
they may be used in a load-split fashion. A value of 255 means they MAY be used in a load-split fashion. A value of 255 means
the RLOC MUST NOT be used for unicast forwarding. the RLOC MUST NOT be used for unicast forwarding.
Weight: when priorities are the same for multiple RLOCs, the weight Weight: when priorities are the same for multiple RLOCs, the weight
indicates how to balance unicast traffic between them. Weight is indicates how to balance unicast traffic between them. Weight is
encoded as a relative weight of total unicast packets that match encoded as a relative weight of total unicast packets that match
the mapping entry. For example if there are 4 locators in a the mapping entry. For example if there are 4 locators in a
locator set, where the weights assigned are 30, 20, 20, and 10, locator set, where the weights assigned are 30, 20, 20, and 10,
the first locator will get 37.5% of the traffic, the 2nd and 3rd the first locator will get 37.5% of the traffic, the 2nd and 3rd
locators will get 25% of traffic and the 4th locator will get locators will get 25% of traffic and the 4th locator will get
12.5% of the traffic. If all weights for a locator-set are equal, 12.5% of the traffic. If all weights for a locator-set are equal,
skipping to change at page 35, line 31 skipping to change at page 35, line 29
Unused Flags: set to 0 when sending and ignored on receipt. Unused Flags: set to 0 when sending and ignored on receipt.
L: when this bit is set, the locator is flagged as a local locator to L: when this bit is set, the locator is flagged as a local locator to
the ETR that is sending the Map-Reply. When a Map-Server is doing the ETR that is sending the Map-Reply. When a Map-Server is doing
proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
0 for all locators in this locator-set. 0 for all locators in this locator-set.
p: when this bit is set, an ETR informs the RLOC-probing ITR that the p: when this bit is set, an ETR informs the RLOC-probing ITR that the
locator address, for which this bit is set, is the one being RLOC- locator address, for which this bit is set, is the one being RLOC-
probed and may be different from the source address of the Map- probed and MAY be different from the source address of the Map-
Reply. An ITR that RLOC-probes a particular locator, MUST use Reply. An ITR that RLOC-probes a particular locator, MUST use
this locator for retrieving the data structure used to store the this locator for retrieving the data structure used to store the
fact that the locator is reachable. The "p" bit is set for a fact that the locator is reachable. The "p" bit is set for a
single locator in the same locator set. If an implementation sets single locator in the same locator set. If an implementation sets
more than one "p" bit erroneously, the receiver of the Map-Reply more than one "p" bit erroneously, the receiver of the Map-Reply
MUST select the first locator. The "p" bit MUST NOT be set for MUST select the first locator. The "p" bit MUST NOT be set for
locator-set records sent in Map-Request and Map-Register messages. locator-set records sent in Map-Request and Map-Register messages.
R: set when the sender of a Map-Reply has a route to the locator in R: set when the sender of a Map-Reply has a route to the locator in
the locator data record. This receiver may find this useful to the locator data record. This receiver may find this useful to
skipping to change at page 36, line 7 skipping to change at page 36, line 6
Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
assigned to an ETR. Note that the destination RLOC address MAY be assigned to an ETR. Note that the destination RLOC address MAY be
an anycast address. A source RLOC can be an anycast address as an anycast address. A source RLOC can be an anycast address as
well. The source or destination RLOC MUST NOT be the broadcast well. The source or destination RLOC MUST NOT be the broadcast
address (255.255.255.255 or any subnet broadcast address known to address (255.255.255.255 or any subnet broadcast address known to
the router), and MUST NOT be a link-local multicast address. The the router), and MUST NOT be a link-local multicast address. The
source RLOC MUST NOT be a multicast address. The destination RLOC source RLOC MUST NOT be a multicast address. The destination RLOC
SHOULD be a multicast address if it is being mapped from a SHOULD be a multicast address if it is being mapped from a
multicast destination EID. multicast destination EID.
Mapping Protocol Data: See [CONS] for details. This field is Mapping Protocol Data: This field is optional and present when the
optional and present when the UDP length indicates there is enough UDP length indicates there is enough space in the packet to
space in the packet to include it. The Mapping Protocol Data is include it.
used when needed by the particular mapping system.
6.1.5. EID-to-RLOC UDP Map-Reply Message 6.1.5. EID-to-RLOC UDP Map-Reply Message
A Map-Reply returns an EID-prefix with a prefix length that is less A Map-Reply returns an EID-prefix with a prefix length that is less
than or equal to the EID being requested. The EID being requested is than or equal to the EID being requested. The EID being requested is
either from the destination field of an IP header of a Data-Probe or either from the destination field of an IP header of a Data-Probe or
the EID record of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the Map-Reply are
globally-routable IP addresses of all ETRs for the LISP site. Each globally-routable IP addresses of all ETRs for the LISP site. Each
RLOC conveys status reachability but does not convey path RLOC conveys status reachability but does not convey path
reachability from a requesters perspective. Separate testing of path reachability from a requesters perspective. Separate testing of path
skipping to change at page 37, line 28 skipping to change at page 37, line 27
map-cache while keeping less-specific entries. map-cache while keeping less-specific entries.
Map-Replies SHOULD be sent for an EID-prefix no more often than once Map-Replies SHOULD be sent for an EID-prefix no more often than once
per second to the same requesting router. For scalability, it is per second to the same requesting router. For scalability, it is
expected that aggregation of EID addresses into EID-prefixes will expected that aggregation of EID addresses into EID-prefixes will
allow one Map-Reply to satisfy a mapping for the EID addresses in the allow one Map-Reply to satisfy a mapping for the EID addresses in the
prefix range thereby reducing the number of Map-Request messages. prefix range thereby reducing the number of Map-Request messages.
Map-Reply records can have an empty locator-set. A negative Map- Map-Reply records can have an empty locator-set. A negative Map-
Reply is a Map-Reply with an empty locator-set. Negative Map-Replies Reply is a Map-Reply with an empty locator-set. Negative Map-Replies
convey special actions by the sender to the ITR or PTR which have convey special actions by the sender to the ITR or PITR which have
solicited the Map-Reply. There are two primary applications for solicited the Map-Reply. There are two primary applications for
Negative Map-Replies. The first is for a Map-Resolver to instruct an Negative Map-Replies. The first is for a Map-Resolver to instruct an
ITR or PTR when a destination is for a LISP site versus a non-LISP ITR or PITR when a destination is for a LISP site versus a non-LISP
site. And the other is to source quench Map-Requests which are sent site. And the other is to source quench Map-Requests which are sent
for non-allocated EIDs. for non-allocated EIDs.
For each Map-Reply record, the list of locators in a locator-set MUST For each Map-Reply record, the list of locators in a locator-set MUST
appear in the same order for each ETR that originates a Map-Reply appear in the same order for each ETR that originates a Map-Reply
message. The locator-set MUST be sorted in order of ascending IP message. The locator-set MUST be sorted in order of ascending IP
address where an IPv4 locator address is considered numerically 'less address where an IPv4 locator address is considered numerically 'less
than' an IPv6 locator address. than' an IPv6 locator address.
When sending a Map-Reply message, the destination address is copied When sending a Map-Reply message, the destination address is copied
skipping to change at page 38, line 16 skipping to change at page 38, line 16
When an ETR is misconfigured or compromised, it could return coarse When an ETR is misconfigured or compromised, it could return coarse
EID-prefixes in Map-Reply messages it sends. The EID-prefix could EID-prefixes in Map-Reply messages it sends. The EID-prefix could
cover EID-prefixes which are allocated to other sites redirecting cover EID-prefixes which are allocated to other sites redirecting
their traffic to the locators of the compromised site. their traffic to the locators of the compromised site.
To solve this problem, there are two basic solutions that could be To solve this problem, there are two basic solutions that could be
used. The first is to have Map-Servers proxy-map-reply on behalf of used. The first is to have Map-Servers proxy-map-reply on behalf of
ETRs so their registered EID-prefixes are the ones returned in Map- ETRs so their registered EID-prefixes are the ones returned in Map-
Replies. Since the interaction between an ETR and Map-Server is Replies. Since the interaction between an ETR and Map-Server is
secured with shared-keys, it is more difficult for an ETR to secured with shared-keys, it is easier for an ETR to detect
misbehave. The second solution is to have ITRs and PTRs cache EID- misbehavior. The second solution is to have ITRs and PITRs cache
prefixes with mask-lengths that are greater than or equal to a EID-prefixes with mask-lengths that are greater than or equal to a
configured prefix length. This limits the damage to a specific width configured prefix length. This limits the damage to a specific width
of any EID-prefix advertised, but needs to be coordinated with the of any EID-prefix advertised, but needs to be coordinated with the
allocation of site prefixes. These solutions can be used allocation of site prefixes. These solutions can be used
independently or at the same time. independently or at the same time.
At the time of this writing, other approaches are being considered At the time of this writing, other approaches are being considered
and researched. and researched.
6.1.6. Map-Register Message Format 6.1.6. Map-Register Message Format
skipping to change at page 39, line 40 skipping to change at page 39, line 40
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map- P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map-
Register message requesting for the Map-Server to proxy Map-Reply. Register message requesting for the Map-Server to proxy Map-Reply.
The Map-Server will send non-authoritative Map-Replies on behalf The Map-Server will send non-authoritative Map-Replies on behalf
of the ETR. Details on this usage will be provided in a future of the ETR. Details on this usage can be found in [LISP-MS].
version of this draft.
Reserved: It MUST be set to 0 on transmit and MUST be ignored on Reserved: It MUST be set to 0 on transmit and MUST be ignored on
receipt. receipt.
M: This is the want-map-notify bit, when set to 1 an ETR is M: This is the want-map-notify bit, when set to 1 an ETR is
requesting for a Map-Notify message to be returned in response to requesting for a Map-Notify message to be returned in response to
sending a Map-Register message. The Map-Notify message sent by a sending a Map-Register message. The Map-Notify message sent by a
Map-Server is used to an acknowledge receipt of a Map-Register Map-Server is used to an acknowledge receipt of a Map-Register
message. message.
Record Count: The number of records in this Map-Register message. A Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record' record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages.
Since the Map-Register message is authenticated, the nonce field
is not needed for any security function.
Key ID: A configured ID to find the configured Message Key ID: A configured ID to find the configured Message
Authentication Code (MAC) algorithm and key value used for the Authentication Code (MAC) algorithm and key value used for the
authentication function. See Section 14.4 for codepoint authentication function. See Section 14.4 for codepoint
assignments. assignments.
Authentication Data Length: The length in bytes of the Authentication Data Length: The length in bytes of the
Authentication Data field that follows this field. The length of Authentication Data field that follows this field. The length of
the Authentication Data field is dependent on the Message the Authentication Data field is dependent on the Message
Authentication Code (MAC) algorithm used. The length field allows Authentication Code (MAC) algorithm used. The length field allows
a device that doesn't know the MAC algorithm to correctly parse a device that doesn't know the MAC algorithm to correctly parse
the packet. the packet.
Authentication Data: The message digest used from the output of the Authentication Data: The message digest used from the output of the
Message Authentication Code (MAC) algorithm. The entire Map- Message Authentication Code (MAC) algorithm. The entire Map-
Register payload is authenticated with this field preset to 0. Register payload is authenticated with this field preset to 0.
After the MAC is computed, it is placed in this field. After the MAC is computed, it is placed in this field.
Implementations of this specification MUST include support for Implementations of this specification MUST include support for
HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-256-128 [RFC6234] HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-256-128 [RFC6234]
is recommended. is RECOMMENDED.
The definition of the rest of the Map-Register can be found in the The definition of the rest of the Map-Register can be found in the
Map-Reply section. Map-Reply section.
6.1.7. Map-Notify Message Format 6.1.7. Map-Notify Message Format
The usage details of the Map-Notify message can be found in The usage details of the Map-Notify message can be found in
specification [LISP-MS]. This section solely defines the message specification [LISP-MS]. This section solely defines the message
format. format.
The message is sent inside a UDP packet with a source UDP port equal The message is sent inside a UDP packet with source and destination
to 4342 and a destination port equal to the source port from the Map- UDP ports equal to 4342.
Register message this Map-Notify message is responding to.
The Map-Notify message format is: The Map-Notify message format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 | Reserved | Record Count | |Type=4 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 43, line 26 skipping to change at page 43, line 26
UDP: The inner UDP header where the port assignments depends on the UDP: The inner UDP header where the port assignments depends on the
control packet being encapsulated. When the control packet is a control packet being encapsulated. When the control packet is a
Map-Request or Map-Register, the source port is ITR/PITR selected Map-Request or Map-Register, the source port is ITR/PITR selected
and the destination port is 4342. When the control packet is a and the destination port is 4342. When the control packet is a
Map-Reply, the source port is 4342 and the destination port is Map-Reply, the source port is 4342 and the destination port is
assigned from the source port of the invoking Map-Request. Port assigned from the source port of the invoking Map-Request. Port
number 4341 MUST NOT be assigned to either port. The checksum number 4341 MUST NOT be assigned to either port. The checksum
field MUST be non-zero. field MUST be non-zero.
LCM: The format is one of the control message formats described in LCM: The format is one of the control message formats described in
this section. At this time, only Map-Request messages and PIM this section. At this time, only Map-Request messages are allowed
Join-Prune messages [MLISP] are allowed to be encapsulated. to be encapsulated. And in the future, PIM Join-Prune messages
Encapsulating other types of LISP control messages are for further [MLISP] might be allowed. Encapsulating other types of LISP
study. When Map-Requests are sent for RLOC-probing purposes (i.e control messages are for further study. When Map-Requests are
the probe-bit is set), they MUST NOT be sent inside Encapsulated sent for RLOC-probing purposes (i.e the probe-bit is set), they
Control Messages. MUST NOT be sent inside Encapsulated Control Messages.
6.2. Routing Locator Selection 6.2. Routing Locator Selection
Both client-side and server-side may need control over the selection Both client-side and server-side may need control over the selection
of RLOCs for conversations between them. This control is achieved by of RLOCs for conversations between them. This control is achieved by
manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
messages. Alternatively, RLOC information may be gleaned from messages. Alternatively, RLOC information MAY be gleaned from
received tunneled packets or EID-to-RLOC Map-Request messages. received tunneled packets or EID-to-RLOC Map-Request messages.
The following enumerates different scenarios for choosing RLOCs and The following enumerates different scenarios for choosing RLOCs and
the controls that are available: the controls that are available:
o Server-side returns one RLOC. Client-side can only use one RLOC. o Server-side returns one RLOC. Client-side can only use one RLOC.
Server-side has complete control of the selection. Server-side has complete control of the selection.
o Server-side returns a list of RLOC where a subset of the list has o Server-side returns a list of RLOC where a subset of the list has
the same best priority. Client can only use the subset list the same best priority. Client can only use the subset list
skipping to change at page 45, line 33 skipping to change at page 45, line 33
3. An ITR which participates in the global routing system can 3. An ITR which participates in the global routing system can
determine that an RLOC is down if no BGP RIB route exists that determine that an RLOC is down if no BGP RIB route exists that
matches the RLOC IP address. matches the RLOC IP address.
4. An ITR may receive an ICMP Port Unreachable message from a 4. An ITR may receive an ICMP Port Unreachable message from a
destination host. This occurs if an ITR attempts to use destination host. This occurs if an ITR attempts to use
interworking [INTERWORK] and LISP-encapsulated data is sent to a interworking [INTERWORK] and LISP-encapsulated data is sent to a
non-LISP-capable site. non-LISP-capable site.
5. An ITR may receive a Map-Reply from a ETR in response to a 5. An ITR may receive a Map-Reply from an ETR in response to a
previously sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of the Map-Reply is
likely up since the ETR was able to send the Map-Reply to the likely up since the ETR was able to send the Map-Reply to the
ITR. ITR.
6. When an ETR receives an encapsulated packet from an ITR, the 6. When an ETR receives an encapsulated packet from an ITR, the
source RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet is likely up.
7. An ITR/ETR pair can use the Locator Reachability Algorithms 7. An ITR/ETR pair can use the Locator Reachability Algorithms
described in this section, namely Echo-Noncing or RLOC-Probing. described in this section, namely Echo-Noncing or RLOC-Probing.
skipping to change at page 47, line 41 skipping to change at page 47, line 41
use the lack of return traffic as an indication that the ETR is use the lack of return traffic as an indication that the ETR is
unreachable. Instead, it MUST use an alternate mechanisms to unreachable. Instead, it MUST use an alternate mechanisms to
determine reachability. determine reachability.
6.3.1. Echo Nonce Algorithm 6.3.1. Echo Nonce Algorithm
When data flows bidirectionally between locators from different When data flows bidirectionally between locators from different
sites, a data-plane mechanism called "nonce echoing" can be used to sites, a data-plane mechanism called "nonce echoing" can be used to
determine reachability between an ITR and ETR. When an ITR wants to determine reachability between an ITR and ETR. When an ITR wants to
solicit a nonce echo, it sets the N and E bits and places a 24-bit solicit a nonce echo, it sets the N and E bits and places a 24-bit
nonce in the LISP header of the next encapsulated data packet. nonce [RFC4086] in the LISP header of the next encapsulated data
packet.
When this packet is received by the ETR, the encapsulated packet is When this packet is received by the ETR, the encapsulated packet is
forwarded as normal. When the ETR next sends a data packet to the forwarded as normal. When the ETR next sends a data packet to the
ITR, it includes the nonce received earlier with the N bit set and E ITR, it includes the nonce received earlier with the N bit set and E
bit cleared. The ITR sees this "echoed nonce" and knows the path to bit cleared. The ITR sees this "echoed nonce" and knows the path to
and from the ETR is up. and from the ETR is up.
The ITR will set the E-bit and N-bit for every packet it sends while The ITR will set the E-bit and N-bit for every packet it sends while
in echo-nonce-request state. The time the ITR waits to process the in echo-nonce-request state. The time the ITR waits to process the
echoed nonce before it determines the path is unreachable is variable echoed nonce before it determines the path is unreachable is variable
skipping to change at page 48, line 43 skipping to change at page 48, line 44
the E-bit in a encapsulated data packet when it knows the ETR is the E-bit in a encapsulated data packet when it knows the ETR is
enabled for echo-noncing. This is conveyed by the E-bit in the Map- enabled for echo-noncing. This is conveyed by the E-bit in the Map-
Reply message. Reply message.
Note that other locator reachability mechanisms are being researched Note that other locator reachability mechanisms are being researched
and can be used to compliment or even override the Echo Nonce and can be used to compliment or even override the Echo Nonce
Algorithm. See next section for an example of control-plane probing. Algorithm. See next section for an example of control-plane probing.
6.3.2. RLOC Probing Algorithm 6.3.2. RLOC Probing Algorithm
RLOC Probing is a method that an ITR or PTR can use to determine the RLOC Probing is a method that an ITR or PITR can use to determine the
reachability status of one or more locators that it has cached in a reachability status of one or more locators that it has cached in a
map-cache entry. The probe-bit of the Map-Request and Map-Reply map-cache entry. The probe-bit of the Map-Request and Map-Reply
messages are used for RLOC Probing. messages are used for RLOC Probing.
RLOC probing is done in the control-plane on a timer basis where an RLOC probing is done in the control-plane on a timer basis where an
ITR or PTR will originate a Map-Request destined to a locator address ITR or PITR will originate a Map-Request destined to a locator
from one of its own locator addresses. A Map-Request used as an address from one of its own locator addresses. A Map-Request used as
RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on the an RLOC-probe is NOT encapsulated and NOT sent to a Map-Server or on
ALT like one would when soliciting mapping data. The EID record the ALT like one would when soliciting mapping data. The EID record
encoded in the Map-Request is the EID-prefix of the map-cache entry encoded in the Map-Request is the EID-prefix of the map-cache entry
cached by the ITR or PTR. The ITR may include a mapping data record cached by the ITR or PITR. The ITR may include a mapping data record
for its own database mapping information which contains the local for its own database mapping information which contains the local
EID-prefixes and RLOCs for its site. EID-prefixes and RLOCs for its site.
When an ETR receives a Map-Request message with the probe-bit set, it When an ETR receives a Map-Request message with the probe-bit set, it
returns a Map-Reply with the probe-bit set. The source address of returns a Map-Reply with the probe-bit set. The source address of
the Map-Reply is set according to the procedure described in the Map-Reply is set according to the procedure described in
Section 6.1.5. The Map-Reply SHOULD contain mapping data for the Section 6.1.5. The Map-Reply SHOULD contain mapping data for the
EID-prefix contained in the Map-Request. This provides the EID-prefix contained in the Map-Request. This provides the
opportunity for the ITR or PTR, which sent the RLOC-probe to get opportunity for the ITR or PITR, which sent the RLOC-probe to get
mapping updates if there were changes to the ETR's database mapping mapping updates if there were changes to the ETR's database mapping
entries. entries.
There are advantages and disadvantages of RLOC Probing. The greatest There are advantages and disadvantages of RLOC Probing. The greatest
benefit of RLOC Probing is that it can handle many failure scenarios benefit of RLOC Probing is that it can handle many failure scenarios
allowing the ITR to determine when the path to a specific locator is allowing the ITR to determine when the path to a specific locator is
reachable or has become unreachable, thus providing a robust reachable or has become unreachable, thus providing a robust
mechanism for switching to using another locator from the cached mechanism for switching to using another locator from the cached
locator. RLOC Probing can also provide rough RTT estimates between a locator. RLOC Probing can also provide rough RTT estimates between a
pair of locators which can be useful for network management purposes pair of locators which can be useful for network management purposes
skipping to change at page 50, line 30 skipping to change at page 50, line 31
destination addresses, source and destination TCP, UDP, or SCTP destination addresses, source and destination TCP, UDP, or SCTP
port numbers and the IP protocol number field or IPv6 next- port numbers and the IP protocol number field or IPv6 next-
protocol fields of a packet a host originates from within a LISP protocol fields of a packet a host originates from within a LISP
site. When a packet is not a TCP, UDP, or SCTP packet, the site. When a packet is not a TCP, UDP, or SCTP packet, the
source and destination addresses only from the header are used to source and destination addresses only from the header are used to
compute the hash. compute the hash.
2. Take the hash value and divide it by the number of locators 2. Take the hash value and divide it by the number of locators
stored in the locator-set for the EID-to-RLOC mapping. stored in the locator-set for the EID-to-RLOC mapping.
3. The remainder will be yield a value of 0 to "number of locators 3. The remainder will yield a value of 0 to "number of locators
minus 1". Use the remainder to select the locator in the minus 1". Use the remainder to select the locator in the
locator-set. locator-set.
Note that when a packet is LISP encapsulated, the source port number Note that when a packet is LISP encapsulated, the source port number
in the outer UDP header needs to be set. Selecting a hashed value in the outer UDP header needs to be set. Selecting a hashed value
allows core routers which are attached to Link Aggregation Groups allows core routers which are attached to Link Aggregation Groups
(LAGs) to load-split the encapsulated packets across member links of (LAGs) to load-split the encapsulated packets across member links of
such LAGs. Otherwise, core routers would see a single flow, since such LAGs. Otherwise, core routers would see a single flow, since
packets have a source address of the ITR, for packets which are packets have a source address of the ITR, for packets which are
originated by different EIDs at the source site. A suggested setting originated by different EIDs at the source site. A suggested setting
skipping to change at page 51, line 29 skipping to change at page 51, line 29
have new locators appended to the end of the list. So some ITRs can have new locators appended to the end of the list. So some ITRs can
have a new mapping while other ITRs have only an old mapping that is have a new mapping while other ITRs have only an old mapping that is
used until they time out. When an ITR has only an old mapping but used until they time out. When an ITR has only an old mapping but
detects bits set in the loc-status-bits that correspond to locators detects bits set in the loc-status-bits that correspond to locators
beyond the list it has cached, it simply ignores them. However, this beyond the list it has cached, it simply ignores them. However, this
can only happen for locator addresses that are lexicographically can only happen for locator addresses that are lexicographically
greater than the locator addresses in the existing locator-set. greater than the locator addresses in the existing locator-set.
When a locator record is inserted in the middle of a locator-set, to When a locator record is inserted in the middle of a locator-set, to
maintain lexicographic order, the SMR procedure in Section 6.6.2 is maintain lexicographic order, the SMR procedure in Section 6.6.2 is
used to inform ITRs and PTRs of the new locator-status-bit mappings. used to inform ITRs and PITRs of the new locator-status-bit mappings.
When a locator record is removed from a locator-set, ITRs that have When a locator record is removed from a locator-set, ITRs that have
the mapping cached will not use the removed locator because the xTRs the mapping cached will not use the removed locator because the xTRs
will set the loc-status-bit to 0. So even if the locator is in the will set the loc-status-bit to 0. So even if the locator is in the
list, it will not be used. For new mapping requests, the xTRs can list, it will not be used. For new mapping requests, the xTRs can
set the locator AFI to 0 (indicating an unspecified address), as well set the locator AFI to 0 (indicating an unspecified address), as well
as setting the corresponding loc-status-bit to 0. This forces ITRs as setting the corresponding loc-status-bit to 0. This forces ITRs
with old or new mappings to avoid using the removed locator. with old or new mappings to avoid using the removed locator.
If many changes occur to a mapping over a long period of time, one If many changes occur to a mapping over a long period of time, one
skipping to change at page 52, line 48 skipping to change at page 52, line 48
the mappings they have cached. the mappings they have cached.
Since the ETRs don't keep track of remote ITRs that have cached their Since the ETRs don't keep track of remote ITRs that have cached their
mappings, they do not know which ITRs need to have their mappings mappings, they do not know which ITRs need to have their mappings
updated. As a result, an ETR will solicit Map-Requests (called an updated. As a result, an ETR will solicit Map-Requests (called an
SMR message) from those sites to which it has been sending SMR message) from those sites to which it has been sending
encapsulated data to for the last minute. In particular, an ETR will encapsulated data to for the last minute. In particular, an ETR will
send an SMR an ITR to which it has recently sent encapsulated data. send an SMR an ITR to which it has recently sent encapsulated data.
An SMR message is simply a bit set in a Map-Request message. An ITR An SMR message is simply a bit set in a Map-Request message. An ITR
or PTR will send a Map-Request when they receive an SMR message. or PITR will send a Map-Request when they receive an SMR message.
Both the SMR sender and the Map-Request responder MUST rate-limited Both the SMR sender and the Map-Request responder MUST rate-limited
these messages. Rate-limiting can be implemented as a global rate- these messages. Rate-limiting can be implemented as a global rate-
limiter or one rate-limiter per SMR destination. limiter or one rate-limiter per SMR destination.
The following procedure shows how a SMR exchange occurs when a site The following procedure shows how a SMR exchange occurs when a site
is doing locator-set compaction for an EID-to-RLOC mapping: is doing locator-set compaction for an EID-to-RLOC mapping:
1. When the database mappings in an ETR change, the ETRs at the site 1. When the database mappings in an ETR change, the ETRs at the site
begin to send Map-Requests with the SMR bit set for each locator begin to send Map-Requests with the SMR bit set for each locator
in each map-cache entry the ETR caches. in each map-cache entry the ETR caches.
skipping to change at page 60, line 28 skipping to change at page 60, line 28
Segment 2 (in the core network based on RLOCs): Segment 2 (in the core network based on RLOCs):
ITR ---> next-hop ... next-hop ---> ETR ITR ---> next-hop ... next-hop ---> ETR
Segment 3 (in the destination LISP site based on EIDs): Segment 3 (in the destination LISP site based on EIDs):
ETR ---> next-hop ... last-hop ---> destination-host ETR ---> next-hop ... last-hop ---> destination-host
For segment 1 of the path, ICMP Time Exceeded messages are returned For segment 1 of the path, ICMP Time Exceeded messages are returned
in the normal matter as they are today. The ITR performs a TTL in the normal manner as they are today. The ITR performs a TTL
decrement and test for 0 before encapsulating. So the ITR hop is decrement and test for 0 before encapsulating. So the ITR hop is
seen by the traceroute source has an EID address (the address of seen by the traceroute source has an EID address (the address of
site-facing interface). site-facing interface).
For segment 2 of the path, ICMP Time Exceeded messages are returned For segment 2 of the path, ICMP Time Exceeded messages are returned
to the ITR because the TTL decrement to 0 is done on the outer to the ITR because the TTL decrement to 0 is done on the outer
header, so the destination of the ICMP messages are to the ITR RLOC header, so the destination of the ICMP messages are to the ITR RLOC
address, the source RLOC address of the encapsulated traceroute address, the source RLOC address of the encapsulated traceroute
packet. The ITR looks inside of the ICMP payload to inspect the packet. The ITR looks inside of the ICMP payload to inspect the
traceroute source so it can return the ICMP message to the address of traceroute source so it can return the ICMP message to the address of
skipping to change at page 64, line 8 skipping to change at page 64, line 8
back to the home agent for delivery to the mobile node. As the back to the home agent for delivery to the mobile node. As the
mobile node's EID or available RLOC changes, LISP EID-to-RLOC mobile node's EID or available RLOC changes, LISP EID-to-RLOC
mappings are required for communication between the mobile node and mappings are required for communication between the mobile node and
the home agent, whether via foreign agent or not. As a mobile the home agent, whether via foreign agent or not. As a mobile
endpoint changes networks, up to three LISP mapping changes may be endpoint changes networks, up to three LISP mapping changes may be
required: required:
o The mobile node moves from an old location to a new visited o The mobile node moves from an old location to a new visited
network location and notifies its home agent that it has done so. network location and notifies its home agent that it has done so.
The Mobile IPv4 control packets the mobile node sends pass through The Mobile IPv4 control packets the mobile node sends pass through
one of the new visited network's ITRs, which needs a EID-RLOC one of the new visited network's ITRs, which needs an EID-RLOC
mapping for the home agent. mapping for the home agent.
o The home agent might not have the EID-RLOC mappings for the mobile o The home agent might not have the EID-RLOC mappings for the mobile
node's "care-of" address or its foreign agent in the new visited node's "care-of" address or its foreign agent in the new visited
network, in which case it will need to acquire them. network, in which case it will need to acquire them.
o When packets are sent directly to the correspondent node, it may o When packets are sent directly to the correspondent node, it may
be that no traffic has been sent from the new visited network to be that no traffic has been sent from the new visited network to
the correspondent node's network, and the new visited network's the correspondent node's network, and the new visited network's
ITR will need to obtain an EID-RLOC mapping for the correspondent ITR will need to obtain an EID-RLOC mapping for the correspondent
skipping to change at page 68, line 26 skipping to change at page 68, line 26
provides a basic level of security, in many ways similar to the provides a basic level of security, in many ways similar to the
security experienced in the current Internet routing system. It is security experienced in the current Internet routing system. It is
hard for off-path attackers to launch attacks against these LISP hard for off-path attackers to launch attacks against these LISP
mechanisms, as they do not have the nonce values. Sending a large mechanisms, as they do not have the nonce values. Sending a large
number of packets to accidentally find the right nonce value is number of packets to accidentally find the right nonce value is
possible, but would already by itself be a denial-of-service attack. possible, but would already by itself be a denial-of-service attack.
On-path attackers can perform far more serious attacks, but on-path On-path attackers can perform far more serious attacks, but on-path
attackers can launch serious attacks in the current Internet as well, attackers can launch serious attacks in the current Internet as well,
including eavesdropping, blocking or redirecting traffic. including eavesdropping, blocking or redirecting traffic.
LISP does not rely on a PKI infrastructure or a more heavy weight LISP does not rely on a PKI or a more heavy weight authentication
authentication system. These systems challenge the scalability of system. These systems challenge the scalability of LISP which was a
LISP which was a primary design goal. primary design goal.
DoS attack prevention will depend on implementations rate-limiting DoS attack prevention will depend on implementations rate-limiting
Map-Requests and Map-Replies to the control plane as well as rate- Map-Requests and Map-Replies to the control plane as well as rate-
limiting the number of data-triggered Map-Replies. limiting the number of data-triggered Map-Replies.
An incorrectly implemented or malicious ITR might choose to ignore An incorrectly implemented or malicious ITR might choose to ignore
the priority and weights provided by the ETR in its Map-Reply. This the priority and weights provided by the ETR in its Map-Reply. This
traffic steering would be limited to the traffic that is sent by this traffic steering would be limited to the traffic that is sent by this
ITR's site, and no more severe than if the site initiated a bandwidth ITR's site, and no more severe than if the site initiated a bandwidth
DoS attack on (one of) the ETR's ingress links. The ITR's site would DoS attack on (one of) the ETR's ingress links. The ITR's site would
typically gain no benefit from not respecting the weights, and would typically gain no benefit from not respecting the weights, and would
likely to receive better service by abiding by them. likely to receive better service by abiding by them.
To deal with map-cache exhaustion attempts in an ITR/PTR, the To deal with map-cache exhaustion attempts in an ITR/PITR, the
implementation should consider putting a maximum cap on the number of implementation should consider putting a maximum cap on the number of
entries stored with a reserve list for special or frequently accessed entries stored with a reserve list for special or frequently accessed
sites. This should be a configuration policy control set by the sites. This should be a configuration policy control set by the
network administrator who manages ITRs and PTRs. When overlapping network administrator who manages ITRs and PITRs. When overlapping
EID-prefixes occur across multiple map-cache entries, the integrity EID-prefixes occur across multiple map-cache entries, the integrity
of the set must be wholly maintained. So if a more-specific entry of the set must be wholly maintained. So if a more-specific entry
cannot be added due to reaching the maximum cap, then none of the cannot be added due to reaching the maximum cap, then none of the
less specifics should be stored in the map-cache. less specifics should be stored in the map-cache.
Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, Given that the ITR/PITR maintains a cache of EID-to-RLOC mappings,
cache sizing and maintenance is an issue to be kept in mind during cache sizing and maintenance is an issue to be kept in mind during
implementation. It is a good idea to have instrumentation in place implementation. It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work will be used to determine which cache management strategies work
best. In general, it is difficult to defend against cache trashing best. In general, it is difficult to defend against cache trashing
attacks. It should be noted that an undersized cache in an ITR/PTR attacks. It should be noted that an undersized cache in an ITR/PITR
not only causes adverse affect on the site or region they support, not only causes adverse affect on the site or region they support,
but may also cause increased Map-Request load on the mapping system. but may also cause increased Map-Request load on the mapping system.
There is a security risk implicit in the fact that ETRs generate the There is a security risk implicit in the fact that ETRs generate the
EID prefix to which they are responding. An ETR can claim a shorter EID prefix to which they are responding. An ETR can claim a shorter
prefix than it is actually responsible for. Various mechanisms to prefix than it is actually responsible for. Various mechanisms to
ameliorate or resolve this issue will be examined in the future, ameliorate or resolve this issue will be examined in the future,
[LISP-SEC]. [LISP-SEC].
Spoofing of inner header addresses of LISP encapsulated packets is Spoofing of inner header addresses of LISP encapsulated packets is
skipping to change at page 73, line 23 skipping to change at page 73, line 23
mapping database systems is strongly encouraged. mapping database systems is strongly encouraged.
o Failure and recovery of LISP site partitioning (see Section 6.4), o Failure and recovery of LISP site partitioning (see Section 6.4),
in the presence of redundant configuration (see Section 8.5) needs in the presence of redundant configuration (see Section 8.5) needs
further research and experimentation. further research and experimentation.
o The characteristics of map-cache management under exceptional o The characteristics of map-cache management under exceptional
conditions, such as denial-of-service attacks are not fully conditions, such as denial-of-service attacks are not fully
understood. Further experience is needed to determine whether understood. Further experience is needed to determine whether
current caching methods are practical or in need of further current caching methods are practical or in need of further
development. See Section 12 for additional thoughts and development. In particular, the performance, scaling and security
considerations. characteristics of the map-cache will be discovered as part of
this experiment. Performance metrics to be observed are packet
reordering associated with the LISP data probe and loss of the
first packet in a flow associated with map-caching. The impact of
these upon TCP will be observed. See Section 12 for additional
thoughts and considerations.
o Preliminary work has been done to ensure that sites employing LISP o Preliminary work has been done to ensure that sites employing LISP
can interconnect with the rest of the Internet. This work is can interconnect with the rest of the Internet. This work is
documented in [INTERWORK] but further experimentation and documented in [INTERWORK] but further experimentation and
experience is needed. experience is needed.
o At present, no mechanism for automated key management for message o At present, no mechanism for automated key management for message
authentication is defined. Addressing automated key management is authentication is defined. Addressing automated key management is
necessary before this specification could be developed into a necessary before this specification could be developed into a
standards track RFC. See Section 12 for further details regarding standards track RFC. See Section 12 for further details regarding
security considerations. security considerations.
o In order to maintain security and stability, Internet Protocols
typically isolate the control and data planes. Therefore, user
activity cannot cause control plane state to be created or
destroyed. LISP does not maintain this separation. The degree to
which the loss of separation impacts security and stability is a
topic for experimental observation.
o LISP allows for different mapping database systems to be used.
While only one [ALT] is currently well-defined, each mapping
database will likely have some impact on the security of the EID-
to-RLOC mappings. How each mapping database system's security
properties impact on LISP overall is for further study.
16. References 16. References
16.1. Normative References 16.1. Normative References
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)", Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-09.txt (work in progress). draft-ietf-lisp-alt-09.txt (work in progress).
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-12.txt (work in progress). draft-ietf-lisp-ms-12.txt (work in progress).
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[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.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
skipping to change at page 75, line 16 skipping to change at page 76, line 22
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[UDP-TUNNELS] [UDP-TUNNELS]
Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
Packets", draft-eubanks-chimento-6man-01.txt (work in Packets", draft-eubanks-chimento-6man-01.txt (work in
progress), October 2010. progress), October 2010.
[UDP-ZERO]
Fairhurst, G. and M. Westerland, "IPv6 UDP Checksum
Considerations", draft-ietf-6man-udpzero-04.txt (work in
progress), October 2011.
[VERSIONING] [VERSIONING]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
Versioning", draft-ietf-lisp-map-versioning-05.txt (work Versioning", draft-ietf-lisp-map-versioning-05.txt (work
in progress). in progress).
16.2. Informative References 16.2. Informative References
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS NUMBERS
http://www.iana.org/assignments/address-family-numbers. http://www.iana.org/assignments/address-family-numbers.
skipping to change at page 76, line 41 skipping to change at page 78, line 4
[LISP-MIB] [LISP-MIB]
Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Schudel, G., Jain, A., and V. Moreno, "LISP MIB",
draft-ietf-lisp-mib-02.txt (work in progress). draft-ietf-lisp-mib-02.txt (work in progress).
[LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
Mobility Architecture", draft-meyer-lisp-mn-06.txt (work Mobility Architecture", draft-meyer-lisp-mn-06.txt (work
in progress). in progress).
[LISP-SEC] [LISP-SEC]
Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O.
Bonaventure, "LISP-Security (LISP-SEC)", Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-00.txt (work in progress). draft-ietf-lisp-sec-00.txt (work in progress).
[LOC-ID-ARCH] [LOC-ID-ARCH]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", Locator/ID Separation",
draft-meyer-loc-id-implications-01.txt (work in progress). draft-meyer-loc-id-implications-02.txt (work in progress).
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-ietf-lisp-multicast-10.txt (work in progress). draft-ietf-lisp-multicast-10.txt (work in progress).
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-08.txt (work in progress). draft-lear-lisp-nerd-08.txt (work in progress).
[OPENLISP] [OPENLISP]
Iannone, L. and O. Bonaventure, "OpenLISP Implementation Iannone, L. and O. Bonaventure, "OpenLISP Implementation
skipping to change at page 77, line 47 skipping to change at page 80, line 5
Optimization for Mobile IPv6", RFC 4866, May 2007. Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, Workshop on Routing and Addressing", RFC 4984,
September 2007. September 2007.
[RPKI] Lepinski, M., "An Infrastructure to Support Secure [RPKI] Lepinski, M., "An Infrastructure to Support Secure
Internet Routing", draft-ietf-sidr-arch-13.txt (work in Internet Routing", draft-ietf-sidr-arch-13.txt (work in
progress), February 2011. progress), February 2011.
[RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
for Routing Protocol Meta-data Dissemination",
draft-handley-p2ppush-unpublished-2007726.txt (work in
progress).
Appendix A. Acknowledgments Appendix A. Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues to provide value
to the LISP authors. to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
of location and identity, as well as detailed review of the LISP of location and identity, as well as detailed review of the LISP
architecture and documents, coupled with enthusiasm for making LISP a architecture and documents, coupled with enthusiasm for making LISP a
skipping to change at page 79, line 7 skipping to change at page 81, line 7
LISP working group draft. LISP working group draft.
The LISP working group would like to give a special thanks to Jari The LISP working group would like to give a special thanks to Jari
Arkko, the Internet Area AD at the time the set of LISP documents Arkko, the Internet Area AD at the time the set of LISP documents
were being prepared for IESG last call, for his meticulous review and were being prepared for IESG last call, for his meticulous review and
detail commentary on the 7 working group last call drafts progressing detail commentary on the 7 working group last call drafts progressing
toward experimental RFCs. toward experimental RFCs.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-16.txt B.1. Changes to draft-ietf-lisp-17.txt
o Posted December 2011 after IETF last call comments.
o Make Map-Notify port assignment be 4342 in both source and
destination ports. This change was agreed on and put in [LISP-MS]
but was not updated in this spec.
B.2. Changes to draft-ietf-lisp-16.txt
o Posted October 2011 after AD review by Jari. o Posted October 2011 after AD review by Jari.
B.2. Changes to draft-ietf-lisp-15.txt B.3. Changes to draft-ietf-lisp-15.txt
o Posted July 2011. Fixing IDnits errors. o Posted July 2011. Fixing IDnits errors.
o Change description on how to select a source address for RLOC- o Change description on how to select a source address for RLOC-
probe Map-Replies to refer to the "EID-to-RLOC Map-Reply Message" probe Map-Replies to refer to the "EID-to-RLOC Map-Reply Message"
section. section.
B.3. Changes to draft-ietf-lisp-14.txt B.4. Changes to draft-ietf-lisp-14.txt
o Post working group last call and pre-IESG last call review. o Post working group last call and pre-IESG last call review.
o Indicate that an ICMP Unreachable message should be sent when a o Indicate that an ICMP Unreachable message should be sent when a
packet matches a drop-based negative map-cache entry. packet matches a drop-based negative map-cache entry.
o Indicate how a map-cache set of overlapping EID-prefixes must o Indicate how a map-cache set of overlapping EID-prefixes must
maintain integrity when the map-cache maximum cap is reached. maintain integrity when the map-cache maximum cap is reached.
o Add Joel's description for the definition of an EID, that the bit o Add Joel's description for the definition of an EID, that the bit
skipping to change at page 80, line 5 skipping to change at page 82, line 9
in the Data Probe definition section. in the Data Probe definition section.
o Added text indicating that more-specific EID-prefixes must not be o Added text indicating that more-specific EID-prefixes must not be
removed when less-specific entries stay in the map-cache. This is removed when less-specific entries stay in the map-cache. This is
to preserve the integrity of the EID-prefix set. to preserve the integrity of the EID-prefix set.
o Add clarifying text in the Security Considerations section about o Add clarifying text in the Security Considerations section about
how an ETR must not decapsulate and forward a packet that is not how an ETR must not decapsulate and forward a packet that is not
for its configured EID-prefix range. for its configured EID-prefix range.
B.4. Changes to draft-ietf-lisp-13.txt B.5. Changes to draft-ietf-lisp-13.txt
o Posted June 2011 to complete working group last call. o Posted June 2011 to complete working group last call.
o Tracker item 87. Put Yakov suggested wording in the EID-prefix o Tracker item 87. Put Yakov suggested wording in the EID-prefix
definition section to reference [INTERWORK] and [LISP-DEPLOY] definition section to reference [INTERWORK] and [LISP-DEPLOY]
about discussion on transition and access mechanisms. about discussion on transition and access mechanisms.
o Change "ITRs" to "ETRs" in the Locator Status Bit definition o Change "ITRs" to "ETRs" in the Locator Status Bit definition
section and data packet description section per Damien's comment. section and data packet description section per Damien's comment.
skipping to change at page 80, line 38 skipping to change at page 82, line 42
o Remove Security Area Statement title and reword section with o Remove Security Area Statement title and reword section with
Eliot's provided text. The text was agreed upon by LISP-WG chairs Eliot's provided text. The text was agreed upon by LISP-WG chairs
and Security ADs. and Security ADs.
o Remove word "potential" from the over-claiming paragraph of the o Remove word "potential" from the over-claiming paragraph of the
Security Considerations section per Stephen's request. Security Considerations section per Stephen's request.
o Wordsmithing and other editorial comments from Alia. o Wordsmithing and other editorial comments from Alia.
B.5. Changes to draft-ietf-lisp-12.txt B.6. Changes to draft-ietf-lisp-12.txt
o Posted April 2011. o Posted April 2011.
o Tracker item 87. Provided rewording how an EID-prefix can be o Tracker item 87. Provided rewording how an EID-prefix can be
reused in the definition section of "EID-prefix". reused in the definition section of "EID-prefix".
o Tracker item 95. Change "eliminate" to "defer" in section 4.1. o Tracker item 95. Change "eliminate" to "defer" in section 4.1.
o Tracker item 110. Added that the Mapping Protocol Data field in o Tracker item 110. Added that the Mapping Protocol Data field in
the Map-Reply message is only used when needed by the particular the Map-Reply message is only used when needed by the particular
skipping to change at page 82, line 5 skipping to change at page 84, line 9
indicating that site partitioning is under investigation. indicating that site partitioning is under investigation.
o Tracker item 58. Added last paragraph of Security Considerations o Tracker item 58. Added last paragraph of Security Considerations
section about how to protect inner header EID address spoofing section about how to protect inner header EID address spoofing
attacks. attacks.
o Add suggested Sam text to indicate that all security concerns need o Add suggested Sam text to indicate that all security concerns need
not be addressed for moving document to Experimental RFC status. not be addressed for moving document to Experimental RFC status.
Put this in a subsection of the Security Considerations section. Put this in a subsection of the Security Considerations section.
B.6. Changes to draft-ietf-lisp-11.txt B.7. Changes to draft-ietf-lisp-11.txt
o Posted March 30, 2011. o Posted March 30, 2011.
o Change IANA URL. The URL we had pointed to a general protocol o Change IANA URL. The URL we had pointed to a general protocol
numbers page. numbers page.
o Added the "s" bit to the Map-Request to allow SMR-invoked Map- o Added the "s" bit to the Map-Request to allow SMR-invoked Map-
Requests to be sent to a MN ETR via the map-server. Requests to be sent to a MN ETR via the map-server.
o Generalize text for the definition of Reencapsuatling tunnels. o Generalize text for the definition of Reencapsuatling tunnels.
skipping to change at page 82, line 45 skipping to change at page 85, line 5
reachability. reachability.
o Change "BGP RIB" to "RIB" per Clarence's comment. o Change "BGP RIB" to "RIB" per Clarence's comment.
o Fixed complaints by IDnits. o Fixed complaints by IDnits.
o Add subsection to Security Considerations section indicating how o Add subsection to Security Considerations section indicating how
EID-prefix overclaiming in Map-Replies is for further study and EID-prefix overclaiming in Map-Replies is for further study and
add a reference to LISP-SEC. add a reference to LISP-SEC.
B.7. Changes to draft-ietf-lisp-10.txt B.8. Changes to draft-ietf-lisp-10.txt
o Posted March 2011. o Posted March 2011.
o Add p-bit to Map-Request so there is documentary reasons to know o Add p-bit to Map-Request so there is documentary reasons to know
when a PITR has sent a Map-Request to an ETR. when a PITR has sent a Map-Request to an ETR.
o Add Map-Notify message which is used to acknowledge a Map-Register o Add Map-Notify message which is used to acknowledge a Map-Register
message sent to a Map-Server. message sent to a Map-Server.
o Add M-bit to the Map-Register message so an ETR that wants an o Add M-bit to the Map-Register message so an ETR that wants an
skipping to change at page 83, line 20 skipping to change at page 85, line 27
o Add S-bit to the ECM and Map-Reply messages to describe security o Add S-bit to the ECM and Map-Reply messages to describe security
data that can be present in each message. Then refer to data that can be present in each message. Then refer to
[LISP-SEC] for expansive details. [LISP-SEC] for expansive details.
o Add Network Management Considerations section and point to the MIB o Add Network Management Considerations section and point to the MIB
and LIG drafts. and LIG drafts.
o Remove the word "simple" per Yakov's comments. o Remove the word "simple" per Yakov's comments.
B.8. Changes to draft-ietf-lisp-09.txt B.9. Changes to draft-ietf-lisp-09.txt
o Posted October 2010. o Posted October 2010.
o Add to IANA Consideration section about the use of LCAF Type o Add to IANA Consideration section about the use of LCAF Type
values that accepted and maintained by the IANA registry and not values that accepted and maintained by the IANA registry and not
the LCAF specification. the LCAF specification.
o Indicate that implementations should be able to receive LISP o Indicate that implementations should be able to receive LISP
control messages when either UDP port is 4342, so they can be control messages when either UDP port is 4342, so they can be
robust in the face of intervening NAT boxes. robust in the face of intervening NAT boxes.
o Add paragraph to SMR section to indicate that an ITR does not need o Add paragraph to SMR section to indicate that an ITR does not need
to respond to an SMR-based Map-Request when it has no map-cache to respond to an SMR-based Map-Request when it has no map-cache
entry for the SMR source's EID-prefix. entry for the SMR source's EID-prefix.
B.9. Changes to draft-ietf-lisp-08.txt B.10. Changes to draft-ietf-lisp-08.txt
o Posted August 2010. o Posted August 2010.
o In section 6.1.6, remove statement about setting TTL to 0 in Map- o In section 6.1.6, remove statement about setting TTL to 0 in Map-
Register messages. Register messages.
o Clarify language in section 6.1.5 about Map-Replying to Data- o Clarify language in section 6.1.5 about Map-Replying to Data-
Probes or Map-Requests. Probes or Map-Requests.
o Indicate that outer TTL should only be copied to inner TTL when it o Indicate that outer TTL should only be copied to inner TTL when it
skipping to change at page 85, line 26 skipping to change at page 87, line 31
o Remove text on copying nonce from SMR to SMR-invoked Map- Request o Remove text on copying nonce from SMR to SMR-invoked Map- Request
per Vina's comment about a possible DoS vector. per Vina's comment about a possible DoS vector.
o Clarify (S/2 + H) in the stateless MTU section. o Clarify (S/2 + H) in the stateless MTU section.
o Add text to reflect Damien's comment about the description of the o Add text to reflect Damien's comment about the description of the
"ITR-RLOC Address" field in the Map-Request. that the list of RLOC "ITR-RLOC Address" field in the Map-Request. that the list of RLOC
addresses are local addresses of the Map-Requester. addresses are local addresses of the Map-Requester.
B.10. Changes to draft-ietf-lisp-07.txt B.11. Changes to draft-ietf-lisp-07.txt
o Posted April 2010. o Posted April 2010.
o Added I-bit to data header so LSB field can also be used as an o Added I-bit to data header so LSB field can also be used as an
Instance ID field. When this occurs, the LSB field is reduced to Instance ID field. When this occurs, the LSB field is reduced to
8-bits (from 32-bits). 8-bits (from 32-bits).
o Added V-bit to the data header so the 24-bit nonce field can also o Added V-bit to the data header so the 24-bit nonce field can also
be used for source and destination version numbers. be used for source and destination version numbers.
skipping to change at page 87, line 5 skipping to change at page 89, line 5
o In section 9.2, add text to describe what the signature of o In section 9.2, add text to describe what the signature of
traceroute packets can look like. traceroute packets can look like.
o Removed references to Data Probe for introductory example. Data- o Removed references to Data Probe for introductory example. Data-
probes are still part of the LISP design but not encouraged. probes are still part of the LISP design but not encouraged.
o Added the definition for "LISP site" to the Definition of Terms" o Added the definition for "LISP site" to the Definition of Terms"
section. section.
B.11. Changes to draft-ietf-lisp-06.txt B.12. Changes to draft-ietf-lisp-06.txt
Editorial based changes: Editorial based changes:
o Posted December 2009. o Posted December 2009.
o Fix typo for flags in LISP data header. Changed from "4" to "5". o Fix typo for flags in LISP data header. Changed from "4" to "5".
o Add text to indicate that Map-Register messages must contain a o Add text to indicate that Map-Register messages must contain a
computed UDP checksum. computed UDP checksum.
skipping to change at page 88, line 13 skipping to change at page 90, line 13
These type of Map-Requests are used as RLOC-probes and are sent These type of Map-Requests are used as RLOC-probes and are sent
directly to locator addresses in the underlying network. directly to locator addresses in the underlying network.
o Add text in section 6.1.5 about returning all EID-prefixes in a o Add text in section 6.1.5 about returning all EID-prefixes in a
Map-Reply sent by an ETR when there are overlapping EID-prefixes Map-Reply sent by an ETR when there are overlapping EID-prefixes
configure. configure.
o Add text in a new subsection of section 6.1.5 about dealing with o Add text in a new subsection of section 6.1.5 about dealing with
Map-Replies with coarse EID-prefixes. Map-Replies with coarse EID-prefixes.
B.12. Changes to draft-ietf-lisp-05.txt B.13. Changes to draft-ietf-lisp-05.txt
o Posted September 2009. o Posted September 2009.
o Added this Document Change Log appendix. o Added this Document Change Log appendix.
o Added section indicating that encapsulated Map-Requests must use o Added section indicating that encapsulated Map-Requests must use
destination UDP port 4342. destination UDP port 4342.
o Don't use AH in Map-Registers. Put key-id, auth-length, and auth- o Don't use AH in Map-Registers. Put key-id, auth-length, and auth-
data in Map-Register payload. data in Map-Register payload.
skipping to change at page 88, line 41 skipping to change at page 90, line 41
o The LISP-CONS authors thought that the Type definitions for CONS o The LISP-CONS authors thought that the Type definitions for CONS
should be removed from this specification. should be removed from this specification.
o Removed nonce from Map-Register message, it wasn't used so no need o Removed nonce from Map-Register message, it wasn't used so no need
for it. for it.
o Clarify what to do for unspecified Action bits for negative Map- o Clarify what to do for unspecified Action bits for negative Map-
Replies. Since No Action is a drop, make value 0 Drop. Replies. Since No Action is a drop, make value 0 Drop.
B.13. Changes to draft-ietf-lisp-04.txt B.14. Changes to draft-ietf-lisp-04.txt
o Posted September 2009. o Posted September 2009.
o How do deal with record count greater than 1 for a Map-Request. o How do deal with record count greater than 1 for a Map-Request.
Damien and Joel comment. Joel suggests: 1) Specify that senders Damien and Joel comment. Joel suggests: 1) Specify that senders
compliant with the current document will always set the count to compliant with the current document will always set the count to
1, and note that the count is included for future extensibility. 1, and note that the count is included for future extensibility.
2) Specify what a receiver compliant with the draft should do if 2) Specify what a receiver compliant with the draft should do if
it receives a request with a count greater than 1. Presumably, it it receives a request with a count greater than 1. Presumably, it
should send some error back? should send some error back?
skipping to change at page 89, line 26 skipping to change at page 91, line 26
confirm that can actually be implemented. In particular, hardware confirm that can actually be implemented. In particular, hardware
that verifies UDP checksums on receive needs to be checked to make that verifies UDP checksums on receive needs to be checked to make
sure it permits 0 checksums." sure it permits 0 checksums."
o Margaret wants a reference to o Margaret wants a reference to
http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt. http://www.ietf.org/id/draft-eubanks-chimento-6man-00.txt.
o Fix description in Map-Request section. Where we describe Map- o Fix description in Map-Request section. Where we describe Map-
Reply Record, change "R-bit" to "M-bit". Reply Record, change "R-bit" to "M-bit".
o Add the mobility bit to Map-Replies. So PTRs don't probe so often o Add the mobility bit to Map-Replies. So PITRs don't probe so
for MNs but often enough to get mapping updates. often for MNs but often enough to get mapping updates.
o Indicate SHA1 can be used as well for Map-Registers. o Indicate SHA1 can be used as well for Map-Registers.
o More Fred comments on MTU handling. o More Fred comments on MTU handling.
o Isidor comment about spec'ing better periodic Map-Registers. Will o Isidor comment about spec'ing better periodic Map-Registers. Will
be fixed in draft-ietf-lisp-ms-02.txt. be fixed in draft-ietf-lisp-ms-02.txt.
o Margaret's comment on gleaning: "The current specification does o Margaret's comment on gleaning: "The current specification does
not make it clear how long gleaned map entries should be retained not make it clear how long gleaned map entries should be retained
skipping to change at page 90, line 32 skipping to change at page 92, line 32
o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Reference IPsec RFC 4302. Comment from Sam and Brian Weis.
o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
noncing. Comment by Pedro and Dino. noncing. Comment by Pedro and Dino.
o Jesper made a comment to loosen the language about requiring the o Jesper made a comment to loosen the language about requiring the
copy of inner TTL to outer TTL since the text to get mixed-AF copy of inner TTL to outer TTL since the text to get mixed-AF
traceroute to work would violate the "MUST" clause. Changed from traceroute to work would violate the "MUST" clause. Changed from
MUST to SHOULD in section 5.3. MUST to SHOULD in section 5.3.
B.14. Changes to draft-ietf-lisp-03.txt B.15. Changes to draft-ietf-lisp-03.txt
o Posted July 2009. o Posted July 2009.
o Removed loc-reach-bits longword from control packets per Damien o Removed loc-reach-bits longword from control packets per Damien
comment. comment.
o Clarifications in MTU text from Roque. o Clarifications in MTU text from Roque.
o Added text to indicate that the locator-set be sorted by locator o Added text to indicate that the locator-set be sorted by locator
address from Isidor. address from Isidor.
o Clarification text from John Zwiebel in Echo-Nonce section. o Clarification text from John Zwiebel in Echo-Nonce section.
B.15. Changes to draft-ietf-lisp-02.txt B.16. Changes to draft-ietf-lisp-02.txt
o Posted July 2009. o Posted July 2009.
o Encapsulation packet format change to add E-bit and make loc- o Encapsulation packet format change to add E-bit and make loc-
reach-bits 32-bits in length. reach-bits 32-bits in length.
o Added Echo-Nonce Algorithm section. o Added Echo-Nonce Algorithm section.
o Clarification how ECN bits are copied. o Clarification how ECN bits are copied.
o Moved S-bit in Map-Request. o Moved S-bit in Map-Request.
o Added P-bit in Map-Request and Map-Reply messages to anticipate o Added P-bit in Map-Request and Map-Reply messages to anticipate
RLOC-Probe Algorithm. RLOC-Probe Algorithm.
o Added to Mobility section to reference [LISP-MN]. o Added to Mobility section to reference [LISP-MN].
B.16. Changes to draft-ietf-lisp-01.txt B.17. Changes to draft-ietf-lisp-01.txt
o Posted 2 days after draft-ietf-lisp-00.txt in May 2009. o Posted 2 days after draft-ietf-lisp-00.txt in May 2009.
o Defined LEID to be a "LISP EID". o Defined LEID to be a "LISP EID".
o Indicate encapsulation use IPv4 DF=0. o Indicate encapsulation use IPv4 DF=0.
o Added negative Map-Reply messages with drop, native-forward, and o Added negative Map-Reply messages with drop, native-forward, and
send-map-request actions. send-map-request actions.
o Added Proxy-Map-Reply bit to Map-Register. o Added Proxy-Map-Reply bit to Map-Register.
B.17. Changes to draft-ietf-lisp-00.txt B.18. Changes to draft-ietf-lisp-00.txt
o Posted May 2009. o Posted May 2009.
o Rename of draft-farinacci-lisp-12.txt. o Rename of draft-farinacci-lisp-12.txt.
o Acknowledgment to RRG. o Acknowledgment to RRG.
Authors' Addresses Authors' Addresses
Dino Farinacci Dino Farinacci
 End of changes. 102 change blocks. 
236 lines changed or deleted 280 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/