draft-ietf-lisp-09.txt   draft-ietf-lisp-10.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: April 14, 2011 D. Lewis Expires: September 5, 2011 D. Lewis
cisco Systems cisco Systems
October 11, 2010 March 4, 2011
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-09 draft-ietf-lisp-10
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 April 14, 2011. This Internet-Draft will expire on September 5, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 41 skipping to change at page 2, line 41
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 22
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 23
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 24
5.5. Using Virtualization and Segmentation with LISP . . . . . 24 5.5. Using Virtualization and Segmentation with LISP . . . . . 24
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 26
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 26
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 28
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 28
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 30 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 30
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 . . . . . . . . . . 35 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. Encapsulated Control Message Format . . . . . . . . . 39 6.1.7. Map-Notify Message Format . . . . . . . . . . . . . . 40
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 41 6.1.8. Encapsulated Control Message Format . . . . . . . . . 41
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 42 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 43
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 45 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 45
6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 46 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 47
6.4. EID Reachability within a LISP Site . . . . . . . . . . . 47 6.3.2. RLOC Probing Algorithm . . . . . . . . . . . . . . . . 48
6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 47 6.4. EID Reachability within a LISP Site . . . . . . . . . . . 49
6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 48 6.5. Routing Locator Hashing . . . . . . . . . . . . . . . . . 49
6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 49 6.6. Changing the Contents of EID-to-RLOC Mappings . . . . . . 50
6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 49 6.6.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 51
6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 51 6.6.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 52
7. Router Performance Considerations . . . . . . . . . . . . . . 52 6.6.3. Database Map Versioning . . . . . . . . . . . . . . . 53
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 53 7. Router Performance Considerations . . . . . . . . . . . . . . 55
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 54 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 56
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 54 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 57
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 55 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 57
8.4. LISP Functionality with Conventional NATs . . . . . . . . 55 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 58
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 56 8.4. LISP Functionality with Conventional NATs . . . . . . . . 58
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 57 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 59
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 57 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 60
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 57 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 60
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 59 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 60
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 59 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 62
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 59 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 62
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 59 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 62
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 61 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 62
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 61 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 64
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 63 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 64
12. Security Considerations . . . . . . . . . . . . . . . . . . . 64 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 66
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 65 12. Security Considerations . . . . . . . . . . . . . . . . . . . 67
13.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 65 13. Network Management Considerations . . . . . . . . . . . . . . 68
13.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 65 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 69
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 66 14.1. LISP Address Type Codes . . . . . . . . . . . . . . . . . 69
14.1. Normative References . . . . . . . . . . . . . . . . . . . 66 14.2. LISP UDP Port Numbers . . . . . . . . . . . . . . . . . . 69
14.2. Informative References . . . . . . . . . . . . . . . . . . 67 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 70 15.1. Normative References . . . . . . . . . . . . . . . . . . . 70
Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 71 15.2. Informative References . . . . . . . . . . . . . . . . . . 71
B.1. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 71 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 74
B.2. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 71 Appendix B. Document Change Log . . . . . . . . . . . . . . . . . 75
B.3. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 73 B.1. Changes to draft-ietf-lisp-10.txt . . . . . . . . . . . . 75
B.4. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 74 B.2. Changes to draft-ietf-lisp-09.txt . . . . . . . . . . . . 75
B.5. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 75 B.3. Changes to draft-ietf-lisp-08.txt . . . . . . . . . . . . 75
B.6. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 76 B.4. Changes to draft-ietf-lisp-07.txt . . . . . . . . . . . . 77
B.7. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 78 B.5. Changes to draft-ietf-lisp-06.txt . . . . . . . . . . . . 79
B.8. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 78 B.6. Changes to draft-ietf-lisp-05.txt . . . . . . . . . . . . 80
B.9. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 78 B.7. Changes to draft-ietf-lisp-04.txt . . . . . . . . . . . . 80
B.10. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 79 B.8. Changes to draft-ietf-lisp-03.txt . . . . . . . . . . . . 82
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 B.9. Changes to draft-ietf-lisp-02.txt . . . . . . . . . . . . 83
B.10. Changes to draft-ietf-lisp-01.txt . . . . . . . . . . . . 83
B.11. Changes to draft-ietf-lisp-00.txt . . . . . . . . . . . . 83
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84
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 16, line 14 skipping to change at page 16, line 14
5. LISP Encapsulation Details 5. LISP Encapsulation Details
Since additional tunnel headers are prepended, the packet becomes Since additional tunnel headers are prepended, the packet becomes
larger and can exceed the MTU of any link traversed from the ITR to larger and can exceed the MTU of any link traversed from the ITR to
the ETR. It is recommended in IPv4 that packets do not get the ETR. It is recommended in IPv4 that packets do not get
fragmented as they are encapsulated by the ITR. Instead, the packet fragmented as they are encapsulated by the ITR. Instead, the packet
is dropped and an ICMP Too Big message is returned to the source. is dropped and an ICMP Too Big message is returned to the source.
This specification recommends that implementations support for one of This specification recommends that implementations support for one of
the proposed fragmentation and reassembly schemes. These two simple the proposed fragmentation and reassembly schemes. These two
existing schemes are detailed in Section 5.4. existing schemes are detailed in Section 5.4.
5.1. LISP IPv4-in-IPv4 Header Format 5.1. LISP IPv4-in-IPv4 Header Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ |Version| IHL |Type of Service| Total Length | / |Version| IHL |Type of Service| Total Length |
/ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Identification |Flags| Fragment Offset | | | Identification |Flags| Fragment Offset |
skipping to change at page 22, line 45 skipping to change at page 22, line 45
codepoint (the value is '11', the Congestion Experienced (CE) codepoint (the value is '11', the Congestion Experienced (CE)
codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from codepoint), then ETR decapsulation MUST copy the 2-bit ECN field from
the stripped outer header to the surviving inner header that is used the stripped outer header to the surviving inner header that is used
to forward the packet beyond the ETR. These requirements preserve to forward the packet beyond the ETR. These requirements preserve
Congestion Experienced (CE) indications when a packet that uses ECN Congestion Experienced (CE) indications when a packet that uses ECN
traverses a LISP tunnel and becomes marked with a CE indication due traverses a LISP tunnel and becomes marked with a CE indication due
to congestion between the tunnel endpoints. to congestion between the tunnel endpoints.
5.4. Dealing with Large Encapsulated Packets 5.4. Dealing with Large Encapsulated Packets
This section proposes two simple mechanisms to deal with packets that This section proposes two mechanisms to deal with packets that exceed
exceed the path MTU between the ITR and ETR. the path MTU between the ITR and ETR.
It is left to the implementor to decide if the stateless or stateful It is left to the implementor to decide if the stateless or stateful
mechanism should be implemented. Both or neither can be used since mechanism should be implemented. Both or neither can be used since
it is a local decision in the ITR regarding how to deal with MTU it is a local decision in the ITR regarding how to deal with MTU
issues, and sites can interoperate with differing mechanisms. issues, and sites can interoperate with differing mechanisms.
Both stateless and stateful mechanisms also apply to Reencapsulating Both stateless and stateful mechanisms also apply to Reencapsulating
and Recursive Tunneling. So any actions below referring to an ITR and Recursive Tunneling. So any actions below referring to an ITR
also apply to an TE-ITR. also apply to an TE-ITR.
skipping to change at page 24, line 40 skipping to change at page 24, line 40
Even though this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has advantages over the
stateless IP fragmentation mechanism, by not involving the stateless IP fragmentation mechanism, by not involving the
destination host with reassembly of ITR fragmented packets. destination host with reassembly of ITR fragmented packets.
5.5. Using Virtualization and Segmentation with LISP 5.5. Using Virtualization and Segmentation with LISP
When multiple organizations inside of a LISP site are using private When multiple organizations inside of a LISP site are using private
addresses [RFC1918] as EID-prefixes, their address spaces MUST remain addresses [RFC1918] as EID-prefixes, their address spaces MUST remain
segregated due to possible address duplication. An Instance ID in segregated due to possible address duplication. An Instance ID in
the address encoding can aid in making the entire AFI based address the address encoding can aid in making the entire AFI based address
unique. See IANA Considerations Section 13.1 for details for unique. See IANA Considerations Section 14.1 for details for
possible address encodings. possible address encodings.
An Instance ID can be carried in a LISP encapsulated packet. An ITR An Instance ID can be carried in a LISP encapsulated packet. An ITR
that prepends a LISP header, will copy a 24-bit value, used by the that prepends a LISP header, will copy a 24-bit value, used by the
LISP router to uniquely identify the address space. The value is LISP router to uniquely identify the address space. The value is
copied to the Instance ID field of the LISP header and the I-bit is copied to the Instance ID field of the LISP header and the I-bit is
set to 1. set to 1.
When an ETR decapsulates a packet, the Instance ID from the LISP When an ETR decapsulates a packet, the Instance ID from the LISP
header is used as a table identifier to locate the forwarding table header is used as a table identifier to locate the forwarding table
skipping to change at page 28, line 14 skipping to change at page 28, line 14
6.1.1. LISP Packet Type Allocations 6.1.1. LISP Packet Type Allocations
This section will be the authoritative source for allocating LISP This section will be the authoritative source for allocating LISP
Type values. Current allocations are: Type values. Current allocations are:
Reserved: 0 b'0000' Reserved: 0 b'0000'
LISP Map-Request: 1 b'0001' LISP Map-Request: 1 b'0001'
LISP Map-Reply: 2 b'0010' LISP Map-Reply: 2 b'0010'
LISP Map-Register: 3 b'0011' LISP Map-Register: 3 b'0011'
LISP Map-Notify: 4 b'0100'
LISP Encapsulated Control Message: 8 b'1000' LISP Encapsulated Control Message: 8 b'1000'
6.1.2. Map-Request Message Format 6.1.2. Map-Request Message Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|M|P|S| Reserved | IRC | Record Count | |Type=1 |A|M|P|S|p| Reserved | IRC | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | Source EID Address ... | | Source-EID-AFI | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... | | ITR-RLOC-AFI 1 | ITR-RLOC Address 1 ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
skipping to change at page 29, line 21 skipping to change at page 29, line 21
the Map-Request. the Map-Request.
P: This is the probe-bit which indicates that a Map-Request SHOULD be P: This is the probe-bit which indicates that a Map-Request SHOULD be
treated as a locator reachability probe. The receiver SHOULD treated as a locator reachability probe. The receiver SHOULD
respond with a Map-Reply with the probe-bit set, indicating the respond with a Map-Reply with the probe-bit set, indicating the
Map-Reply is a locator reachability probe reply, with the nonce Map-Reply is a locator reachability probe reply, with the nonce
copied from the Map-Request. See Section 6.3.2 for more details. copied from the Map-Request. See Section 6.3.2 for more details.
S: This is the SMR bit. See Section 6.6.2 for details. S: This is the 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
Map-Request.
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and 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 32, line 10 skipping to change at page 32, line 10
Request" to the "piggybacked" EID. Doing this forces the "verifying Request" to the "piggybacked" EID. Doing this forces the "verifying
Map-Request" to go through the mapping database system to reach the Map-Request" to go through the mapping database system to reach the
authoritative source of information about that EID, guarding against authoritative source of information about that EID, guarding against
RLOC-spoofing in in the "piggybacked" mapping data. RLOC-spoofing in in the "piggybacked" mapping data.
6.1.4. Map-Reply Message Format 6.1.4. Map-Reply Message Format
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P|E| 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-AFI |
skipping to change at page 32, line 46 skipping to change at page 32, line 46
P: This is the probe-bit which indicates that the Map-Reply is in P: This is the probe-bit which indicates that the Map-Reply is in
response to a locator reachability probe Map-Request. The nonce response to a locator reachability probe Map-Request. The nonce
field MUST contain a copy of the nonce value from the original field MUST contain a copy of the nonce value from the original
Map-Request. See Section 6.3.2 for more details. Map-Request. See Section 6.3.2 for more details.
E: Indicates that the ETR which sends this Map-Reply message is E: Indicates that the ETR which sends this Map-Reply message is
advertising that the site is enabled for the Echo-Nonce locator advertising that the site is enabled for the Echo-Nonce locator
reachability algorithm. See Section 6.3.1 for more details. reachability algorithm. See Section 6.3.1 for more details.
S: This is the Security bit. When set to 1 the field following the
Mapping Protocol Data field will have the following format. The
detailed format of the Authentication Data Content field can be
found in [LISP-SEC] when AD Type is equal to 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AD Type | Authentication Data Content . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved: Set to 0 on transmission and ignored on receipt. Reserved: Set to 0 on transmission and 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.
skipping to change at page 38, line 20 skipping to change at page 39, line 8
format. format.
The message is sent in UDP with a destination UDP port of 4342 and a The message is sent in UDP with a destination UDP port of 4342 and a
randomly selected UDP source port number. randomly selected UDP source port number.
The Map-Register message format is: The Map-Register message format is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P| Reserved | Record Count | |Type=3 |P| Reserved |M| Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . | | Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce | | . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length | | Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~ ~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
skipping to change at page 39, line 15 skipping to change at page 39, line 45
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: Set to 0 on transmission and ignored on receipt.
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
sending a Map-Register message. The Map-Notify message sent by a
Map-Server is used to an acknowledge receipt of a Map-Register
message.
Record Count: The number of records in this Map-Register message. A Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record' record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages. Nonce: This 8-byte Nonce field is set to 0 in Map-Register messages.
Key ID: A configured ID to find the configured Message Key ID: A configured ID to find the configured Message
Authentication Code (MAC) algorithm and key value used for the Authentication Code (MAC) algorithm and key value used for the
authentication function. authentication function.
skipping to change at page 39, line 43 skipping to change at page 40, line 33
Message Authentication Code (MAC) algorithm. The entire Map- Message Authentication Code (MAC) algorithm. The entire Map-
Register payload is authenticated with this field preset to 0. Register payload is authenticated with this field preset to 0.
After the MAC is computed, it is placed in this field. After the MAC is computed, it is placed in this field.
Implementations of this specification MUST include support for Implementations of this specification MUST include support for
HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634] HMAC-SHA-1-96 [RFC2404] and support for HMAC-SHA-128-256 [RFC4634]
is recommended. is recommended.
The definition of the rest of the Map-Register can be found in the The definition of the rest of the Map-Register can be found in the
Map-Reply section. Map-Reply section.
6.1.7. Encapsulated Control Message Format 6.1.7. Map-Notify Message Format
The usage details of the Map-Notify message can be found in
specification [LISP-MS]. This section solely defines the message
format.
The message is sent inside a UDP packet with a source UDP port equal
to 4342 and a destination port equal to the source port from the Map-
Register message this Map-Notify message is responding to.
The Map-Notify message format is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=4 | Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID | Authentication Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Authentication Data ~
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len | ACT |A| Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Rsvd | Map-Version Number | EID-AFI |
o +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
r | EID-prefix |
d +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /| Priority | Weight | M Priority | M Weight |
| L +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| o | Unused Flags |L|p|R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions:
Type: 4 (Map-Notify)
The Map-Notify message has the same contents as a Map-Register
message. See Map-Register section for field descriptions.
6.1.8. Encapsulated Control Message Format
An Encapsulated Control Message is used to encapsulate control An Encapsulated Control Message is used to encapsulate control
packets sent between xTRs and the mapping database system described packets sent between xTRs and the mapping database system described
in [LISP-MS]. in [LISP-MS].
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
OH | (uses RLOC addresses) | OH | (uses RLOC addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = 4342 | / | Source Port = xxxx | Dest Port = 4342 |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LH |Type=8 | Reserved | LH |Type=8 |S| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | IPv4 or IPv6 Header | / | IPv4 or IPv6 Header |
IH | (uses RLOC or EID addresses) | IH | (uses RLOC or EID addresses) |
\ | | \ | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Source Port = xxxx | Dest Port = yyyy | / | Source Port = xxxx | Dest Port = yyyy |
UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ UDP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | UDP Length | UDP Checksum | \ | UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
LCM | LISP Control Message | LCM | LISP Control Message |
skipping to change at page 40, line 41 skipping to change at page 42, line 41
OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the OH: The outer IPv4 or IPv6 header which uses RLOC addresses in the
source and destination header address fields. source and destination header address fields.
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
Reserved field will have the following format. The detailed
format of the Authentication Data Content field can be found in
[LISP-SEC] when AD Type is equal to 1.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
header is an EID. header is an EID.
UDP: The inner UDP header where the port assignments depends on the UDP: The inner UDP header where the port assignments depends on the
control packet being encapsulated. When the control packet is a control packet being encapsulated. When the control packet is a
Map-Request or Map-Register, the source port is ITR/PITR selected Map-Request or Map-Register, the source port is ITR/PITR selected
and the destination port is 4342. When the control packet is a and the destination port is 4342. When the control packet is a
Map-Reply, the source port is 4342 and the destination port is Map-Reply, the source port is 4342 and the destination port is
skipping to change at page 45, line 14 skipping to change at page 47, line 31
most cases, the ETR can also reach the ITR but cannot assume this to most cases, the ETR can also reach the ITR but cannot assume this to
be true due to the possibility of path asymmetry. In the presence of be true due to the possibility of path asymmetry. In the presence of
unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT unidirectional traffic flow from an ITR to an ETR, the ITR SHOULD NOT
use the lack of return traffic as an indication that the ETR is use the lack of return traffic as an indication that the ETR is
unreachable. Instead, it MUST use an alternate mechanisms to unreachable. Instead, it MUST use an alternate mechanisms to
determine reachability. determine reachability.
6.3.1. Echo Nonce Algorithm 6.3.1. Echo Nonce Algorithm
When data flows bidirectionally between locators from different When data flows bidirectionally between locators from different
sites, a simple mechanism called "nonce echoing" can be used to sites, a data-plane mechanism called "nonce echoing" can be used to
determine reachability between an ITR and ETR. When an ITR wants to determine reachability between an ITR and ETR. When an ITR wants to
solicit a nonce echo, it sets the N and E bits and places a 24-bit solicit a nonce echo, it sets the N and E bits and places a 24-bit
nonce in the LISP header of the next encapsulated data packet. nonce in the LISP header of the next encapsulated data packet.
When this packet is received by the ETR, the encapsulated packet is When this packet is received by the ETR, the encapsulated packet is
forwarded as normal. When the ETR next sends a data packet to the forwarded as normal. When the ETR next sends a data packet to the
ITR, it includes the nonce received earlier with the N bit set and E ITR, it includes the nonce received earlier with the N bit set and E
bit cleared. The ITR sees this "echoed nonce" and knows the path to bit cleared. The ITR sees this "echoed nonce" and knows the path to
and from the ETR is up. and from the ETR is up.
skipping to change at page 65, line 5 skipping to change at page 68, line 5
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.
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.
13. IANA Considerations 13. Network Management Considerations
Considerations for Network Management tools exist so the LISP
protocol suite can be operationally managed. The mechanisms can be
found in [LISP-MIB] and [LISP-LIG].
14. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the LISP Authority (IANA) regarding registration of values related to the LISP
specification, in accordance with BCP 26 and RFC 5226 [RFC5226]. specification, in accordance with BCP 26 and RFC 5226 [RFC5226].
There are two name spaces in LISP that require registration: There are two name spaces in LISP that require registration:
o LISP IANA registry allocations should not be made for purposes o LISP IANA registry allocations should not be made for purposes
unrelated to LISP routing or transport protocols. unrelated to LISP routing or transport protocols.
o The following policies are used here with the meanings defined in o The following policies are used here with the meanings defined in
BCP 26: "Specification Required", "IETF Consensus", "Experimental BCP 26: "Specification Required", "IETF Consensus", "Experimental
Use", "First Come First Served". Use", "First Come First Served".
13.1. LISP Address Type Codes 14.1. LISP Address Type Codes
Instance ID type codes have a range from 0 to 15, of which 0 and 1 Instance ID type codes have a range from 0 to 15, of which 0 and 1
have been allocated [LCAF]. New Type Codes MUST be allocated have been allocated [LCAF]. New Type Codes MUST be allocated
starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review. starting at 2. Type Codes 2 - 10 are to be assigned by IETF Review.
Type Codes 11 - 15 are available on a First Come First Served policy. Type Codes 11 - 15 are available on a First Come First Served policy.
The following codes have been allocated: The following codes have been allocated:
Type 0: Null Body Type Type 0: Null Body Type
Type 1: AFI List Type Type 1: AFI List Type
See [LCAF] for details for other possible unapproved address See [LCAF] for details for other possible unapproved address
encodings. The unapproved LCAF encodings are an area for further encodings. The unapproved LCAF encodings are an area for further
study and experimentation. study and experimentation.
13.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.
14. References 15. References
14.1. Normative References 15.1. Normative References
[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.
skipping to change at page 67, line 27 skipping to change at page 71, line 27
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-00.txt (work in
progress), February 2009. progress), February 2009.
14.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/numbers.html, Febuary 2007. NUMBERS http://www.iana.org/numbers.html, 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-04.txt (work in progress), April 2010. draft-ietf-lisp-alt-06.txt (work in progress), March 2011.
[CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed [CHIAPPA] Chiappa, J., "Endpoints and Endpoint names: A Proposed
Enhancement to the Internet Architecture", Internet- Enhancement to the Internet Architecture", Internet-
Draft http://www.chiappa.net/~jnc/tech/endpoints.txt, Draft http://www.chiappa.net/~jnc/tech/endpoints.txt,
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-01.txt (work in progress), draft-ietf-lisp-interworking-02.txt (work in progress),
March 2010. March 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-02.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-LIG]
Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
draft-ietf-lisp-lig-01.txt (work in progress),
October 2010.
[LISP-MAIN] [LISP-MAIN]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-farinacci-lisp-12.txt (work in progress), draft-farinacci-lisp-12.txt (work in progress),
March 2009. March 2009.
[LISP-MIB]
Schudel, G., Jain, A., and V. Moreno, "LISP MIB",
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-05.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-05.txt (work in progress), April 2010. draft-ietf-lisp-ms-07.txt (work in progress), March 2011.
[LISP-SEC]
Maino, F., Ermagon, V., Cabellos, A., Sausez, D., and O.
Bonaventure, "LISP-Security (LISP-SEC)",
draft-maino-lisp-sec-00.txt (work in progress),
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-04.txt (work in progress),
skipping to change at page 69, line 21 skipping to change at page 73, line 35
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005. September 2005.
[RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol [RPMD] Handley, M., Huici, F., and A. Greenhalgh, "RPMD: Protocol
for Routing Protocol Meta-data Dissemination", for Routing Protocol Meta-data Dissemination",
draft-handley-p2ppush-unpublished-2007726.txt (work in draft-handley-p2ppush-unpublished-2007726.txt (work in
progress), July 2007. progress), July 2007.
[VERSIONING] [VERSIONING]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping Iannone, L., Saucez, D., and O. Bonaventure, "LISP Mapping
Versioning", draft-iannone-lisp-mapping-versioning-02.txt Versioning", draft-ietf-lisp-map-versioning-01.txt (work
(work in progress), July 2010. in progress), March 2011.
Appendix A. Acknowledgments Appendix A. Acknowledgments
An initial thank you goes to Dave Oran for planting the seeds for the An initial thank you goes to Dave Oran for planting the seeds for the
initial ideas for LISP. His consultation continues to provide value initial ideas for LISP. His consultation continues to provide value
to the LISP authors. to the LISP authors.
A special and appreciative thank you goes to Noel Chiappa for A special and appreciative thank you goes to Noel Chiappa for
providing architectural impetus over the past decades on separation providing architectural impetus over the past decades on separation
of location and identity, as well as detailed review of the LISP of location and identity, as well as detailed review of the LISP
architecture and documents, coupled with enthusiasm for making LISP a architecture and documents, coupled with enthusiasm for making LISP a
practical and incremental transition for the Internet. practical and incremental transition for the Internet.
The authors would like to gratefully acknowledge many people who have The authors would like to gratefully acknowledge many people who have
contributed discussion and ideas to the making of this proposal. contributed discussion and ideas to the making of this proposal.
They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller, They include Scott Brim, Andrew Partan, John Zwiebel, Jason Schiller,
Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston, Lixia Zhang, Dorian Kim, Peter Schoenmaker, Vijay Gill, Geoff Huston,
David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley, David Conrad, Mark Handley, Ron Bonica, Ted Seely, Mark Townsley,
Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler, Chris Morrow, Brian Weis, Dave McGrew, Peter Lothberg, Dave Thaler,
Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi Eliot Lear, Shane Amante, Ved Kafle, Olivier Bonaventure, Luigi
Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Roger Iannone, Robin Whittle, Brian Carpenter, Joel Halpern, Terry
Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Manderson, Roger Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van
Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Beijnum, Roland Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien
Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque Saucez, Damian Lezama, Attilla De Groot, Parantap Lahiri, David
Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin, Margaret Black, Roque Gagliano, Isidor Kouvelas, Jesper Skriver, Fred Templin,
Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari Arkko, Margaret Wasserman, Sam Hartman, Michael Hofling, Pedro Marques, Jari
Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu, Dhirendra Arkko, Gregg Schudel, Srinivas Subramanian, Amit Jain, Xu Xiaohu,
Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri Dhirendra Trivedi, Yakov Rekhter, John Scudder, John Drake, Dimitri
Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, and Vina Papadimitriou, Ross Callon, Selina Heimlich, Job Snijders, Vina
Ermagan. Ermagan, Albert Cabellos, Fabio Maino, Victor Moreno, and Chris
White.
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-09.txt B.1. Changes to draft-ietf-lisp-10.txt
o Posted March 2011.
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.
o Add Map-Notify message which is used to acknowledge a Map-Register
message sent to a Map-Server.
o Add M-bit to the Map-Register message so an ETR that wants an
acknowledgment for the Map-Register can request one.
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
[LISP-SEC] for expansive details.
o Add Network Management Considerations section and point to the MIB
and LIG drafts.
o Remove the word "simple" per Yakov's comments.
B.2. 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.2. Changes to draft-ietf-lisp-08.txt B.3. 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 73, line 11 skipping to change at page 77, line 33
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.3. Changes to draft-ietf-lisp-07.txt B.4. 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 74, line 34 skipping to change at page 79, line 8
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.4. Changes to draft-ietf-lisp-06.txt B.5. 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 75, line 43 skipping to change at page 80, line 16
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.5. Changes to draft-ietf-lisp-05.txt B.6. 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 76, line 24 skipping to change at page 80, line 44
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.6. Changes to draft-ietf-lisp-04.txt B.7. 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 78, line 15 skipping to change at page 82, line 35
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.7. Changes to draft-ietf-lisp-03.txt B.8. 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.8. Changes to draft-ietf-lisp-02.txt B.9. 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.9. Changes to draft-ietf-lisp-01.txt B.10. 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.10. Changes to draft-ietf-lisp-00.txt B.11. 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. 46 change blocks. 
98 lines changed or deleted 224 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/