draft-ietf-lisp-11.txt   draft-ietf-lisp-12.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: September 30, 2011 D. Lewis Expires: October 28, 2011 D. Lewis
cisco Systems cisco Systems
March 29, 2011 April 26, 2011
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-11 draft-ietf-lisp-12
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 September 30, 2011. This Internet-Draft will expire on October 28, 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 2, line 50 skipping to change at page 2, line 50
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 . . . . . . . . . . . . . . . . . 49 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 . . . . . . 50
6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 51 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 51
6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52
6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 53 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
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 59 8.5. Packets Egressing a LISP Site . . . . . . . . . . . . . . 59
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 60 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 60
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 60 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 61
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 60 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 61
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 62 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 61
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 62 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 63
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 62 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 63
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 62 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 63
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 64 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 63
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 64 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 65
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 66 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 65
12. Security Considerations . . . . . . . . . . . . . . . . . . . 67 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 67
13. Network Management Considerations . . . . . . . . . . . . . . 68 12. Security Considerations . . . . . . . . . . . . . . . . . . . 68
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69 12.1. IETF Security Area Statement . . . . . . . . . . . . . . . 69
14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 69 13. Network Management Considerations . . . . . . . . . . . . . . 70
14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 69 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70 14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 71
15.1. Normative References . . . . . . . . . . . . . . . . . . . 70 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 71
15.2. Informative References . . . . . . . . . . . . . . . . . . 71 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 74 15.1. Normative References . . . . . . . . . . . . . . . . . . . 72
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 75 15.2. Informative References . . . . . . . . . . . . . . . . . . 73
B.1. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 75 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 76
B.2. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 75 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 77
B.3. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 76 B.1. Changes to draft-ietf-lisp-12.txt . . . . . . . . . . . . 77
B.4. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 76 B.2. Changes to draft-ietf-lisp-11.txt . . . . . . . . . . . . 78
B.5. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 78 B.3. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 79
B.6. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 80 B.4. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 79
B.7. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 81 B.5. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 80
B.8. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 81 B.6. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 81
B.9. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 83 B.7. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 83
B.10. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 83 B.8. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 84
B.11. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 84 B.9. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 85
B.12. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 84 B.10. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 86
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 B.11. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 87
B.12. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 87
B.13. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 87
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 88
1. Requirements Notation 1. Requirements Notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Introduction 2. Introduction
This document describes the Locator/Identifier Separation Protocol This document describes the Locator/Identifier Separation Protocol
skipping to change at page 7, line 5 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
management which would be required for an Internet standard
equivalent. See Section 12.1 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
block assigned to a site by each service provider to which a site block assigned to a site by each service provider to which a site
skipping to change at page 8, line 11 skipping to change at page 8, line 11
discussions with other Locator/ID separation proposals, a LISP EID discussions with other Locator/ID separation proposals, a LISP EID
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 an EID-prefix. However, a globally routed address or PA) is not inherently an EID-prefix. A globally routed address
block may be removed from global routing and reused as an EID- block may be used by its assignee as an EID block. This would
prefix. A site that receives an explicitly allocated EID-prefix require coordination and cooperation with the entities managing
may not use that EID-prefix as a globally routed prefix assigned the mapping infrastructure. Once this has been done, that block
to RLOCs. could be removed from the globally routed IP system, if other
suitable transition and access mechanisms are in place. The
converse is not supported. That is, a site which receives an
explicitly allocated EID-prefix may not use that EID-prefix as a
globally prefix.
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 15, line 27 skipping to change at page 15, line 27
a LISP header prepended by the ITR using the appropriate RLOC as a LISP header prepended by the ITR using the appropriate RLOC as
the LISP header destination address learned from the ETR. Note the LISP header destination address learned from the ETR. Note
the packet may be sent to a different ETR than the one which the packet may be sent to a different ETR than the one which
returned the Map-Reply due to the source site's hashing policy or returned the Map-Reply due to the source site's hashing policy or
the destination site's locator-set policy. the destination site's 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), strips the LISP
header and forwards the packets to the attached destination host. header and forwards the packets to the attached destination host.
In order to eliminate 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.
5. LISP Encapsulation Details 5. LISP Encapsulation Details
skipping to change at page 21, line 37 skipping to change at page 21, line 37
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 other ITRs 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. 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
with that address that 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 30, line 25 skipping to change at page 30, line 25
ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that ITR-RLOC-AFI: Address family of the "ITR-RLOC Address" field that
follows this field. follows this field.
ITR-RLOC Address: Used to give the ETR the option of selecting the ITR-RLOC Address: Used to give the ETR the option of selecting the
destination address from any address family for the Map-Reply destination address from any address family for the Map-Reply
message. This address MUST be a routable RLOC address of the message. This address MUST be a routable RLOC address of the
sender of the Map-Request message. sender of the Map-Request message.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
EID-prefix-AFI: Address family of EID-prefix according to [RFC5226] EID-prefix-AFI: Address family of EID-prefix according to [AFI]
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family. When a Map-Request is sent by an ITR because a address-family. When a Map-Request is sent by an ITR because a
data packet is received for a destination where there is no data packet is received for a destination where there is no
mapping entry, the EID-prefix is set to the destination IP address mapping entry, the EID-prefix is set to the destination IP address
of the data packet. And the 'EID mask-len' is set to 32 or 128 of the data packet. And the 'EID mask-len' is set to 32 or 128
for IPv4 or IPv6, respectively. When an xTR wants to query a site for IPv4 or IPv6, respectively. When an xTR wants to query a site
about the status of a mapping it already has cached, the EID- about the status of a mapping it already has cached, the EID-
prefix used in the Map-Request has the same mask-length as the prefix used in the Map-Request has the same mask-length as the
EID-prefix returned from the site when it sent a Map-Reply EID-prefix returned from the site when it sent a Map-Reply
skipping to change at page 32, line 21 skipping to change at page 32, line 21
|Type=2 |P|E|S| Reserved | Record Count | |Type=2 |P|E|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-AFI | c | Rsvd | Map-Version Number | EID-prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix | r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data | | Mapping Protocol Data |
skipping to change at page 34, line 28 skipping to change at page 34, line 28
Map-Version Number: When this 12-bit value is non-zero the Map-Reply Map-Version Number: When this 12-bit value is non-zero the Map-Reply
sender is informing the ITR what the version number is for the sender is informing the ITR what the version number is for the
EID-record contained in the Map-Reply. The ETR can allocate this EID-record contained in the Map-Reply. The ETR can allocate this
number internally but MUST coordinate this value with other ETRs number internally but MUST coordinate this value with other ETRs
for the site. When this value is 0, there is no versioning for the site. When this value is 0, there is no versioning
information conveyed. The Map-Version Number can be included in information conveyed. The Map-Version Number can be included in
Map-Request and Map-Register messages. See Section 6.6.3 for more Map-Request and Map-Register messages. See Section 6.6.3 for more
details. details.
EID-AFI: Address family of EID-prefix according to [RFC5226]. EID-prefix-AFI: Address family of EID-prefix according to [AFI].
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family. address-family.
Priority: each RLOC is assigned a unicast priority. Lower values Priority: each RLOC is assigned a unicast priority. Lower values
are more preferable. When multiple RLOCs have the same priority, are more preferable. When multiple RLOCs have the same priority,
they may be used in a load-split fashion. A value of 255 means they may be used in a load-split fashion. A value of 255 means
the RLOC MUST NOT be used for unicast forwarding. the RLOC MUST NOT be used for unicast forwarding.
Weight: when priorities are the same for multiple RLOCs, the weight Weight: when priorities are the same for multiple RLOCs, the weight
indicates how to balance unicast traffic between them. Weight is indicates how to balance unicast traffic between them. Weight is
encoded as a relative weight of total unicast packets that match encoded as a relative weight of total unicast packets that match
the mapping entry. If a non-zero weight value is used for any the mapping entry. For example if there are 4 locators in a
RLOC, then all RLOCs MUST use a non-zero weight value and then the locator set, where the weights assigned are 30, 20, 20, and 10,
sum of all weight values MUST equal 100. If a zero value is used the first locator will get 37.5% of the traffic, the 2nd and 3rd
for any RLOC weight, then all weights MUST be zero and the locators will get 25% of traffic and the 4th locator will get
12.5% of the traffic. If all weights for a locator-set are equal,
receiver of the Map-Reply will decide how to load-split traffic. receiver of the Map-Reply will decide how to load-split traffic.
See Section 6.5 for a suggested hash algorithm to distribute load See Section 6.5 for a suggested hash algorithm to distribute load
across locators with same priority and equal weight values. across locators with same priority and equal weight values.
M Priority: each RLOC is assigned a multicast priority used by an M Priority: each RLOC is assigned a multicast priority used by an
ETR in a receiver multicast site to select an ITR in a source ETR in a receiver multicast site to select an ITR in a source
multicast site for building multicast distribution trees. A value multicast site for building multicast distribution trees. A value
of 255 means the RLOC MUST NOT be used for joining a multicast of 255 means the RLOC MUST NOT be used for joining a multicast
distribution tree. distribution tree.
M Weight: when priorities are the same for multiple RLOCs, the M Weight: when priorities are the same for multiple RLOCs, the
weight indicates how to balance building multicast distribution weight indicates how to balance building multicast distribution
trees across multiple ITRs. The weight is encoded as a relative trees across multiple ITRs. The weight is encoded as a relative
weight of total number of trees built to the source site weight (similar to the unicast Weights) of total number of trees
identified by the EID-prefix. If a non-zero weight value is used built to the source site identified by the EID-prefix. If all
for any RLOC, then all RLOCs MUST use a non-zero weight value and weights for a locator-set are equal, the receiver of the Map-Reply
then the sum of all weight values MUST equal 100. If a zero value will decide how to distribute multicast state across ITRs.
is used for any RLOC weight, then all weights MUST be zero and the
receiver of the Map-Reply will decide how to distribute multicast
state across ITRs.
Unused Flags: set to 0 when sending and ignored on receipt. Unused Flags: set to 0 when sending and ignored on receipt.
L: when this bit is set, the locator is flagged as a local locator to L: when this bit is set, the locator is flagged as a local locator to
the ETR that is sending the Map-Reply. When a Map-Server is doing the ETR that is sending the Map-Reply. When a Map-Server is doing
proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to proxy Map-Replying [LISP-MS] for a LISP site, the L bit is set to
0 for all locators in this locator-set. 0 for all locators in this locator-set.
p: when this bit is set, an ETR informs the RLOC-probing ITR that the p: when this bit is set, an ETR informs the RLOC-probing ITR that the
locator address, for which this bit is set, is the one being RLOC- locator address, for which this bit is set, is the one being RLOC-
skipping to change at page 35, line 37 skipping to change at page 35, line 39
Reply. An ITR that RLOC-probes a particular locator, MUST use Reply. An ITR that RLOC-probes a particular locator, MUST use
this locator for retrieving the data structure used to store the this locator for retrieving the data structure used to store the
fact that the locator is reachable. The "p" bit is set for a fact that the locator is reachable. The "p" bit is set for a
single locator in the same locator set. If an implementation sets single locator in the same locator set. If an implementation sets
more than one "p" bit erroneously, the receiver of the Map-Reply more than one "p" bit erroneously, the receiver of the Map-Reply
MUST select the first locator. The "p" bit MUST NOT be set for MUST select the first locator. The "p" bit MUST NOT be set for
locator-set records sent in Map-Request and Map-Register messages. locator-set records sent in Map-Request and Map-Register messages.
R: set when the sender of a Map-Reply has a route to the locator in R: set when the sender of a Map-Reply has a route to the locator in
the locator data record. This receiver may find this useful to the locator data record. This receiver may find this useful to
know when determining if the locator is reachable from the know if the locator is up but not necessarily reachable from the
receiver. See also Section 6.4 for another way the R-bit may be receiver's point of view. See also Section 6.4 for another way
used. the R-bit may be used.
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] or [ALT] for details. This field
is optional and present when the UDP length indicates there is is optional and present when the UDP length indicates there is
enough space in the packet to include it. enough space in the packet to include it. The Mapping Protocol
Data is 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 22 skipping to change at page 39, line 22
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length | | Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-AFI | c | Rsvd | Map-Version Number | EID-prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix | r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 22 skipping to change at page 41, line 22
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length | | Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved | R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-AFI | c | Rsvd | Map-Version Number | EID-prefix-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix | r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight | | /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI | | o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 44, line 46 skipping to change at page 44, line 46
sending a Map-Request to the source EID (the inner header IP sending a Map-Request to the source EID (the inner header IP
source address) of the received encapsulated packet. A reply to source address) of the received encapsulated packet. A reply to
this "verifying Map-Request" is used to fully populate the map- this "verifying Map-Request" is used to fully populate the map-
cache entry for the "gleaned" EID and is stored and used for the cache entry for the "gleaned" EID and is stored and used for the
time indicated from the TTL field of a received Map-Reply. When a time indicated from the TTL field of a received Map-Reply. When a
verified map-cache entry is stored, data gleaning no longer occurs verified map-cache entry is stored, data gleaning no longer occurs
for subsequent packets which have a source EID that matches the for subsequent packets which have a source EID that matches the
EID-prefix of the verified entry. EID-prefix of the verified entry.
RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be RLOCs that appear in EID-to-RLOC Map-Reply messages are assumed to be
reachable when the R-bit for the locator record is set to 1. Neither reachable when the R-bit for the locator record is set to 1. When
the information contained in a Map-Reply or that stored in the the R-bit is set to 0, an ITR or PITR MUST not encapsulate to the
mapping database system provides reachability information for RLOCs. RLOC. Neither the information contained in a Map-Reply or that
Note that reachability is not part of the mapping system and is stored in the mapping database system provides reachability
determined using one or more of the Routing Locator Reachability information for RLOCs. Note that reachability is not part of the
Algorithms described in the next section. mapping system and is determined using one or more of the Routing
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 Loc-Status-Bits in the LISP header of an
encapsulated data packet received from an ITR. If the ETR is 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
skipping to change at page 49, line 39 skipping to change at page 49, line 43
A site may be multihomed using two or more ETRs. The hosts and A site may be multihomed using two or more ETRs. The hosts and
infrastructure within a site will be addressed using one or more EID infrastructure within a site will be addressed using one or more EID
prefixes that are mapped to the RLOCs of the relevant ETRs in the prefixes that are mapped to the RLOCs of the relevant ETRs in the
mapping system. One possible failure mode is for an ETR to lose mapping system. One possible failure mode is for an ETR to lose
reachability to one or more of the EID prefixes within its own site. reachability to one or more of the EID prefixes within its own site.
When this occurs when the ETR sends Map-Replies, it can clear the When this occurs when the ETR sends Map-Replies, it can clear the
R-bit associated with its own locator. And when the ETR is also an R-bit associated with its own locator. And when the ETR is also an
ITR, it can clear its locator-status-bit in the encapsulation data ITR, it can clear its locator-status-bit in the encapsulation data
header. header.
It is recognized there are no simple solutions to the site
partitioning problem because it is hard to know which part of the
EID-prefix range is partitioned. And which locators can reach any
sub-ranges of the EID-prefixes. This problem is under investigation
with the expectation that experiments will tell us more. Note, this
is not a new problem introduced by the LISP architecture. The
problem exists today when a multi-homed site uses BGP to advertise
its reachability upstream.
6.5. Routing Locator Hashing 6.5. Routing Locator Hashing
When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to When an ETR provides an EID-to-RLOC mapping in a Map-Reply message to
a requesting ITR, the locator-set for the EID-prefix may contain a requesting ITR, the locator-set for the EID-prefix may contain
different priority values for each locator address. When more than different priority values for each locator address. When more than
one best priority locator exists, the ITR can decide how to load one best priority locator exists, the ITR can decide how to load
share traffic against the corresponding locators. share traffic against the corresponding locators.
The following hash algorithm may be used by an ITR to select a The following hash algorithm may be used by an ITR to select a
locator for a packet destined to an EID for the EID-to-RLOC mapping: locator for a packet destined to an EID for the EID-to-RLOC mapping:
skipping to change at page 50, line 49 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 a locator record is added to the end of a locator-set, it is When adding a new locator record in lexiographic order to the end of
easy to update mappings. We assume new mappings will maintain the a locator-set, it is easy to update mappings. We assume new mappings
same locator ordering as the old mapping but just have new locators will maintain the same locator ordering as the old mapping but just
appended to the end of the list. So some ITRs can have a new mapping have new locators appended to the end of the list. So some ITRs can
while other ITRs have only an old mapping that is used until they have a new mapping while other ITRs have only an old mapping that is
time out. When an ITR has only an old mapping but detects bits set used until they time out. When an ITR has only an old mapping but
in the loc-status-bits that correspond to locators beyond the list it detects bits set in the loc-status-bits that correspond to locators
has cached, it simply ignores them. However, this can only happen beyond the list it has cached, it simply ignores them. However, this
for locator addresses that are lexicographically greater than the can only happen for locator addresses that are lexicographically
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 lexiographic 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
skipping to change at page 59, line 5 skipping to change at page 59, line 5
message MUST be a globally routable address and therefore SHOULD NOT message MUST be a globally routable address and therefore SHOULD NOT
contain [RFC1918] addresses. If a LISP router is configured with contain [RFC1918] addresses. If a LISP router is configured with
private addresses, they MUST be used only in the outer IP header so private addresses, they MUST be used only in the outer IP header so
the NAT device can translate properly. Otherwise, EID addresses MUST the NAT device can translate properly. Otherwise, EID addresses MUST
be translated before encapsulation is performed. Both NAT be translated before encapsulation is performed. Both NAT
translation and LISP encapsulation functions could be co-located in translation and LISP encapsulation functions could be co-located in
the same device. the same device.
More details on LISP address translation can be found in [INTERWORK]. More details on LISP address translation can be found in [INTERWORK].
8.5. Packets Egressing a LISP Site
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'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
mappings, traffic will be dropped while the mappings are retrieved
from the mapping system. The retrieval of these messages may
increase the load of requests being sent into the mapping system.
While this is not anticipated this will be a problem, the deployment
and experimentation will determine if there is an issue requiring
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 67, line 25 skipping to change at page 68, line 25
toward providing decent authentication. toward providing decent authentication.
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
the priority and weights provided by the ETR in its Map-Reply. This
traffic steering would be limited to the traffic that is sent by this
ITR's site, and no more severe than if the site initiated a bandwidth
DoS attack on (one of) the ETR's ingress links. The ITR's site would
typically gain no benefit from not respecting the weights, and would
likely to receive better service by abiding by them.
To deal with map-cache exhaustion attempts in an ITR/PTR, the To deal with map-cache exhaustion attempts in an ITR/PTR, the
implementation should consider putting a maximum cap on the number of implementation should consider putting a maximum cap on the number of
entries stored with a reserve list for special or frequently accessed entries stored with a reserve list for special or frequently accessed
sites. This should be a configuration policy control set by the sites. This should be a configuration policy control set by the
network administrator who manages ITRs and PTRs. network administrator who manages ITRs and PTRs.
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. 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
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 potential security risk implicit in the fact that ETRs
generate the EID prefix to which they are responding. In theory, an generate the EID prefix to which they are responding. In theory, an
ETR can claim a shorter prefix than it is actually responsible for. ETR can claim a shorter prefix than it is actually responsible for.
Various mechanisms to ameliorate or resolve this issue will be Various mechanisms to ameliorate or resolve this issue will be
examined in the future, [LISP-SEC]. examined in the future, [LISP-SEC].
Spoofing of inner header addresses of LISP encapsulated packets is
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
EID-prefix range prior to encapsulation. ETRs MUST NOT decapsulate
and forward packets into their site where the inner header
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
compare the inner header source EID address and the outer header
source RLOC address with the mapping that exists in the mapping
database. Then when spoofing attacks occur, the outer header source
RLOC address can be used to trace back the attack to the source site,
using existing operational tools.
12.1. IETF Security Area Statement
This document represents the thinking of the LISP working group. The
Security Area of the IETF believes there is an open security issue
how LISP interacts with BCP 107's guidance on automated key
management. This and other issues would need to be resolved before
standardization of LISP. Accounting for these concerns may change
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
Authority (IANA) regarding registration of values related to the LISP Authority (IANA) regarding registration of values related to the LISP
skipping to change at page 71, line 24 skipping to change at page 73, line 24
[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.
[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-00.txt (work in Packets"", draft-eubanks-chimento-6man-01.txt (work in
progress), February 2009. 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 http://www.iana.org/.../address-family-numbers,
Febuary 2007. Febuary 2007.
[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-06.txt (work in progress), March 2011.
skipping to change at page 73, line 10 skipping to change at page 75, line 10
February 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-04.txt (work in progress), draft-ietf-lisp-multicast-05.txt (work in progress),
October 2010. April 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 74, line 34 skipping to change at page 76, line 34
Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry
Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van
Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien
Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David
Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin,
Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari
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,
and Clarence Filsfils. 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-11.txt B.1. 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
resued in the definition section of "EID-prefix".
o Tracker item 95. Change "eliminate" to "defer" in section 4.1.
o Tracker item 110. Added that the Mapping Protocol Data field in
the Map-Reply message is only used when needed by the particular
Mapping Database System.
o Tracker item 111. Indicate that if an LSB that is assocaited with
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
reachability.
o Tracker item 107. Indicate that weights are relative to each
other versus requiring an addition of up to 100%.
o Tracker item 46. Add a sentence how LISP products should be sized
for the appropriate demand so cache thrashing is avoided.
o Change some references of RFC 5226 to [AFI] per Luigi.
o Per Luigi, make reference to "EID-AFI" consistent to "EID-prefix-
AFI".
o Tracker item 66. Indicate that appending locators to a locator-
set is done when the added locators are lexiographically greater
than the previous ones in the set.
o Tracker item 87. Once again reword the definition of the EID-
prefix to reflect recent comments.
o Tracker item 70. Added text to security section on what the
implications could be if an ITR does not obey priority and weights
from a Map-Reply message.
o Tracker item 54. Added text to the new section titled "Packets
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
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.
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
locator-record of a Map-Reply.
o Tracker item 33. Add paragraph to the EID Reachability section
indicating that site parittioning is under investigation.
o Tracker item 58. Added last paragraph of Security Considerations
section about how to protect inner header EID address spoofing
attacks.
o Add suggested Sam text to indicate that all security concerns need
not be addressed for moving document to Experimental RFC status.
Put this in a subsection of the Secuirty Considerations section.
B.2. Changes to draft-ietf-lisp-11.txt
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.
o Add pargraph suggested by Joel to explain how implementation o Add pargraph 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
skipping to change at page 75, line 43 skipping to change at page 79, line 9
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 paragraph 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.2. Changes to draft-ietf-lisp-10.txt B.3. 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 76, line 20 skipping to change at page 79, line 35
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.3. Changes to draft-ietf-lisp-09.txt B.4. 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.4. Changes to draft-ietf-lisp-08.txt B.5. 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 78, line 26 skipping to change at page 81, line 42
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.5. Changes to draft-ietf-lisp-07.txt B.6. 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 80, line 5 skipping to change at page 83, line 17
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.6. Changes to draft-ietf-lisp-06.txt B.7. 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 81, line 13 skipping to change at page 84, line 26
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.7. Changes to draft-ietf-lisp-05.txt B.8. 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 81, line 41 skipping to change at page 85, line 5
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.8. Changes to draft-ietf-lisp-04.txt B.9. 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 83, line 32 skipping to change at page 86, line 44
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.9. Changes to draft-ietf-lisp-03.txt B.10. 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.10. Changes to draft-ietf-lisp-02.txt B.11. 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.11. Changes to draft-ietf-lisp-01.txt B.12. 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.12. Changes to draft-ietf-lisp-00.txt B.13. 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. 44 change blocks. 
102 lines changed or deleted 234 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/