draft-ietf-lisp-alt-06.txt   draft-ietf-lisp-alt-07.txt 
Network Working Group V. Fuller Network Working Group V. Fuller
Internet-Draft D. Farinacci Internet-Draft D. Farinacci
Intended status: Experimental D. Meyer Intended status: Experimental D. Meyer
Expires: September 5, 2011 D. Lewis Expires: January 1, 2012 D. Lewis
Cisco Cisco
March 4, 2011 June 30, 2011
LISP Alternative Topology (LISP+ALT) LISP Alternative Topology (LISP+ALT)
draft-ietf-lisp-alt-06.txt draft-ietf-lisp-alt-07.txt
Abstract Abstract
This document describes a simple mapping database to be used by the This document describes a simple distributed index system to be used
Locator/ID Separation Protocol (LISP) to find Endpoint Identifier by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
(EID) to Routing Locator (RLOC) mappings. Termed the Alternative (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
Logical Topology (ALT), the database is built as an overlay network which holds the mapping information for a particular Endpoint
on the public Internet using the Border Gateway Protocol (BGP) and Identifier (EID). The MR can then query that ETR to obtain the
the Generic Routing Encapsulation (GRE). Using these proven actual mapping information, which consists of a list of Routing
protocols, the ALT can be built and deployed relatively quickly Locators (RLOCs) for the EID. Termed the Alternative Logical
without major changes to the existing routing infrastructure. Topology (ALT), the index is built as an overlay network on the
public Internet using the Border Gateway Protocol (BGP) and the
Generic Routing Encapsulation (GRE). Using these proven protocols,
the ALT can be built and deployed relatively quickly without any
changes to the existing routing infrastructure.
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.
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 September 5, 2011. This Internet-Draft will expire on January 1, 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 8 3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 8 3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 9
3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 9 3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 10
3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 9 3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10
3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 9 3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10
3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 9 3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10
3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 10 3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11
4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 11 4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 12 4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13
4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 12 4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13
4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 14 4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15
5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 15 5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16
5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 15 5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16
5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 15 5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 16
6. BGP configuration and protocol considerations . . . . . . . . 17 6. BGP configuration and protocol considerations . . . . . . . . 18
6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 17 6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 18
6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 17 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 18
7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 18 7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 19
7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 18 7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 19
7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 18 7.2. Traffic engineering using LISP . . . . . . . . . . . . . . 19
7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 19 7.3. Edge aggregation and dampening . . . . . . . . . . . . . . 20
7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 19 7.4. EID assignment flexibility vs. ALT scaling . . . . . . . . 20
8. Connecting sites to the ALT network . . . . . . . . . . . . . 21 8. Connecting sites to the ALT network . . . . . . . . . . . . . 22
8.1. ETRs originating information into the ALT . . . . . . . . 21 8.1. ETRs originating information into the ALT . . . . . . . . 22
8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 21 8.2. ITRs Using the ALT . . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 24 10. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 24 10.1. Apparent LISP+ALT Vulnerabilities . . . . . . . . . . . . 25
10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 25 10.2. Survey of LISP+ALT Security Mechanisms . . . . . . . . . . 26
10.3. Use of new IETF standard BGP Security mechanisms . . . . . 25 10.3. Use of new IETF standard BGP Security mechanisms . . . . . 26
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
12.1. Normative References . . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . . 28
12.2. Informative References . . . . . . . . . . . . . . . . . . 27 12.2. Informative References . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
This document describes the LISP+ALT mapping database, to be used by This document describes the LISP+ALT system, used by a [LISP] ITR or
LISP to find EID-to-RLOC mappings. The ALT network is built using MR to find the ETR that holds the RLOC mapping information for a
the Border Gateway Protocol (BGP, [RFC4271]), the BGP multi-protocol particular EID. The ALT network is built using the Border Gateway
extension [RFC4760], and the Generic Routing Encapsulation (GRE, Protocol (BGP, [RFC4271]), the BGP multi-protocol extension
[RFC2784]) to construct an overlay network of devices (ALT Routers) [RFC4760], and the Generic Routing Encapsulation (GRE, [RFC2784]) to
which operate on EID-prefixes and use EIDs as forwarding construct an overlay network of devices (ALT Routers) which operate
destinations. on EID-prefixes and use EIDs as forwarding destinations.
ALT Routers advertise hierarchically-delegated segments of the EID ALT Routers advertise hierarchically-delegated segments of the EID
namespace (i.e., prefixes) toward the rest of the ALT; they also namespace (i.e., prefixes) toward the rest of the ALT; they also
forward traffic destined for an EID covered by one of those prefixes forward traffic destined for an EID covered by one of those prefixes
toward the network element that is authoritative for that EID and is toward the network element that is authoritative for that EID and is
the origin of the BGP advertisement for that EID-prefix. An Ingress the origin of the BGP advertisement for that EID-prefix. An Ingress
Tunnel Router (ITR) uses this overlay to send a LISP Map-Request (see Tunnel Router (ITR) uses this overlay to send a LISP Map-Request
[LISP]) to the Egress Tunnel Router (ETR) that holds the EID-to-RLOC (defined in [LISP]) to the Egress Tunnel Router (ETR) that holds the
mapping for a matching EID-prefix. In most cases, an ITR does not EID-to-RLOC mapping for a matching EID-prefix. In most cases, an ITR
connect directly to the overlay network but instead sends Map- does not connect directly to the overlay network but instead sends
Requests via a Map-Resolver (MR; see [LISP-MS]) which does. Map-Requests via a Map-Resolver (described in [LISP-MS]) which does.
Likewise, in most cases, an ETR does not connect directly to the Likewise, in most cases, an ETR does not connect directly to the
overlay network but instead registers its EID-prefixes with a Map- overlay network but instead registers its EID-prefixes with a Map-
Server that advertises those EID-prefixes on to the ALT and forwards Server that advertises those EID-prefixes on to the ALT and forwards
Map-Requests for them to the ETR. Map-Requests for them to the ETR.
It is important to note that the ALT does not distribute actual EID- It is important to note that the ALT does not distribute actual EID-
to-RLOC mappings. What it does provide is a forwarding path from an to-RLOC mappings. What it does provide is a forwarding path from an
ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which ITR (or MR) which requires an EID-to-RLOC mapping to an ETR which
holds that mapping. The ITR/MR uses this path to send an ALT holds that mapping. The ITR/MR uses this path to send an ALT
Datagram (see Section 3) to an ETR which then responds with a Map- Datagram (see Section 3) to an ETR which then responds with a Map-
skipping to change at page 3, line 50 skipping to change at page 4, line 50
and GRE); little, if any, LISP-specific modifications should be and GRE); little, if any, LISP-specific modifications should be
needed for such devices to be deployed on the ALT. Note, though, needed for such devices to be deployed on the ALT. Note, though,
that organizational and operational considerations suggest that ALT that organizational and operational considerations suggest that ALT
Routers be both logically and physically separate from the "native" Routers be both logically and physically separate from the "native"
Internet packet transport system; deploying this overlay on those Internet packet transport system; deploying this overlay on those
routers which are already participating in the global routing system routers which are already participating in the global routing system
and actively forwarding Internet traffic is not recommended. and actively forwarding Internet traffic is not recommended.
The remainder of this document is organized as follows: Section 2 The remainder of this document is organized as follows: Section 2
provides the definitions of terms used in this document. Section 3 provides the definitions of terms used in this document. Section 3
outlines the basic LISP 1.5 model. Section 4 provides a basic outlines the LISP ALT model, where EID prefixes are routed across an
overview of the LISP Alternate Topology architecture, and Section 5 overlay network. Section 4 provides a basic overview of the LISP
describes how the ALT uses BGP to propagate Endpoint Identifier Alternate Topology architecture, and Section 5 describes how the ALT
reachability over the overlay network and Section 6 describes other uses BGP to propagate Endpoint Identifier reachability over the
considerations for using BGP on the ALT. Section 7 describes the overlay network and Section 6 describes other considerations for
construction of the ALT aggregation hierarchy, and Section 8 using BGP on the ALT. Section 7 describes the construction of the
discusses how LISP+ALT elements are connected to form the overlay ALT aggregation hierarchy, and Section 8 discusses how LISP+ALT
network. elements are connected to form the overlay network.
2. Definition of Terms 2. Definition of Terms
LISP+ALT operates on two name spaces and introduces a new network This section provides high-level definitions of LISP concepts and
element, the LISP+ALT Router (see below). This section provides components involved with and affected by LISP+ALT.
high-level definitions of the LISP+ALT name spaces, network elements,
and message types.
Alternative Logical Topology (ALT): The virtual overlay network Alternative Logical Topology (ALT): The virtual overlay network
made up of tunnels between LISP+ALT Routers. The Border Gateway made up of tunnels between LISP+ALT Routers. The Border Gateway
Protocol (BGP) runs between ALT Routers and is used to carry Protocol (BGP) runs between ALT Routers and is used to carry
reachability information for EID-prefixes. The ALT provides a way reachability information for EID-prefixes. The ALT provides a way
to forward Map-Requests (and, if supported, Data Probes) toward to forward Map-Requests (and, if supported, Data Probes) toward
the ETR that "owns" an EID-prefix. As a tunneled overlay, its the ETR that "owns" an EID-prefix. As a tunneled overlay, its
performance is expected to be quite limited so use of it to performance is expected to be quite limited so use of it to
forward high-bandwidth flows of Data Probes is strongly forward high-bandwidth flows of Data Probes is strongly
discouraged (see Section 3.3 for additional discussion). discouraged (see Section 3.3 for additional discussion).
skipping to change at page 8, line 15 skipping to change at page 9, line 15
3. The LISP+ALT model 3. The LISP+ALT model
The LISP+ALT model uses the same basic query/response protocol that The LISP+ALT model uses the same basic query/response protocol that
is documented in [LISP]. In particular, LISP+ALT provides two types is documented in [LISP]. In particular, LISP+ALT provides two types
of packet that an ITR can originate to obtain EID-to-RLOC mappings: of packet that an ITR can originate to obtain EID-to-RLOC mappings:
Map-Request: A Map-Request message is sent into the ALT to request Map-Request: A Map-Request message is sent into the ALT to request
an EID-to-RLOC mapping. The ETR which owns the mapping will an EID-to-RLOC mapping. The ETR which owns the mapping will
respond to the ITR with a Map-Reply message. Since the ALT only respond to the ITR with a Map-Reply message. Since the ALT only
forwards on EID destinations, the destination address of the Map- forwards on EID destinations, the destination address of the Map-
Request sent on the ALT must be an EID. See [LISP] for the format Request sent on the ALT must be an EID.
of Map-Request and Map-Reply packets.
Data Probe: Alternatively, an ITR may encapsulate and send the first Data Probe: Alternatively, an ITR may encapsulate and send the first
data packet destined for an EID with no known RLOCs into the ALT data packet destined for an EID with no known RLOCs into the ALT
as a Data Probe. This might be done minimize packet loss and to as a Data Probe. This might be done minimize packet loss and to
probe for the mapping. As above, the authoritative ETR for the probe for the mapping. As above, the authoritative ETR for the
EID-prefix will respond to the ITR with a Map-Reply message when EID-prefix will respond to the ITR with a Map-Reply message when
it receives the data packet over the ALT. As a side-effect, the it receives the data packet over the ALT. As a side-effect, the
encapsulated data packet is delivered to the end-system at the ETR encapsulated data packet is delivered to the end-system at the ETR
site. Note that the Data Probe's inner IP destination address, site. Note that the Data Probe's inner IP destination address,
which is an EID, is copied to the outer IP destination address so which is an EID, is copied to the outer IP destination address so
that the resulting packet can be routed over the ALT. See that the resulting packet can be routed over the ALT. See
Section 3.3 for caveats on the usability of Data Probes. Section 3.3 for caveats on the usability of Data Probes.
The term "ALT Datagram" is short-hand for a Map-Request or Data Probe The term "ALT Datagram" is short-hand for a Map-Request or Data Probe
to be sent into or forwarded on the ALT. Note that while the outer to be sent into or forwarded on the ALT. Note that such packets use
header Source Address of an ALT Datagram is currently expected to be an RLOC as the outer header source IP address and an EID as the outer
an RLOC, there may be situations (e.g. for experimentation with header destination IP address.
caching in intermediate ALT nodes) where an EID would be used to
force a Map-Reply to be routed back through the ALT. Detailed descriptions of the LISP packet types referenced by this
document may be found in [LISP].
3.1. Routeability of EIDs 3.1. Routeability of EIDs
A LISP EID has the same syntax as IP address and can be used, A LISP EID has the same syntax as IP address and can be used,
unaltered, as the source or destination of an IP datagram. In unaltered, as the source or destination of an IP datagram. In
general, though, EIDs are not routable on the public Internet; LISP+ general, though, EIDs are not routable on the public Internet; LISP+
ALT provides a separate, virtual network, known as the LISP ALT provides a separate, virtual network, known as the LISP
Alternative Logical Topology (ALT) on which a datagram using an EID Alternative Logical Topology (ALT) on which a datagram using an EID
as an IP destination address may be transmitted. This network is as an IP destination address may be transmitted. This network is
built as an overlay on the public Internet using tunnels to built as an overlay on the public Internet using tunnels to
skipping to change at page 19, line 8 skipping to change at page 20, line 8
owns it, it is possible to perform site-to-site traffic engineering owns it, it is possible to perform site-to-site traffic engineering
by setting the preference and/or weight fields, and by including by setting the preference and/or weight fields, and by including
more-specific EID-to-RLOC information in Map-Reply messages. more-specific EID-to-RLOC information in Map-Reply messages.
This is a powerful mechanism that can conceivably replace the This is a powerful mechanism that can conceivably replace the
traditional practice of routing prefix deaggregation for traffic traditional practice of routing prefix deaggregation for traffic
engineering purposes. Rather than propagating more-specific engineering purposes. Rather than propagating more-specific
information into the global routing system for local- or regional- information into the global routing system for local- or regional-
optimization of traffic flows, such more-specific information can be optimization of traffic flows, such more-specific information can be
exchanged, through LISP (not LISP+ALT), on an as-needed basis between exchanged, through LISP (not LISP+ALT), on an as-needed basis between
only those ITRs/ETRs (and, thus, site pairs) that need it. Should a only those ITRs/ETRs (and, thus, site pairs) that need it. Such an
receiving ITR decide that it does not wish to store such more- exchange of "more-specifics" between sites facilitates traffic
specific information, it has the option of discarding it as long as a engineering, by allowing richer and more fine-grained policies to be
shorter, covering EID-prefix exists. Such an exchange of "more- applied without advertising additional prefixes into either the ALT
specifics" between sites facilitates traffic engineering, by allowing or the global routing system.
richer and more fine-grained policies to be applied without
advertising additional prefixes into either the ALT or the global
routing system.
Note that these new traffic engineering capabilities are an attribute Note that these new traffic engineering capabilities are an attribute
of LISP and are not specific to LISP+ALT; discussion is included here of LISP and are not specific to LISP+ALT; discussion is included here
because the BGP-based global routing system has traditionally used because the BGP-based global routing system has traditionally used
propagation of more-specific routes as a crude form of traffic propagation of more-specific routes as a crude form of traffic
engineering. engineering.
7.3. Edge aggregation and dampening 7.3. Edge aggregation and dampening
Normal BGP best common practices apply to the ALT network. In Normal BGP best common practices apply to the ALT network. In
skipping to change at page 20, line 44 skipping to change at page 21, line 41
placement of aggregation boundaries. placement of aggregation boundaries.
4. EID prefix portability between competing operators of the ALT 4. EID prefix portability between competing operators of the ALT
infrastructure. A significant benefit for an end-site to adopt infrastructure. A significant benefit for an end-site to adopt
LISP is the availability of EID space that is not tied to a LISP is the availability of EID space that is not tied to a
specific connectivity provider; it is important to ensure that an specific connectivity provider; it is important to ensure that an
end site doesn't trade lock-in to a connectivity provider for end site doesn't trade lock-in to a connectivity provider for
lock-in to a provider of its EID assignment, ALT connectivity, or lock-in to a provider of its EID assignment, ALT connectivity, or
Map Server facilities. Map Server facilities.
This is, by no means, and exhaustive list. This is, by no means, an exhaustive list.
While resolving these issues is beyond the scope of this document, While resolving these issues is beyond the scope of this document,
the authors recommend that existing distributed resource structures, the authors recommend that existing distributed resource structures,
such as the IANA/Regional Internet Registries and the ICANN/Domain such as the IANA/Regional Internet Registries and the ICANN/Domain
Registrar, be carefully considered when designing and deploying the Registrar, be carefully considered when designing and deploying the
ALT infrastructure. ALT infrastructure.
8. Connecting sites to the ALT network 8. Connecting sites to the ALT network
8.1. ETRs originating information into the ALT 8.1. ETRs originating information into the ALT
skipping to change at page 27, line 11 skipping to change at page 28, line 11
to provide invaluable insight as the LISP effort has evolved. Others to provide invaluable insight as the LISP effort has evolved. Others
who have provided valuable contributions include John Zwiebel, Hannu who have provided valuable contributions include John Zwiebel, Hannu
Flinck, Amit Jain, John Scudder, and Scott Brim. Flinck, Amit Jain, John Scudder, and Scott Brim.
12. References 12. References
12.1. Normative References 12.1. Normative References
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)", "Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-10.txt (work in progress), March 2011. draft-ietf-lisp-14.txt (work in progress), June 2011.
[LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server", [LISP-MS] Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-07.txt (work in progress), March 2011. draft-ietf-lisp-ms-09.txt (work in progress), May 2011.
[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.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
 End of changes. 16 change blocks. 
91 lines changed or deleted 90 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/