draft-ietf-lisp-lig-03.txt   draft-ietf-lisp-lig-04.txt 
Network Working Group D. Farinacci Network Working Group D. Farinacci
Internet-Draft D. Meyer Internet-Draft D. Meyer
Intended status: Experimental cisco Systems Intended status: Experimental cisco Systems
Expires: January 10, 2012 July 9, 2011 Expires: February 11, 2012 August 10, 2011
LISP Internet Groper (LIG) LISP Internet Groper (LIG)
draft-ietf-lisp-lig-03 draft-ietf-lisp-lig-04
Abstract Abstract
A simple tool called the LISP Internet Groper or 'lig' can be used to A simple tool called the LISP Internet Groper or 'lig' can be used to
query the LISP mapping database. This draft describes how it works. query the LISP mapping database. This draft describes how it works.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 31 skipping to change at page 1, line 31
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 10, 2012. This Internet-Draft will expire on February 11, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4
3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 3. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Implementation Details . . . . . . . . . . . . . . . . . . . . 9
5. Implementation Details . . . . . . . . . . . . . . . . . . . . 9 4.1. LISP Router Implementation . . . . . . . . . . . . . . . . 9
5.1. LISP Router Implementation . . . . . . . . . . . . . . . . 9 4.2. Public Domain Host Implementation . . . . . . . . . . . . 10
5.2. Public Domain Host Implementation . . . . . . . . . . . . 10 5. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 12
6. Testing the ALT . . . . . . . . . . . . . . . . . . . . . . . 12 6. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 13
7. Future Enhancements . . . . . . . . . . . . . . . . . . . . . 13 7. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 14
8. Deployed Network Diagnostic Tools . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 10.2. Informative References . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Requirements Notation 1. Introduction
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Introduction
LISP [LISP] specifies an architecture and mechanism for replacing the LISP [LISP] specifies an architecture and mechanism for replacing the
addresses currently used by IP with two separate name spaces: addresses currently used by IP with two separate name spaces:
Endpoint IDS (EIDs), used within sites, and Routing Locators (RLOCs), Endpoint IDS (EIDs), used within sites, and Routing Locators (RLOCs),
used on the transit networks that make up the Internet used on the transit networks that make up the Internet
infrastructure. To achieve this separation, the Locator/ID infrastructure. To achieve this separation, the Locator/ID
Separation Protocol (LISP) defines protocol mechanisms for mapping Separation Protocol (LISP) defines protocol mechanisms for mapping
from EIDs to RLOCs. In addition, LISP assumes the existence of a from EIDs to RLOCs. In addition, LISP assumes the existence of a
database to store and propagate those mappings globally. Several database to store and propagate those mappings globally. Several
such databases have been proposed, among them: LISP-CONS [CONS], such databases have been proposed, among them: LISP-CONS [CONS],
LISP-NERD [NERD], and LISP+ALT [ALT], with LISP+ALT being the system LISP-NERD [NERD], and LISP+ALT [ALT], with LISP+ALT being the system
that is currently being implemented and deployed on the pilot LISP that is currently being implemented and deployed on the pilot LISP
network. network.
In conjunction with the various mapping systems, there exists a In conjunction with the various mapping systems, there exists a
network based API called LISP Map-Server [LISP-MS]. Using Map network based API called LISP Map-Server [LISP-MS]. Using Map
Resolvers and Map Servers allows LISP sites to query and register Resolvers and Map Servers allows LISP sites to query and register
into the database in a uniform way independent of the mapping system into the database in a uniform way independent of the mapping system
used. Sending Map-Requests to Map Resolvers provides a secure used. Sending Map-Requests to Map Resolvers provides a secure
mechanism mechanism to obtain a Map-Reply containing the mechanism to obtain a Map-Reply containing the authoritative EID-to-
authoritative EID-to-RLOC mapping for a destination LISP site. RLOC mapping for a destination LISP site.
The 'lig' is a manual management tool to query the mapping database. The 'lig' is a manual management tool to query the mapping database.
It can be run by all devices which implement LISP, including ITRs, It can be run by all devices which implement LISP, including ITRs,
ETRs, PTR, Map-Resolvers, Map-Servers, and LISP-ALT routers, as well ETRs, PTR, Map-Resolvers, Map-Servers, and LISP-ALT routers, as well
as by a host system at either a LISP-capable or non-LISP-capable as by a host system at either a LISP-capable or non-LISP-capable
site. site.
3. Definition of Terms 2. Definition of Terms
Map-Server: a network infrastructure component which learns EID-to- Map-Server: a network infrastructure component which learns EID-to-
RLOC mapping entries from an authoritative source (typically, an RLOC mapping entries from an authoritative source (typically, an
ETR, though static configuration or another out-of-band mechanism ETR, though static configuration or another out-of-band mechanism
may be used). A Map-Server advertises these mappings in the may be used). A Map-Server advertises these mappings in the
distributed mapping database. distributed mapping database.
Map-Resolver: a network infrastructure component which accepts LISP Map-Resolver: a network infrastructure component which accepts LISP
Encapsulated Map-Requests, typically from an ITR, quickly Encapsulated Map-Requests, typically from an ITR, quickly
determines whether or not the destination IP address is part of determines whether or not the destination IP address is part of
skipping to change at page 5, line 40 skipping to change at page 4, line 40
Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value Endpoint ID (EID): a 32-bit (for IPv4) or 128-bit (for IPv6) value
used in the source and destination address fields of the first used in the source and destination address fields of the first
(most inner) LISP header of a packet. The host obtains a (most inner) LISP header of a packet. The host obtains a
destination EID the same way it obtains an destination address destination EID the same way it obtains an destination address
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.
EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that EID-to-RLOC Cache: a short-lived, on-demand table in an ITR that
stores, tracks, and is responsible for timing-out and otherwise stores, tracks, and is responsible for timing-out and otherwise
validating EID-to-RLOC mappings. This cache is distinct from the validating EID-to-RLOC mappings. This cache is distinct from the
full "database" of EID-to-RLOC mappings, it is dynamic, local to full "database" of EID-to-RLOC mappings, it is dynamic, local to
skipping to change at page 6, line 21 skipping to change at page 5, line 21
Encapsulated Map-Request (EMR): an EMR is a Map-Request message Encapsulated Map-Request (EMR): an EMR is a Map-Request message
which is encapsulated with another LISP header using UDP which is encapsulated with another LISP header using UDP
destination port number 4341. It is used so an ITR, PTR, or a destination port number 4341. It is used so an ITR, PTR, or a
system initiating a 'lig' command can get the Map-Request to a system initiating a 'lig' command can get the Map-Request to a
Map-Resolver by using locater addresses. When the Map-Request is Map-Resolver by using locater addresses. When the Map-Request is
decapsulated by the Map-Resolver it will be forwarded on the ALT decapsulated by the Map-Resolver it will be forwarded on the ALT
network to the Map-Server that has injected the EID-prefix for a network to the Map-Server that has injected the EID-prefix for a
registered site. The Map-Server will then encapsulate the Map- registered site. The Map-Server will then encapsulate the Map-
Request in a LISP packet and send it to an an ETR at the site. Request in a LISP packet and send it to an an ETR at the site.
The ETR will then return an authoritative reply to the system that The ETR will then return an authoritative reply to the system that
initiated the request. initiated the request. See [LISP] for packet format details.
4. Basic Overview Ingress Tunnel Router (ITR): An ITR is a router which accepts an IP
packet with a single IP header (more precisely, an IP packet that
does not contain a LISP header). The router treats this "inner"
IP destination address as an EID and performs an EID-to-RLOC
mapping lookup. The router then prepends an "outer" IP header
with one of its globally-routable RLOCs in the source address
field and the result of the mapping lookup in the destination
address field. Note that this destination RLOC may be an
intermediate, proxy device that has better knowledge of the EID-
to-RLOC mapping closer to the destination EID. In general, an ITR
receives IP packets from site end-systems on one side and sends
LISP-encapsulated IP packets toward the Internet on the other
side.
Egress Tunnel Router (ETR): An ETR is a router that accepts an IP
packet where the destination address in the "outer" IP header is
one of its own RLOCs. The router strips the "outer" header and
forwards the packet based on the next IP header found. In
general, an ETR receives LISP-encapsulated IP packets from the
Internet on one side and sends decapsulated IP packets to site
end-systems on the other side. ETR functionality does not have to
be limited to a router device. A server host can be the endpoint
of a LISP tunnel as well.
xTR: A xTR is a reference to an ITR or ETR when direction of data
flow is not part of the context description. xTR refers to the
router that is the tunnel endpoint. Used synonymously with the
term "Tunnel Router". For example, "An xTR can be located at the
Customer Edge (CE) router", meaning both ITR and ETR functionality
is at the CE router.
Provider Assigned (PA) Addresses: PA addresses are an a address
block assigned to a site by each service provider to which a site
connects. Typically, each block is sub-block of a service
provider Classless Inter-Domain Routing (CIDR) [RFC4632] block and
is aggregated into the larger block before being advertised into
the global Internet. Traditionally, IP multihoming has been
implemented by each multi-homed site acquiring its own, globally-
visible prefix. LISP uses only topologically-assigned and
aggregatable address blocks for RLOCs, eliminating this
demonstrably non-scalable practice.
3. Basic Overview
When the lig command is run, a Map-Request is sent for a destination When the lig command is run, a Map-Request is sent for a destination
EID. When a Map-Reply is returned, the contents are displayed to the EID. When a Map-Reply is returned, the contents are displayed to the
user. The information displayed includes: user. The information displayed includes:
o The EID-prefix for the site the queried destination EID matches. o The EID-prefix for the site the queried destination EID matches.
o The locator address of the Map Replier. o The locator address of the Map Replier.
o The locator-set for the mapping entry which includes the locator o The locator-set for the mapping entry which includes the locator
skipping to change at page 7, line 48 skipping to change at page 7, line 48
if a site has registered successfully with a Map-Server. if a site has registered successfully with a Map-Server.
The first usage has already been described. Verifying registration The first usage has already been described. Verifying registration
is called "ligging yourself". What occurs is in the lig initiator, a is called "ligging yourself". What occurs is in the lig initiator, a
Map-Request is sent for one of the EIDs for the lig initiator's site. Map-Request is sent for one of the EIDs for the lig initiator's site.
The Map-Request is then returned to one of the ETRs for the lig The Map-Request is then returned to one of the ETRs for the lig
initiating site. In response to the Map-Request, a Map-Reply is sent initiating site. In response to the Map-Request, a Map-Reply is sent
back to the locator address of the lig initiator (note the Map-Reply back to the locator address of the lig initiator (note the Map-Reply
could be sent by the lig initiator). That Map-Reply is processed and could be sent by the lig initiator). That Map-Reply is processed and
the mapping data for lig initiating site is displayed for the user. the mapping data for lig initiating site is displayed for the user.
Refer to the syntax in section Section 5.1 for an implementation of Refer to the syntax in section Section 4.1 for an implementation of
"ligging yourself". However, for host-based implementations within a "ligging yourself". However, for host-based implementations within a
LISP site, "lig self" is less useful since the host may not have an LISP site, "lig self" is less useful since the host may not have an
RLOC to receive a Map-Reply with. But, lig can be used in a non-LISP RLOC to receive a Map-Reply with. But, lig can be used in a non-LISP
site as well as from infrastructure hosts to get mapping information. site as well as from infrastructure hosts to get mapping information.
5. Implementation Details 4. Implementation Details
5.1. LISP Router Implementation 4.1. LISP Router Implementation
The cisco LISP prototype implementation has support for lig for IPv4 The cisco LISP prototype implementation has support for lig for IPv4
and IPv6. The command line description is: and IPv6. The command line description is:
lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>] lig <dest-eid> [source <source-eid>] [to <mr>] [count <1-5>]
This command initiates the LISP Internet Groper. It is similar to This command initiates the LISP Internet Groper. It is similar to
the DNS analogue 'dig' but works on the LISP mapping database. When the DNS analogue 'dig' but works on the LISP mapping database. When
this command is invoked, the local system will send a Map-Request to this command is invoked, the local system will send a Map-Request to
the configured Map-Resolver. When a Map-Reply is returned, its the configured Map-Resolver. When a Map-Reply is returned, its
skipping to change at page 10, line 33 skipping to change at page 10, line 33
Send loopback map-request to 10.0.0.1 for 192.168.2.0 ... Send loopback map-request to 10.0.0.1 for 192.168.2.0 ...
Received map-reply from 10.0.0.3 with rtt 0.001592 secs Received map-reply from 10.0.0.3 with rtt 0.001592 secs
Map-cache entry for EID 192.168.2.0: Map-cache entry for EID 192.168.2.0:
192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57 192.168.2.0/24, uptime: 00:00:02, expires: 23:59:57
via map-reply, self via map-reply, self
Locator Uptime State Priority/Weight Packets In/Out Locator Uptime State Priority/Weight Packets In/Out
10.0.0.3 00:00:02 up 1/100 0/0 10.0.0.3 00:00:02 up 1/100 0/0
titanium-simlo# lig self6 titanium-simlo# lig self6
Send loopback map-request to 10.0.0.1 for 192:168:1:: ... Send loopback map-request to 10.0.0.1 for 2001:db8:1:: ...
Received map-reply from 10::1 with rtt 0.044372 secs Received map-reply from 10::1 with rtt 0.044372 secs
Map-cache entry for EID 192:168:1::: Map-cache entry for EID 192:168:1:::
192:168:1::/48, uptime: 00:00:01, expires: 23:59:58 2001:db8:1::/48, uptime: 00:00:01, expires: 23:59:58
via map-reply, self via map-reply, self
Locator Uptime State Priority/Weight Packets In/Out Locator Uptime State Priority/Weight Packets In/Out
10.0.0.3 00:00:01 up 1/100 0/0 10.0.0.3 00:00:01 up 1/100 0/0
10::1 00:00:01 up 2/0 0/0 2001:db8:ffff::1 00:00:01 up 2/0 0/0
5.2. Public Domain Host Implementation 4.2. Public Domain Host Implementation
There is a public domain implementation that can run on any x86 based There is a public domain implementation that can run on any x86 based
system. The only requirement is that the system that initiates lig system. The only requirement is that the system that initiates lig
must have an address assigned from the locator namespace. must have an address assigned from the locator namespace.
lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>] lig [-d] <eid> -m <map-resolver> [-c <count>] [-t <timeout>]
Parameter description: Parameter description:
-d: prints additional protocol debug output. -d: prints additional protocol debug output.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
192.168.1.0/24, record ttl: 60 192.168.1.0/24, record ttl: 60
Locator State Priority/Weight Locator State Priority/Weight
10.0.0.1 up 1/25 10.0.0.1 up 1/25
10.0.0.2 up 1/25 10.0.0.2 up 1/25
10.0.0.3 up 1/25 10.0.0.3 up 1/25
10.0.0.4 up 2/25 10.0.0.4 up 2/25
The public domain implementation of lig is available at The public domain implementation of lig is available at
http://github.com/davidmeyer/lig. http://github.com/davidmeyer/lig.
6. Testing the ALT 5. Testing the ALT
There are cases where a Map-Reply is returned from a lig request but There are cases where a Map-Reply is returned from a lig request but
the user doesn't really know how much of the mapping infrastructure the user doesn't really know how much of the mapping infrastructure
was tested. There are two cases to consider, avoiding the ALT and was tested. There are two cases to consider, avoiding the ALT and
traversing the ALT. traversing the ALT.
When an ITR sends a lig request to its Map-Resolver for a When an ITR sends a lig request to its Map-Resolver for a
destination-EID, the Map-Resolver could also be configured as a Map- destination-EID, the Map-Resolver could also be configured as a Map-
Server. And if the destination-EID is for a site that registers with Server. And if the destination-EID is for a site that registers with
this Map-Server, the Map-Request is sent to the site directly without this Map-Server, the Map-Request is sent to the site directly without
skipping to change at page 13, line 5 skipping to change at page 13, line 5
glass" node. This type of router has BGP peering sessions with other glass" node. This type of router has BGP peering sessions with other
ALT routers where it does not inject any EID-prefixes into the ALT ALT routers where it does not inject any EID-prefixes into the ALT
but just learns ones advertised by other ALT routers and Map-Servers. but just learns ones advertised by other ALT routers and Map-Servers.
This router is configured as a Map-Resolver. Lig users can point to This router is configured as a Map-Resolver. Lig users can point to
the ALT looking-glass router for Map-Resolver services via the "to the ALT looking-glass router for Map-Resolver services via the "to
<map-resolver>" parameter on the lig command. The ALT looking-glass <map-resolver>" parameter on the lig command. The ALT looking-glass
node can be used to lig other sites as well as your own site. When node can be used to lig other sites as well as your own site. When
the ALT looking-glass is used as a Map-Resolver, you can be assured the ALT looking-glass is used as a Map-Resolver, you can be assured
the ALT network is being tested. the ALT network is being tested.
7. Future Enhancements 6. Future Enhancements
When negative Map-Replies have been further developed and When negative Map-Replies have been further developed and
implemented, lig should be modified appropriately to process and implemented, lig should be modified appropriately to process and
clearly indicate how and why a negative Map-Reply was received. clearly indicate how and why a negative Map-Reply was received.
Negative Map-Replies could be sent in the following cases, the lig Negative Map-Replies could be sent in the following cases, the lig
request was initiated for a non-EID address or the Map-Request request was initiated for a non-EID address or the Map-Request
initiated by lig request is being rejected due to rate-limiting on initiated by lig request is being rejected due to rate-limiting on
the replier. the replier.
8. Deployed Network Diagnostic Tools 7. Deployed Network Diagnostic Tools
There is an web-based interface to do auto-polling with lig on the There is an web-based interface to do auto-polling with lig on the
back-end for most of the LISP sites on the LISP test network. The back-end for most of the LISP sites on the LISP test network. The
web-page can be accessed at http://www.lisp4.net/status. web-page can be accessed at http://www.lisp4.net/status.
There is a LISP site monitoring web-based interface that can be found There is a LISP site monitoring web-based interface that can be found
at http://www.lisp4.net/lisp-site. at http://www.lisp4.net/lisp-site.
At http://baldomar.ccaba.upc.edu/lispmon, written by the folks at At http://baldomar.ccaba.upc.edu/lispmon, written by the folks at
UPC, shows a geographical map indicating where each LISP site UPC, shows a geographical map indicating where each LISP site
resides. resides.
9. Security Considerations 8. Security Considerations
The use of lig does not affect the security of the LISP The use of lig does not affect the security of the LISP
infrastructure as it is simply a tool that facilities diagnostic infrastructure as it is simply a tool that facilities diagnostic
querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the querying. See [LISP], [ALT], and [LISP-MS] for descriptions of the
security properties of the LISP infrastructure. security properties of the LISP infrastructure.
10. IANA Considerations 9. IANA Considerations
This document makes no request of the IANA. This document makes no request of the IANA.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
Requirement Levels", BCP 14, RFC 2119, March 1997. (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, August 2006.
11.2. Informative References 10.2. Informative References
[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-ietfr-lisp-alt-06.txt (work in progress). draft-ietfr-lisp-alt-06.txt (work in progress).
[CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A [CONS] Farinacci, D., Fuller, V., and D. Meyer, "LISP-CONS: A
Content distribution Overlay Network Service for LISP", Content distribution Overlay Network Service for LISP",
draft-meyer-lisp-cons-04.txt (work in progress). draft-meyer-lisp-cons-04.txt (work in progress).
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
 End of changes. 26 change blocks. 
49 lines changed or deleted 85 lines changed or added

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