draft-ietf-lisp-15.txt   draft-ietf-lisp-16.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: January 10, 2012 D. Lewis Expires: May 3, 2012 D. Lewis
cisco Systems cisco Systems
July 9, 2011 October 31, 2011
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-15 draft-ietf-lisp-16
Abstract Abstract
This draft describes a network-based protocol that enables separation This draft describes a network-based protocol that enables separation
of IP addresses into two new numbering spaces: Endpoint Identifiers of IP addresses into two new numbering spaces: Endpoint Identifiers
(EIDs) and Routing Locators (RLOCs). No changes are required to (EIDs) and Routing Locators (RLOCs). No changes are required to
either host protocol stacks or to the "core" of the Internet either host protocol stacks or to the "core" of the Internet
infrastructure. LISP can be incrementally deployed, without a "flag infrastructure. LISP can be incrementally deployed, without a "flag
day", and offers traffic engineering, multi-homing, and mobility day", and offers traffic engineering, multi-homing, and mobility
benefits even to early adopters, when there are relatively few LISP- benefits to early adopters, even when there are relatively few LISP-
capable sites. capable sites.
Design and development of LISP was largely motivated by the problem Design and development of LISP was largely motivated by the problem
statement produced by the October, 2006 IAB Routing and Addressing statement produced by the October 2006 IAB Routing and Addressing
Workshop. Workshop.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2012. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 26 skipping to change at page 2, line 26
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4 1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 4
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16 5. LISP Encapsulation Details . . . . . . . . . . . . . . . . . . 16
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 17
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 23
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24
5.5. Using Virtualization and Segmentation with LISP . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 31 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 31
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 32
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 36
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 38
6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40
6.1.8. Encapsulated Control Message Format . . . . . . . . . 41 6.1.8. Encapsulated Control Message Format . . . . . . . . . 41
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47
6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48
6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49
6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 50 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 50
6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 50 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 51
6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 51 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 52
6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52
6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 54 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 54
7. Router Performance Considerations . . . . . . . . . . . . . . 55 7. Router Performance Considerations . . . . . . . . . . . . . . 55
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 57 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 57
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 58 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 58
8.4. LISP Functionality with Conventional NATs . . . . . . . . 58 8.4. LISP Functionality with Conventional NATs . . . . . . . . 58
8.5. Packets Egressing a LISP Site . . . . . . . . . . . . . . 59 8.5. Packets Egressing a LISP Site . . . . . . . . . . . . . . 59
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 60 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 60
skipping to change at page 3, line 23 skipping to change at page 3, line 23
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 63 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 63
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 63 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 63
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 63 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 63
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 63 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 63
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 65 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 65
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67
12. Security Considerations . . . . . . . . . . . . . . . . . . . 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 68
13. Network Management Considerations . . . . . . . . . . . . . . 70 13. Network Management Considerations . . . . . . . . . . . . . . 70
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71 14.1. LISP ACT and Flag Fields . . . . . . . . . . . . . . . . . 71
14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71 14.2. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 14.3. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71
15.1. Normative References . . . . . . . . . . . . . . . . . . . 72 14.4. LISP Key ID Numbers . . . . . . . . . . . . . . . . . . . 72
15.2. Informative References . . . . . . . . . . . . . . . . . . 73 15. Known Open Issues and Areas of Future Work . . . . . . . . . . 73
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 76 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 77 16.1. Normative References . . . . . . . . . . . . . . . . . . . 74
B.1. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 77 16.2. Informative References . . . . . . . . . . . . . . . . . . 75
B.2. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 77 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 78
B.3. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 77 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 79
B.4. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 78 B.1. Changes to draft-ietf-lisp-16.txt . . . . . . . . . . . . 79
B.5. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 79 B.2. Changes to draft-ietf-lisp-15.txt . . . . . . . . . . . . 79
B.6. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 80 B.3. Changes to draft-ietf-lisp-14.txt . . . . . . . . . . . . 79
B.7. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 81 B.4. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 80
B.8. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 81 B.5. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 80
B.9. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 83 B.6. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 82
B.10. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 84 B.7. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 82
B.11. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 85 B.8. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 83
B.12. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 86 B.9. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 83
B.13. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 88 B.10. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 85
B.14. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 88 B.11. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 87
B.15. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 89 B.12. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 88
B.16. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 89 B.13. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 88
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90 B.14. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 90
B.15. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 90
B.16. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 91
B.17. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 91
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 92
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 6, line 14 skipping to change at page 6, line 14
explicitly a separate "module" to facilitate experimentation with a explicitly a separate "module" to facilitate experimentation with a
variety of approaches. One database design that is being developed variety of approaches. One database design that is being developed
and prototyped as part of the LISP working group work is [ALT]. and prototyped as part of the LISP working group work is [ALT].
Others that have been described but not implemented include [CONS], Others that have been described but not implemented include [CONS],
[EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general- [EMACS], [RPMD], [NERD]. Finally, [LISP-MS], documents a general-
purpose service interface for accessing a mapping database; this purpose service interface for accessing a mapping database; this
interface is intended to make the mapping database modular so that interface is intended to make the mapping database modular so that
different approaches can be tried without the need to modify different approaches can be tried without the need to modify
installed xTRs. installed xTRs.
This experimental specification does not address automated key This experimental specification has areas that require additional
management. Addressing automated key management is necessary for experience and measurement. Results of such work may lead to
Internet standards. See Section 12 for further security details. modifications and enhancements of protocol mechanisms defined in this
document. See Section 15 for specific, known issues that are in need
of further work during development, implementation, and prototype
deployment.
3. Definition of Terms 3. Definition of Terms
Provider Independent (PI) Addresses: PI addresses are an address Provider Independent (PI) Addresses: PI addresses are an address
block assigned from a pool where blocks are not associated with block assigned from a pool where blocks are not associated with
any particular location in the network (e.g. from a particular any particular location in the network (e.g. from a particular
service provider), and is therefore not topologically aggregatable service provider), and is therefore not topologically aggregatable
in the routing system. in the routing system.
Provider Assigned (PA) Addresses: PA addresses are an a address Provider Assigned (PA) Addresses: PA addresses are an a address
skipping to change at page 11, line 38 skipping to change at page 11, line 38
sending Map-Request messages. sending Map-Request messages.
Server-side: a term used in this document to indicate a connection Server-side: a term used in this document to indicate a connection
initiation attempt is being accepted for a destination EID. The initiation attempt is being accepted for a destination EID. The
ETR(s) at the destination LISP site are the first to send Map- ETR(s) at the destination LISP site are the first to send Map-
Replies to the source site initiating the connection. The ETR(s) Replies to the source site initiating the connection. The ETR(s)
at this destination site can obtain mappings by gleaning at this destination site can obtain mappings by gleaning
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 Algoriths described in Section 6.3. Reachability Algorithms described in Section 6.3.
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
skipping to change at page 12, line 36 skipping to change at page 12, line 36
two Internet hosts, an ITR prepends a new LISP header to each packet two Internet hosts, an ITR prepends a new LISP header to each packet
and an egress tunnel router strips the new header. The ITR performs and an egress tunnel router strips the new header. The ITR performs
EID-to-RLOC lookups to determine the routing path to the ETR, which EID-to-RLOC lookups to determine the routing path to the ETR, which
has the RLOC as one of its IP addresses. has the RLOC as one of its IP addresses.
Some basic rules governing LISP are: Some basic rules governing LISP are:
o End-systems (hosts) only send to addresses which are EIDs. They o End-systems (hosts) only send to addresses which are EIDs. They
don't know addresses are EIDs versus RLOCs but assume packets get don't know addresses are EIDs versus RLOCs but assume packets get
to LISP routers, which in turn, deliver packets to the destination to LISP routers, which in turn, deliver packets to the destination
the end-system has specified. the end-system has specified. 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 blocks. topologically-oriented addresses from provider CIDR blocks.
o When a router originates packets it may use as a source address o When a router originates packets it may use as a source address
skipping to change at page 14, line 10 skipping to change at page 14, line 10
could be the site's border router at the service provider attachment could be the site's border router at the service provider attachment
point. Mixing and matching of site-operated, ISP-operated, and other point. Mixing and matching of site-operated, ISP-operated, and other
tunnel routers is allowed for maximum flexibility. See Section 8 for tunnel routers is allowed for maximum flexibility. See Section 8 for
more details. more details.
4.1. Packet Flow Sequence 4.1. Packet Flow Sequence
This section provides an example of the unicast packet flow with the This section provides an example of the unicast packet flow with the
following conditions: following conditions:
o Source host "host1.example.abc.com" is sending a packet to o Source host "host1.abc.example.com" is sending a packet to
"host2.example.xyz.com", exactly what host1 would do if the site "host2.xyz.example.com", exactly what host1 would do if the site
was not using LISP. was not using LISP.
o Each site is multi-homed, so each tunnel router has an address o Each site is multi-homed, so each tunnel router has an address
(RLOC) assigned from the service provider address block for each (RLOC) assigned from the service provider address block for each
provider to which that particular tunnel router is attached. provider to which that particular tunnel router is attached.
o The ITR(s) and ETR(s) are directly connected to the source and o The ITR(s) and ETR(s) are directly connected to the source and
destination, respectively, but the source and destination can be destination, respectively, but the source and destination can be
located anywhere in LISP site. located anywhere in LISP site.
o Map-Requests can be sent on the underlying routing system topology o Map-Requests can be sent on the underlying routing system topology
or over an alternative topology [ALT]. or over an alternative topology [ALT].
o Map-Replies are sent on the underlying routing system topology. o Map-Replies are sent on the underlying routing system topology.
Client host1.example.abc.com wants to communicate with server Client host1.abc.example.com wants to communicate with server
host2.example.xyz.com: host2.xyz.example.com:
1. host1.example.abc.com wants to open a TCP connection to 1. host1.abc.example.com wants to open a TCP connection to
host2.example.xyz.com. It does a DNS lookup on host2.xyz.example.com. It does a DNS lookup on
host2.example.xyz.com. An A/AAAA record is returned. This host2.xyz.example.com. An A/AAAA record is returned. This
address is the destination EID. The locally-assigned address of address is the destination EID. The locally-assigned address of
host1.example.abc.com is used as the source EID. An IPv4 or IPv6 host1.abc.example.com is used as the source EID. An IPv4 or IPv6
packet is built and forwarded through the LISP site as a normal packet is built and forwarded through the LISP site as a normal
IP packet until it reaches a LISP ITR. IP packet until it reaches a LISP ITR.
2. The LISP ITR must be able to map the EID destination to an RLOC 2. The LISP ITR must be able to map the EID destination to an RLOC
of one of the ETRs at the destination site. The specific method of one of the ETRs at the destination site. The specific method
used to do this is not described in this example. See [ALT] or used to do this is not described in this example. See [ALT] or
[CONS] for possible solutions. [CONS] for possible solutions.
3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be 3. The ITR will send a LISP Map-Request. Map-Requests SHOULD be
rate-limited. rate-limited.
4. When an alternate mapping system is not in use, the Map-Request 4. When an alternate mapping system is not in use, the Map-Request
packet is routed through the underlying routing system. packet is routed through the underlying routing system.
Otherwise, the Map-Request packet is routed on an alternate Otherwise, the Map-Request packet is routed on an alternate
logical topology. In either case, when the Map-Request arrives logical topology, for example the [ALT] database mapping system.
at one of the ETRs at the destination site, it will process the In either case, when the Map-Request arrives at one of the ETRs
packet as a control message. at the destination site, it will process the packet as a control
message.
5. The ETR looks at the destination EID of the Map-Request and 5. The ETR looks at the destination EID of the Map-Request and
matches it against the prefixes in the ETR's configured EID-to- matches it against the prefixes in the ETR's configured EID-to-
RLOC mapping database. This is the list of EID-prefixes the ETR RLOC mapping database. This is the list of EID-prefixes the ETR
is supporting for the site it resides in. If there is no match, is supporting for the site it resides in. If there is no match,
the Map-Request is dropped. Otherwise, a LISP Map-Reply is the Map-Request is dropped. Otherwise, a LISP Map-Reply is
returned to the ITR. returned to the ITR.
6. The ITR receives the Map-Reply message, parses the message (to 6. The ITR receives the Map-Reply message, parses the message (to
check for format validity) and stores the mapping information check for format validity) and stores the mapping information
from the packet. This information is stored in the ITR's EID-to- from the packet. This information is stored in the ITR's EID-to-
RLOC mapping cache. Note that the map cache is an on-demand RLOC mapping cache. Note that the map cache is an on-demand
cache. An ITR will manage its map cache in such a way that cache. An ITR will manage its map cache in such a way that
optimizes for its resource constraints. optimizes for its resource constraints.
7. Subsequent packets from host1.example.abc.com to 7. Subsequent packets from host1.abc.example.com to
host2.example.xyz.com will have a LISP header prepended by the host2.xyz.example.com will have a LISP header prepended by the
ITR using the appropriate RLOC as the LISP header destination ITR using the appropriate RLOC as the LISP header destination
address learned from the ETR. Note the packet may be sent to a address learned from the ETR. Note the packet may be sent to a
different ETR than the one which returned the Map-Reply due to different ETR than the one which returned the Map-Reply due to
the source site's hashing policy or the destination site's the source site's hashing policy or the destination site's
locator-set policy. locator-set policy.
8. The ETR receives these packets directly (since the destination 8. The ETR receives these packets directly (since the destination
address is one of its assigned IP addresses), strips the LISP address is one of its assigned IP addresses), checks the validity
header and forwards the packets to the attached destination host. of the addresses, strips the LISP header, and forwards packets to
the attached destination host.
In order to defer the need for a mapping lookup in the reverse In order to defer the need for a mapping lookup in the reverse
direction, an ETR MAY create a cache entry that maps the source EID direction, an ETR MAY create a cache entry that maps the source EID
(inner header source IP address) to the source RLOC (outer header (inner header source IP address) to the source RLOC (outer header
source IP address) in a received LISP packet. Such a cache entry is source IP address) in a received LISP packet. Such a cache entry is
termed a "gleaned" mapping and only contains a single RLOC for the termed a "gleaned" mapping and only contains a single RLOC for the
EID in question. More complete information about additional RLOCs EID in question. More complete information about additional RLOCs
SHOULD be verified by sending a LISP Map-Request for that EID. Both SHOULD be verified by sending a LISP Map-Request for that EID. Both
ITR and the ETR may also influence the decision the other makes in ITR and the ETR may also influence the decision the other makes in
selecting an RLOC. See Section 6 for more details. selecting an RLOC. See Section 6 for more details.
skipping to change at page 16, line 23 skipping to change at page 16, line 23
This specification recommends that implementations support for one of This specification recommends that implementations support for one of
the proposed fragmentation and reassembly schemes. These two the proposed fragmentation and reassembly schemes. These two
existing schemes are detailed in Section 5.4. existing schemes are detailed in Section 5.4.
Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP Since IPv4 or IPv6 addresses can be either EIDs or RLOCs, the LISP
architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner architecture supports IPv4 EIDs with IPv6 RLOCs (where the inner
header is in IPv4 packet format and the other header is in IPv6 header is in IPv4 packet format and the other header is in IPv6
packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header packet format) or IPv6 EIDs with IPv4 RLOCs (where the inner header
is in IPv6 packet format and the other header is in IPv4 packet is in IPv6 packet format and the other header is in IPv4 packet
format). The next sub-sections illustrate packet formats for the format). The next sub-sections illustrate packet formats for the
homogenous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4 homogeneous case (IPv4-in-IPv4 and IPv6-in-IPv6) but all 4
combinations SHOULD be supported. combinations MUST be supported.
5.1. LISP IPv4-in-IPv4 Header Format 5.1. LISP IPv4-in-IPv4 Header Format
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length | / |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 19, line 41 skipping to change at page 19, line 41
verify the checksum value. If it chooses to perform such verify the checksum value. If it chooses to perform such
verification, and the verification fails, the packet MUST be verification, and the verification fails, the packet MUST be
silently dropped. If the ETR chooses not to perform the silently dropped. If the ETR chooses not to perform the
verification, or performs the verification successfully, the verification, or performs the verification successfully, the
packet MUST be accepted for decapsulation. The handling of UDP packet MUST be accepted for decapsulation. The handling of UDP
checksums for all tunneling protocols, including LISP, is under checksums for all tunneling protocols, including LISP, is under
active discussion within the IETF. When that discussion active discussion within the IETF. When that discussion
concludes, any necessary changes will be made to align LISP with concludes, any necessary changes will be made to align LISP with
the outcome of the broader discussion. the outcome of the broader discussion.
UDP Length: The UDP length field is for an IPv4 encapsulated packet, UDP Length: The UDP length field is set for an IPv4 encapsulated
the inner header Total Length plus the UDP and LISP header lengths packet to be the sum of the inner header IPv4 Total Length plus
are used. For an IPv6 encapsulated packet, the inner header the UDP and LISP header lengths. For an IPv6 encapsulated packet,
Payload Length plus the size of the IPv6 header (40 bytes) plus the UDP length field is the sum of the inner header IPv6 Payload
the size of the UDP and LISP headers are used. The UDP header Length, the size of the IPv6 header (40 bytes), and the size of
length is 8 bytes. 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
bit is set to 1, the Locator-Status-Bits in the second 32-bits of bit is set to 1, the Locator Status Bits in the second 32-bits of
the LISP header are in use. the LISP header are in use.
x 1 x x 0 x x x x 1 x x 0 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version | |N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Status Bits | | Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
E: The E bit is the echo-nonce-request bit. When this bit is set to E: The E bit is the echo-nonce-request bit. When this bit is set to
1, the N bit MUST be 1. This bit SHOULD be ignored and has no 1, the N bit MUST be 1. This bit SHOULD be ignored and has no
meaning when the N bit is set to 0. See Section 6.3.1 for meaning when the N bit is set to 0. See Section 6.3.1 for
details. details.
V: The V bit is the Map-Version present bit. When this bit is set to V: The V bit is the Map-Version present bit. When this bit is set to
1, the N bit MUST be 0. Refer to Section 6.6.3 for more details. 1, the N bit MUST be 0. Refer to Section 6.6.3 for more details.
This bit indicates that the first 4 bytes of the LISP header is This bit indicates that the LISP header is encoded as:
encoded as:
0 x 0 1 x x x x 0 x 0 1 x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Source Map-Version | Dest Map-Version | |N|L|E|V|I|flags| Source Map-Version | Dest Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID/Locator Status Bits | | Instance ID/Locator Status Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
I: The I bit is the Instance ID bit. See Section 5.5 for more I: The I bit is the Instance ID bit. See Section 5.5 for more
details. When this bit is set to 1, the Locator Status Bits field details. When this bit is set to 1, the Locator Status Bits field
is reduced to 8-bits and the high-order 24-bits are used as an is reduced to 8-bits and the high-order 24-bits are used as an
Instance ID. If the L-bit is set to 0, then the low-order 8 bits Instance ID. If the L-bit is set to 0, then the low-order 8 bits
are transmitted as zero and ignored on receipt. The format of the are transmitted as zero and ignored on receipt. The format of the
last 4 bytes of the LISP header would look like: LISP header would look like:
x x x x 1 x x x x x x x 1 x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|N|L|E|V|I|flags| Nonce/Map-Version | |N|L|E|V|I|flags| Nonce/Map-Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | LSBs | | Instance ID | LSBs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
flags: The flags field is a 3-bit field is reserved for future flag flags: The flags field is a 3-bit field is reserved for future flag
use. It MUST be set to 0 on transmit and MUST be ignored on use. It MUST be set to 0 on transmit and MUST be ignored on
receipt. receipt.
LISP Nonce: The LISP nonce field is a 24-bit value that is randomly LISP Nonce: The LISP nonce field is a 24-bit value that is randomly
generated by an ITR when the N-bit is set to 1. The nonce is also generated by an ITR when the N-bit is set to 1. Nonce generation
used when the E-bit is set to request the nonce value to be echoed algorithms are an implementation matter but are required to
by the other side when packets are returned. When the E-bit is generate different nonces when sending to different destinations.
clear but the N-bit is set, a remote ITR is either echoing a However, the same nonce can be used for a period of time to the
previously requested echo-nonce or providing a random nonce. See same destination. The nonce is also used when the E-bit is set to
Section 6.3.1 for more details. request the nonce value to be echoed by the other side when
packets are returned. When the E-bit is clear but the N-bit is
set, a remote ITR is either echoing a previously requested echo-
nonce or providing a random nonce. See Section 6.3.1 for more
details.
LISP Locator Status Bits: The locator status bits field in the LISP LISP Locator Status Bits: The locator status bits field in the LISP
header is set by an ITR to indicate to an ETR the up/down status header is set by an ITR to indicate to an ETR the up/down status
of the Locators in the source site. Each RLOC in a Map-Reply is of the Locators in the source site. Each RLOC in a Map-Reply is
assigned an ordinal value from 0 to n-1 (when there are n RLOCs in assigned an ordinal value from 0 to n-1 (when there are n RLOCs in
a mapping entry). The Locator Status Bits are numbered from 0 to a mapping entry). The Locator Status Bits are numbered from 0 to
n-1 from the least significant bit of field. The field is 32-bits n-1 from the least significant bit of field. The field is 32-bits
when the I-bit is set to 0 and is 8 bits when the I-bit is set to when the I-bit is set to 0 and is 8 bits when the I-bit is set to
1. When a Locator Status Bit is set to 1, the ITR is indicating 1. When a Locator Status Bit is set to 1, the ITR is indicating
to the ETR the RLOC associated with the bit ordinal has up status. to the ETR the RLOC associated with the bit ordinal has up status.
skipping to change at page 22, line 20 skipping to change at page 22, line 26
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 caveat, 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. header will carry the same Time to Live as the old outer header minus
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
Section 9.3 for TTL exception handling for traceroute packets. Section 9.3 for TTL exception handling for traceroute packets.
The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service The ECN field occupies bits 6 and 7 of both the IPv4 Type of Service
field and the IPv6 Traffic Class field [RFC3168]. The ECN field field and the IPv6 Traffic Class field [RFC3168]. The ECN field
requires special treatment in order to avoid discarding indications requires special treatment in order to avoid discarding indications
skipping to change at page 24, line 40 skipping to change at page 24, line 49
Even though this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has advantages over the
stateless IP fragmentation mechanism, by not involving the stateless IP fragmentation mechanism, by not involving the
destination host with reassembly of ITR fragmented packets. destination host with reassembly of ITR fragmented packets.
5.5. Using Virtualization and Segmentation with LISP 5.5. Using Virtualization and Segmentation with LISP
When multiple organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are using private
addresses [RFC1918] as EID-prefixes, their address spaces MUST remain addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
segregated due to possible address duplication. An Instance ID in segregated due to possible address duplication. An Instance ID in
the address encoding can aid in making the entire AFI based address the address encoding can aid in making the entire AFI based address
unique. See IANA Considerations Section 14.1 for details for unique. See IANA Considerations Section 14.2 for details for
possible address encodings. possible address encodings.
An Instance ID can be carried in a LISP encapsulated packet. An ITR An Instance ID can be carried in a LISP encapsulated packet. An ITR
that prepends a LISP header, will copy a 24-bit value, used by the that prepends a LISP header, will copy a 24-bit value, used by the
LISP router to uniquely identify the address space. The value is LISP router to uniquely identify the address space. The value is
copied to the Instance ID field of the LISP header and the I-bit is copied to the Instance ID field of the LISP header and the I-bit is
set to 1. set to 1.
When an ETR decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID from the LISP
header is used as a table identifier to locate the forwarding table header is used as a table identifier to locate the forwarding table
skipping to change at page 29, line 10 skipping to change at page 29, line 10
| Mapping Protocol Data | | Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Type: 1 (Map-Request) Type: 1 (Map-Request)
A: This is an authoritative bit, which is set to 0 for UDP-based Map- A: This is an authoritative bit, which is set to 0 for UDP-based Map-
Requests sent by an ITR. Requests sent by an ITR.
M: When set, it indicates a Map-Reply Record segment is included in M: This is the map-data-present bit, when set, it indicates a Map-
the Map-Request. Reply Record segment is included in the Map-Request.
P: This is the probe-bit which indicates that a Map-Request SHOULD be P: This is the probe-bit which indicates that a Map-Request SHOULD be
treated as a locator reachability probe. The receiver SHOULD treated as a locator reachability probe. The receiver SHOULD
respond with a Map-Reply with the probe-bit set, indicating the respond with a Map-Reply with the probe-bit set, indicating the
Map-Reply is a locator reachability probe reply, with the nonce Map-Reply is a locator reachability probe reply, with the nonce
copied from the Map-Request. See Section 6.3.2 for more details. copied from the Map-Request. See Section 6.3.2 for more details.
S: This is the SMR bit. See Section 6.6.2 for details. S: This is the Solicit-Map-Request (SMR) bit. See Section 6.6.2 for
details.
p: This is the PITR bit. This bit is set to 1 when a PITR sends a p: This is the PITR bit. This bit is set to 1 when a PITR sends a
Map-Request. Map-Request.
s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is s: This is the SMR-invoked bit. This bit is set to 1 when an xTR is
sending a Map-Request in response to a received SMR-based Map- sending a Map-Request in response to a received SMR-based Map-
Request. Request.
Reserved: It MUST be set to 0 on transmit and MUST be ignored on Reserved: It MUST be set to 0 on transmit and MUST be ignored on
receipt. receipt.
IRC: This 5-bit field is the ITR-RLOC Count which encodes the IRC: This 5-bit field is the ITR-RLOC Count which encodes the
additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields additional number of (ITR-RLOC-AFI, ITR-RLOC Address) fields
present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC- present in this message. At least one (ITR-RLOC-AFI, ITR-RLOC-
Address) pair must always be encoded. Multiple ITR-RLOC Address Address) pair must always be encoded. Multiple ITR-RLOC Address
fields are used so a Map-Replier can select which destination fields are used so a Map-Replier can select which destination
address to use for a Map-Reply. The IRC value ranges from 0 to address to use for a Map-Reply. The IRC value ranges from 0 to
31, and for a value of 1, there are 2 ITR-RLOC addresses encoded 31. For a value of 0, there is 1 ITR-RLOC address encoded, and
and so on up to 31 which encodes a total of 32 ITR-RLOC addresses. for a value of 1, there are 2 ITR-RLOC addresses encoded and so on
up to 31 which encodes a total of 32 ITR-RLOC addresses.
Record Count: The number of records in this Map-Request message. A Record Count: The number of records in this Map-Request message. A
record is comprised of the portion of the packet that is labeled record is comprised of the portion of the packet that is labeled
'Rec' above and occurs the number of times equal to Record Count. 'Rec' above and occurs the number of times equal to Record Count.
For this version of the protocol, a receiver MUST accept and For this version of the protocol, a receiver MUST accept and
process Map-Requests that contain one or more records, but a process Map-Requests that contain one or more records, but a
sender MUST only send Map-Requests containing one record. Support sender MUST only send Map-Requests containing one record. Support
for requesting multiple EIDs in a single Map-Request message will for requesting multiple EIDs in a single Map-Request message will
be specified in a future version of the protocol. be specified in a future version of the protocol.
skipping to change at page 31, line 11 skipping to change at page 31, line 15
Mapping Protocol Data: See [CONS] for details. This field is Mapping Protocol Data: See [CONS] for details. This field is
optional and present when the UDP length indicates there is enough optional and present when the UDP length indicates there is enough
space in the packet to include it. 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 destination-EID from the address used for the Map-Request is the destination-EID from the
packet which had a mapping cache lookup failure. For the latter 2 packet which had a mapping cache lookup failure. For the latter two
cases, the destination IP address used for the Map-Request is one of cases, the destination IP address used for the Map-Request is one of
the RLOC addresses from the locator-set of the map cache entry. The the RLOC addresses from the locator-set of the map cache entry. The
source address is either an IPv4 or IPv6 RLOC address depending if source address is either an IPv4 or IPv6 RLOC address depending if
the Map-Request is using an IPv4 versus IPv6 header, respectively. the Map-Request is using an IPv4 versus IPv6 header, respectively.
In all cases, the UDP source port number for the Map-Request message In all cases, the UDP source port number for the Map-Request message
is an ITR/PITR selected 16-bit value and the UDP destination port is an ITR/PITR selected 16-bit value and the UDP destination port
number is set to the well-known destination port number 4342. A number is set to the well-known destination port number 4342. A
successful Map-Reply updates the cached set of RLOCs associated with successful Map-Reply, which is one that has a nonce that matches an
the EID prefix range. outstanding Map-Request nonce, will update the cached set of RLOCs
associated with the EID prefix range.
One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST One or more Map-Request (ITR-RLOC-AFI, ITR-RLOC-Address) fields MUST
be filled in by the ITR. The number of fields (minus 1) encoded MUST be filled in by the ITR. The number of fields (minus 1) encoded MUST
be placed in the IRC field. The ITR MAY include all locally be placed in the IRC field. The ITR MAY include all locally
configured locators in this list or just provide one locator address configured locators in this list or just provide one locator address
from each address family it supports. If the ITR erroneously from each address family it supports. If the ITR erroneously
provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map- provides no ITR-RLOC addresses, the Map-Replier MUST drop the Map-
Request. Request.
Map-Requests can also be LISP encapsulated using UDP destination port Map-Requests can also be LISP encapsulated using UDP destination port
skipping to change at page 40, line 13 skipping to change at page 40, line 13
message. message.
Record Count: The number of records in this Map-Register message. A Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record' record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages.
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. authentication function. See Section 14.4 for codepoint
assignments.
Authentication Data Length: The length in bytes of the Authentication Data Length: The length in bytes of the
Authentication Data field that follows this field. The length of Authentication Data field that follows this field. The length of
the Authentication Data field is dependent on the Message the Authentication Data field is dependent on the Message
Authentication Code (MAC) algorithm used. The length field allows Authentication Code (MAC) algorithm used. The length field allows
a device that doesn't know the MAC algorithm to correctly parse a device that doesn't know the MAC algorithm to correctly parse
the packet. the packet.
Authentication Data: The message digest used from the output of the Authentication Data: The message digest used from the output of the
Message Authentication Code (MAC) algorithm. The entire Map- Message Authentication Code (MAC) algorithm. The entire Map-
Register payload is authenticated with this field preset to 0. Register payload is authenticated with this field preset to 0.
After the MAC is computed, it is placed in this field. After the MAC is computed, it is placed in this field.
Implementations of this specification MUST include support for Implementations of this specification MUST include support for
HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC6234] HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-256-128 [RFC6234]
is recommended. is recommended.
The definition of the rest of the Map-Register can be found in the The definition of the rest of the Map-Register can be found in the
Map-Reply section. Map-Reply section.
6.1.7. Map-Notify Message Format 6.1.7. Map-Notify Message Format
The usage details of the Map-Notify message can be found in The usage details of the Map-Notify message can be found in
specification [LISP-MS]. This section solely defines the message specification [LISP-MS]. This section solely defines the message
format. format.
skipping to change at page 41, line 42 skipping to change at page 41, line 42
Packet field descriptions: Packet field descriptions:
Type: 4 (Map-Notify) Type: 4 (Map-Notify)
The Map-Notify message has the same contents as a Map-Register The Map-Notify message has the same contents as a Map-Register
message. See Map-Register section for field descriptions. message. See Map-Register section for field descriptions.
6.1.8. Encapsulated Control Message Format 6.1.8. Encapsulated Control Message Format
An Encapsulated Control Message is used to encapsulate control An Encapsulated Control Message (ECM) is used to encapsulate control
packets sent between xTRs and the mapping database system described packets sent between xTRs and the mapping database system described
in [LISP-MS]. in [LISP-MS].
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 45, line 11 skipping to change at page 45, line 11
stored in the mapping database system provides reachability stored in the mapping database system provides reachability
information for RLOCs. Note that reachability is not part of the information for RLOCs. Note that reachability is not part of the
mapping system and is determined using one or more of the Routing mapping system and is determined using one or more of the Routing
Locator Reachability Algorithms described in the next section. Locator Reachability Algorithms described in the next section.
6.3. Routing Locator Reachability 6.3. Routing Locator Reachability
Several mechanisms for determining RLOC reachability are currently Several mechanisms for determining RLOC reachability are currently
defined: defined:
1. An ETR may examine the Loc-Status-Bits in the LISP header of an 1. An ETR may examine the Locator Status Bits in the LISP header of
encapsulated data packet received from an ITR. If the ETR is an encapsulated data packet received from an ITR. If the ETR is
also acting as an ITR and has traffic to return to the original also acting as an ITR and has traffic to return to the original
ITR site, it can use this status information to help select an ITR site, it can use this status information to help select an
RLOC. RLOC.
2. An ITR may receive an ICMP Network or ICMP Host Unreachable 2. An ITR may receive an ICMP Network or ICMP Host Unreachable
message for an RLOC it is using. This indicates that the RLOC is message for an RLOC it is using. This indicates that the RLOC is
likely down. likely down. Note, trusting ICMP messages may not be desirable
but neither is ignoring them completely. Implementations are
encouraged to follow current best practices in treating these
conditions.
3. An ITR which participates in the global routing system can 3. An ITR which participates in the global routing system can
determine that an RLOC is down if no BGP RIB route exists that determine that an RLOC is down if no BGP RIB route exists that
matches the RLOC IP address. matches the RLOC IP address.
4. An ITR may receive an ICMP Port Unreachable message from a 4. An ITR may receive an ICMP Port Unreachable message from a
destination host. This occurs if an ITR attempts to use destination host. This occurs if an ITR attempts to use
interworking [INTERWORK] and LISP-encapsulated data is sent to a interworking [INTERWORK] and LISP-encapsulated data is sent to a
non-LISP-capable site. non-LISP-capable site.
skipping to change at page 45, line 41 skipping to change at page 45, line 44
previously sent Map-Request. The RLOC source of the Map-Reply is previously sent Map-Request. The RLOC source of the Map-Reply is
likely up since the ETR was able to send the Map-Reply to the likely up since the ETR was able to send the Map-Reply to the
ITR. ITR.
6. When an ETR receives an encapsulated packet from an ITR, the 6. When an ETR receives an encapsulated packet from an ITR, the
source RLOC from the outer header of the packet is likely up. source RLOC from the outer header of the packet is likely up.
7. An ITR/ETR pair can use the Locator Reachability Algorithms 7. An ITR/ETR pair can use the Locator Reachability Algorithms
described in this section, namely Echo-Noncing or RLOC-Probing. described in this section, namely Echo-Noncing or RLOC-Probing.
When determining Locator up/down reachability by examining the Loc- When determining Locator up/down reachability by examining the
Status-Bits from the LISP encapsulated data packet, an ETR will Locator Status Bits from the LISP encapsulated data packet, an ETR
receive up to date status from an encapsulating ITR about will receive up to date status from an encapsulating ITR about
reachability for all ETRs at the site. CE-based ITRs at the source reachability for all ETRs at the site. CE-based ITRs at the source
site can determine reachability relative to each other using the site site can determine reachability relative to each other using the site
IGP as follows: IGP as follows:
o Under normal circumstances, each ITR will advertise a default o Under normal circumstances, each ITR will advertise a default
route into the site IGP. route into the site IGP.
o If an ITR fails or if the upstream link to its PE fails, its o If an ITR fails or if the upstream link to its PE fails, its
default route will either time-out or be withdrawn. default route will either time-out or be withdrawn.
Each ITR can thus observe the presence or lack of a default route Each ITR can thus observe the presence or lack of a default route
originated by the others to determine the Locator Status Bits it sets originated by the others to determine the Locator Status Bits it sets
for them. for them.
RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The RLOCs listed in a Map-Reply are numbered with ordinals 0 to n-1. The
Loc-Status-Bits in a LISP encapsulated packet are numbered from 0 to Locator Status Bits in a LISP encapsulated packet are numbered from 0
n-1 starting with the least significant bit. For example, if an RLOC to n-1 starting with the least significant bit. For example, if an
listed in the 3rd position of the Map-Reply goes down (ordinal value RLOC listed in the 3rd position of the Map-Reply goes down (ordinal
2), then all ITRs at the site will clear the 3rd least significant value 2), then all ITRs at the site will clear the 3rd least
bit (xxxx x0xx) of the Loc-Status-Bits field for the packets they significant bit (xxxx x0xx) of the Locator Status Bits field for the
encapsulate. packets they encapsulate.
When an ETR decapsulates a packet, it will check for any change in When an ETR decapsulates a packet, it will check for any change in
the Loc-Status-Bits field. When a bit goes from 1 to 0, the ETR will the Locator Status Bits field. When a bit goes from 1 to 0, the ETR
refrain from encapsulating packets to an RLOC that is indicated as if acting also as an ITR, will refrain from encapsulating packets to
down. It will only resume using that RLOC if the corresponding Loc- an RLOC that is indicated as down. It will only resume using that
Status-Bit returns to a value of 1. Loc-Status-Bits are associated RLOC if the corresponding Locator Status Bit returns to a value of 1.
with a locator-set per EID-prefix. Therefore, when a locator becomes Locator Status Bits are associated with a locator-set per EID-prefix.
unreachable, the Loc-Status-Bit that corresponds to that locator's Therefore, when a locator becomes unreachable, the Locator Status Bit
position in the list returned by the last Map-Reply will be set to that corresponds to that locator's position in the list returned by
zero for that particular EID-prefix. the last Map-Reply will be set to zero for that particular EID-
prefix.
When ITRs at the site are not deployed in CE routers, the IGP can When ITRs at the site are not deployed in CE routers, the IGP can
still be used to determine the reachability of Locators provided they still be used to determine the reachability of Locators provided they
are injected into the IGP. This is typically done when a /32 address are injected into the IGP. This is typically done when a /32 address
is configured on a loopback interface. is configured on a loopback interface.
When ITRs receive ICMP Network or Host Unreachable messages as a When ITRs receive ICMP Network or Host Unreachable messages as a
method to determine unreachability, they will refrain from using method to determine unreachability, they will refrain from using
Locators which are described in Locator lists of Map-Replies. Locators which are described in Locator lists of Map-Replies.
However, using this approach is unreliable because many network However, using this approach is unreliable because many network
operators turn off generation of ICMP Unreachable messages. operators turn off generation of ICMP Unreachable messages.
If an ITR does receive an ICMP Network or Host Unreachable message, If an ITR does receive an ICMP Network or Host Unreachable message,
it MAY originate its own ICMP Unreachable message destined for the it MAY originate its own ICMP Unreachable message destined for the
host that originated the data packet the ITR encapsulated. host that originated the data packet the ITR encapsulated.
Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a Also, BGP-enabled ITRs can unilaterally examine the RIB to see if a
locator address from a locator-set in a mapping entry matches a locator address from a locator-set in a mapping entry matches a
prefix. If it does not find one and BGP is running in the Default prefix. If it does not find one and BGP is running in the Default
Free Zone (DFZ), it can decide to not use the locator even though the Free Zone (DFZ), it can decide to not use the locator even though the
Loc-Status-Bits indicate the locator is up. In this case, the path Locator Status Bits indicate the locator is up. In this case, the
from the ITR to the ETR that is assigned the locator is not path from the ITR to the ETR that is assigned the locator is not
available. More details are in [LOC-ID-ARCH]. available. More details are in [LOC-ID-ARCH].
Optionally, an ITR can send a Map-Request to a Locator and if a Map- Optionally, an ITR can send a Map-Request to a Locator and if a Map-
Reply is returned, reachability of the Locator has been determined. Reply is returned, reachability of the Locator has been determined.
Obviously, sending such probes increases the number of control Obviously, sending such probes increases the number of control
messages originated by tunnel routers for active flows, so Locators messages originated by tunnel routers for active flows, so Locators
are assumed to be reachable when they are advertised. are assumed to be reachable when they are advertised.
This assumption does create a dependency: Locator unreachability is This assumption does create a dependency: Locator unreachability is
detected by the receipt of ICMP Host Unreachable messages. When an detected by the receipt of ICMP Host Unreachable messages. When an
skipping to change at page 53, line 32 skipping to change at page 53, line 39
SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate SMR-invoked Map-Request. The Map-Reply messages SHOULD be rate
limited. This is important to avoid Map-Reply implosion. limited. This is important to avoid Map-Reply implosion.
5. The ETRs, at the site with the changed mapping, record the fact 5. The ETRs, at the site with the changed mapping, record the fact
that the site that sent the Map-Request has received the new that the site that sent the Map-Request has received the new
mapping data in the mapping cache entry for the remote site so mapping data in the mapping cache entry for the remote site so
the loc-status-bits are reflective of the new mapping for packets the loc-status-bits are reflective of the new mapping for packets
going to the remote site. The ETR then stops sending SMR going to the remote site. The ETR then stops sending SMR
messages. messages.
Experimentation is in progress to determine the appropriate rate-
limit parameters.
For security reasons an ITR MUST NOT process unsolicited Map-Replies. For security reasons an ITR MUST NOT process unsolicited Map-Replies.
To avoid map-cache entry corruption by a third-party, a sender of an To avoid map-cache entry corruption by a third-party, a sender of an
SMR-based Map-Request MUST be verified. If an ITR receives an SMR- SMR-based Map-Request MUST be verified. If an ITR receives an SMR-
based Map-Request and the source is not in the locator-set for the based Map-Request and the source is not in the locator-set for the
stored map-cache entry, then the responding Map-Request MUST be sent stored map-cache entry, then the responding Map-Request MUST be sent
with an EID destination to the mapping database system. Since the with an EID destination to the mapping database system. Since the
mapping database system is more secure to reach an authoritative ETR, mapping database system is more secure to reach an authoritative ETR,
it will deliver the Map-Request to the authoritative source of the it will deliver the Map-Request to the authoritative source of the
mapping data. mapping data.
skipping to change at page 56, line 5 skipping to change at page 55, line 33
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 bytes to a MAC rewrite string and prepending the string as part of
the outgoing encapsulation procedure. Routers that support GRE 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
Section 12.
8. Deployment Scenarios 8. Deployment Scenarios
This section will explore how and where ITRs and ETRs can be deployed This section will explore how and where ITRs and ETRs can be deployed
and will discuss the pros and cons of each deployment scenario. For and will discuss the pros and cons of each deployment scenario. For
a more detailed deployment recommendation, refer to [LISP-DEPLOY]. a more detailed deployment recommendation, refer to [LISP-DEPLOY].
There are two basic deployment trade-offs to consider: centralized There are two basic deployment trade-offs to consider: centralized
versus distributed caches and flat, recursive, or re-encapsulating versus distributed caches and flat, recursive, or re-encapsulating
tunneling. When deciding on centralized versus distributed caching, tunneling. When deciding on centralized versus distributed caching,
the following issues should be considered: the following issues should be considered:
o Are the tunnel routers spread out so that the caches are spread o Are the tunnel routers spread out so that the caches are spread
across all the memories of each router? across all the memories of each router? A centralized cache is
when an ITR keeps a cache for all the EIDs it is encapsulating to.
The packet takes a direct path to the destination locator. A
distributed cache is when an ITR needs help from other re-
encapsulating routers because it does not store all the cache
entries for the EIDs is it encapsulating to. So the packet takes
a path through re-encapsulating routers that have a different set
of cache entries.
o Should management "touch points" be minimized by choosing few o Should management "touch points" be minimized by choosing few
tunnel routers, just enough for redundancy? tunnel routers, just enough for redundancy?
o In general, using more ITRs doesn't increase management load, o In general, using more ITRs doesn't increase management load,
since caches are built and stored dynamically. On the other hand, since caches are built and stored dynamically. On the other hand,
more ETRs does require more management since EID-prefix-to-RLOC more ETRs does require more management since EID-prefix-to-RLOC
mappings need to be explicitly configured. mappings need to be explicitly configured.
When deciding on flat, recursive, or re-encapsulation tunneling, the When deciding on flat, recursive, or re-encapsulation tunneling, the
skipping to change at page 63, line 30 skipping to change at page 63, line 30
maintaining session continuity. Renumbering is involved. LISP can maintaining session continuity. Renumbering is involved. LISP can
help with the issues surrounding renumbering [RFC4192] [LISA96] by help with the issues surrounding renumbering [RFC4192] [LISA96] by
decoupling the address space used by a site from the address spaces decoupling the address space used by a site from the address spaces
used by its ISPs. [RFC4984] used by its ISPs. [RFC4984]
10.3. Fast Endpoint Mobility 10.3. Fast Endpoint Mobility
Fast endpoint mobility occurs when an endpoint moves relatively Fast endpoint mobility occurs when an endpoint moves relatively
rapidly, changing its IP layer network attachment point. Maintenance rapidly, changing its IP layer network attachment point. Maintenance
of session continuity is a goal. This is where the Mobile IPv4 of session continuity is a goal. This is where the Mobile IPv4
[RFC5944] and Mobile IPv6 [RFC3775] [RFC4866] mechanisms are used, [RFC5944] and Mobile IPv6 [RFC6275] [RFC4866] mechanisms are used,
and primarily where interactions with LISP need to be explored. and primarily where interactions with LISP need to be explored.
The problem is that as an endpoint moves, it may require changes to The problem is that as an endpoint moves, it may require changes to
the mapping between its EID and a set of RLOCs for its new network the mapping between its EID and a set of RLOCs for its new network
location. When this is added to the overhead of mobile IP binding location. When this is added to the overhead of mobile IP binding
updates, some packets might be delayed or dropped. updates, some packets might be delayed or dropped.
In IPv4 mobility, when an endpoint is away from home, packets to it In IPv4 mobility, when an endpoint is away from home, packets to it
are encapsulated and forwarded via a home agent which resides in the are encapsulated and forwarded via a home agent which resides in the
home area the endpoint's address belongs to. The home agent will home area the endpoint's address belongs to. The home agent will
skipping to change at page 68, line 11 skipping to change at page 68, line 11
approach is chosen for LISP-Multicast. Details for LISP-Multicast approach is chosen for LISP-Multicast. Details for LISP-Multicast
and Interworking with non-LISP sites is described in specification and Interworking with non-LISP sites is described in specification
[MLISP]. [MLISP].
12. Security Considerations 12. Security Considerations
It is believed that most of the security mechanisms will be part of It is believed that most of the security mechanisms will be part of
the mapping database service when using control plane procedures for the mapping database service when using control plane procedures for
obtaining EID-to-RLOC mappings. For data plane triggered mappings, obtaining EID-to-RLOC mappings. For data plane triggered mappings,
as described in this specification, protection is provided against as described in this specification, protection is provided against
ETR spoofing by using Return- Routability mechanisms evidenced by the ETR spoofing by using Return-Routability mechanisms evidenced by the
use of a 24-bit Nonce field in the LISP encapsulation header and a use of a 24-bit Nonce field in the LISP encapsulation header and a
64-bit Nonce field in the LISP control message. The nonce, coupled 64-bit Nonce field in the LISP control message.
with the ITR accepting only solicited Map-Replies goes a long way
toward providing decent authentication. The nonce, coupled with the ITR accepting only solicited Map-Replies
provides a basic level of security, in many ways similar to the
security experienced in the current Internet routing system. It is
hard for off-path attackers to launch attacks against these LISP
mechanisms, as they do not have the nonce values. Sending a large
number of packets to accidentally find the right nonce value is
possible, but would already by itself be a denial-of-service attack.
On-path attackers can perform far more serious attacks, but on-path
attackers can launch serious attacks in the current Internet as well,
including eavesdropping, blocking or redirecting traffic.
LISP does not rely on a PKI infrastructure or a more heavy weight LISP does not rely on a PKI infrastructure or a more heavy weight
authentication system. These systems challenge the scalability of authentication system. These systems challenge the scalability of
LISP which was a primary design goal. LISP which was a primary design goal.
DoS attack prevention will depend on implementations rate-limiting DoS attack prevention will depend on implementations rate-limiting
Map-Requests and Map-Replies to the control plane as well as rate- Map-Requests and Map-Replies to the control plane as well as rate-
limiting the number of data-triggered Map-Replies. limiting the number of data-triggered Map-Replies.
An incorrectly implemented or malicious ITR might choose to ignore An incorrectly implemented or malicious ITR might choose to ignore
skipping to change at page 68, line 48 skipping to change at page 69, line 8
EID-prefixes occur across multiple map-cache entries, the integrity EID-prefixes occur across multiple map-cache entries, the integrity
of the set must be wholly maintained. So if a more-specific entry of the set must be wholly maintained. So if a more-specific entry
cannot be added due to reaching the maximum cap, then none of the cannot be added due to reaching the maximum cap, then none of the
less specifics should be stored in the map-cache. less specifics should be stored in the map-cache.
Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings, Given that the ITR/PTR maintains a cache of EID-to-RLOC mappings,
cache sizing and maintenance is an issue to be kept in mind during cache sizing and maintenance is an issue to be kept in mind during
implementation. It is a good idea to have instrumentation in place implementation. It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work will be used to determine which cache management strategies work
best. It should be noted that an undersized cache in an ITR/PTR not best. In general, it is difficult to defend against cache trashing
only causes adverse affect on the site or region they support, but attacks. It should be noted that an undersized cache in an ITR/PTR
may also cause increased Map-Request load on the mapping system. not only causes adverse affect on the site or region they support,
but may also cause increased Map-Request load on the mapping system.
There is a security risk implicit in the fact that ETRs generate the There is a security risk implicit in the fact that ETRs generate the
EID prefix to which they are responding. An ETR can claim a shorter EID prefix to which they are responding. An ETR can claim a shorter
prefix than it is actually responsible for. Various mechanisms to prefix than it is actually responsible for. Various mechanisms to
ameliorate or resolve this issue will be examined in the future, ameliorate or resolve this issue will be examined in the future,
[LISP-SEC]. [LISP-SEC].
Spoofing of inner header addresses of LISP encapsulated packets is Spoofing of inner header addresses of LISP encapsulated packets is
possible like with any tunneling mechanism. ITRs MUST verify the possible like with any tunneling mechanism. ITRs MUST verify the
source address of a packet to be an EID that belongs to the site's source address of a packet to be an EID that belongs to the site's
EID-prefix range prior to encapsulation. An ETR must only EID-prefix range prior to encapsulation. An ETR must only
decapsulate and forward datagrams with an inner header destination decapsulate and forward datagrams with an inner header destination
that matches one of its EID-prefix ranges. If, upon receipt and that matches one of its EID-prefix ranges. If, upon receipt and
decapsulation, the destination EID of a datagram does not match one decapsulation, the destination EID of a datagram does not match one
of the ETR's configured EID-prefixes, the ETR MUST drop the of the ETR's configured EID-prefixes, the ETR MUST drop the datagram.
datragram. If a LISP encapsulated packet arrives at an ETR, it MAY If a LISP encapsulated packet arrives at an ETR, it SHOULD compare
compare the inner header source EID address and the outer header the inner header source EID address and the outer header source RLOC
source RLOC address with the mapping that exists in the mapping address with the mapping that exists in the mapping database. Then
database. Then when spoofing attacks occur, the outer header source when spoofing attacks occur, the outer header source RLOC address can
RLOC address can be used to trace back the attack to the source site, be used to trace back the attack to the source site, using existing
using existing operational tools. operational tools.
This experimental specification does not address automated key This experimental specification does not address automated key
management (AKM). BCP 107 provides guidance in this area. In management (AKM). BCP 107 provides guidance in this area. In
addition, at the time of this writing, substantial work is being addition, at the time of this writing, substantial work is being
undertaken to improve security of the routing system [KARP], [RPKI], undertaken to improve security of the routing system [KARP], [RPKI],
[BGP-SEC], [LISP-SEC], Future work on LISP should address BCP-107 as [BGP-SEC], [LISP-SEC]. Future work on LISP should address BCP-107 as
well as other open security considerations, which may require changes well as other open security considerations, which may require changes
to this specification. to this specification.
13. Network Management Considerations 13. Network Management Considerations
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
skipping to change at page 71, line 17 skipping to change at page 71, line 17
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 two 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 Consensus", "Experimental BCP 26: "Specification Required", "IETF Review", "Experimental
Use", "First Come First Served". Use", "First Come First Served".
14.1. LISP Address Type Codes 14.1. LISP ACT and Flag Fields
Instance ID type codes have a range from 0 to 15, of which 0 and 1 New ACT values (Section 6.1.5) can be allocated through IETF review
have been allocated [LCAF]. New Type Codes MUST be allocated or IESG approval. Four values have already been allocated by this
starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. specification (Section 6.1.5).
Type Codes 11 - 15 are available on a First Come First Served policy.
The following codes have been allocated: In addition, the LISP protocol has a number of flag and reserved
fields, such as the LISP header flags field (Section 5.3). New bits
for flags can be taken into use from these fields through IETF review
or IESG approval, but these need not be managed by IANA.
Type 0: Null Body Type 14.2. LISP Address Type Codes
Type 1: AFI List Type LISP Address [LCAF] type codes have a range from 0 to 255. New type
codes MUST be allocated consecutively starting at 0. Type Codes 0 -
127 are to be assigned by IETF review or IESG approval.
See [LCAF] for details for other possible unapproved address Type Codes 128 - 255 are available on a First Come First Served
encodings. The unapproved LCAF encodings are an area for further policy.
study and experimentation.
14.2. LISP UDP Port Numbers This registry, initially empty, is constructed for future-use
experimental work of LCAF values. See [LCAF] for details for other
possible unapproved address encodings. The unapproved LCAF encodings
are an area for further study and experimentation.
14.3. LISP UDP Port Numbers
The IANA registry has allocated UDP port numbers 4341 and 4342 for The IANA registry has allocated UDP port numbers 4341 and 4342 for
LISP data-plane and control-plane operation, respectively. LISP data-plane and control-plane operation, respectively.
15. References 14.4. LISP Key ID Numbers
15.1. Normative References The following Key ID values are defined by this specification as used
in any packet type that references a Key ID field:
[BGP-SEC] Lepinski, M., "An Overview of BGPSEC", Name Number Defined in
draft-lepinski-bgpsec-overview-00.txt (work in progress), -----------------------------------------------
March 2011. None 0 n/a
HMAC-SHA-1-96 1 [RFC2404]
HMAC-SHA-256-128 2 [RFC6234]
[KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication for 15. Known Open Issues and Areas of Future Work
Routing Protocols (KARP)Design Guidelines",
draft-ietf-karp-design-guide-02.txt (work in progress), As an experimental specification, this work is, by definition,
March 2011. incomplete. Specific areas where additional experience and work are
needed include:
o At present, only [ALT] is defined for implementing a database of
EID-to-RLOC mapping information. Additional research on other
mapping database systems is strongly encouraged.
o Failure and recovery of LISP site partitioning (see Section 6.4),
in the presence of redundant configuration (see Section 8.5) needs
further research and experimentation.
o The characteristics of map-cache management under exceptional
conditions, such as denial-of-service attacks are not fully
understood. Further experience is needed to determine whether
current caching methods are practical or in need of further
development. See Section 12 for additional thoughts and
considerations.
o Preliminary work has been done to ensure that sites employing LISP
can interconnect with the rest of the Internet. This work is
documented in [INTERWORK] but further experimentation and
experience is needed.
o At present, no mechanism for automated key management for message
authentication is defined. Addressing automated key management is
necessary before this specification could be developed into a
standards track RFC. See Section 12 for further details regarding
security considerations.
16. References
16.1. Normative References
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-09.txt (work in progress).
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-12.txt (work in progress).
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980. August 1980.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets", E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996. BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001. RFC 3168, September 2001.
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984,
September 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path [RFC5496] Wijnands, IJ., Boers, A., and E. Rosen, "The Reverse Path
Forwarding (RPF) Vector TLV", RFC 5496, March 2009. Forwarding (RPF) Vector TLV", RFC 5496, March 2009.
[RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised", [RFC5944] Perkins, C., "IP Mobility Support for IPv4, Revised",
RFC 5944, November 2010. RFC 5944, November 2010.
[RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms [RFC6234] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011. (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011.
[RPKI] Lepinski, M., "An Infrastructure to Support Secure [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
Internet Routing", draft-ietf-sidr-arch-13.txt (work in in IPv6", RFC 6275, July 2011.
progress), February 2011.
[UDP-TUNNELS] [UDP-TUNNELS]
Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled
Packets", draft-eubanks-chimento-6man-01.txt (work in Packets", draft-eubanks-chimento-6man-01.txt (work in
progress), October 2010. progress), October 2010.
15.2. Informative References [VERSIONING]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
Versioning", draft-ietf-lisp-map-versioning-05.txt (work
in progress).
16.2. Informative References
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS NUMBERS
http://www.iana.org/assignments/address-family-numbers. http://www.iana.org/assignments/address-family-numbers.
[AFI-REGISTRY] [AFI-REGISTRY]
IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBER registry http://www.iana.org/assignments/ NUMBER registry http://www.iana.org/assignments/
address-family-numbers/ address-family-numbers/
address-family-numbers.xml#address-family-numbers-1. address-family-numbers.xml#address-family-numbers-1.
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [BGP-SEC] Lepinski, M., "An Overview of BGPSEC",
Alternative Topology (LISP-ALT)", draft-lepinski-bgpsec-overview-00.txt (work in progress),
draft-ietf-lisp-alt-07.txt (work in progress). March 2011.
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed
Enhancement to the Internet Architecture", Internet- Enhancement to the Internet Architecture", Internet-
Draft http://www.chiappa.net/~jnc/tech/endpoints.txt. Draft http://www.chiappa.net/~jnc/tech/endpoints.txt.
[CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
Content distribution Overlay Network Service for LISP", Content distribution Overlay Network Service for LISP",
draft-meyer-lisp-cons-04.txt (work in progress). draft-meyer-lisp-cons-04.txt (work in progress).
[EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID [EMACS] Brim, S., Farinacci, D., Meyer, D., and J. Curran, "EID
Mappings Multicast Across Cooperating Systems for LISP", Mappings Multicast Across Cooperating Systems for LISP",
draft-curran-lisp-emacs-00.txt (work in progress). draft-curran-lisp-emacs-00.txt (work in progress).
[INTERWORK] [INTERWORK]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6", "Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-02.txt (work in progress). draft-ietf-lisp-interworking-02.txt (work in progress).
[KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP)Design Guidelines",
draft-ietf-karp-design-guide-06.txt (work in progress),
October 2011.
[LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical [LCAF] Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format", draft-farinacci-lisp-lcaf-05.txt (work in Address Format", draft-farinacci-lisp-lcaf-06.txt (work in
progress). progress).
[LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp, [LISA96] Lear, E., Katinsky, J., Coffin, J., and D. Tharp,
"Renumbering: Threat or Menace?", Usenix . "Renumbering: Threat or Menace?", Usenix .
[LISP-DEPLOY] [LISP-DEPLOY]
Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis, Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis,
"LISP Network Element Deployment Considerations", "LISP Network Element Deployment Considerations",
draft-jakab-lisp-deployment-03.txt (work in progress). draft-ietf-lisp-deployment-02.txt (work in progress).
[LISP-LIG] [LISP-LIG]
Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)", Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
draft-ietf-lisp-lig-02.txt (work in progress). draft-ietf-lisp-lig-06.txt (work in progress).
[LISP-MAIN] [LISP-MAIN]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12.txt (work in progress). draft-farinacci-lisp-12.txt (work in progress).
[LISP-MIB] [LISP-MIB]
Schudel, G., Jain, A., and V. Moreno, "LISP MIB", Schudel, G., Jain, A., and V. Moreno, "LISP MIB",
draft-ietf-lisp-mib-02.txt (work in progress). draft-ietf-lisp-mib-02.txt (work in progress).
[LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP [LISP-MN] Farinacci, D., Fuller, V., Lewis, D., and D. Meyer, "LISP
Mobility Architecture", draft-meyer-lisp-mn-05.txt (work Mobility Architecture", draft-meyer-lisp-mn-06.txt (work
in progress). in progress).
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-09.txt (work in progress).
[LISP-SEC] [LISP-SEC]
Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O. Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O.
Bonaventure, "LISP-Security (LISP-SEC)", Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-00.txt (work in progress). draft-ietf-lisp-sec-00.txt (work in progress).
[LOC-ID-ARCH] [LOC-ID-ARCH]
Meyer, D. and D. Lewis, "Architectural Implications of Meyer, D. and D. Lewis, "Architectural Implications of
Locator/ID Separation", Locator/ID Separation",
draft-meyer-loc-id-implications-01.txt (work in progress). draft-meyer-loc-id-implications-01.txt (work in progress).
[MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, [MLISP] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments", "LISP for Multicast Environments",
draft-ietf-lisp-multicast-06.txt (work in progress). draft-ietf-lisp-multicast-10.txt (work in progress).
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-08.txt (work in progress). draft-lear-lisp-nerd-08.txt (work in progress).
[OPENLISP] [OPENLISP]
Iannone, L. and O. Bonaventure, "OpenLISP Implementation Iannone, L. and O. Bonaventure, "OpenLISP Implementation
Report", draft-iannone-openlisp-implementation-02.txt Report", draft-iannone-openlisp-implementation-01.txt
(work in progress). (work in progress).
[RADIR] Narten, T., "Routing and Addressing Problem Statement", [RADIR] Narten, T., "Routing and Addressing Problem Statement",
draft-narten-radir-problem-statement-05.txt (work in draft-narten-radir-problem-statement-05.txt (work in
progress). progress).
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984,
September 2007.
[RPKI] Lepinski, M., "An Infrastructure to Support Secure
Internet Routing", draft-ietf-sidr-arch-13.txt (work in
progress), February 2011.
[RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
for Routing Protocol Meta-data Dissemination", for Routing Protocol Meta-data Dissemination",
draft-handley-p2ppush-unpublished-2007726.txt (work in draft-handley-p2ppush-unpublished-2007726.txt (work in
progress). progress).
[VERSIONING]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
Versioning", draft-ietf-lisp-map-versioning-01.txt (work
in progress).
Appendix A. Acknowledgments Appendix A. Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues to provide value
to the LISP authors. to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
of location and identity, as well as detailed review of the LISP of location and identity, as well as detailed review of the LISP
architecture and documents, coupled with enthusiasm for making LISP a architecture and documents, coupled with enthusiasm for making LISP a
skipping to change at page 77, line 5 skipping to change at page 78, line 40
Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu,
Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri
Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina
Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White, Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, Chris White,
Clarence Filsfils, and Alia Atlas. Clarence Filsfils, and Alia Atlas.
This work originated in the Routing Research Group (RRG) of the IRTF. This work originated in the Routing Research Group (RRG) of the IRTF.
The individual submission [LISP-MAIN] was converted into this IETF The individual submission [LISP-MAIN] was converted into this IETF
LISP working group draft. LISP working group draft.
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
were being prepared for IESG last call, for his meticulous review and
detail commentary on the 7 working group last call drafts progressing
toward experimental RFCs.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-15.txt B.1. Changes to draft-ietf-lisp-16.txt
o Posted October 2011 after AD review by Jari.
B.2. 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.2. Changes to draft-ietf-lisp-14.txt B.3. 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
maintian 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
string value can be an RLOC for another device in abstract but the string value can be an RLOC for another device in abstract but the
architecture allows it to be an EID of one device and the same architecture allows it to be an EID of one device and the same
value as an RLOC for another device. value as an RLOC for another device.
o In the "Tunnel Encapsulation Details" section, indicate that 4 o In the "Tunnel Encapsulation Details" section, indicate that 4
combinations of encapsulation are supported. combinations of encapsulation are supported.
o Add what ETR should do for a Data-Probe when received for a o Add what ETR should do for a Data-Probe when received for a
skipping to change at page 77, line 45 skipping to change at page 80, line 5
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.3. Changes to draft-ietf-lisp-13.txt B.4. 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 78, line 30 skipping to change at page 80, line 38
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.4. Changes to draft-ietf-lisp-12.txt B.5. 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
resued 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
Mapping Database System. Mapping Database System.
o Tracker item 111. Indicate that if an LSB that is assocaited with o Tracker item 111. Indicate that if an LSB that is associated with
an anycast address, that there is at least one RLOC that is up. an anycast address, that there is at least one RLOC that is up.
o Tracker item 108. Make clear the R-bit does not define RLOC path o Tracker item 108. Make clear the R-bit does not define RLOC path
reachability. reachability.
o Tracker item 107. Indicate that weights are relative to each o Tracker item 107. Indicate that weights are relative to each
other versus requiring an addition of up to 100%. other versus requiring an addition of up to 100%.
o Tracker item 46. Add a sentence how LISP products should be sized o Tracker item 46. Add a sentence how LISP products should be sized
for the appropriate demand so cache thrashing is avoided. for the appropriate demand so cache thrashing is avoided.
skipping to change at page 79, line 35 skipping to change at page 81, line 41
Egressing a LISP Site" to describe the implications when two or Egressing a LISP Site" to describe the implications when two or
more ITRs exist at a site where only one ITR is used for egress more ITRs exist at a site where only one ITR is used for egress
traffic and when there is a shift of traffic to the others, how traffic and when there is a shift of traffic to the others, how
the map-cache will need to be populated in those new egress ITRs. the map-cache will need to be populated in those new egress ITRs.
o Tracker item 33. Make more clear in the Routing Locator Selection o Tracker item 33. Make more clear in the Routing Locator Selection
section what an ITR should do when it sees an R-bit of 0 in a section what an ITR should do when it sees an R-bit of 0 in a
locator-record of a Map-Reply. locator-record of a Map-Reply.
o Tracker item 33. Add paragraph to the EID Reachability section o Tracker item 33. Add paragraph to the EID Reachability section
indicating that site parittioning 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 Secuirty Considerations section. Put this in a subsection of the Security Considerations section.
B.5. Changes to draft-ietf-lisp-11.txt B.6. 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 defintion of Reencapsuatling tunnels. o Generalize text for the definition of Reencapsuatling tunnels.
o Add pargraph suggested by Joel to explain how implementation o Add paragraph suggested by Joel to explain how implementation
experimentation will be used to determine the proper cache experimentation will be used to determine the proper cache
management techniques. management techniques.
o Add Yakov provided text for the definition of "EID-to-RLOC o Add Yakov provided text for the definition of "EID-to-RLOC
"Database". "Database".
o Add reference in Section 8, Deployment Scenarios, to the o Add reference in Section 8, Deployment Scenarios, to the
draft-jakab-lisp-deploy-02.txt draft. draft-jakab-lisp-deploy-02.txt draft.
o Clarify sentence about no hardware changes needed to support LISP o Clarify sentence about no hardware changes needed to support LISP
encapsulation. encapsulation.
o Add paragraph about what is the procedure when a locator is o Add paragraph about what is the procedure when a locator is
inserted in the middle of a locator-set. inserted in the middle of a locator-set.
o Add a definition for Locator-Status-Bits so we can emphasize they o Add a definition for Locator Status Bits so we can emphasize they
are used as a hint for router up/down status and not path are used as a hint for router up/down status and not path
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.6. Changes to draft-ietf-lisp-10.txt B.7. 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 81, line 4 skipping to change at page 83, line 13
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
acknowledgment for the Map-Register can request one. acknowledgment for the Map-Register can request one.
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.7. Changes to draft-ietf-lisp-09.txt B.8. 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.8. Changes to draft-ietf-lisp-08.txt B.9. 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 83, line 17 skipping to change at page 85, line 26
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.9. Changes to draft-ietf-lisp-07.txt B.10. 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 84, line 38 skipping to change at page 87, line 5
o In section 9.2, add text to describe what the signature of o In section 9.2, add text to describe what the signature of
traceroute packets can look like. traceroute packets can look like.
o Removed references to Data Probe for introductory example. Data- o Removed references to Data Probe for introductory example. Data-
probes are still part of the LISP design but not encouraged. probes are still part of the LISP design but not encouraged.
o Added the definition for "LISP site" to the Definition of Terms" o Added the definition for "LISP site" to the Definition of Terms"
section. section.
B.10. Changes to draft-ietf-lisp-06.txt B.11. Changes to draft-ietf-lisp-06.txt
Editorial based changes: Editorial based changes:
o Posted December 2009. o Posted December 2009.
o Fix typo for flags in LISP data header. Changed from "4" to "5". o Fix typo for flags in LISP data header. Changed from "4" to "5".
o Add text to indicate that Map-Register messages must contain a o Add text to indicate that Map-Register messages must contain a
computed UDP checksum. computed UDP checksum.
skipping to change at page 85, line 47 skipping to change at page 88, line 13
These type of Map-Requests are used as RLOC-probes and are sent These type of Map-Requests are used as RLOC-probes and are sent
directly to locator addresses in the underlying network. directly to locator addresses in the underlying network.
o Add text in section 6.1.5 about returning all EID-prefixes in a o Add text in section 6.1.5 about returning all EID-prefixes in a
Map-Reply sent by an ETR when there are overlapping EID-prefixes Map-Reply sent by an ETR when there are overlapping EID-prefixes
configure. configure.
o Add text in a new subsection of section 6.1.5 about dealing with o Add text in a new subsection of section 6.1.5 about dealing with
Map-Replies with coarse EID-prefixes. Map-Replies with coarse EID-prefixes.
B.11. Changes to draft-ietf-lisp-05.txt B.12. 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 86, line 27 skipping to change at page 88, line 41
o The LISP-CONS authors thought that the Type definitions for CONS o The LISP-CONS authors thought that the Type definitions for CONS
should be removed from this specification. should be removed from this specification.
o Removed nonce from Map-Register message, it wasn't used so no need o Removed nonce from Map-Register message, it wasn't used so no need
for it. for it.
o Clarify what to do for unspecified Action bits for negative Map- o Clarify what to do for unspecified Action bits for negative Map-
Replies. Since No Action is a drop, make value 0 Drop. Replies. Since No Action is a drop, make value 0 Drop.
B.12. Changes to draft-ietf-lisp-04.txt B.13. 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 88, line 18 skipping to change at page 90, line 32
o Reference IPsec RFC 4302. Comment from Sam and Brian Weis. o Reference IPsec RFC 4302. Comment from Sam and Brian Weis.
o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo- o Put E-bit in Map-Reply to tell ITRs that the ETR supports echo-
noncing. Comment by Pedro and Dino. noncing. Comment by Pedro and Dino.
o Jesper made a comment to loosen the language about requiring the o Jesper made a comment to loosen the language about requiring the
copy of inner TTL to outer TTL since the text to get mixed-AF copy of inner TTL to outer TTL since the text to get mixed-AF
traceroute to work would violate the "MUST" clause. Changed from traceroute to work would violate the "MUST" clause. Changed from
MUST to SHOULD in section 5.3. MUST to SHOULD in section 5.3.
B.13. Changes to draft-ietf-lisp-03.txt B.14. 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.14. Changes to draft-ietf-lisp-02.txt B.15. 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.15. Changes to draft-ietf-lisp-01.txt B.16. 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.16. Changes to draft-ietf-lisp-00.txt B.17. 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. 107 change blocks. 
218 lines changed or deleted 323 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/