draft-ietf-lisp-02.txt   draft-ietf-lisp-03.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft V. Fuller Internet-Draft V. Fuller
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: January 10, 2010 D. Lewis Expires: January 28, 2010 D. Lewis
cisco Systems cisco Systems
July 9, 2009 July 27, 2009
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-02.txt draft-ietf-lisp-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 January 10, 2010. This Internet-Draft will expire on January 28, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 32 skipping to change at page 2, line 32
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14 4.1. Packet Flow Sequence . . . . . . . . . . . . . . . . . . . 14
5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16 5. Tunneling Details . . . . . . . . . . . . . . . . . . . . . . 16
5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17 5.1. LISP IPv4-in-IPv4 Header Format . . . . . . . . . . . . . 17
5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18 5.2. LISP IPv6-in-IPv6 Header Format . . . . . . . . . . . . . 18
5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19 5.3. Tunnel Header Field Descriptions . . . . . . . . . . . . . 19
5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 21
5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 21 5.4.1. A Stateless Solution to MTU Handling . . . . . . . . . 21
5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 23 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 24
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 23 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 24
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 25 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 26
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 25 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 26
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 27 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 28
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 28 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 29
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 31 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 32
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 32 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 33
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 34 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 34
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 35 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 36
6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 37 6.3.1. Echo Nonce Algorithm . . . . . . . . . . . . . . . . . 38
6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 38 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 39
6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 39 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 40
6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 39 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 40
6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 40 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 41
7. Router Performance Considerations . . . . . . . . . . . . . . 42 7. Router Performance Considerations . . . . . . . . . . . . . . 43
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 43 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 44
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 44 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 45
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 44 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 45
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 45 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 46
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 46 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 47
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 47 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 48
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 47 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 48
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 47 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 48
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 49 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 50
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 49 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 50
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 49 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 50
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 49 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 50
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 51 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 52
10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 51 10.5. LISP Mobile Node Mobility . . . . . . . . . . . . . . . . 52
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 53 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 54
12. Security Considerations . . . . . . . . . . . . . . . . . . . 54 12. Security Considerations . . . . . . . . . . . . . . . . . . . 55
13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 55 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 56
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 58 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 59
14.1. Normative References . . . . . . . . . . . . . . . . . . . 58 14.1. Normative References . . . . . . . . . . . . . . . . . . . 59
14.2. Informative References . . . . . . . . . . . . . . . . . . 59 14.2. Informative References . . . . . . . . . . . . . . . . . . 60
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 64
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
Many years of discussion about the current IP routing and addressing Many years of discussion about the current IP routing and addressing
skipping to change at page 19, line 29 skipping to change at page 19, line 29
fields contain RLOCs obtained from the ingress router's EID-to- fields contain RLOCs obtained from the ingress router's EID-to-
RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768]. RLOC cache. The IP protocol number is "UDP (17)" from [RFC0768].
The DF bit of the Flags field is set to 0. The DF bit of the Flags field is set to 0.
UDP Header: contains a ITR selected source port when encapsulating a UDP Header: contains a ITR selected source port when encapsulating a
packet. See Section 6.4 for details on the hash algorithm used packet. See Section 6.4 for details on the hash algorithm used
select a source port based on the 5-tuple of the inner header. select a source port based on the 5-tuple of the inner header.
The destination port MUST be set to the well-known IANA assigned The destination port MUST be set to the well-known IANA assigned
port value 4341. port value 4341.
UDP Checksum: this field field MUST be transmitted as 0 and ignored UDP Checksum: this field MUST be transmitted as 0 and ignored on
on receipt by the ETR. Note, even when the UDP checksum is receipt by the ETR. Note, even when the UDP checksum is
transmitted as 0 an intervening NAT device can recalculate the transmitted as 0 an intervening NAT device can recalculate the
checksum and rewrite the UDP checksum field to non-zero. For checksum and rewrite the UDP checksum field to non-zero. For
performance reasons, the ETR MUST ignore the checksum and MUST not performance reasons, the ETR MUST ignore the checksum and MUST not
do a checksum computation. do a checksum computation.
UDP Length: for an IPv4 encapsulated packet, the inner header Total UDP Length: for an IPv4 encapsulated packet, the inner header Total
Length plus the UDP and LISP header lengths are used. For an IPv6 Length plus the UDP and LISP header lengths are used. For an IPv6
encapsulated packet, the inner header Payload Length plus the size encapsulated packet, the inner header Payload Length plus the size
of the IPv6 header (40 bytes) plus the size of the UDP and LISP of the IPv6 header (40 bytes) plus the size of the UDP and LISP
headers are used. The UDP header length is 8 bytes. The LISP headers are used. The UDP header length is 8 bytes. The LISP
skipping to change at page 20, line 21 skipping to change at page 20, line 21
S: this is the Solicit-Map-Request (SMR) bit. See section S: this is the Solicit-Map-Request (SMR) bit. See section
Section 6.5.2 for details. Section 6.5.2 for details.
E: this is the echo-nonce-request bit. See section Section 6.3.1 for E: this is the echo-nonce-request bit. See section Section 6.3.1 for
details. details.
rsvd-flags: this 6-bit field is reserved for future flag use. It is rsvd-flags: this 6-bit field is reserved for future flag use. It is
set to 0 on transmit and ignored on receipt. set to 0 on transmit and ignored on receipt.
LISP Nonce: is a 24-bit value that is randomly generated by an ITR. LISP Nonce: is a 24-bit value that is randomly generated by an ITR.
It is used to test route-returnability when xTRs exchange The nonce is also used when the E-bit is set to request the nonce
encapsulated data packets with the SMR bit set, Data-Probe, Map- value to be echoed by the other side when packets are returned.
Request, or Map-Reply messages. See section Section 6.3.1 for more details. The nonce is also
used when SMR-bit is set to solicit the other side to send a Map-
Request containing this nonce. See section Section 6.5.2 for
details.
When doing Recursive Tunneling or ITR/PTR encapsulation: When doing Recursive Tunneling or ITR/PTR encapsulation:
o The OH header Time to Live field (or Hop Limit field, in case of o The OH header Time to Live field (or Hop Limit field, in case of
IPv6) MUST be copied from the IH header Time to Live field. IPv6) MUST be copied from the IH header Time to Live field.
o The OH header Type of Service field (or the Traffic Class field, o The OH header Type of Service field (or the Traffic Class field,
in the case of IPv6) SHOULD be copied from the IH header Type of in the case of IPv6) SHOULD be copied from the IH header Type of
Service field (with one caveat, see below). Service field (with one caveat, see below).
skipping to change at page 21, line 27 skipping to change at page 21, line 30
In the event that the MTU issues mentioned above prove to be more In the event that the MTU issues mentioned above prove to be more
serious than expected, this section proposes 2 simple mechanisms to serious than expected, this section proposes 2 simple mechanisms to
deal with large packets. One is stateless using IP fragmentation and deal with large packets. One is stateless using IP fragmentation and
the other is stateful using Path MTU Discovery [RFC1191]. the other is stateful using Path MTU Discovery [RFC1191].
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 decided as mechanism should be implemented. Both or neither can be decided as
well since it is a local decision in the ITR regarding how to deal well since it is a local decision in the ITR regarding how to deal
with MTU issues. Sites can interoperate with differing mechanisms. with MTU issues. Sites can interoperate with differing mechanisms.
Both stateless and stateful mechanisms also apply to Reencapsulating
and Recursive Tunneling. So any actions reference below to an ITR
also apply to an TE-ITR.
5.4.1. A Stateless Solution to MTU Handling 5.4.1. A Stateless Solution to MTU Handling
An ITR stateless solution to handle MTU issues is described as An ITR stateless solution to handle MTU issues is described as
follows: follows:
1. Define an architectural constant S for the maximum size of a 1. Define an architectural constant S for the maximum size of a
packet, in bytes, an ITR would receive from a source inside of packet, in bytes, an ITR would receive from a source inside of
its site. its site.
2. Define L to be the maximum size, in bytes, a packet of size S 2. Define L to be the maximum size, in bytes, a packet of size S
skipping to change at page 22, line 28 skipping to change at page 22, line 35
5.4.2. A Stateful Solution to MTU Handling 5.4.2. A Stateful Solution to MTU Handling
An ITR stateful solution to handle MTU issues is describe as follows An ITR stateful solution to handle MTU issues is describe as follows
and was first introduced in [OPENLISP]: and was first introduced in [OPENLISP]:
1. The ITR will keep state of the effective MTU for each locator per 1. The ITR will keep state of the effective MTU for each locator per
mapping cache entry. The effective MTU is what the core network mapping cache entry. The effective MTU is what the core network
can deliver along the path between ITR and ETR. can deliver along the path between ITR and ETR.
2. When an encapsulated packet, with DF bit always set to 0, exceeds 2. When an IPv6 encapsulated packet or an IPv4 encapsulated packet
what the core network can deliver, one of the intermediate with DF bit set to 0, exceeds what the core network can deliver,
routers on the path will send an ICMP Too Big message to the ITR. one of the intermediate routers on the path will send an ICMP Too
The ITR will parse the ICMP message to determine which locator is Big message to the ITR. The ITR will parse the ICMP message to
affected by the effective MTU change and then record the new determine which locator is affected by the effective MTU change
effective MTU value in the mapping cache entry. and then record the new effective MTU value in the mapping cache
entry.
3. When a packet is received by the ITR from a source inside of the 3. When a packet is received by the ITR from a source inside of the
site and the size of the packet is greater than the effective MTU site and the size of the packet is greater than the effective MTU
stored with the mapping cache entry associated with the stored with the mapping cache entry associated with the
destination EID the packet is for, the ITR will send an ICMP Too destination EID the packet is for, the ITR will send an ICMP Too
Big message back to the source. The packet size advertised by Big message back to the source. The packet size advertised by
the ITR in the ICMP Too Big message is the effective MTU minus the ITR in the ICMP Too Big message is the effective MTU minus
the LISP encapsulation length. the LISP encapsulation length.
Even though this mechanism is stateful, it has advantages over the Even though this mechanism is stateful, it has advantages over the
skipping to change at page 25, line 24 skipping to change at page 26, line 24
LISP-CONS Open Message: 8 b'1000' LISP-CONS Open Message: 8 b'1000'
LISP-CONS Push-Add Message: 9 b'1001' LISP-CONS Push-Add Message: 9 b'1001'
LISP-CONS Push-Delete Message: 10 b'1010' LISP-CONS Push-Delete Message: 10 b'1010'
LISP-CONS Unreachable Message 11 b'1011' LISP-CONS Unreachable Message 11 b'1011'
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Reach Bits | |Type=1 |A|M|P|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=1 |A|R|P|S| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source-EID-AFI | ITR-AFI | | Source-EID-AFI | ITR-AFI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source EID Address ... | | Source EID Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating ITR RLOC Address ... | | Originating ITR RLOC Address ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ | Reserved | EID mask-len | EID-prefix-AFI | / | Reserved | EID mask-len | EID-prefix-AFI |
Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Rec +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ | EID-prefix ... | \ | EID-prefix ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Map-Reply Record ... | | Map-Reply Record ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data | | Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Locator Reach Bits: These bits MUST be set to 0 on transmission and
ignored on receipt. They cannot be used for indicating
reachability because the Map-Request does not have the EID-prefix
for the sending site so the receiver of the Map-Request cannot
know what mapping entry to associate the reachability with.
However, when Mapping Data is provided in the Map-Reply Record
field, and the receiver of the Map-Request is configured to accept
the mapping data, the R-bit per locator entry in the EID-prefix
record is used to denote reachability.
Nonce: A 4-byte random value created by the sender of the Map-
Request.
Type: 1 (Map-Request) Type: 1 (Map-Request)
A: This is an authoritative bit, which is set to 0 for UDP-based Map- A: This is an authoritative bit, which is set to 0 for UDP-based Map-
Requests sent by an ITR. See other control-specific documents Requests sent by an ITR.
[CONS] for TCP-based Map-Requests.
R: When set, it indicates a Map-Reply Record segment is included in M: When set, it indicates a Map-Reply Record segment is included in
the Map-Request. the Map-Request.
P: Indicates that a Map-Request should be treated as a "piggyback" P: Indicates that a Map-Request should be treated as a "piggyback"
locator reachability probe. The receiver should respond with a locator reachability probe. The receiver should respond with a
Map-Reply with the P bit set and the nonce copied from the Map- Map-Reply with the P bit set and the nonce copied from the Map-
Request. Details on this usage will be provided in a future Request. Details on this usage will be provided in a future
version of this draft. version of this draft.
S: This is the SMR bit. See Section 6.5.2 for details. S: This is the SMR bit. See Section 6.5.2 for details.
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 request message. A Record Count: The number of records in this request message. A
record is comprised of the portion of the packet is labeled 'Rec' record is comprised of the portion of the packet is labeled 'Rec'
above and occurs the number of times equal to Record count. above and occurs the number of times equal to Record count.
Nonce: A 4-byte random value created by the sender of the Map-
Request. This nonce will be returned in the Map-Reply.
Source-EID-AFI: Address family of the "Source EID Address" field. Source-EID-AFI: Address family of the "Source EID Address" field.
ITR-AFI: Address family of the "Originating ITR RLOC Address" field. ITR-AFI: Address family of the "Originating ITR RLOC Address" field.
Source EID Address: This is the EID of the source host which Source EID Address: This is the EID of the source host which
originated the packet which is invoking this Map-Request. originated the packet which is invoking this Map-Request.
Originating ITR RLOC Address: Used to give the ETR the option of Originating ITR RLOC Address: Used to give the ETR the option of
returning a Map-Reply in the address-family of this locator. returning a Map-Reply in the address-family of this locator.
skipping to change at page 28, line 10 skipping to change at page 29, line 10
in [LISP-MS]. in [LISP-MS].
Map-Requests MUST be rate-limited. It is recommended that a Map- Map-Requests MUST be rate-limited. It is recommended that a Map-
Request for the same EID-prefix be sent no more than once per second. Request for the same EID-prefix be sent no more than once per second.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Reach Bits | |Type=2 |P| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 |P| Reserved | Record Count |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len |A| ACT | Reserved | R | Locator Count | EID mask-len |A| ACT | Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Reserved | EID-AFI | c | Reserved | EID-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 |R| Loc-AFI | | o | Unused Flags |R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mapping Protocol Data | | Mapping Protocol Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Locator Reach Bits: Refer to Section 5.3. This field MUST be set to
0 on transmission and ignored on receipt. The locator
reachability is encoded as the R-bit in each locator entry of each
EID-prefix record.
Nonce: A 4-byte value set in a Data-Probe packet or a Map-Request
that is echoed here in the Map-Reply.
Type: 2 (Map-Reply) Type: 2 (Map-Reply)
P: Indicates that the Map-Reply is in response to a "piggyback" P: Indicates that the Map-Reply is in response to a "piggyback"
locator reachability Map-Request. The nonce field should contain locator reachability Map-Request. The nonce field should contain
a copy of the nonce value from the original Map-Request. Details a copy of the nonce value from the original Map-Request. Details
on this usage will be provided in a future version of this draft. on this usage will be provided in a future version of this draft.
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 4-byte value set in a Data-Probe packet or a Map-Request
that is echoed here in the Map-Reply.
Record TTL: The time in minutes the recipient of the Map-Reply will Record TTL: The time in minutes the recipient of the Map-Reply will
store the mapping. If the TTL is 0, the entry should be removed store the mapping. If the TTL is 0, the entry should be removed
from the cache immediately. If the value is 0xffffffff, the from the cache immediately. If the value is 0xffffffff, the
recipient can decide locally how long to store the mapping. recipient can decide locally how long to store the mapping.
Locator Count: The number of Locator entries. A locator entry Locator Count: The number of Locator entries. A locator entry
comprises what is labeled above as 'Loc'. The locator count can comprises what is labeled above as 'Loc'. The locator count can
be 0 indicating there are no locators for the EID-prefix. be 0 indicating there are no locators for the EID-prefix.
EID mask-len: Mask length for EID prefix. EID mask-len: Mask length for EID prefix.
skipping to change at page 30, line 38 skipping to change at page 31, line 32
the EID-prefix. If a non-zero weight value is used for any RLOC, the EID-prefix. If a non-zero weight value is used for any RLOC,
then all RLOCs must use a non-zero weight value and then the sum then all RLOCs must use a non-zero weight value and then the sum
of all weight values MUST equal 100. If a zero value is used for of all weight values MUST equal 100. If a zero value is used for
any RLOC weight, then all weights MUST be zero and the receiver of any RLOC weight, then all weights MUST be zero and the receiver of
the Map-Reply will decide how to distribute multicast state across the Map-Reply will decide how to distribute multicast state across
ITRs. ITRs.
Unused Flags: set to 0 when sending and ignored on receipt. Unused Flags: set to 0 when sending and ignored on receipt.
R: when this bit is set, the locator is known to be reachable from R: when this bit is set, the locator is known to be reachable from
the Map-Reply sender's perspective. When there is a single the Map-Reply sender's perspective.
mapping record in the message, the R-bit for each locator must
have a consistent setting with the bitfield setting of the 'Loc
Reach Bits' field in the early part of the header. When there are
multiple mapping records in the message, the 'Loc Reach Bits'
field is set to 0.
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 or router acting as a proxy replier for the assigned to an ETR or router acting as a proxy replier for the
EID-prefix. Note that the destination RLOC address MAY be an EID-prefix. Note that the destination RLOC address MAY be an
anycast address. A source RLOC can be an anycast address as well. anycast address. A source RLOC can be an anycast address as well.
The source or destination RLOC MUST NOT be the broadcast address The source or destination RLOC MUST NOT be the broadcast address
(255.255.255.255 or any subnet broadcast address known to the (255.255.255.255 or any subnet broadcast address known to the
router), and MUST NOT be a link-local multicast address. 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
skipping to change at page 32, line 6 skipping to change at page 32, line 48
Map-Reply records can have an empty locator-set. This type of a Map- Map-Reply records can have an empty locator-set. This type of a Map-
Reply is called a Negative Map-Reply. Negative Map-Replies convey Reply is called a Negative Map-Reply. Negative Map-Replies convey
special actions by the sender to the ITR or PTR which have solicited special actions by the sender to the ITR or PTR which have solicited
the Map-Reply. There are two primary applications for Negative Map- the Map-Reply. There are two primary applications for Negative Map-
Replies. The first is for a Map-Resolver to instruct an ITR or PTR Replies. The first is for a Map-Resolver to instruct an ITR or PTR
when a destination is for a LISP site versus a non-LISP site. And when a destination is for a LISP site versus a non-LISP site. And
the other is to source quench Map-Requests which are sent for non- the other is to source quench Map-Requests which are sent for non-
allocated EIDs. allocated EIDs.
For each Map-Reply record, the list of locators in a locator-set MUST
appear in the same order for each ETR that originates a Map-Reply
message. The locator-set MUST be sorted in order of ascending IP
address where an IPv4 locator address is considered numerically 'less
than' an IPv6 locator addresss.
6.1.6. Map-Register Message Format 6.1.6. Map-Register Message Format
The usage details of the Map-Register message can be found in The usage details of the Map-Register message can be found in
specification [LISP-MS]. This section solely defines the message specification [LISP-MS]. This section solely defines the message
format. format.
The message is sent in a UDP with a destination UDP port 4342 and a The message is sent in a UDP with a destination UDP port 4342 and a
randomly selected UDP port number. Before an IPv4 or IPv6 network randomly selected UDP port number. Before an IPv4 or IPv6 network
layer header is prepended, an AH header is prepended to carry layer header is prepended, an AH header is prepended to carry
authentication information. The format conforms to the IPsec authentication information. The format conforms to the IPsec
skipping to change at page 33, line 8 skipping to change at page 34, line 8
The Next Header field is set to UDP. The SPI field is set to 0 The Next Header field is set to UDP. The SPI field is set to 0
(since no Security Association or Key Exchange protocol is being (since no Security Association or Key Exchange protocol is being
used). The Sequence Number is a randomly chosen value by the sender. used). The Sequence Number is a randomly chosen value by the sender.
The Authentication Data is 16 bytes and holds a MD5 HMAC. The Authentication Data is 16 bytes and holds a MD5 HMAC.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locator Reach Bits | |Type=3 |P| Reserved | Record Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 |P| Reserved | Record Count |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len |A| ACT | Reserved | R | Locator Count | EID mask-len |A| ACT | Reserved |
e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ e +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
c | Reserved | EID-AFI | c | Reserved | EID-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 |R| Loc-AFI | | o | Unused Flags |R| Loc-AFI |
| c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | c +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| \| Locator | | \| Locator |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Packet field descriptions: Packet field descriptions:
Locator Reach Bits: Refer to Section 5.3. This field MUST be set to
0 on transmission and ignored on receipt. The locator
reachability is encoded as the R-bit in each locator entry of each
EID-prefix record.
Nonce: The Nonce field is set to 0 in Map-Register messages.
Type: 3 (Map-Register) Type: 3 (Map-Register)
P: Set to 1 by an ETR which sends a Map-Register message requesting P: Set to 1 by an ETR which sends a Map-Register message requesting
for the Map-Server to proxy Map-Reply. The Map-Server will send for the Map-Server to proxy Map-Reply. The Map-Server will send
non-authoritative Map-Replies on behalf of the ETR. Details on non-authoritative Map-Replies on behalf of the ETR. Details on
this usage will be provided in a future version of this draft. this usage will be provided in a future version of this draft.
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 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: The Nonce field is set to 0 in Map-Register messages.
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.2. Routing Locator Selection 6.2. Routing Locator Selection
Both client-side and server-side may need control over the selection Both client-side and server-side may need control over the selection
of RLOCs for conversations between them. This control is achieved by of RLOCs for conversations between them. This control is achieved by
manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply manipulating the Priority and Weight fields in EID-to-RLOC Map-Reply
messages. Alternatively, RLOC information may be gleaned from messages. Alternatively, RLOC information may be gleaned from
received tunneled packets or EID-to-RLOC Map-Request messages. received tunneled packets or EID-to-RLOC Map-Request messages.
skipping to change at page 37, line 34 skipping to change at page 38, line 26
6.3.1. Echo Nonce Algorithm 6.3.1. Echo Nonce Algorithm
When there is bidirectional data flow between a pair of locators, a When there is bidirectional data flow between a pair of locators, a
simple mechanism called "nonce echoing" can be used to determine simple mechanism called "nonce echoing" can be used to determine
reachability between an ITR and ETR. When an ITR wants to solicit a reachability between an ITR and ETR. When an ITR wants to solicit a
nonce echo, it sets the E-bit and places a 24-bit nonce in the LISP nonce echo, it sets the E-bit and places a 24-bit nonce in the LISP
header of the next encapsulated data packet. 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. The ITR sees this "echo ITR, it includes the nonce received earlier with the E-bit cleared.
nonce reply" and knows the path to and from the ETR is up. The ITR sees this "echoed nonce" and knows the path to and from the
ETR is up.
The time the ITR waits for the echoed nonce before it determines the The ITR will set the E-bit for every packet it sends while in echo-
path is down is variable and a choice left for the implementation. nonce-request state. The time the ITR waits to process the echoed
nonce before it determines the path is unreachable is variable and a
choice left for the implementation.
If the ITR is receiving packets from the ETR but does not see the If the ITR is receiving packets from the ETR but does not see the
nonce echoed, then the path to the ETR is down. This decision may be nonce echoed while being in echo-nonce-request state, then the path
overridden by other locator reachability algorithms. Once the ITR to the ETR is unreachable. This decision may be overridden by other
determines the path to the ETR is down it can switch to another locator reachability algorithms. Once the ITR determines the path to
locator for that EID-prefix. the ETR is down it can switch to another locator for that EID-prefix.
Note that "ITR" and "ETR" are relative terms here. Both devices must Note that "ITR" and "ETR" are relative terms here. Both devices must
be implementing both ITR and ETR functionality for the echo nonce be implementing both ITR and ETR functionality for the echo nonce
mechanism to operate. mechanism to operate.
The ITR and ETR may both go into echo-nonce-request state at the same The ITR and ETR may both go into echo-nonce-request state at the same
time. The number of packets sent or the time during which echo nonce time. The number of packets sent or the time during which echo nonce
requests are sent is an implementation specific setting. However, requests are sent is an implementation specific setting. However,
when an ITR is in echo-nonce-request state, it can echo the ETR's when an ITR is in echo-nonce-request state, it can echo the ETR's
nonce in the next packet that it encapsulates and then subsequently, nonce in the next set of packets that it encapsulates and then
continue sending echo-nonce-request packets. subsequently, continue sending echo-nonce-request packets.
This mechanism does not completely solve the forward path This mechanism does not completely solve the forward path
reachability problem as traffic may be unidirectional. That is, the reachability problem as traffic may be unidirectional. That is, the
ETR receiving traffic at a site may not may not be the same device as ETR receiving traffic at a site may not may not be the same device as
an ITR which transmits traffic from that site or the site to site an ITR which transmits traffic from that site or the site to site
traffic is unidirectional so there is no ITR returning traffic. traffic is unidirectional so there is no ITR returning traffic.
Note that other locator reachability mechanisms are being researched. Note that other locator reachability mechanisms are being researched
and can be used to compliment or even override the Echo Nonce
Algorithm.
6.4. Routing Locator Hashing 6.4. 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
skipping to change at page 62, line 27 skipping to change at page 63, line 27
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, Roger
Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland Jorgensen, Ran Atkinson, Stig Venaas, Iljitsch van Beijnum, Roland
Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian Bless, Dana Blair, Bill Lynch, Marc Woolward, Damien Saucez, Damian
Lezama, Attilla De Groot, Parantap Lahiri, and David Black. Lezama, Attilla De Groot, Parantap Lahiri, David Black, Roque
Gagliano, and Isidor Kouvelas.
In particular, we would like to thank Dave Meyer for his clever In particular, we would like to thank Dave Meyer for his clever
suggestion for the name "LISP". ;-) suggestion for the name "LISP". ;-)
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.
Authors' Addresses Authors' Addresses
 End of changes. 32 change blocks. 
110 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/