draft-ietf-lisp-alt-09.txt   draft-ietf-lisp-alt-10.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: March 23, 2012 D. Lewis Expires: June 8, 2012 D. Lewis
Cisco Cisco
September 20, 2011 December 6, 2011
LISP Alternative Topology (LISP+ALT) LISP Alternative Topology (LISP+ALT)
draft-ietf-lisp-alt-09.txt draft-ietf-lisp-alt-10.txt
Abstract Abstract
This document describes a simple distributed index system to be used This document describes a simple distributed index system to be used
by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router by a Locator/ID Separation Protocol (LISP) Ingress Tunnel Router
(ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR) (ITR) or Map Resolver (MR) to find the Egress Tunnel Router (ETR)
which holds the mapping information for a particular Endpoint which holds the mapping information for a particular Endpoint
Identifier (EID). The MR can then query that ETR to obtain the Identifier (EID). The MR can then query that ETR to obtain the
actual mapping information, which consists of a list of Routing actual mapping information, which consists of a list of Routing
Locators (RLOCs) for the EID. Termed the Alternative Logical Locators (RLOCs) for the EID. Termed the Alternative Logical
Topology (ALT), the index is built as an overlay network on the Topology (ALT), the index is built as an overlay network on the
public Internet using the Border Gateway Protocol (BGP) and the public Internet using the Border Gateway Protocol (BGP) and the
Generic Routing Encapsulation (GRE). Using these proven protocols, Generic Routing Encapsulation (GRE).
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 March 23, 2012. This Internet-Draft will expire on June 8, 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
skipping to change at page 3, line 18 skipping to change at page 2, line 25
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6
3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 9 3. The LISP+ALT model . . . . . . . . . . . . . . . . . . . . . . 9
3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 9 3.1. Routeability of EIDs . . . . . . . . . . . . . . . . . . . 9
3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 10 3.1.1. Mechanisms for an ETR to originate EID-prefixes . . . 10
3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10 3.1.2. Mechanisms for an ITR to forward to EID-prefixes . . . 10
3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10 3.1.3. Map Server Model preferred . . . . . . . . . . . . . . 10
3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10 3.2. Connectivity to non-LISP sites . . . . . . . . . . . . . . 10
3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11 3.3. Caveats on the use of Data Probes . . . . . . . . . . . . 11
4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12 4. LISP+ALT: Overview . . . . . . . . . . . . . . . . . . . . . . 12
4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13 4.1. ITR traffic handling . . . . . . . . . . . . . . . . . . . 13
4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 13 4.2. EID Assignment - Hierarchy and Topology . . . . . . . . . 14
4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15 4.3. Use of GRE and BGP between LISP+ALT Routers . . . . . . . 15
5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16 5. EID-prefix Propagation and Map-Request Forwarding . . . . . . 16
5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16 5.1. Changes to ITR behavior with LISP+ALT . . . . . . . . . . 16
5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 17 5.2. Changes to ETR behavior with LISP+ALT . . . . . . . . . . 17
5.3. ALT Datagram forwarding falure . . . . . . . . . . . . . . 17 5.3. ALT Datagram forwarding falure . . . . . . . . . . . . . . 17
6. BGP configuration and protocol considerations . . . . . . . . 19 6. BGP configuration and protocol considerations . . . . . . . . 19
6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 19 6.1. Autonomous System Numbers (ASNs) in LISP+ALT . . . . . . . 19
6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 19 6.2. Sub-Address Family Identifier (SAFI) for LISP+ALT . . . . 19
7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 20 7. EID-prefix Aggregation . . . . . . . . . . . . . . . . . . . . 20
7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 20 7.1. Stability of the ALT . . . . . . . . . . . . . . . . . . . 20
skipping to change at page 6, line 20 skipping to change at page 6, line 20
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).
Legacy Internet: The portion of the Internet which does not run
LISP and does not participate in LISP+ALT.
ALT Router: The devices which run on the ALT. The ALT is a static ALT Router: The devices which run on the ALT. The ALT is a static
network built using tunnels between ALT Routers. These routers network built using tunnels between ALT Routers. These routers
are deployed in a roughly-hierarchical mesh in which routers at are deployed in a roughly-hierarchical mesh in which routers at
each level in the topology are responsible for aggregating EID- each level in the topology are responsible for aggregating EID-
prefixes learned from those logically "below" them and advertising prefixes learned from those logically "below" them and advertising
summary prefixes to those logically "above" them. Prefix learning summary prefixes to those logically "above" them. Prefix learning
and propagation between ALT Routers is done using BGP. An ALT and propagation between ALT Routers is done using BGP. An ALT
Router at the lowest level, or "edge" of the ALT, learns EID- Router at the lowest level, or "edge" of the ALT, learns EID-
prefixes from its "client" ETRs. See Section 3.1 for a prefixes from its "client" ETRs. See Section 3.1 for a
description of how EID-prefixes are learned at the "edge" of the description of how EID-prefixes are learned at the "edge" of the
skipping to change at page 8, line 6 skipping to change at page 8, line 6
EID-to-RLOC Mapping: A binding between an EID-prefix and the set of EID-to-RLOC Mapping: A binding between an EID-prefix and the set of
RLOCs that can be used to reach it; sometimes referred to simply RLOCs that can be used to reach it; sometimes referred to simply
as a "mapping". as a "mapping".
EID-prefix Reachability: An EID-prefix is said to be "reachable" if EID-prefix Reachability: An EID-prefix is said to be "reachable" if
at least one of its locators is reachable. That is, an EID-prefix at least one of its locators is reachable. That is, an EID-prefix
is reachable if the ETR that is authoritative for a given EID-to- is reachable if the ETR that is authoritative for a given EID-to-
RLOC mapping is reachable. RLOC mapping is reachable.
Default Mapping: A Default Mapping is a mapping entry for EID- Default Mapping: A Default Mapping is a mapping entry for EID-
prefix 0.0.0.0/0 (0::/0 for ipv6). It maps to a locator-set used prefix 0.0.0.0/0 (::/0 for ipv6). It maps to a locator-set used
for all EIDs in the Internet. If there is a more specific EID- for all EIDs in the Internet. If there is a more specific EID-
prefix in the mapping cache it overrides the Default Mapping prefix in the mapping cache it overrides the Default Mapping
entry. The Default Mapping can be learned by configuration or entry. The Default Mapping can be learned by configuration or
from a Map-Reply message. from a Map-Reply message.
ALT Default Route: An EID-prefix value of 0.0.0.0/0 (or 0::/0 for ALT Default Route: An EID-prefix value of 0.0.0.0/0 (or ::/0 for
ipv6) which may be learned from the ALT or statically configured ipv6) which may be learned from the ALT or statically configured
on an edge ALT Router. The ALT-Default Route defines a forwarding on an edge ALT Router. The ALT-Default Route defines a forwarding
path for a packet to be sent into the ALT on a router which does path for a packet to be sent into the ALT on a router which does
not have a full ALT forwarding database. not have a full ALT forwarding database.
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:
skipping to change at page 12, line 23 skipping to change at page 12, line 23
The basic idea embodied in LISP+ALT is to use BGP, running on a The basic idea embodied in LISP+ALT is to use BGP, running on a
tunneled overlay network (the ALT), to establish reachability between tunneled overlay network (the ALT), to establish reachability between
ALT Routers. The ALT BGP Route Information Base (RIB) is comprised ALT Routers. The ALT BGP Route Information Base (RIB) is comprised
of EID-prefixes and associated next hops. ALT Routers interconnect of EID-prefixes and associated next hops. ALT Routers interconnect
using BGP and propagate EID-prefix updates among themselves. EID- using BGP and propagate EID-prefix updates among themselves. EID-
prefix information is learned from ETRs at the "edge" of the ALT prefix information is learned from ETRs at the "edge" of the ALT
either through the use of the Map Server interface (the commmon either through the use of the Map Server interface (the commmon
case), static configuration, or by BGP-speaking ETRs. case), static configuration, or by BGP-speaking ETRs.
An ITR uses the ALT to learn the best path for forwarding an ALT Map Resolvers learns paths through the ALT to Map Servers for EID-
Datagram destined to a particular EID-prefix. An ITR will normally prefixes. An ITR will normally use a Map Resolver to send its ALT
use a Map Resolver to send its ALT Datagrams on to the ALT but may, Datagrams on to the ALT but may, in unusual cases (see
in unusual circumstances, use a static ALT Default Route or connect Section 3.1.2), use a static ALT Default Route or connect to the ALT
to the ALT using BGP. using BGP. Likewise, an ETR will normally register its prefixes in
the mapping database using a Map Server can sometimes (see
Section 3.1.1) connect directly to the ALT using BGP. See [LISP-MS]
for details on Map Servers and Map Resolvers.
Note that while this document specifies the use of Generic Routing Note that while this document specifies the use of Generic Routing
Encapsulation (GRE) as a tunneling mechanism, there is no reason that Encapsulation (GRE) as a tunneling mechanism, there is no reason that
parts of the ALT cannot be built using other tunneling technologies, parts of the ALT cannot be built using other tunneling technologies,
particularly in cases where GRE does not meet security, management, particularly in cases where GRE does not meet security, management,
or other operational requirements. References to "GRE tunnel" in or other operational requirements. References to "GRE tunnel" in
later sections of this document should therefore not be taken as later sections of this document should therefore not be taken as
prohibiting or precluding the use of other tunneling mechanisms. prohibiting or precluding the use of other tunneling mechanisms.
Note also that two ALT Routers that are directly adjacent (with no Note also that two ALT Routers that are directly adjacent (with no
layer-3 router hops between them) need not use a tunnel between them; layer-3 router hops between them) need not use a tunnel between them;
skipping to change at page 13, line 50 skipping to change at page 14, line 7
Traffic routed on to the ALT consists solely of ALT Datagrams, i.e. Traffic routed on to the ALT consists solely of ALT Datagrams, i.e.
Map-Requests and Data Probes (if supported). Given the relatively Map-Requests and Data Probes (if supported). Given the relatively
low performance expected of a tunneled topology, ALT Routers (and Map low performance expected of a tunneled topology, ALT Routers (and Map
Resolvers) should aggressively rate-limit the ingress of ALT Resolvers) should aggressively rate-limit the ingress of ALT
Datagrams from ITRs and, if possible, should be configured to not Datagrams from ITRs and, if possible, should be configured to not
accept packets that are not ALT Datagrams. accept packets that are not ALT Datagrams.
4.2. EID Assignment - Hierarchy and Topology 4.2. EID Assignment - Hierarchy and Topology
EID-prefixes are expected to be allocated to a LISP site by Internet The ALT database is organized in a herarchical manner with EID-
Registries. Where a site has multiple allocations which are aligned prefixs aggregated on power-of-2 block boundaries. Where a LISP site
on a power-of-2 block boundary, they should be aggregated into a has multiple EID-prefixes that are aligned on apower-of-2 block
single EID-prefix for advertisement. The ALT network is built in a boundary, they should be aggregated into a single EID-prefix for
roughly hierarchical, partial mesh which is intended to allow advertisement. The ALT network is built in a roughly hierarchical,
aggregation where clearly-defined hierarchical boundaries exist. partial mesh which is intended to allow aggregation where clearly-
Building such a structure should minimize the number of EID-prefixes defined hierarchical boundaries exist. Building such a structure
carried by LISP+ALT nodes near the top of the hierarchy. should minimize the number of EID-prefixes carried by LISP+ALT nodes
near the top of the hierarchy.
Routes on the ALT do not need to respond to changes in policy, Routes on the ALT do not need to respond to changes in policy,
subscription, or underlying physical connectivity, so the topology subscription, or underlying physical connectivity, so the topology
can remain relatively static and aggregation can be sustained. can remain relatively static and aggregation can be sustained.
Because routing on the ALT uses BGP, the same rules apply for Because routing on the ALT uses BGP, the same rules apply for
generating aggregates; in particular, a ALT Router should only be generating aggregates; in particular, a ALT Router should only be
configured to generate an aggregate if it is configured with BGP configured to generate an aggregate if it is configured with BGP
sessions to all of the originators of components (more-specific sessions to all of the originators of components (more-specific
prefixes) of that aggregate. Not all of the components of need to be prefixes) of that aggregate. Not all of the components of need to be
present for the aggregate to be originated (some may be holes in the present for the aggregate to be originated (some may be holes in the
skipping to change at page 22, line 4 skipping to change at page 22, line 4
There are major open questions regarding how the ALT will be deployed There are major open questions regarding how the ALT will be deployed
and what organization(s) will operate it. In a simple, non- and what organization(s) will operate it. In a simple, non-
distributed world, centralized administration of EID prefix distributed world, centralized administration of EID prefix
assignment and ALT network design would facilitate a well- aggregated assignment and ALT network design would facilitate a well- aggregated
ALT routing system. Business and other realities will likely result ALT routing system. Business and other realities will likely result
in a more complex, distributed system involving multiple levels of in a more complex, distributed system involving multiple levels of
prefix delegation, multiple operators of parts of the ALT prefix delegation, multiple operators of parts of the ALT
infrastructure, and a combination of competition and cooperation infrastructure, and a combination of competition and cooperation
among the participants. In addition, re-use of existing IP address among the participants. In addition, re-use of existing IP address
assignments, both "PI" and "PA", to avoid renumbering when sites assignments, both provider-independent ("PI") and provider-assigned
transition to LISP will further complicate the processes of building ("PA"), to avoid renumbering when sites transition to LISP will
and operating the ALT. further complicate the processes of building and operating the ALT.
A number of conflicting considerations need to be kept in mind when A number of conflicting considerations need to be kept in mind when
designing and building the ALT. Among them are: designing and building the ALT. Among them are:
1. Target ALT routing state size and level of aggregation. As 1. Target ALT routing state size and level of aggregation. As
described in Section 7.1, the ALT should not suffer from some of described in Section 7.1, the ALT should not suffer from some of
the performance constraints or stability issues as the Internet the performance constraints or stability issues as the Internet
global routing system, so some reasonable level of deaggregation global routing system, so some reasonable level of deaggregation
and increased number of EID prefixes beyond what might be and increased number of EID prefixes beyond what might be
considered ideal should be acceptable. That said, measures, such considered ideal should be acceptable. That said, measures, such
skipping to change at page 26, line 18 skipping to change at page 26, line 18
security mechanisms are comprised of existing technologies in wide security mechanisms are comprised of existing technologies in wide
operational use today, so securing the ALT should be mostly a matter operational use today, so securing the ALT should be mostly a matter
of applying the same technology that is used to secure the BGP-based of applying the same technology that is used to secure the BGP-based
global routing system (see Section 10.3 below). global routing system (see Section 10.3 below).
10.1. Apparent LISP+ALT Vulnerabilities 10.1. Apparent LISP+ALT Vulnerabilities
This section briefly lists the known potential vulnerabilities of This section briefly lists the known potential vulnerabilities of
LISP+ALT. LISP+ALT.
Mapping Integrity: Can an attacker insert bogus mappings to black- Mapping Integrity: Potential for an attacker to insert bogus
hole (create Denial-of-Service, or DoS attack) or intercept LISP mappings to black-hole (create Denial-of-Service, or DoS attack)
data-plane packets? or intercept LISP data-plane packets.
ALT Router Availability: Can an attacker DoS the ALT Routers ALT Router Availability: Can an attacker DoS the ALT Routers
connected to a given ETR? If a site's ETR cannot advertise its connected to a given ETR? If a site's ETR cannot advertise its
EID-to-RLOC mappings, the site is essentially unavailable. EID-to-RLOC mappings, the site is essentially unavailable.
ITR Mapping/Resources: Can an attacker force an ITR or ALT Router to ITR Mapping/Resources: Can an attacker force an ITR or ALT Router to
drop legitimate mapping requests by flooding it with random drop legitimate mapping requests by flooding it with random
destinations for which it will generate large numbers of Map- destinations for which it will generate large numbers of Map-
Requests and fill its mapping cache? Further study is required to Requests and fill its mapping cache? Further study is required to
see the impact of admission control on the overlay network. see the impact of admission control on the overlay network.
skipping to change at page 27, line 7 skipping to change at page 27, line 7
prepared to rate-limit traffic (ALT Datagrams) that could be prepared to rate-limit traffic (ALT Datagrams) that could be
received across the ALT. received across the ALT.
UDP Map-Reply from ETR: Since Map-Replies are sent directly from the UDP Map-Reply from ETR: Since Map-Replies are sent directly from the
ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various ETR to the ITR's RLOC, the ITR's RLOC may be vulnerable to various
types of DoS attacks (this is a general property of LISP, not an types of DoS attacks (this is a general property of LISP, not an
LISP+ALT vulnerability). LISP+ALT vulnerability).
More-specific prefix leakage: Because EID-prefixes on the ALT are More-specific prefix leakage: Because EID-prefixes on the ALT are
expected to be fairly well-aggregated and EID-prefixes propagated expected to be fairly well-aggregated and EID-prefixes propagated
out to the global Internet (see [LISP-IW] much more so, accidental out to the global Internet (see [LISP-IW]) much more so,
leaking or malicious advertisement of an EID-prefix into the accidental leaking or malicious advertisement of an EID-prefix
global routing system could cause traffic redirection away from a into the global routing system could cause traffic redirection
LISP site. This is not really a new problem, though, and its away from a LISP site. This is not really a new problem, though,
solution can only be achieved by much more strict prefix filtering and its solution can only be achieved by much more strict prefix
and authentication on the global routing system. filtering and authentication on the global routing system.
Section Section 10.3 describes an existingapproach to solving this
problem.
10.2. Survey of LISP+ALT Security Mechanisms 10.2. Survey of LISP+ALT Security Mechanisms
Explicit peering: The devices themselves can both prioritize Explicit peering: The devices themselves can both prioritize
incoming packets, as well as potentially do key checks in hardware incoming packets, as well as potentially do key checks in hardware
to protect the control plane. to protect the control plane.
Use of TCP to connect elements: This makes it difficult for third Use of TCP to connect elements: This makes it difficult for third
parties to inject packets. parties to inject packets.
Use of HMAC Protected BGP/TCP Connections: HMAC is used to verify Use of HMAC to protect BGP/TCP connections: HMAC [RFC5925] is used
message integrity and authenticity, making it nearly impossible to verify the integrity and authenticity of TCP connections used
for third party devices to either insert or modify messages. to exchange BGP messages, making it nearly impossible for third
party devices to either insert or modify messages.
Message Sequence Numbers and Nonce Values in Messages: This allows Message sequence numbers and nonce values in messages: This allows
an ITR to verify that the Map-Reply from an ETR is in response to an ITR to verify that the Map-Reply from an ETR is in response to
a Map-Request originated by that ITR (this is a general property a Map-Request originated by that ITR (this is a general property
of LISP; LISP+ALT does not change this behavior). of LISP; LISP+ALT does not change this behavior).
10.3. Use of new IETF standard BGP Security mechanisms 10.3. Use of new IETF standard BGP Security mechanisms
LISP+ALT's use of BGP allows the ALT to take advantage of BGP LISP+ALT's use of BGP allows it to take advantage of BGP security
security features designed for existing Internet BGP use. Should the features designed for existing Internet BGP use. This means that
Internet community converge on the work currently being done in the LISP+ALT can and should use technology developed for adding security
IETF SIDR working group or should either S-BGP [I-D.murphy-bgp-secr] to BGP (in the IETF SIDR working group or elsewhere) to provide
or soBGP [I-D.white-sobgparchitecture] be implemented and widely-
deployed, LISP+ALT can readily use these mechanisms to provide
authentication of EID-prefix origination and EID-to-RLOC mappings. authentication of EID-prefix origination and EID-to-RLOC mappings.
11. Acknowledgments 11. Acknowledgments
The authors would like to specially thank J. Noel Chiappa who was a The authors would like to specially thank J. Noel Chiappa who was a
key contributer to the design of the LISP-CONS mapping database (many key contributer to the design of the LISP-CONS mapping database (many
ideas from which made their way into LISP+ALT) and who has continued ideas from which made their way into LISP+ALT) and who has continued
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, Scott Brim, and Jari Arkko. Flinck, Amit Jain, John Scudder, Scott Brim, and Jari Arkko.
skipping to change at page 29, line 15 skipping to change at page 29, line 15
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-15.txt (work in progress), July 2011. draft-ietf-lisp-15.txt (work in progress), July 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-12.txt (work in progress), draft-ietf-lisp-ms-12.txt (work in progress),
September 2011. October 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
Plan", BCP 122, RFC 4632, August 2006. Plan", BCP 122, RFC 4632, August 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760, "Multiprotocol Extensions for BGP-4", RFC 4760,
January 2007. January 2007.
12.2. Informative References 12.2. Informative References
[I-D.murphy-bgp-secr]
Murphy, S., "BGP Security Analysis",
draft-murphy-bgp-secr-04 (work in progress),
November 2001.
[I-D.white-sobgparchitecture]
White, R., "Architecture and Deployment Considerations for
Secure Origin BGP (soBGP)",
draft-white-sobgparchitecture-00 (work in progress),
May 2004.
[LISP-IW] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [LISP-IW] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and ipv6", "Interworking LISP with IPv4 and ipv6",
draft-ietf-lisp-interworking-02.txt (work in progress), draft-ietf-lisp-interworking-02.txt (work in progress),
March 2011. March 2011.
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
Authentication Option", RFC 5925, June 2010.
Authors' Addresses Authors' Addresses
Vince Fuller Vince Fuller
Cisco Cisco
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: vaf@cisco.com Email: vaf@cisco.com
 End of changes. 20 change blocks. 
60 lines changed or deleted 52 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/