draft-ietf-lisp-19.txt   draft-ietf-lisp-20.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: July 8, 2012 D. Lewis Expires: July 25, 2012 D. Lewis
cisco Systems cisco Systems
January 5, 2012 January 22, 2012
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-19 draft-ietf-lisp-20
Abstract Abstract
This draft describes a network layer based protocol that enables This draft describes a network layer based protocol that enables
separation of IP addresses into two new numbering spaces: Endpoint separation of IP addresses into two new numbering spaces: Endpoint
Identifiers (EIDs) and Routing Locators (RLOCs). No changes are Identifiers (EIDs) and Routing Locators (RLOCs). No changes are
required to either host protocol stacks or to the "core" of the required to either host protocol stacks or to the "core" of the
Internet infrastructure. LISP can be incrementally deployed, without Internet infrastructure. LISP can be incrementally deployed, without
a "flag day", and offers traffic engineering, multi-homing, and a "flag day", and offers traffic engineering, multi-homing, and
mobility benefits to early adopters, even when there are relatively mobility benefits to early adopters, even when there are relatively
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 July 8, 2012. This Internet-Draft will expire on July 25, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 2, line 20 skipping to change at page 2, line 20
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 15 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 16
5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 17 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 18
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 18 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 19
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 19
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 20 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 21
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 24 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 25
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 24 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 25
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 25 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 26
5.5. Using Virtualization and Segmentation with LISP . . . . . 25 5.5. Using Virtualization and Segmentation with LISP . . . . . 26
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 27 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 28
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 27 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 28
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 29 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 30
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 29 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 30
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 32 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 33
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 33 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 34
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 37 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 38
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 39 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 40
6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 41 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 42
6.1.8. Encapsulated Control Message Format . . . . . . . . . 42 6.1.8. Encapsulated Control Message Format . . . . . . . . . 43
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 44 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 45
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 46 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 47
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 48 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 49
6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 49 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 50
6.4. EID Reachability within a LISP Site . . . . . . . . . . . 50 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 51
6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 51 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 52
6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 52 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 53
6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 53 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 54
6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 53 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 54
6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 55 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 56
7. Router Performance Considerations . . . . . . . . . . . . . . 56 7. Router Performance Considerations . . . . . . . . . . . . . . 57
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 57 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 58
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 58 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 59
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 58 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 59
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 59 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 60
8.4. LISP Functionality with Conventional NATs . . . . . . . . 59 8.4. LISP Functionality with Conventional NATs . . . . . . . . 60
8.5. Packets Egressing a LISP Site . . . . . . . . . . . . . . 60 8.5. Packets Egressing a LISP Site . . . . . . . . . . . . . . 61
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 61 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 62
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 62 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 63
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 62 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 63
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 62 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 63
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 64 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 65
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 64 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 65
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 64 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 65
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 64 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 65
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 66 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 67
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 66 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 67
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 68 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 69
12. Security Considerations . . . . . . . . . . . . . . . . . . . 69 12. Security Considerations . . . . . . . . . . . . . . . . . . . 70
13. Network Management Considerations . . . . . . . . . . . . . . 71 13. Network Management Considerations . . . . . . . . . . . . . . 72
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
14.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . . 72 14.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . . 73
14.2. LISP Address Type Codes . . . . . . . . . . . . . . . . . 72 14.2. LISP Address Type Codes . . . . . . . . . . . . . . . . . 73
14.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 72 14.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 73
14.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . . 73 14.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . . 74
15. Known Open Issues and Areas of Future Work . . . . . . . . . . 74 15. Known Open Issues and Areas of Future Work . . . . . . . . . . 75
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 76 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77
16.1. Normative References . . . . . . . . . . . . . . . . . . . 76 16.1. Normative References . . . . . . . . . . . . . . . . . . . 77
16.2. Informative References . . . . . . . . . . . . . . . . . . 77 16.2. Informative References . . . . . . . . . . . . . . . . . . 78
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 81 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 82
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 82 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 83
B.1. Changes to draft-ietf-lisp-19.txt . . . . . . . . . . . . 82 B.1. Changes to draft-ietf-lisp-20.txt . . . . . . . . . . . . 83
B.2. Changes to draft-ietf-lisp-18.txt . . . . . . . . . . . . 82 B.2. Changes to draft-ietf-lisp-19.txt . . . . . . . . . . . . 83
B.3. Changes to draft-ietf-lisp-17.txt . . . . . . . . . . . . 82 B.3. Changes to draft-ietf-lisp-18.txt . . . . . . . . . . . . 83
B.4. Changes to draft-ietf-lisp-16.txt . . . . . . . . . . . . 82 B.4. Changes to draft-ietf-lisp-17.txt . . . . . . . . . . . . 83
B.5. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 82 B.5. Changes to draft-ietf-lisp-16.txt . . . . . . . . . . . . 83
B.6. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 82 B.6. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 83
B.7. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 83 B.7. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 83
B.8. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 84 B.8. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 84
B.9. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 85 B.9. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 85
B.10. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 86 B.10. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 86
B.11. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 86 B.11. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 87
B.12. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 87 B.12. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 87
B.13. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 88 B.13. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 88
B.14. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 90 B.14. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 90
B.15. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 91 B.15. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 91
B.16. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 92 B.16. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 92
B.17. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 93 B.17. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 93
B.18. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 94 B.18. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 95
B.19. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 94 B.19. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 95
B.20. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 94 B.20. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95 B.21. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 96
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 97
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
skipping to change at page 7, line 15 skipping to change at page 7, line 15
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], [NERD]. Finally, [LISP-MS], documents a general-purpose [EMACS], [NERD]. Finally, [LISP-MS], documents a general-purpose
service interface for accessing a mapping database; this interface is service interface for accessing a mapping database; this interface is
intended to make the mapping database modular so that different intended to make the mapping database modular so that different
approaches can be tried without the need to modify installed LISP approaches can be tried without the need to modify installed LISP
capable devices in LISP sites. 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. It is NOT RECOMMENDED for deployment
modifications and enhancements of protocol mechanisms defined in this beyond experimental situations. Results of experimentation may lead
document. See Section 15 for specific, known issues that are in need to modifications and enhancements of protocol mechanisms defined in
of further work during development, implementation, and prototype this document. See Section 15 for specific, known issues that are in
deployment. need of further work during development, implementation, and
experimentation.
An examination of the implications of LISP on Internet traffic,
applications, routers, and security is for future study. This
analysis will explain what role LISP can play in scalable routing and
will also look at scalability and levels of state required for
encapsulation, decapsulation, liveness, and so on.
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 an address Provider Assigned (PA) Addresses: PA addresses are an address block
block assigned to a site by each service provider to which a site 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 [RFC0791] or IPv6
egress tunnel router (ETR). A RLOC is the output of an EID-to- [RFC2460] address of an egress tunnel router (ETR). A RLOC is the
RLOC mapping lookup. An EID maps to one or more RLOCs. output of an EID-to-RLOC mapping lookup. An EID maps to one or
Typically, RLOCs are numbered from topologically-aggregatable more RLOCs. Typically, RLOCs are numbered from topologically-
blocks that are assigned to a site at each point to which it aggregatable blocks that are assigned to a site at each point to
attaches to the global Internet; where the topology is defined by which it attaches to the global Internet; where the topology is
the connectivity of provider networks, RLOCs can be thought of as defined by the connectivity of provider networks, RLOCs can be
PA addresses. Multiple RLOCs can be assigned to the same ETR thought of as PA addresses. Multiple RLOCs can be assigned to the
device or to multiple ETR devices at a site. same ETR 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 used on the public Internet
EID-prefix block associated with the site where the host is must have the same properties as any other IP address used in that
located. An EID can be used by a host to refer to other hosts. manner; this means, among other things, that it must be globally
EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks MAY be unique. An EID is allocated to a host from an EID-prefix block
assigned in a hierarchical manner, independent of the network associated with the site where the host is located. An EID can be
topology, to facilitate scaling of the mapping database. In used by a host to refer to other hosts. EIDs MUST NOT be used as
addition, an EID block assigned to a site may have site-local LISP RLOCs. Note that EID blocks MAY be assigned in a
structure (subnetting) for routing within the site; this structure hierarchical manner, independent of the network topology, to
is not visible to the global routing system. In theory, the bit facilitate scaling of the mapping database. In addition, an EID
string that represents an EID for one device can represent an RLOC block assigned to a site may have site-local structure
for a different device. As the architecture is realized, if a (subnetting) for routing within the site; this structure is not
given bit string is both an RLOC and an EID, it must refer to the visible to the global routing system. In theory, the bit string
same entity in both cases. When used in discussions with other that represents an EID for one device can represent an RLOC 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 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
larger EID-prefix block. A globally routed address block (whether larger EID-prefix block. A globally routed address block (whether
skipping to change at page 9, line 33 skipping to change at page 9, line 36
mechanisms are in place. Discussion of such transition and access mechanisms are in place. Discussion of such transition and access
mechanisms can be 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 that resides in a
packet with a single IP header (more precisely, an IP packet that LISP site. Packets sent by sources inside of the LISP site to
does not contain a LISP header). The router treats this "inner" destinations outside of the site are candidates for encapsulation
IP destination address as an EID and performs an EID-to-RLOC by the ITR. The ITR treats the IP destination address as an EID
mapping lookup. The router then prepends an "outer" IP header and performs an EID-to-RLOC mapping lookup. The router then
with one of its globally-routable RLOCs in the source address prepends an "outer" IP header with one of its globally-routable
field and the result of the mapping lookup in the destination RLOCs in the source address field and the result of the mapping
address field. Note that this destination RLOC MAY be an lookup in the destination address field. Note that this
intermediate, proxy device that has better knowledge of the EID- destination RLOC MAY be an intermediate, proxy device that has
to-RLOC mapping closer to the destination EID. In general, an ITR better knowledge of the EID-to-RLOC mapping closer to the
receives IP packets from site end-systems on one side and sends destination EID. In general, an ITR receives IP packets from site
LISP-encapsulated IP packets toward the Internet on the other end-systems on one side and sends LISP-encapsulated IP packets
side. toward the Internet on the other 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
RLOC) or the inner destination address (the originating hosts RLOC) or the inner destination address (the originating hosts
supplied EID). supplied EID).
TE-ITR: A TE-ITR is an ITR that is deployed in a service provider TE-ITR: A TE-ITR is an ITR that is deployed in a service provider
network that prepends an additional LISP header for Traffic network that prepends an additional LISP header for Traffic
skipping to change at page 11, line 6 skipping to change at page 11, line 11
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 since a partial set
of locators can be used.
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 they are never 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 they are never 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-octet
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
IPv4 or IPv6 address. See [AFI]/[AFI-REGISTRY] and [RFC3232] for IPv4 or IPv6 address. See [AFI]/[AFI-REGISTRY] and [RFC3232] for
details. An AFI value of 0 used in this specification indicates details. An AFI value of 0 used in this specification indicates
an unspecified encoded address where the length of the address is an unspecified encoded address where the length of the address is
0 bytes following the 16-bit AFI value of 0. 0 octets following the 16-bit AFI value of 0.
Negative Mapping Entry: A negative mapping entry, also known as a Negative Mapping Entry: A negative mapping entry, also known as a
negative cache entry, is an EID-to-RLOC entry where an EID-prefix negative cache entry, is an EID-to-RLOC entry where an EID-prefix
is advertised or stored with no RLOCs. That is, the locator-set is advertised or stored with no RLOCs. That is, the locator-set
for the EID-to-RLOC entry is empty or has an encoded locator count for the EID-to-RLOC entry is empty or has an encoded locator count
of 0. This type of entry could be used to describe a prefix from of 0. This type of entry could be used to describe a prefix from
a non-LISP site, which is explicitly not in the mapping database. a non-LISP site, which is explicitly not in the mapping database.
There are a set of well defined actions that are encoded in a There are a set of well defined actions that are encoded in a
Negative Map-Reply. Negative Map-Reply (Section 6.1.5).
Data Probe: A data-probe is a LISP-encapsulated data packet where Data Probe: A data-probe is a LISP-encapsulated data packet where
the inner header destination address equals the outer header the inner header destination address equals the outer header
destination address used to trigger a Map-Reply by a decapsulating destination address used to trigger a Map-Reply by a decapsulating
ETR. In addition, the original packet is decapsulated and ETR. In addition, the original packet is decapsulated and
delivered to the destination host if the destination EID is in the delivered to the destination host if the destination EID is in the
EID-prefix range configured on the ETR. Otherwise, the packet is EID-prefix range configured on the ETR. Otherwise, the packet is
discarded. A Data Probe is used in some of the mapping database discarded. A Data Probe is used in some of the mapping database
designs to "probe" or request a Map-Reply from an ETR; in other designs to "probe" or request a Map-Reply from an ETR; in other
cases, Map-Requests are used. See each mapping database design cases, Map-Requests are used. See each mapping database design
for details. for details. When using Data Probes, by sending Map-Requests on
the underlying routing system, EID-prefixes must be advertised.
However, this is discouraged if the core is to scale by having
less EID-prefixes stored in the core router's routing tables.
Proxy ITR (PITR): A PITR is also known as a PTR is defined and Proxy ITR (PITR): A PITR is defined and described in [INTERWORK], a
described in [INTERWORK], a PITR acts like an ITR but does so on PITR acts like an ITR but does so on behalf of non-LISP sites
behalf of non-LISP sites which send packets to destinations at 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, this limits off-path data insertion. receiver, this limits off-path data insertion. A route-
returnability check is verified when a message is sent with a
nonce, another message is returned with the same nonce, and the
destination of the original message appears as the source of the
returned message.
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 13, line 5 skipping to change at page 13, line 12
information from Map-Requests, Data-Probes, or encapsulated information from Map-Requests, Data-Probes, or encapsulated
packets. packets.
Locator Status Bits (LSBs): Locator status bits are present in the Locator Status Bits (LSBs): Locator status bits are present in the
LISP header. They are used by ITRs to inform ETRs about the up/ LISP header. They are used by ITRs to inform ETRs about the up/
down status of all ETRs at the local site. These bits are used as down status of all ETRs at the local site. These bits are used as
a hint to convey up/down router status and not path reachability a hint to convey up/down router status and not path reachability
status. The LSBs can be verified by use of one of the Locator status. The LSBs can be verified by use of one of the Locator
Reachability Algorithms described in Section 6.3. Reachability Algorithms described in Section 6.3.
Anycast Address: a term used in this document to refer to the same
IPv4 or IPv6 address configured and used on multiple systems at
the same time. An EID or RLOC can be an anycast address in each
of their own address spaces.
4. Basic Overview 4. Basic Overview
One key concept of LISP is that end-systems (hosts) operate the same One key concept of LISP is that end-systems (hosts) operate the same
way they do today. The IP addresses that hosts use for tracking way they do today. The IP addresses that hosts use for tracking
sockets, connections, and for sending and receiving packets do not sockets, connections, and for sending and receiving packets do not
change. In LISP terminology, these IP addresses are called Endpoint change. In LISP terminology, these IP addresses are called Endpoint
Identifiers (EIDs). Identifiers (EIDs).
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
skipping to change at page 13, line 35 skipping to change at page 14, line 35
this "outer header" are RLOCs. During end-to-end packet exchange this "outer header" are RLOCs. During end-to-end packet exchange
between two Internet hosts, an ITR prepends a new LISP header to each between two Internet hosts, an ITR prepends a new LISP header to each
packet and an egress tunnel router strips the new header. The ITR packet and an egress tunnel router strips the new header. The ITR
performs EID-to-RLOC lookups to determine the routing path to the performs EID-to-RLOC lookups to determine the routing path to the
ETR, which 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 destinations, which in turn, LISP routers deliver packets to to their intended destinations. In a system where LISP is
the destination the end-system has specified. The procedure a deployed, LISP routers intercept EID addressed packets and assist
host uses to send IP packets does not change. in delivering them across the network core where EIDs cannot be
routed. The procedure a 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 (Classless topologically-oriented addresses from provider CIDR (Classless
Inter-Domain Routing) blocks. Inter-Domain Routing) blocks.
skipping to change at page 20, line 7 skipping to change at page 21, line 7
r + + r + +
| | | |
^ + 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 (IH): 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, [RFC0791], [RFC2460]. addresses are EIDs, [RFC0791], [RFC2460].
Outer Header: The outer header is a new header prepended by an ITR. Outer Header: (OH) The outer header is a new header prepended by an
The address fields contain RLOCs obtained from the ingress ITR. 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 setting of the DF bit Flags field is from [RFC0768]. The setting of the DF bit Flags field is
according to rules in Section 5.4.1 and Section 5.4.2. according to rules in Section 5.4.1 and Section 5.4.2.
UDP Header: The UDP header contains an 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.
skipping to change at page 20, line 44 skipping to change at page 21, line 44
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
the UDP and LISP header lengths. For an IPv6 encapsulated packet, the UDP and LISP header lengths. For an IPv6 encapsulated packet,
the UDP length field is the sum of the inner header IPv6 Payload the UDP length field is the sum of the inner header IPv6 Payload
Length, the size of the IPv6 header (40 bytes), and the size of Length, the size of the IPv6 header (40 octets), and the size of
the UDP and LISP headers. the UDP and LISP headers.
N: The N bit is the nonce-present bit. When this bit is set to 1, N: The N bit is the nonce-present bit. When this bit is set to 1,
the low-order 24-bits of the first 32-bits of the LISP header the low-order 24-bits of the first 32-bits of the LISP header
contains a Nonce. See Section 6.3.1 for details. Both N and V contains a Nonce. See Section 6.3.1 for details. Both N and V
bits MUST NOT be set in the same packet. If they are, a bits MUST NOT be set in the same packet. If they are, a
decapsulating ETR MUST treat the "Nonce/Map-Version" field as decapsulating ETR MUST treat the "Nonce/Map-Version" field as
having a Nonce value present. having a Nonce value present.
L: The L bit is the Locator Status Bits field enabled bit. When this L: The L bit is the Locator Status Bits field enabled bit. When this
skipping to change at page 23, line 7 skipping to change at page 24, line 7
ETR is considered 'up'. 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 exception, see below).
When doing ETR/PETR decapsulation: When doing ETR/PETR decapsulation:
o The inner header Time to Live field (or Hop Limit field, in case o The inner header Time to Live field (or Hop Limit field, in case
of IPv6) SHOULD be copied from the outer header Time to Live of IPv6) SHOULD be copied from the outer header Time to Live
field, when the Time to Live field of the outer header is less field, when the Time to Live field of the outer header is less
than the Time to Live of the inner header. Failing to perform than the Time to Live of the inner header. Failing to perform
this check can cause the Time to Live of the inner header to this check can cause the Time to Live of the inner header to
increment across encapsulation/decapsulation cycle. This check is increment across encapsulation/decapsulation cycle. This check is
also performed when doing initial encapsulation when a packet also performed when doing initial encapsulation when a packet
comes to an ITR or PITR destined for a LISP site. comes to an ITR or PITR destined for a LISP site.
o The inner header Type of Service field (or the Traffic Class o The inner header Type of Service field (or the Traffic Class
field, in the case of IPv6) SHOULD be copied from the outer header field, in the case of IPv6) SHOULD be copied from the outer header
Type of Service field (with one caveat, see below). Type of Service field (with one exception, see below).
Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate Note if an ETR/PETR is also an ITR/PITR and choose to reencapsulate
after decapsulating, the net effect of this is that the new outer after decapsulating, the net effect of this is that the new outer
header will carry the same Time to Live as the old outer header minus header will carry the same Time to Live as the old outer header minus
1. 1.
Copying the TTL serves two purposes: first, it preserves the distance Copying the TTL serves two purposes: first, it preserves the distance
the host intended the packet to travel; second, and more importantly, the host intended the packet to travel; second, and more importantly,
it provides for suppression of looping packets in the event there is it provides for suppression of looping packets in the event there is
a loop of concatenated tunnels due to misconfiguration. See a loop of concatenated tunnels due to misconfiguration. See
skipping to change at page 24, line 25 skipping to change at page 25, line 25
Both stateless and stateful mechanisms also apply to Reencapsulating Both stateless and stateful mechanisms also apply to Reencapsulating
and Recursive Tunneling. So any actions below referring to an ITR and Recursive Tunneling. So any actions below referring to an ITR
also apply to an TE-ITR. also apply to an TE-ITR.
5.4.1. A Stateless Solution to MTU Handling 5.4.1. A Stateless Solution to MTU Handling
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 octets, 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 octets, 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. Therefore, S + H = L. outer network layer header of size H. Therefore, 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 octets worth of encapsulation to yield a packet size greater than L
bytes, it resolves the MTU issue by first splitting the original octets, 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
individually encapsulated packets. It strips the LISP headers then individually encapsulated packets. It strips the LISP headers then
forwards each fragment to the destination host of the destination forwards each fragment to the destination host of the destination
site. The two fragments are reassembled at the destination host into site. The two fragments are reassembled at the destination host into
the single IP datagram that was originated by the source host. Note the single IP datagram that was originated by the source host. Note
skipping to change at page 28, line 39 skipping to change at page 30, line 5
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.
The format of control messages includes the UDP header so the The format of control messages includes the UDP header so the
checksum and length fields can be used to protect and delimit message checksum and length fields can be used to protect and delimit message
boundaries. boundaries.
This main LISP specification is the authoritative source for message
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 and for defining LISP control message formats. Current
allocations are:
Reserved: 0 b'0000' Reserved: 0 b'0000'
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100' LISP Map-Notify: 4 b'0100'
LISP Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
6.1.2. Map-Request Message Format 6.1.2. Map-Request Message Format
skipping to change at page 29, line 42 skipping to change at page 30, line 43
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI n | ITR-RLOC Address n ... | | ITR-RLOC-AFI n | ITR-RLOC Address n ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-prefix-AFI | / | Reserved | EID mask-len | EID-prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-prefix ... | \ | EID-prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... | | Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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. Set to 1 when an ITR wants the Requests sent by an ITR. Set to 1 when an ITR wants the
destination site to return the Map-Reply rather than the mapping destination site to return the Map-Reply rather than the mapping
database system. database system.
skipping to change at page 31, line 5 skipping to change at page 32, line 5
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.
Nonce: An 8-byte random value created by the sender of the Map- Nonce: An 8-octet random value created by the sender of the Map-
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
skipping to change at page 31, line 32 skipping to change at page 32, line 32
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.
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 octets if an IPv4 address-family, 16 octets if an IPv6
address-family. When a Map-Request is sent by an ITR because a address-family. When a Map-Request is sent by an ITR because a
data packet is received for a destination where there is no data packet is received for a destination where there is no
mapping entry, the EID-prefix is set to the destination IP address mapping entry, the EID-prefix is set to the destination IP address
of the data packet. And the 'EID mask-len' is set to 32 or 128 of the data packet. And the 'EID mask-len' is set to 32 or 128
for IPv4 or IPv6, respectively. When an xTR wants to query a site for IPv4 or IPv6, respectively. When an xTR wants to query a site
about the status of a mapping it already has cached, the EID- about the status of a mapping it already has cached, the EID-
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: This field is optional and present when the
UDP length indicates there is enough space in the packet to
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 data packet's destination address used for the Map-Request is the data packet's destination
address (i.e. the destination-EID) which had a mapping cache lookup address (i.e. the destination-EID) which had a mapping cache lookup
failure. For the latter two cases, the destination IP address used failure. For the latter two cases, the destination IP address used
for the Map-Request is one of the RLOC addresses from the locator-set for the Map-Request is one of the RLOC addresses from the locator-set
of the map cache entry. The source address is either an IPv4 or IPv6 of the map cache entry. The source address is either an IPv4 or IPv6
skipping to change at page 33, line 33 skipping to change at page 34, line 33
c | Rsvd | Map-Version Number | EID-prefix-AFI | c | Rsvd | Map-Version Number | EID-prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix | r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 2 (Map-Reply) Type: 2 (Map-Reply)
P: This is the probe-bit which indicates that the Map-Reply is in P: This is the probe-bit which indicates that the Map-Reply is in
response to a locator reachability probe Map-Request. The nonce response to a locator reachability probe Map-Request. The nonce
field MUST contain a copy of the nonce value from the original field MUST contain a copy of the nonce value from the original
Map-Request. See Section 6.3.2 for more details. Map-Request. See Section 6.3.2 for more details.
E: Indicates that the ETR which sends this Map-Reply message is E: Indicates that the ETR which sends this Map-Reply message is
advertising that the site is enabled for the Echo-Nonce locator advertising that the site is enabled for the Echo-Nonce locator
reachability algorithm. See Section 6.3.1 for more details. reachability algorithm. See Section 6.3.1 for more details.
S: This is the Security bit. When set to 1 the field following the S: This is the Security bit. When set to 1 the following
Mapping Protocol Data field will have the following format. The authentication information will be appended to the end of the Map-
detailed format of the Authentication Data Content is for further Reply. The detailed format of the Authentication Data Content is
study. for further study.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . | | AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
skipping to change at page 35, line 33 skipping to change at page 36, line 33
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 octets if an IPv4 address-family, 16 octets 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
skipping to change at page 36, line 10 skipping to change at page 37, line 10
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,
receiver of the Map-Reply will decide how to load-split traffic. receiver of the Map-Reply will decide how to load-split traffic.
See Section 6.5 for a suggested hash algorithm to distribute load See Section 6.5 for a suggested hash algorithm to distribute load
across locators with same priority and equal weight values. across locators with same priority and equal weight values.
M Priority: each RLOC is assigned a multicast priority used by an M Priority: each RLOC is assigned a multicast priority used by an
ETR in a receiver multicast site to select an ITR in a source ETR in a receiver multicast site to select an ITR in a source
multicast site for building multicast distribution trees. A value multicast site for building multicast distribution trees. A value
of 255 means the RLOC MUST NOT be used for joining a multicast of 255 means the RLOC MUST NOT be used for joining a multicast
distribution tree. distribution tree. For more details, see [MLISP].
M Weight: when priorities are the same for multiple RLOCs, the M Weight: when priorities are the same for multiple RLOCs, the
weight indicates how to balance building multicast distribution weight indicates how to balance building multicast distribution
trees across multiple ITRs. The weight is encoded as a relative trees across multiple ITRs. The weight is encoded as a relative
weight (similar to the unicast Weights) of total number of trees weight (similar to the unicast Weights) of total number of trees
built to the source site identified by the EID-prefix. If all built to the source site identified by the EID-prefix. If all
weights for a locator-set are equal, the receiver of the Map-Reply weights for a locator-set are equal, the receiver of the Map-Reply
will decide how to distribute multicast state across ITRs. will decide how to distribute multicast state across ITRs. For
more details, see [MLISP].
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-
skipping to change at page 37, line 6 skipping to change at page 38, line 7
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: This field is optional and present when the
UDP length indicates there is enough space in the packet to
include it.
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
reachability is required, See Section 6.3 for details. reachability is required, See Section 6.3 for details.
skipping to change at page 41, line 9 skipping to change at page 42, line 9
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-octet Nonce field is set to 0 in Map-Register
Since the Map-Register message is authenticated, the nonce field messages. Since the Map-Register message is authenticated, the
is not currently used for any security function but may be in the nonce field is not currently used for any security function but
future as part of an anti-replay solution. may be in the future as part of an anti-replay solution.
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 octets 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.
skipping to change at page 56, line 24 skipping to change at page 57, line 24
hardware. This may be mitigated by creating special FIB entries hardware. This may be mitigated by creating special FIB entries
for the EID-prefixes of EIDs served by the ETR (those for which for the EID-prefixes of EIDs served by the ETR (those for which
the router provides an RLOC translation). These FIB entries are the router provides an RLOC translation). These FIB entries are
marked with a flag indicating that control plane processing should marked with a flag indicating that control plane processing should
be performed. The forwarding logic of testing for particular IP be performed. The forwarding logic of testing for particular IP
protocol number value is not necessary. There are a few proven protocol number value is not necessary. There are a few proven
cases where no changes to existing deployed hardware were needed cases where no changes to existing deployed hardware were needed
to support the LISP data-plane. to support the LISP data-plane.
o On an ITR, prepending a new IP header consists of adding more o On an ITR, prepending a new IP header consists of adding more
bytes to a MAC rewrite string and prepending the string as part of octets to a MAC rewrite string and prepending the string as part
the outgoing encapsulation procedure. Routers that support GRE of the outgoing encapsulation procedure. Routers that support GRE
tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already tunneling [RFC2784] or 6to4 tunneling [RFC3056] may already
support this action. support this action.
o A packet's source address or interface the packet was received on o A packet's source address or interface the packet was received on
can be used to select a VRF (Virtual Routing/Forwarding). The can be used to select a VRF (Virtual Routing/Forwarding). The
VRF's routing table can be used to find EID-to-RLOC mappings. VRF's routing table can be used to find EID-to-RLOC mappings.
For performance issues related to map-cache management, see section For performance issues related to map-cache management, see section
Section 12. Section 12.
skipping to change at page 62, line 19 skipping to change at page 63, line 19
IPv6 traceroute follows the procedure described above since the IPv6 traceroute follows the procedure described above since the
entire traceroute data packet is included in ICMP Time Exceeded entire traceroute data packet is included in ICMP Time Exceeded
message payload. Therefore, only the ITR needs to pay special message payload. Therefore, only the ITR needs to pay special
attention for forwarding ICMP messages back to the traceroute source. attention for forwarding ICMP messages back to the traceroute source.
9.2. IPv4 Traceroute 9.2. IPv4 Traceroute
For IPv4 traceroute, we cannot follow the above procedure since IPv4 For IPv4 traceroute, we cannot follow the above procedure since IPv4
ICMP Time Exceeded messages only include the invoking IP header and 8 ICMP Time Exceeded messages only include the invoking IP header and 8
bytes that follow the IP header. Therefore, when a core router sends octets that follow the IP header. Therefore, when a core router
an IPv4 Time Exceeded message to an ITR, all the ITR has in the ICMP sends an IPv4 Time Exceeded message to an ITR, all the ITR has in the
payload is the encapsulated header it prepended followed by a UDP ICMP payload is the encapsulated header it prepended followed by a
header. The original invoking IP header, and therefore the identity UDP header. The original invoking IP header, and therefore the
of the traceroute source is lost. identity of the traceroute source is lost.
The solution we propose to solve this problem is to cache traceroute The solution we propose to solve this problem is to cache traceroute
IPv4 headers in the ITR and to match them up with corresponding IPv4 IPv4 headers in the ITR and to match them up with corresponding IPv4
Time Exceeded messages received from core routers and the ETR. The Time Exceeded messages received from core routers and the ETR. The
ITR will use a circular buffer for caching the IPv4 and UDP headers ITR will use a circular buffer for caching the IPv4 and UDP headers
of traceroute packets. It will select a 16-bit number as a key to of traceroute packets. It will select a 16-bit number as a key to
find them later when the IPv4 Time Exceeded messages are received. find them later when the IPv4 Time Exceeded messages are received.
When an ITR encapsulates an IPv4 traceroute packet, it will use the When an ITR encapsulates an IPv4 traceroute packet, it will use the
16-bit number as the UDP source port in the encapsulating header. 16-bit number as the UDP source port in the encapsulating header.
When the ICMP Time Exceeded message is returned to the ITR, the UDP When the ICMP Time Exceeded message is returned to the ITR, the UDP
skipping to change at page 72, line 11 skipping to change at page 73, line 11
Considerations for Network Management tools exist so the LISP Considerations for Network Management tools exist so the LISP
protocol suite can be operationally managed. The mechanisms can be protocol suite can be operationally managed. The mechanisms can be
found in [LISP-MIB] and [LISP-LIG]. found in [LISP-MIB] and [LISP-LIG].
14. IANA Considerations 14. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the LISP Authority (IANA) regarding registration of values related to the LISP
specification, in accordance with BCP 26 and RFC 5226 [RFC5226]. specification, in accordance with BCP 26 and RFC 5226 [RFC5226].
There are two name spaces in LISP that require registration: There are four name spaces in LISP that require registration:
o LISP IANA registry allocations should not be made for purposes o LISP IANA registry allocations should not be made for purposes
unrelated to LISP routing or transport protocols. unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Review", "Experimental BCP 26: "Specification Required", "IETF Review", "Experimental
Use", "First Come First Served". Use", "First Come First Served".
14.1. LISP ACT and Flag Fields 14.1. LISP ACT and Flag Fields
skipping to change at page 74, line 33 skipping to change at page 75, line 33
development. In particular, the performance, scaling and security development. In particular, the performance, scaling and security
characteristics of the map-cache will be discovered as part of characteristics of the map-cache will be discovered as part of
this experiment. Performance metrics to be observed are packet this experiment. Performance metrics to be observed are packet
reordering associated with the LISP data probe and loss of the reordering associated with the LISP data probe and loss of the
first packet in a flow associated with map-caching. The impact of first packet in a flow associated with map-caching. The impact of
these upon TCP will be observed. See Section 12 for additional these upon TCP will be observed. See Section 12 for additional
thoughts and considerations. 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 o In order to maintain security and stability, Internet Protocols
typically isolate the control and data planes. Therefore, user typically isolate the control and data planes. Therefore, user
skipping to change at page 76, line 5 skipping to change at page 76, line 6
destroyed. LISP does not maintain this separation. The degree to destroyed. LISP does not maintain this separation. The degree to
which the loss of separation impacts security and stability is a which the loss of separation impacts security and stability is a
topic for experimental observation. topic for experimental observation.
o LISP allows for different mapping database systems to be used. o LISP allows for different mapping database systems to be used.
While only one [ALT] is currently well-defined, each mapping While only one [ALT] is currently well-defined, each mapping
database will likely have some impact on the security of the EID- database will likely have some impact on the security of the EID-
to-RLOC mappings. How each mapping database system's security to-RLOC mappings. How each mapping database system's security
properties impact on LISP overall is for further study. properties impact on LISP overall is for further study.
o An examination of the implications of LISP on Internet traffic,
applications, routers, and security is needed. This will help to
understand the consequences for network stability, routing
protocol function, routing scalability, migration and backward
compatibility, and implementation scalability (as influenced by
additional protocol components, additional state, and additional
processing for encapsulation, decapsulation, liveness).
Other LISP documents may also include open issues and areas for
future work.
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).
skipping to change at page 82, line 7 skipping to change at page 83, 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-19.txt B.1. Changes to draft-ietf-lisp-20.txt
o Posted January 2012 for resolution to Adrian Farrel's security
comments as well as additions to the end of section 2, Elwyn
Davies Gen-Art comments, and Ralph Droms' IANA and EID definition
comments.
B.2. Changes to draft-ietf-lisp-19.txt
o Posted January 2012 for Stephen Farrell's comment resolution. o Posted January 2012 for Stephen Farrell's comment resolution.
B.2. Changes to draft-ietf-lisp-18.txt B.3. Changes to draft-ietf-lisp-18.txt
o Posted December 2011 after reflecting comments from IANA. o Posted December 2011 after reflecting comments from IANA.
o Create reference to sections 5.4.1 and 5.4.2 about DF bit setting o Create reference to sections 5.4.1 and 5.4.2 about DF bit setting
from section 5.3. from section 5.3.
o Inserted two references for Route-Returnability and on-path o Inserted two references for Route-Returnability and on-path
attacks in Security Considerations section. attacks in Security Considerations section.
B.3. Changes to draft-ietf-lisp-17.txt B.4. Changes to draft-ietf-lisp-17.txt
o Posted December 2011 after IETF last call comments. o Posted December 2011 after IETF last call comments.
o Make Map-Notify port assignment be 4342 in both source and o Make Map-Notify port assignment be 4342 in both source and
destination ports. This change was agreed on and put in [LISP-MS] destination ports. This change was agreed on and put in [LISP-MS]
but was not updated in this spec. but was not updated in this spec.
B.4. Changes to draft-ietf-lisp-16.txt B.5. 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.5. Changes to draft-ietf-lisp-15.txt B.6. 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.6. Changes to draft-ietf-lisp-14.txt B.7. 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 83, line 22 skipping to change at page 84, line 31
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.7. Changes to draft-ietf-lisp-13.txt B.8. 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 84, line 7 skipping to change at page 85, line 17
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.8. Changes to draft-ietf-lisp-12.txt B.9. 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 85, line 20 skipping to change at page 86, line 30
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.9. Changes to draft-ietf-lisp-11.txt B.10. 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 86, line 13 skipping to change at page 87, line 23
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.10. Changes to draft-ietf-lisp-10.txt B.11. 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 86, line 35 skipping to change at page 87, line 45
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.11. Changes to draft-ietf-lisp-09.txt B.12. 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.12. Changes to draft-ietf-lisp-08.txt B.13. 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 88, line 42 skipping to change at page 90, line 5
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.13. Changes to draft-ietf-lisp-07.txt B.14. 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 90, line 17 skipping to change at page 91, line 27
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.14. Changes to draft-ietf-lisp-06.txt B.15. 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.
o Add definitions for PITR and PETR. o Add definitions for PITR and PETR.
o Indicate an AFI value of 0 is an unspecified address. o Indicate an AFI value of 0 is an unspecified address.
o Indicate that the TTL field of a Map-Register is not used and set o Indicate that the TTL field of a Map-Register is not used and set
to 0 by the sender. This change makes this spec consistent with to 0 by the sender. This change makes this spec consistent with
[LISP-MS]. [LISP-MS].
o Change "... yield a packet size of L bytes" to "... yield a packet o Change "... yield a packet size of L octets" to "... yield a
size greater than L bytes". packet size greater than L octets".
o Clarify section 6.1.5 on what addresses and ports are used in Map- o Clarify section 6.1.5 on what addresses and ports are used in Map-
Reply messages. Reply messages.
o Clarify that LSBs that go beyond the number of locators do not to o Clarify that LSBs that go beyond the number of locators do not to
be SMRed when the locator addresses are greater lexicographically be SMRed when the locator addresses are greater lexicographically
than the locator in the existing locator-set. than the locator in the existing locator-set.
o Add Gregg, Srini, and Amit to acknowledgment section. o Add Gregg, Srini, and Amit to acknowledgment section.
skipping to change at page 91, line 26 skipping to change at page 92, line 37
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.15. Changes to draft-ietf-lisp-05.txt B.16. 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 92, line 5 skipping to change at page 93, line 16
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.16. Changes to draft-ietf-lisp-04.txt B.17. 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 93, line 44 skipping to change at page 95, line 10
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.17. Changes to draft-ietf-lisp-03.txt B.18. 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.18. Changes to draft-ietf-lisp-02.txt B.19. 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.19. Changes to draft-ietf-lisp-01.txt B.20. 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.20. Changes to draft-ietf-lisp-00.txt B.21. 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. 67 change blocks. 
212 lines changed or deleted 242 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/