draft-ietf-lisp-00.txt   draft-ietf-lisp-01.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: November 27, 2009 D. Lewis Expires: November 29, 2009 D. Lewis
cisco Systems cisco Systems
May 26, 2009 May 28, 2009
Locator/ID Separation Protocol (LISP) Locator/ID Separation Protocol (LISP)
draft-ietf-lisp-00.txt draft-ietf-lisp-01.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 November 27, 2009. This Internet-Draft will expire on November 29, 2009.
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 31 skipping to change at page 2, line 31
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . 20 5.4. Dealing with Large Encapsulated Packets . . . . . . . . . 20
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 . . . . . . . . . 21 5.4.2. A Stateful Solution to MTU Handling . . . . . . . . . 22
6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 23 6. EID-to-RLOC Mapping . . . . . . . . . . . . . . . . . . . . . 23
6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 23 6.1. LISP IPv4 and IPv6 Control Plane Packet Formats . . . . . 23
6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 25 6.1.1. LISP Packet Type Allocations . . . . . . . . . . . . . 25
6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 25 6.1.2. Map-Request Message Format . . . . . . . . . . . . . . 25
6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 27 6.1.3. EID-to-RLOC UDP Map-Request Message . . . . . . . . . 27
6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 28 6.1.4. Map-Reply Message Format . . . . . . . . . . . . . . . 28
6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 30 6.1.5. EID-to-RLOC UDP Map-Reply Message . . . . . . . . . . 31
6.1.6. Map-Register Message Format . . . . . . . . . . . . . 31 6.1.6. Map-Register Message Format . . . . . . . . . . . . . 32
6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 33 6.2. Routing Locator Selection . . . . . . . . . . . . . . . . 34
6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 34 6.3. Routing Locator Reachability . . . . . . . . . . . . . . . 35
6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 37 6.4. Routing Locator Hashing . . . . . . . . . . . . . . . . . 37
6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 37 6.5. Changing the Contents of EID-to-RLOC Mappings . . . . . . 38
6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 38 6.5.1. Clock Sweep . . . . . . . . . . . . . . . . . . . . . 39
6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 39 6.5.2. Solicit-Map-Request (SMR) . . . . . . . . . . . . . . 39
7. Router Performance Considerations . . . . . . . . . . . . . . 41 7. Router Performance Considerations . . . . . . . . . . . . . . 41
8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 42 8. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 42
8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 43 8.1. First-hop/Last-hop Tunnel Routers . . . . . . . . . . . . 43
8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 43 8.2. Border/Edge Tunnel Routers . . . . . . . . . . . . . . . . 43
8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 44 8.3. ISP Provider-Edge (PE) Tunnel Routers . . . . . . . . . . 44
9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 45 9. Traceroute Considerations . . . . . . . . . . . . . . . . . . 45
9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 46 9.1. IPv6 Traceroute . . . . . . . . . . . . . . . . . . . . . 46
9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 46 9.2. IPv4 Traceroute . . . . . . . . . . . . . . . . . . . . . 46
9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 46 9.3. Traceroute using Mixed Locators . . . . . . . . . . . . . 46
10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 48 10. Mobility Considerations . . . . . . . . . . . . . . . . . . . 48
10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 48 10.1. Site Mobility . . . . . . . . . . . . . . . . . . . . . . 48
10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 48 10.2. Slow Endpoint Mobility . . . . . . . . . . . . . . . . . . 48
10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 48 10.3. Fast Endpoint Mobility . . . . . . . . . . . . . . . . . . 48
10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 50 10.4. Fast Network Mobility . . . . . . . . . . . . . . . . . . 50
11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 51 11. Multicast Considerations . . . . . . . . . . . . . . . . . . . 51
12. Security Considerations . . . . . . . . . . . . . . . . . . . 52 12. Security Considerations . . . . . . . . . . . . . . . . . . . 52
13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 53 13. Prototype Plans and Status . . . . . . . . . . . . . . . . . . 53
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14.1. Normative References . . . . . . . . . . . . . . . . . . . 55 14.1. Normative References . . . . . . . . . . . . . . . . . . . 56
14.2. Informative References . . . . . . . . . . . . . . . . . . 56 14.2. Informative References . . . . . . . . . . . . . . . . . . 57
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 59 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 60
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 61
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 8, line 47 skipping to change at page 8, line 47
today, for example through a DNS lookup or SIP exchange. The today, for example through a DNS lookup or SIP exchange. The
source EID is obtained via existing mechanisms used to set a source EID is obtained via existing mechanisms used to set a
host's "local" IP address. An EID is allocated to a host from an host's "local" IP address. An EID is allocated to a host from an
EID-prefix block associated with the site where the host is EID-prefix block associated with the site where the host is
located. An EID can be used by a host to refer to other hosts. located. An EID can be used by a host to refer to other hosts.
EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be
assigned in a hierarchical manner, independent of the network assigned in a hierarchical manner, independent of the network
topology, to facilitate scaling of the mapping database. In topology, to facilitate scaling of the mapping database. In
addition, an EID block assigned to a site may have site-local addition, an EID block assigned to a site may have site-local
structure (subnetting) for routing within the site; this structure structure (subnetting) for routing within the site; this structure
is not visible to the global routing system. is not visible to the global routing system. When used in
discussions with other Locator/ID separation proposals, a LISP EID
will be called a "LEID". Throughout this document, any references
to "EID" refers to an LEID.
EID-prefix: A power-of-2 block of EIDs which are allocated to a EID-prefix: A power-of-2 block of EIDs which are allocated to a
site by an address allocation authority. EID-prefixes are site by an address allocation authority. EID-prefixes are
associated with a set of RLOC addresses which make up a "database associated with a set of RLOC addresses which make up a "database
mapping". EID-prefix allocations can be broken up into smaller mapping". EID-prefix allocations can be broken up into smaller
blocks when an RLOC set is to be associated with the smaller EID- blocks when an RLOC set is to be associated with the smaller EID-
prefix. A globally routed address block (whether PI or PA) is not prefix. A globally routed address block (whether PI or PA) is not
an EID-prefix. However, a globally routed address block may be an EID-prefix. However, a globally routed address block may be
removed from global routing and reused as an EID-prefix. A site removed from global routing and reused as an EID-prefix. A site
that receives an explicitly allocated EID-prefix may not use that that receives an explicitly allocated EID-prefix may not use that
skipping to change at page 11, line 14 skipping to change at page 11, line 18
Address Family Indicator (AFI): a term used to describe an address Address Family Indicator (AFI): a term used to describe an address
encoding in a packet. An address family currently pertains to an encoding in a packet. An address family currently pertains to an
IPv4 or IPv6 address. See [AFI] for details. IPv4 or IPv6 address. See [AFI] for details.
Negative Mapping Entry: also known as a negative cache entry, is an Negative Mapping Entry: also known as a negative cache entry, is an
EID-to-RLOC entry where an EID-prefix is advertised or stored with EID-to-RLOC entry where an EID-prefix is advertised or stored with
no RLOCs. That is, the locator-set for the EID-to-RLOC entry is no RLOCs. That is, the locator-set for the EID-to-RLOC entry is
empty or has an encoded locator count of 0. This type of entry empty or has an encoded locator count of 0. This type of entry
could be used to describe a prefix from a non-LISP site, which is could be used to describe a prefix from a non-LISP site, which is
explicitly not in the mapping database. explicitly not in the mapping database. There are a set of well
defined actions that are encoded in a Negative Map-Reply.
Data Probe: a LISP-encapsulated data packet where the inner header Data Probe: a LISP-encapsulated data packet where the inner header
destination address equals the outer header destination address destination address equals the outer header destination address
used to trigger a Map-Reply by a decapsulating ETR. In addition, used to trigger a Map-Reply by a decapsulating ETR. In addition,
the original packet is decapsulated and delivered to the the original packet is decapsulated and delivered to the
destination host. A Data Probe is used in some of the mapping destination host. A Data Probe is used in some of the mapping
database designs to "probe" or request a Map-Reply from an ETR; in database designs to "probe" or request a Map-Reply from an ETR; in
other cases, Map-Requests are used. See each mapping database other cases, Map-Requests are used. See each mapping database
design for details. design for details.
skipping to change at page 19, line 21 skipping to change at page 19, line 21
5.3. Tunnel Header Field Descriptions 5.3. Tunnel Header Field Descriptions
IH Header: is the inner header, preserved from the datagram received IH Header: is the inner header, preserved from the datagram received
from the originating host. The source and destination IP from the originating host. The source and destination IP
addresses are EIDs. addresses are EIDs.
OH Header: is the outer header prepended by an ITR. The address OH Header: is the outer header prepended by an ITR. The address
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.
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 field MUST be transmitted as 0 and ignored
on receipt by the ETR. Note, even when the UDP checksum is on 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
skipping to change at page 20, line 25 skipping to change at page 20, line 26
encapsulated data packets with the SMR bit set, Data-Probe, Map- encapsulated data packets with the SMR bit set, Data-Probe, Map-
Request, or Map-Reply messages. Request, or Map-Reply messages.
When doing Recursive Tunneling: When doing Recursive Tunneling:
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. Service field (with one caveat, see below).
When doing Re-encapsulated Tunneling: When doing Re-encapsulated Tunneling:
o The new OH header Time to Live field SHOULD be copied from the o The new OH header Time to Live field SHOULD be copied from the
stripped OH header Time to Live field. stripped OH header Time to Live field.
o The new OH header Type of Service field SHOULD be copied from the o The new OH header Type of Service field SHOULD be copied from the
stripped OH header Type of Service field. stripped OH header Type of Service field (with one caveat, see
below)..
Copying the TTL serves two purposes: first, it preserves the distance Copying the TTL serves two purposes: first, it preserves the distance
the host intended the packet to travel; second, and more importantly, the host intended the packet to travel; second, and more importantly,
it provides for suppression of looping packets in the event there is it provides for suppression of looping packets in the event there is
a loop of concatenated tunnels due to misconfiguration. a loop of concatenated tunnels due to misconfiguration.
When the Type of Service code-points indicate the use of ECN
according to [RFC3168], the full-functionality option for simple
tunnels will be used when ITR encapsulating and ETR decapsulating.
Therefore, the Congestion Experience (CE) bit will be preserved when
a packet traveres a LISP tunnel.
5.4. Dealing with Large Encapsulated Packets 5.4. Dealing with Large Encapsulated Packets
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
skipping to change at page 21, line 40 skipping to change at page 21, line 47
site. The two fragments are reassembled at the destination host into site. The two fragments are reassembled at the destination host into
the single IP datagram that was originated by the source host. the single IP datagram that was originated by the source host.
This behavior is performed by the ITR when the source host originates This behavior is performed by the ITR when the source host originates
a packet with the DF field of the IP header is set to 0. When the DF a packet with the DF field of the IP header is set to 0. When the DF
field of the IP header is set to 1, or the packet is an IPv6 packet field of the IP header is set to 1, or the packet is an IPv6 packet
originated by the source host, the ITR will drop the packet when the originated by the source host, the ITR will drop the packet when the
size is greater than L, and sends an ICMP Too Big message to the size is greater than L, and sends an ICMP Too Big message to the
source with a value of S, where S is (L - H). source with a value of S, where S is (L - H).
When the outer header encapsulation uses an IPv4 header the DF bit is
always set to 0.
This specification recommends that L be defined as 1500. This specification recommends that L be defined as 1500.
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 exceeds what the core network can 2. When an encapsulated packet, with DF bit always set to 0, exceeds
deliver, one of the intermediate routers on the path will send an what the core network can deliver, one of the intermediate
ICMP Too Big message to the ITR. The ITR will parse the ICMP routers on the path will send an ICMP Too Big message to the ITR.
message to determine which locator is affected by the effective The ITR will parse the ICMP message to determine which locator is
MTU change and then record the new effective MTU value in the affected by the effective MTU change and then record the new
mapping cache entry. 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 27, line 37 skipping to change at page 27, line 37
packet which had a mapping cache lookup failure. For the later 2 packet which had a mapping cache lookup failure. For the later 2
cases, the destination IP address used for the Map-Request is one of cases, the destination IP address used for the Map-Request is one of
the RLOC addresses from the locator-set of the map cache entry. In the RLOC addresses from the locator-set of the map cache entry. In
all cases, the UDP source port number for the Map-Request message is all cases, the UDP source port number for the Map-Request message is
a randomly allocated 16-bit value and the UDP destination port number a randomly allocated 16-bit value and the UDP destination port number
is set to the well-known destination port number 4342. A successful is set to the well-known destination port number 4342. A successful
Map-Reply updates the cached set of RLOCs associated with the EID Map-Reply updates the cached set of RLOCs associated with the EID
prefix range. prefix range.
Map-Requests can also be LISP encapsulated using UDP destination port Map-Requests can also be LISP encapsulated using UDP destination port
4341 when sent from an ITR to a Map-Resolver. Details on 4341 when sent from an ITR to a Map-Resolver. Likewise, Map-Requests
encapsulated Map-Reqeusts and Map-Resolvers can be found in are LISP encapsulated the same way from a Map-Server to an ETR.
[LISP-MS]. Details on encapsulated Map-Requests and Map-Resolvers can be found
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x| Locator Reach Bits | |x| Locator Reach Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=2 | Reserved | Record Count | |Type=2 | Reserved | Record Count |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len |A| 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 |
skipping to change at page 29, line 24 skipping to change at page 29, line 24
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.
A: The Authoritative bit, when sent by a UDP-based message is always A: The Authoritative bit, when sent by a UDP-based message is always
set by the ETR. See [CONS] for TCP-based Map-Replies. set by the ETR. See [CONS] for TCP-based Map-Replies.
ACT: This 3-bit field describes negative Map-Reply actions. These
bits are used only when the 'Locator Count' field is set to 0.
The action bits are encoded only in Map-Reply messages. The
actions defined are used by an ITR or PTR when a destination EID
matches a negative mapping cache entry. The current assigned
values are:
(0) No action: No action is being conveyed by the sender of the
Map-Reply message.
(1) Natively-Forward: The packet is not encapsulated or dropped
but natively forwarded.
(2) Drop: The packet is dropped silently.
(3) Send-Map-Request: The packet invokes sending a Map-Request.
EID-AFI: Address family of EID-prefix according to [RFC2434]. EID-AFI: Address family of EID-prefix according to [RFC2434].
EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6 EID-prefix: 4 bytes if an IPv4 address-family, 16 bytes if an IPv6
address-family. address-family.
Priority: each RLOC is assigned a unicast priority. Lower values Priority: each RLOC is assigned a unicast priority. Lower values
are more preferable. When multiple RLOCs have the same priority, are more preferable. When multiple RLOCs have the same priority,
they may be used in a load-split fashion. A value of 255 means they may be used in a load-split fashion. A value of 255 means
the RLOC MUST NOT be used for unicast forwarding. the RLOC MUST NOT be used for unicast forwarding.
skipping to change at page 31, line 26 skipping to change at page 31, line 45
expected that aggregation of EID addresses into EID-prefixes will expected that aggregation of EID addresses into EID-prefixes will
allow one Map-Reply to satisfy a mapping for the EID addresses in the allow one Map-Reply to satisfy a mapping for the EID addresses in the
prefix range thereby reducing the number of Map-Request messages. prefix range thereby reducing the number of Map-Request messages.
The addresses for a encapsulated data packets or Map-Request message The addresses for a encapsulated data packets or Map-Request message
are swapped and used for sending the Map-Reply. The UDP source and are swapped and used for sending the Map-Reply. The UDP source and
destination ports are swapped as well. That is, the source port in destination ports are swapped as well. That is, the source port in
the UDP header for the Map-Reply is set to the well-known UDP port the UDP header for the Map-Reply is set to the well-known UDP port
number 4342. number 4342.
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
special actions by the sender to the ITR or PTR which have solicited
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
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-
allocated EIDs.
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
specification [RFC2402]. The Map-Regiter message will use transport specification [RFC2402]. The Map-Register message will use transport
mode by setting the IP protocol number field or the IPv6 next-header mode by setting the IP protocol number field or the IPv6 next-header
field to 51. field to 51.
The AH header from [RFC2402] is: The AH header from [RFC2402] 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Header | Payload Len | RESERVED | | Next Header | Payload Len | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 32, line 21 skipping to change at page 32, line 38
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number Field | | Sequence Number Field |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ Authentication Data (variable) | + Authentication Data (variable) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Sequece 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x| Locator Reach Bits | |x| Locator Reach Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Nonce | | Nonce |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=3 | Reserved | Record Count | |Type=3 |P| Reserved | Record Count |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Record TTL | | | Record TTL |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
R | Locator Count | EID mask-len |A| 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 |
+-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The definition of each field of the Map-Register can be found in the Packet field descriptions:
x: Set to 0 on transmission and ignored on receipt.
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)
P: This is the Proxy-Map-Reply bit. When set to 1, the ETR sending a
Map-Register is asking the Map-Server to send non-authoritative
Map-Replies on behalf of the ETR.
Reserved: Set to 0 on transmission and ignored on receipt.
Record Count: The number of records in this Map-Register message. A
record is comprised of that portion of the packet labeled 'Record'
above and occurs the number of times equal to Record count.
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 54, line 43 skipping to change at page 54, line 43
to http://www.lisp4.net to see translation happening in action to http://www.lisp4.net to see translation happening in action
so your non-LISP site can access a web server in a LISP site. so your non-LISP site can access a web server in a LISP site.
7. Soon http://www.lisp6.net will work where your IPv6 LISP site 7. Soon http://www.lisp6.net will work where your IPv6 LISP site
can talk to a IPv6 web server in a LISP site by using mixed can talk to a IPv6 web server in a LISP site by using mixed
address-family based locators. address-family based locators.
8. An public domain implementation of LISP is underway. See 8. An public domain implementation of LISP is underway. See
[OPENLISP] for details. [OPENLISP] for details.
9. We have started deploying Map-Resolvers and Map-Servers on the 9. We have deployed Map-Resolvers and Map-Servers on the LISP pilot
pilot network to gather experience with [LISP-MS]. network to gather experience with [LISP-MS]. The first layer of
the architecture are the xTRs which use Map-Servers for EID-
prefix registration and Map-Resolvers for EID-to-RLOC mapping
resolution. The second layer are the Map-Resolvers and Map-
Servers which connect to the ALT BGP peering infrastructure.
And the third layer are ALT-routers which aggregate EID-prefixes
and forward Map-Requests.
10. A cisco IOS implementation is underway which currently supports 10. A cisco IOS implementation is underway which currently supports
IPv4 encapsulation and decapsulation features. IPv4 encapsulation and decapsulation features.
11. A LISP router based LIG implementation is supported, deployed,
and used daily to debug and test the LISP pilot network. See
[LIG] for details.
12. A Linux implementation of LIG has been made available and
supported by Dave Meyer. It can be run on any Linux system
which resides in either a LISP site or non-LISP site. See [LIG]
for details.
If interested in writing a LISP implementation, testing any of the If interested in writing a LISP implementation, testing any of the
LISP implementations, or want to be part of the LISP pilot program, LISP implementations, or want to be part of the LISP pilot program,
please contact lisp@ietf.org. please contact lisp@ietf.org.
14. References 14. References
14.1. Normative References 14.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.
skipping to change at page 55, line 38 skipping to change at page 56, line 38
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001. via IPv4 Clouds", RFC 3056, February 2001.
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP",
RFC 3168, September 2001.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route [RFC4866] Arkko, J., Vogt, C., and W. Haddad, "Enhanced Route
Optimization for Mobile IPv6", RFC 4866, May 2007. Optimization for Mobile IPv6", RFC 4866, May 2007.
[RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", RFC 4984, Workshop on Routing and Addressing", RFC 4984,
September 2007. September 2007.
14.2. Informative References 14.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-fuller-lisp-alt-03.txt (work in progress), draft-ietf-lisp-alt-01.txt (work in progress), May 2009.
February 2009.
[APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and [APT] Jen, D., Meisel, M., Massey, D., Wang, L., Zhang, B., and
L. Zhang, "APT: A Practical Transit Mapping Service", L. Zhang, "APT: A Practical Transit Mapping Service",
draft-jen-apt-01.txt (work in progress), November 2007. draft-jen-apt-01.txt (work in progress), November 2007.
[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.
skipping to change at page 56, line 39 skipping to change at page 57, line 39
[DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing [DHTs] Ratnasamy, S., Shenker, S., and I. Stoica, "Routing
Algorithms for DHTs: Some Open Questions", PDF Algorithms for DHTs: Some Open Questions", PDF
file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf. file http://www.cs.rice.edu/Conferences/IPTPS02/174.pdf.
[GSE] "GSE - An Alternate Addressing Architecture for IPv6", [GSE] "GSE - An Alternate Addressing Architecture for IPv6",
draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997. draft-ietf-ipngwg-gseaddr-00.txt (work in progress), 1997.
[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-lewis-lisp-interworking-01.txt (work in progress), draft-ietf-lisp-interworking-00.txt (work in progress),
January 2009. January 2009.
[LIG] Farinacci, D. and D. Meyer, "LISP Internet Groper (LIG)",
draft-farinacci-lisp-lig-01.txt (work in progress),
May 2009.
[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-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-MS] Farinacci, D. and V. Fuller, "LISP Map Server", [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
draft-fuller-lisp-ms-00.txt (work in progress), draft-ietf-lisp-ms-01.txt (work in progress), May 2009.
March 2009.
[LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, [LISP1] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP1) [Routable ID "Locator/ID Separation Protocol (LISP1) [Routable ID
Version]", Version]",
Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt, Slide-set http://www.dinof.net/~dino/ietf/lisp1.ppt,
October 2006. October 2006.
[LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller, [LISP2] Farinacci, D., Oran, D., Fuller, V., and J. Schiller,
"Locator/ID Separation Protocol (LISP2) [DNS-based "Locator/ID Separation Protocol (LISP2) [DNS-based
Version]", Version]",
skipping to change at page 57, line 31 skipping to change at page 58, line 35
February 2008. February 2008.
[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-00.txt (work in progress), draft-ietf-lisp-multicast-01.txt (work in progress),
May 2009. May 2009.
[NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", [NERD] Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
draft-lear-lisp-nerd-04.txt (work in progress), draft-lear-lisp-nerd-04.txt (work in progress),
April 2008. April 2008.
[OPENLISP] [OPENLISP]
Iannone, L. and O. Bonaventure, "OpenLISP Implementation Iannone, L. and O. Bonaventure, "OpenLISP Implementation
Report", draft-iannone-openlisp-implementation-01.txt Report", draft-iannone-openlisp-implementation-01.txt
(work in progress), July 2008. (work in progress), July 2008.
skipping to change at page 59, line 27 skipping to change at page 60, 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, and Parantap Lahiri. Lezama, Attilla De Groot, Parantap Lahiri, and David Black.
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. 34 change blocks. 
44 lines changed or deleted 130 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/