draft-ietf-lisp-12.txt   draft-ietf-lisp-13.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: October 28, 2011 D. Lewis Expires: December 23, 2011 D. Lewis
cisco Systems cisco Systems
April 26, 2011 June 21, 2011
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-12 draft-ietf-lisp-13
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 even to early adopters, when there are relatively few LISP-
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 28, 2011. This Internet-Draft will expire on December 23, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 26 skipping to change at page 3, line 26
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 61 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 61
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 61 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 61
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
12.1. IETF Security Area Statement . . . . . . . . . . . . . . . 69
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 Address Type Codes . . . . . . . . . . . . . . . . . 71
14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
15.1. Normative References . . . . . . . . . . . . . . . . . . . 72 15.1. Normative References . . . . . . . . . . . . . . . . . . . 72
15.2. Informative References . . . . . . . . . . . . . . . . . . 73 15.2. Informative References . . . . . . . . . . . . . . . . . . 73
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 76 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 77
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 77 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 78
B.1. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 77 B.1. Changes to draft-ietf-lisp-13.txt . . . . . . . . . . . . 78
B.2. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 78 B.2. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 78
B.3. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 79 B.3. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 80
B.4. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 79 B.4. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 80
B.5. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 80 B.5. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 81
B.6. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 81 B.6. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 81
B.7. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 83 B.7. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 83
B.8. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 84 B.8. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 85
B.9. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 85 B.9. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 86
B.10. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 86 B.10. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 86
B.11. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 87 B.11. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 88
B.12. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 87 B.12. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 88
B.13. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 87 B.13. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88 B.14. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 90
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 15 skipping to change at page 6, line 15
variety of approaches. One database design that is being developed variety of approaches. One database design that is being developed
and prototyped as part of the LISP working group work is [ALT]. and prototyped as part of the LISP working group work is [ALT].
Others that have been described but not implemented include [CONS], Others that have been described but not implemented include [CONS],
[EMACS], [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 does not address automated key
management which would be required for an Internet standard management. Addressing automated key management is necessary for
equivalent. See Section 12.1 for further security details. Internet standards. See Section 12 for further security details.
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 8, line 12 skipping to change at page 8, line 12
will be called a "LEID". Throughout this document, any references will be called a "LEID". Throughout this document, any references
to "EID" refers to an LEID. to "EID" refers to an LEID.
EID-prefix: An EID-prefix is a power-of-two block of EIDs which are EID-prefix: An EID-prefix is a power-of-two block of EIDs which are
allocated to a site by an address allocation authority. EID- allocated to a site by an address allocation authority. EID-
prefixes are associated with a set of RLOC addresses which make up prefixes are associated with a set of RLOC addresses which make up
a "database mapping". EID-prefix allocations can be broken up a "database mapping". EID-prefix allocations can be broken up
into smaller blocks when an RLOC set is to be associated with the into smaller blocks when an RLOC set is to be associated with the
smaller EID-prefix. A globally routed address block (whether PI smaller EID-prefix. A globally routed address block (whether PI
or PA) is not inherently an EID-prefix. A globally routed address or PA) is not inherently an EID-prefix. A globally routed address
block may be used by its assignee as an EID block. This would block may be used by its assignee as an EID block. The converse
require coordination and cooperation with the entities managing is not supported. That is, a site which receives an explicitly
the mapping infrastructure. Once this has been done, that block allocated EID-prefix may not use that EID-prefix as a globally
could be removed from the globally routed IP system, if other prefix. This would require coordination and cooperation with the
suitable transition and access mechanisms are in place. The entities managing the mapping infrastructure. Once this has been
converse is not supported. That is, a site which receives an done, that block could be removed from the globally routed IP
explicitly allocated EID-prefix may not use that EID-prefix as a system, if other suitable transition and access mechanisms are in
globally prefix. place. Discussion of such transition and access mechanisms can be
found in [INTERWORK] and [LISP-DEPLOY].
End-system: An end-system is an IPv4 or IPv6 device that originates End-system: An end-system is an IPv4 or IPv6 device that originates
packets with a single IPv4 or IPv6 header. The end-system packets with a single IPv4 or IPv6 header. The end-system
supplies an EID value for the destination address field of the IP supplies an EID value for the destination address field of the IP
header when communicating globally (i.e. outside of its routing header when communicating globally (i.e. outside of its routing
domain). An end-system can be a host computer, a switch or router domain). An end-system can be a host computer, a switch or router
device, or any network appliance. device, or any network appliance.
Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP
packet with a single IP header (more precisely, an IP packet that packet with a single IP header (more precisely, an IP packet that
skipping to change at page 10, line 14 skipping to change at page 10, line 20
header. Any references to tunnels in this specification refers to header. Any references to tunnels in this specification refers to
dynamic encapsulating tunnels and never are they statically dynamic encapsulating tunnels and never are they statically
configured. configured.
Reencapsulating Tunnels: Reencapsulating tunneling occurs when an Reencapsulating Tunnels: Reencapsulating tunneling occurs when an
ETR removes a LISP header, then acts as an ITR to prepend another ETR removes a LISP header, then acts as an ITR to prepend another
LISP header. Doing this allows a packet to be re-routed by the LISP header. Doing this allows a packet to be re-routed by the
re-encapsulating router without adding the overhead of additional re-encapsulating router without adding the overhead of additional
tunnel headers. Any references to tunnels in this specification tunnel headers. Any references to tunnels in this specification
refers to dynamic encapsulating tunnels and never are they refers to dynamic encapsulating tunnels and never are they
statically configured. statically configured. When using multiple mapping database
systems, care must be taken to not create reencapsulation loops.
LISP Header: a term used in this document to refer to the outer LISP Header: a term used in this document to refer to the outer
IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte IPv4 or IPv6 header, a UDP header, and a LISP-specific 8-byte
header that follows the UDP header, an ITR prepends or an ETR header that follows the UDP header, an ITR prepends or an ETR
strips. strips.
Address Family Identifier (AFI): a term used to describe an address Address Family Identifier (AFI): a term used to describe an address
encoding in a packet. An address family currently pertains to an encoding in a packet. An address family currently pertains to an
IPv4 or IPv6 address. See [AFI] and [RFC1700] for details. An IPv4 or IPv6 address. See [AFI]/[AFI-REGISTRY] and [RFC1700] for
AFI value of 0 used in this specification indicates an unspecified details. An AFI value of 0 used in this specification indicates
encoded address where the length of the address is 0 bytes an unspecified encoded address where the length of the address is
following the 16-bit AFI value of 0. 0 bytes following the 16-bit AFI value of 0.
Negative Mapping Entry: A negative mapping entry, also known as a Negative Mapping Entry: A negative mapping entry, also known as a
negative cache entry, is an EID-to-RLOC entry where an EID-prefix negative cache entry, is an EID-to-RLOC entry where an EID-prefix
is advertised or stored with no RLOCs. That is, the locator-set is advertised or stored with no RLOCs. That is, the locator-set
for the EID-to-RLOC entry is empty or has an encoded locator count for the EID-to-RLOC entry is empty or has an encoded locator count
of 0. This type of entry could be used to describe a prefix from of 0. This type of entry could be used to describe a prefix from
a non-LISP site, which is explicitly not in the mapping database. a non-LISP site, which is explicitly not in the mapping database.
There are a set of well defined actions that are encoded in a There are a set of well defined actions that are encoded in a
Negative Map-Reply. Negative Map-Reply.
skipping to change at page 11, line 34 skipping to change at page 11, line 39
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 ITRs 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 Algoriths 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
skipping to change at page 13, line 23 skipping to change at page 13, line 23
o EID prefixes are likely to be hierarchically assigned in a manner o EID prefixes are likely to be hierarchically assigned in a manner
which is optimized for administrative convenience and to which is optimized for administrative convenience and to
facilitate scaling of the EID-to-RLOC mapping database. The facilitate scaling of the EID-to-RLOC mapping database. The
hierarchy is based on a address allocation hierarchy which is hierarchy is based on a address allocation hierarchy which is
independent of the network topology. independent of the network topology.
o EIDs may also be structured (subnetted) in a manner suitable for o EIDs may also be structured (subnetted) in a manner suitable for
local routing within an autonomous system. local routing within an autonomous system.
An additional LISP header may be prepended to packets by a TE-ITR An additional LISP header may be prepended to packets by a TE-ITR
when re-routing of the path for a packet is desired. An obvious when re-routing of the path for a packet is desired. A potential
instance of this would be an ISP router that needs to perform traffic use-case for this would be an ISP router that needs to perform
engineering for packets flowing through its network. In such a traffic engineering for packets flowing through its network. In such
situation, termed Recursive Tunneling, an ISP transit acts as an a situation, termed Recursive Tunneling, an ISP transit acts as an
additional ingress tunnel router and the RLOC it uses for the new additional ingress tunnel router and the RLOC it uses for the new
prepended header would be either a TE-ETR within the ISP (along prepended header would be either a TE-ETR within the ISP (along
intra-ISP traffic engineered path) or a TE-ETR within another ISP (an intra-ISP traffic engineered path) or a TE-ETR within another ISP (an
inter-ISP traffic engineered path, where an agreement to build such a inter-ISP traffic engineered path, where an agreement to build such a
path exists). path exists).
In order to avoid excessive packet overhead as well as possible In order to avoid excessive packet overhead as well as possible
encapsulation loops, this document mandates that a maximum of two encapsulation loops, this document mandates that a maximum of two
LISP headers can be prepended to a packet. It is believed two LISP headers can be prepended to a packet. For initial LISP
headers is sufficient, where the first prepended header is used at a deployments, it is assumed two headers is sufficient, where the first
site for Location/Identity separation and second prepended header is prepended header is used at a site for Location/Identity separation
used inside a service provider for Traffic Engineering purposes. and second prepended header is used inside a service provider for
Traffic Engineering purposes.
Tunnel Routers can be placed fairly flexibly in a multi-AS topology. Tunnel Routers can be placed fairly flexibly in a multi-AS topology.
For example, the ITR for a particular end-to-end packet exchange For example, the ITR for a particular end-to-end packet exchange
might be the first-hop or default router within a site for the source might be the first-hop or default router within a site for the source
host. Similarly, the egress tunnel router might be the last-hop host. Similarly, the egress tunnel router might be the last-hop
router directly-connected to the destination host. Another example, router directly-connected to the destination host. Another example,
perhaps for a VPN service out-sourced to an ISP by a site, the ITR perhaps for a VPN service out-sourced to an ISP by a site, the ITR
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
skipping to change at page 21, line 13 skipping to change at page 21, line 13
last 4 bytes of the LISP header would look like: last 4 bytes of the 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 is set to 0 on transmit and ignored on receipt. use. It MUST be set to 0 on transmit and MUST be ignored on
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. The nonce is also
used when the E-bit is set to request the nonce value to be echoed used when the E-bit is set to request the nonce value to be echoed
by the other side when packets are returned. When the E-bit is 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 clear but the N-bit is set, a remote ITR is either echoing a
previously requested echo-nonce or providing a random nonce. See previously requested echo-nonce or providing a random nonce. See
Section 6.3.1 for more details. 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.
See Section 6.3 for details on how an ITR can determine the status See Section 6.3 for details on how an ITR can determine the status
of other ITRs at the same site. When a site has multiple EID- of the ETRs at the same site. When a site has multiple EID-
prefixes which result in multiple mappings (where each could have prefixes which result in multiple mappings (where each could have
a different locator-set), the Locator Status Bits setting in an a different locator-set), the Locator Status Bits setting in an
encapsulated packet MUST reflect the mapping for the EID-prefix encapsulated packet MUST reflect the mapping for the EID-prefix
that the inner-header source EID address matches. If the LSB for that the inner-header source EID address matches. If the LSB for
an anycast locator is set to 1, then there is at least one RLOC an anycast locator is set to 1, then there is at least one RLOC
with that address that the ETR is considered 'up'. with that address the ETR is considered 'up'.
When doing ITR/PITR encapsulation: When doing ITR/PITR encapsulation:
o The outer header Time to Live field (or Hop Limit field, in case o The outer header Time to Live field (or Hop Limit field, in case
of IPv6) SHOULD be copied from the inner header Time to Live of IPv6) SHOULD be copied from the inner header Time to Live
field. field.
o The outer header Type of Service field (or the Traffic Class o The outer header Type of Service field (or the Traffic Class
field, in the case of IPv6) SHOULD be copied from the inner header field, in the case of IPv6) SHOULD be copied from the inner header
Type of Service field (with one caveat, see below). Type of Service field (with one caveat, see below).
skipping to change at page 26, line 9 skipping to change at page 26, line 9
header is used as a table identifier to locate the forwarding table header is used as a table identifier to locate the forwarding table
to use for the inner destination EID lookup. to use for the inner destination EID lookup.
For example, a 802.1Q VLAN tag or VPN identifier could be used as a For example, a 802.1Q VLAN tag or VPN identifier could be used as a
24-bit Instance ID. 24-bit Instance ID.
6. EID-to-RLOC Mapping 6. EID-to-RLOC Mapping
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats
The following new UDP packet types are used to retrieve EID-to-RLOC The following UDP packet formats are used by the LISP control-plane.
mappings:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol = 17 | Header Checksum | | Time to Live | Protocol = 17 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 29, line 28 skipping to change at page 29, line 28
S: This is the SMR bit. See Section 6.6.2 for details. S: This is the 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: Set to 0 on transmission and ignored on receipt. Reserved: It MUST be set to 0 on transmit and MUST be ignored on
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, and 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. and so on up to 31 which encodes a total of 32 ITR-RLOC addresses.
skipping to change at page 33, line 7 skipping to change at page 33, line 7
response to a locator reachability probe Map-Request. The nonce response to a locator reachability probe Map-Request. The nonce
field MUST contain a copy of the nonce value from the original field MUST contain a copy of the nonce value from the original
Map-Request. See Section 6.3.2 for more details. Map-Request. See Section 6.3.2 for more details.
E: Indicates that the ETR which sends this Map-Reply message is E: Indicates that the ETR which sends this Map-Reply message is
advertising that the site is enabled for the Echo-Nonce locator advertising that the site is enabled for the Echo-Nonce locator
reachability algorithm. See Section 6.3.1 for more details. reachability algorithm. See Section 6.3.1 for more details.
S: This is the Security bit. When set to 1 the field following the S: This is the Security bit. When set to 1 the field following the
Mapping Protocol Data field will have the following format. The Mapping Protocol Data field will have the following format. The
detailed format of the Authentication Data Content field can be detailed format of the Authentication Data Content is for further
found in [LISP-SEC] when AD Type is equal to 1. study.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . | | AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: It MUST be set to 0 on transmit and MUST be ignored on
receipt.
Record Count: The number of records in this reply message. A record Record Count: The number of records in this reply message. A record
is comprised of that portion of the packet labeled 'Record' above is comprised of that portion of the packet labeled 'Record' above
and occurs the number of times equal to Record count. and occurs the number of times equal to Record count.
Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value Nonce: A 24-bit value set in a Data-Probe packet or a 64-bit value
from the Map-Request is echoed in this Nonce field of the Map- from the Map-Request is echoed in this Nonce field of the Map-
Reply. Reply.
Record TTL: The time in minutes the recipient of the Map-Reply will Record TTL: The time in minutes the recipient of the Map-Reply will
skipping to change at page 33, line 46 skipping to change at page 34, line 5
ACT: This 3-bit field describes negative Map-Reply actions. These ACT: This 3-bit field describes negative Map-Reply actions. These
bits are used only when the 'Locator Count' field is set to 0. bits are used only when the 'Locator Count' field is set to 0.
The action bits are encoded only in Map-Reply messages. The The action bits are encoded only in Map-Reply messages. The
actions defined are used by an ITR or PTR when a destination EID actions defined are used by an ITR or PTR when a destination EID
matches a negative mapping cache entry. Unassigned values should matches a negative mapping cache entry. Unassigned values should
cause a map-cache entry to be created and, when packets match this cause a map-cache entry to be created and, when packets match this
negative cache entry, they will be dropped. The current assigned negative cache entry, they will be dropped. The current assigned
values are: values are:
(0) No-Action: The map-cache is kept alive and packet (0) No-Action: The map-cache is kept alive and no packet
encapsulation occurs. encapsulation occurs.
(1) Natively-Forward: The packet is not encapsulated or dropped (1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded. but natively forwarded.
(2) Send-Map-Request: The packet invokes sending a Map-Request. (2) Send-Map-Request: The packet invokes sending a Map-Request.
(3) Drop: A packet that matches this map-cache entry is dropped. (3) Drop: A packet that matches this map-cache entry is dropped.
A: The Authoritative bit, when sent by a UDP-based message is always A: The Authoritative bit, when sent by a UDP-based message is always
skipping to change at page 36, line 5 skipping to change at page 36, line 5
Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field) Locator: an IPv4 or IPv6 address (as encoded by the 'Loc-AFI' field)
assigned to an ETR. Note that the destination RLOC address MAY be assigned to an ETR. Note that the destination RLOC address MAY be
an anycast address. A source RLOC can be an anycast address as an anycast address. A source RLOC can be an anycast address as
well. The source or destination RLOC MUST NOT be the broadcast well. The source or destination RLOC MUST NOT be the broadcast
address (255.255.255.255 or any subnet broadcast address known to address (255.255.255.255 or any subnet broadcast address known to
the router), and MUST NOT be a link-local multicast address. The the router), and MUST NOT be a link-local multicast address. The
source RLOC MUST NOT be a multicast address. The destination RLOC source RLOC MUST NOT be a multicast address. The destination RLOC
SHOULD be a multicast address if it is being mapped from a SHOULD be a multicast address if it is being mapped from a
multicast destination EID. multicast destination EID.
Mapping Protocol Data: See [CONS] or [ALT] for details. This field Mapping Protocol Data: See [CONS] for details. This field is
is optional and present when the UDP length indicates there is optional and present when the UDP length indicates there is enough
enough space in the packet to include it. The Mapping Protocol space in the packet to include it. The Mapping Protocol Data is
Data is used when needed by the particular mapping system. used when needed by the particular mapping system.
6.1.5. EID-to-RLOC UDP Map-Reply Message 6.1.5. EID-to-RLOC UDP Map-Reply Message
A Map-Reply returns an EID-prefix with a prefix length that is less A Map-Reply returns an EID-prefix with a prefix length that is less
than or equal to the EID being requested. The EID being requested is than or equal to the EID being requested. The EID being requested is
either from the destination field of an IP header of a Data-Probe or either from the destination field of an IP header of a Data-Probe or
the EID record of a Map-Request. The RLOCs in the Map-Reply are the EID record of a Map-Request. The RLOCs in the Map-Reply are
globally-routable IP addresses of all ETRs for the LISP site. Each globally-routable IP addresses of all ETRs for the LISP site. Each
RLOC conveys status reachability but does not convey path RLOC conveys status reachability but does not convey path
reachability from a requesters perspective. Separate testing of path reachability from a requesters perspective. Separate testing of path
skipping to change at page 39, line 43 skipping to change at page 39, line 43
Packet field descriptions: Packet field descriptions:
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map- P: This is the proxy-map-reply bit, when set to 1 an ETR sends a Map-
Register message requesting for the Map-Server to proxy Map-Reply. Register message requesting for the Map-Server to proxy Map-Reply.
The Map-Server will send non-authoritative Map-Replies on behalf The Map-Server will send non-authoritative Map-Replies on behalf
of the ETR. Details on this usage will be provided in a future of the ETR. Details on this usage will be provided in a future
version of this draft. version of this draft.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: It MUST be set to 0 on transmit and MUST be ignored on
receipt.
M: This is the want-map-notify bit, when set to 1 an ETR is M: This is the want-map-notify bit, when set to 1 an ETR is
requesting for a Map-Notify message to be returned in response to requesting for a Map-Notify message to be returned in response to
sending a Map-Register message. The Map-Notify message sent by a sending a Map-Register message. The Map-Notify message sent by a
Map-Server is used to an acknowledge receipt of a Map-Register Map-Server is used to an acknowledge receipt of a Map-Register
message. message.
Record Count: The number of records in this Map-Register message. A Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record' record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
skipping to change at page 42, line 43 skipping to change at page 42, line 43
UDP: The outer UDP header with destination port 4342. The source UDP: The outer UDP header with destination port 4342. The source
port is randomly allocated. The checksum field MUST be non-zero. port is randomly allocated. The checksum field MUST be non-zero.
LH: Type 8 is defined to be a "LISP Encapsulated Control Message" LH: Type 8 is defined to be a "LISP Encapsulated Control Message"
and what follows is either an IPv4 or IPv6 header as encoded by and what follows is either an IPv4 or IPv6 header as encoded by
the first 4 bits after the reserved field. the first 4 bits after the reserved field.
S: This is the Security bit. When set to 1 the field following the S: This is the Security bit. When set to 1 the field following the
Reserved field will have the following format. The detailed Reserved field will have the following format. The detailed
format of the Authentication Data Content field can be found in format of the Authentication Data Content is for further study.
[LISP-SEC] when AD Type is equal to 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . | | AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IH: The inner IPv4 or IPv6 header which can use either RLOC or EID IH: The inner IPv4 or IPv6 header which can use either RLOC or EID
addresses in the header address fields. When a Map-Request is addresses in the header address fields. When a Map-Request is
encapsulated in this packet format the destination address in this encapsulated in this packet format the destination address in this
skipping to change at page 51, line 11 skipping to change at page 51, line 11
Since the LISP architecture uses a caching scheme to retrieve and Since the LISP architecture uses a caching scheme to retrieve and
store EID-to-RLOC mappings, the only way an ITR can get a more up-to- store EID-to-RLOC mappings, the only way an ITR can get a more up-to-
date mapping is to re-request the mapping. However, the ITRs do not date mapping is to re-request the mapping. However, the ITRs do not
know when the mappings change and the ETRs do not keep track of which know when the mappings change and the ETRs do not keep track of which
ITRs requested its mappings. For scalability reasons, we want to ITRs requested its mappings. For scalability reasons, we want to
maintain this approach but need to provide a way for ETRs change maintain this approach but need to provide a way for ETRs change
their mappings and inform the sites that are currently communicating their mappings and inform the sites that are currently communicating
with the ETR site using such mappings. with the ETR site using such mappings.
When adding a new locator record in lexiographic order to the end of When adding a new locator record in lexicographic order to the end of
a locator-set, it is easy to update mappings. We assume new mappings a locator-set, it is easy to update mappings. We assume new mappings
will maintain the same locator ordering as the old mapping but just will maintain the same locator ordering as the old mapping but just
have new locators appended to the end of the list. So some ITRs can have new locators appended to the end of the list. So some ITRs can
have a new mapping while other ITRs have only an old mapping that is have a new mapping while other ITRs have only an old mapping that is
used until they time out. When an ITR has only an old mapping but used until they time out. When an ITR has only an old mapping but
detects bits set in the loc-status-bits that correspond to locators detects bits set in the loc-status-bits that correspond to locators
beyond the list it has cached, it simply ignores them. However, this beyond the list it has cached, it simply ignores them. However, this
can only happen for locator addresses that are lexicographically can only happen for locator addresses that are lexicographically
greater than the locator addresses in the existing locator-set. greater than the locator addresses in the existing locator-set.
When a locator record is inserted in the middle of a locator-set, to When a locator record is inserted in the middle of a locator-set, to
maintain lexiographic order, the SMR procedure in Section 6.6.2 is maintain lexicographic order, the SMR procedure in Section 6.6.2 is
used to inform ITRs and PTRs of the new locator-status-bit mappings. used to inform ITRs and PTRs of the new locator-status-bit mappings.
When a locator record is removed from a locator-set, ITRs that have When a locator record is removed from a locator-set, ITRs that have
the mapping cached will not use the removed locator because the xTRs the mapping cached will not use the removed locator because the xTRs
will set the loc-status-bit to 0. So even if the locator is in the will set the loc-status-bit to 0. So even if the locator is in the
list, it will not be used. For new mapping requests, the xTRs can list, it will not be used. For new mapping requests, the xTRs can
set the locator AFI to 0 (indicating an unspecified address), as well set the locator AFI to 0 (indicating an unspecified address), as well
as setting the corresponding loc-status-bit to 0. This forces ITRs as setting the corresponding loc-status-bit to 0. This forces ITRs
with old or new mappings to avoid using the removed locator. with old or new mappings to avoid using the removed locator.
skipping to change at page 59, line 14 skipping to change at page 59, line 14
8.5. Packets Egressing a LISP Site 8.5. Packets Egressing a LISP Site
When a LISP site is using two ITRs for redundancy, the failure of one When a LISP site is using two ITRs for redundancy, the failure of one
ITR will likely shift outbound traffic to the second. This second ITR will likely shift outbound traffic to the second. This second
ITR's cache may not not be populated with the same EID-to-RLOC ITR's cache may not not be populated with the same EID-to-RLOC
mapping entries as the first. If this second ITR does not have these mapping entries as the first. If this second ITR does not have these
mappings, traffic will be dropped while the mappings are retrieved mappings, traffic will be dropped while the mappings are retrieved
from the mapping system. The retrieval of these messages may from the mapping system. The retrieval of these messages may
increase the load of requests being sent into the mapping system. increase the load of requests being sent into the mapping system.
While this is not anticipated this will be a problem, the deployment Deployment and experimentation will determine whether this issue
and experimentation will determine if there is an issue requiring requires more attention.
more attention.
9. Traceroute Considerations 9. Traceroute Considerations
When a source host in a LISP site initiates a traceroute to a When a source host in a LISP site initiates a traceroute to a
destination host in another LISP site, it is highly desirable for it destination host in another LISP site, it is highly desirable for it
to see the entire path. Since packets are encapsulated from ITR to to see the entire path. Since packets are encapsulated from ITR to
ETR, the hop across the tunnel could be viewed as a single hop. ETR, the hop across the tunnel could be viewed as a single hop.
However, LISP traceroute will provide the entire path so the user can However, LISP traceroute will provide the entire path so the user can
see 3 distinct segments of the path from a source LISP host to a see 3 distinct segments of the path from a source LISP host to a
destination LISP host: destination LISP host:
skipping to change at page 68, line 48 skipping to change at page 68, line 48
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. It should be noted that an undersized cache in an ITR/PTR not
only causes adverse affect on the site or region they support, but only causes adverse affect on the site or region they support, but
may also cause increased Map-Request load on the mapping system. may also cause increased Map-Request load on the mapping system.
There is a potential security risk implicit in the fact that ETRs There is a security risk implicit in the fact that ETRs generate the
generate the EID prefix to which they are responding. In theory, an EID prefix to which they are responding. An ETR can claim a shorter
ETR can claim a shorter prefix than it is actually responsible for. prefix than it is actually responsible for. Various mechanisms to
Various mechanisms to ameliorate or resolve this issue will be ameliorate or resolve this issue will be examined in the future,
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. ETRs MUST NOT decapsulate EID-prefix range prior to encapsulation. ETRs MUST NOT decapsulate
and forward packets into their site where the inner header and forward packets into their site where the inner header
destination EID does not belong to the ETR's EID-prefix range for the destination EID does not belong to the ETR's EID-prefix range for the
site. If a LISP encapsulated packet arrives at an ETR, it MAY site. If a LISP encapsulated packet arrives at an ETR, it MAY
compare the inner header source EID address and the outer header compare the inner header source EID address and the outer header
source RLOC address with the mapping that exists in the mapping source RLOC address with the mapping that exists in the mapping
database. Then when spoofing attacks occur, the outer header source database. Then when spoofing attacks occur, the outer header source
RLOC address can be used to trace back the attack to the source site, RLOC address can be used to trace back the attack to the source site,
using existing operational tools. using existing operational tools.
12.1. IETF Security Area Statement This experimental specification does not address automated key
management (AKM). BCP 107 provides guidance in this area. In
This document represents the thinking of the LISP working group. The addition, at the time of this writing, substantial work is being
Security Area of the IETF believes there is an open security issue undertaken to improve security of the routing system [KARP], [RPKI],
how LISP interacts with BCP 107's guidance on automated key [BGP-SEC], [LISP-SEC], Future work on LISP should address BCP-107 as
management. This and other issues would need to be resolved before well as other open security considerations, which may require changes
standardization of LISP. Accounting for these concerns may change to this specification.
the underlying design of LISP. It is important that deferring these
discussions in order to publish an experimental protocol sooner not
restrict a standardized solution that balances concerns of all areas
of the IETF.
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
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
skipping to change at page 72, line 9 skipping to change at page 72, line 9
14.2. LISP UDP Port Numbers 14.2. 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 15. References
15.1. Normative References 15.1. Normative References
[BGP-SEC] Lepinski, M., "An Overview of BGPSEC",
draft-lepinski-bgpsec-overview-00.txt (work in progress),
March 2011.
[KARP] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP)Design Guidelines",
draft-ietf-karp-design-guide-02.txt (work in progress),
March 2011.
[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", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987. STD 13, RFC 1034, November 1987.
[RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700, [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
October 1994. October 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
skipping to change at page 73, line 22 skipping to change at page 73, line 32
Workshop on Routing and Addressing", RFC 4984, Workshop on Routing and Addressing", RFC 4984,
September 2007. 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.
[RPKI] Lepinski, M., "An Infrastructure to Support Secure
Internet Routing", draft-ietf-sidr-arch-12.txt (work in
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 15.2. Informative References
[AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBERS http://www.iana.org/.../address-family-numbers, NUMBERS
Febuary 2007. http://www.iana.org/assignments/address-family-numbers,
January 2011.
[AFI-REGISTRY]
IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY
NUMBER registry http://www.iana.org/assignments/
address-family-numbers/
address-family-numbers.xml#address-family-numbers-1,
January 2011.
[ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP [ALT] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP-ALT)", Alternative Topology (LISP-ALT)",
draft-ietf-lisp-alt-06.txt (work in progress), March 2011. draft-ietf-lisp-alt-07.txt (work in progress), June 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,
1999. 1999.
[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-03.txt (work in progress), draft-meyer-lisp-cons-03.txt (work in progress),
November 2007. November 2007.
[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),
November 2007. November 2007.
[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),
March 2011. June 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-04.txt (work in Address Format", draft-farinacci-lisp-lcaf-04.txt (work in
progress), October 2010. progress), October 2010.
[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 , September 1996. "Renumbering: Threat or Menace?", Usenix , September 1996.
[LISP-DEPLOY] [LISP-DEPLOY]
Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis, Jakab, L., Coras, F., Domingo-Pascual, J., and D. Lewis,
skipping to change at page 74, line 42 skipping to change at page 75, line 16
[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-01.txt (work in progress), March 2011. draft-ietf-lisp-mib-01.txt (work in progress), March 2011.
[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-04.txt (work Mobility Architecture", draft-meyer-lisp-mn-04.txt (work
in progress), October 2010. in progress), October 2010.
[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-ietf-lisp-ms-07.txt (work in progress), March 2011. draft-ietf-lisp-ms-09.txt (work in progress), June 2011.
[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-maino-lisp-sec-00.txt (work in progress), draft-ietf-lisp-sec-00.txt (work in progress), June 2011.
February 2011.
[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),
Januaryr 2009. Januaryr 2009.
[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-05.txt (work in progress), draft-ietf-lisp-multicast-06.txt (work in progress),
April 2011. June 2011.
[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),
March 2010. March 2010.
[OPENLISP] [OPENLISP]
Iannone, L. and O. Bonaventure, "OpenLISP Implementation Iannone, L. and O. Bonaventure, "OpenLISP Implementation
Report", draft-iannone-openlisp-implementation-01.txt Report", draft-iannone-openlisp-implementation-01.txt
(work in progress), July 2008. (work in progress), July 2008.
skipping to change at page 77, line 7 skipping to change at page 78, line 7
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.
Appendix B. Document Change Log Appendix B. Document Change Log
B.1. Changes to draft-ietf-lisp-12.txt B.1. Changes to draft-ietf-lisp-13.txt
o Posted June 2011 to complete working group last call.
o Tracker item 87. Put Yakov suggested wording in the EID-prefix
definition section to reference [INTERWORK] and [LISP-DEPLOY]
about discussion on transition and access mechanisms.
o Change "ITRs" to "ETRs" in the Locator Status Bit definition
section and data packet description section per Damien's comment.
o Remove the normative reference to [LISP-SEC] when describing the
S-bit in the ECM and Map-Reply headers.
o Tracker item 54. Added text from John Scudder in the "Packets
Egressing a LISP Site" section.
o Add sentence to the "Reencapsulating Tunnel" definition about how
reencapsulation loops can occur when not coordinating among
multiple mapping database systems.
o Remove "In theory" from a sentence in the Security Considerations
section.
o Remove Security Area Statement title and reword section with
Eliot's provided text. The text was agreed upon by LISP-WG chairs
and Security ADs.
o Remove word "potential" from the over-claiming paragraph of the
Security Considerations section per Stephen's request.
o Wordsmithing and other editorial comments from Alia.
B.2. 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". resued in the definition section of "EID-prefix".
o Tracker item 95. Change "eliminate" to "defer" in section 4.1. o Tracker item 95. Change "eliminate" to "defer" in section 4.1.
o Tracker item 110. Added that the Mapping Protocol Data field in o Tracker item 110. Added that the Mapping Protocol Data field in
the Map-Reply message is only used when needed by the particular the Map-Reply message is only used when needed by the particular
skipping to change at page 77, line 38 skipping to change at page 79, line 23
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.
o Change some references of RFC 5226 to [AFI] per Luigi. o Change some references of RFC 5226 to [AFI] per Luigi.
o Per Luigi, make reference to "EID-AFI" consistent to "EID-prefix- o Per Luigi, make reference to "EID-AFI" consistent to "EID-prefix-
AFI". AFI".
o Tracker item 66. Indicate that appending locators to a locator- o Tracker item 66. Indicate that appending locators to a locator-
set is done when the added locators are lexiographically greater set is done when the added locators are lexicographically greater
than the previous ones in the set. than the previous ones in the set.
o Tracker item 87. Once again reword the definition of the EID- o Tracker item 87. Once again reword the definition of the EID-
prefix to reflect recent comments. prefix to reflect recent comments.
o Tracker item 70. Added text to security section on what the o Tracker item 70. Added text to security section on what the
implications could be if an ITR does not obey priority and weights implications could be if an ITR does not obey priority and weights
from a Map-Reply message. from a Map-Reply message.
o Tracker item 54. Added text to the new section titled "Packets o Tracker item 54. Added text to the new section titled "Packets
skipping to change at page 78, line 20 skipping to change at page 80, line 5
indicating that site parittioning is under investigation. indicating that site parittioning 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 Secuirty Considerations section.
B.2. Changes to draft-ietf-lisp-11.txt B.3. 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 defintion of Reencapsuatling tunnels.
skipping to change at page 79, line 13 skipping to change at page 80, line 45
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.3. Changes to draft-ietf-lisp-10.txt B.4. 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 79, line 35 skipping to change at page 81, line 20
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.4. Changes to draft-ietf-lisp-09.txt B.5. 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.5. Changes to draft-ietf-lisp-08.txt B.6. 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 81, line 42 skipping to change at page 83, 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.6. Changes to draft-ietf-lisp-07.txt B.7. 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 83, line 17 skipping to change at page 85, 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.7. Changes to draft-ietf-lisp-06.txt B.8. 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 84, line 26 skipping to change at page 86, 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.8. Changes to draft-ietf-lisp-05.txt B.9. 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 85, line 5 skipping to change at page 86, 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.9. Changes to draft-ietf-lisp-04.txt B.10. 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 86, line 44 skipping to change at page 88, 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.10. Changes to draft-ietf-lisp-03.txt B.11. 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.11. Changes to draft-ietf-lisp-02.txt B.12. 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.12. Changes to draft-ietf-lisp-01.txt B.13. 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.13. Changes to draft-ietf-lisp-00.txt B.14. 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. 52 change blocks. 
107 lines changed or deleted 160 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/