draft-ietf-lisp-deployment-10.txt   draft-ietf-lisp-deployment-11.txt 
Network Working Group L. Jakab Network Working Group L. Jakab
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Experimental A. Cabellos-Aparicio Intended status: Experimental A. Cabellos-Aparicio
Expires: February 7, 2014 F. Coras Expires: June 12, 2014 F. Coras
J. Domingo-Pascual J. Domingo-Pascual
Technical University of Technical University of
Catalonia Catalonia
D. Lewis D. Lewis
Cisco Systems Cisco Systems
August 6, 2013 December 9, 2013
LISP Network Element Deployment Considerations LISP Network Element Deployment Considerations
draft-ietf-lisp-deployment-10.txt draft-ietf-lisp-deployment-11.txt
Abstract Abstract
This document is a snapshot of different Locator/Identifier This document is a snapshot of different Locator/Identifier
Separation Protocol (LISP) deployment scenarios. It discusses the Separation Protocol (LISP) deployment scenarios. It discusses the
placement of new network elements introduced by the protocol, placement of new network elements introduced by the protocol,
representing the thinking of the authors as of Summer 2013. LISP representing the thinking of the LISP working group as of Summer
deployment scenarios may have evolved since. This memo represents 2013. LISP deployment scenarios may have evolved since. This memo
one stable point in that evolution of understanding. represents one stable point in that evolution of understanding.
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 February 7, 2014. This Internet-Draft will expire on June 12, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Deployment Scenarios . . . . . . . . . . . . . . . . . . . 4
2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Customer Edge . . . . . . . . . . . . . . . . . . . . 4
2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2. Provider Edge . . . . . . . . . . . . . . . . . . . . 6
2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 2.1.3. Tunnel Routers Behind NAT . . . . . . . . . . . . . . 7
2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10 2.1.3.1. ITR . . . . . . . . . . . . . . . . . . . . . . . 7
2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.1.3.2. ETR . . . . . . . . . . . . . . . . . . . . . . . 8
2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.1.3.3. Additional Notes . . . . . . . . . . . . . . . . . 8
2.5.3. Additional Notes . . . . . . . . . . . . . . . . . . . 11 2.2. Functional Models with Tunnel Routers . . . . . . . . . . 8
2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 2.2.1. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . 8
3. Map Resolvers and Map Servers . . . . . . . . . . . . . . . . 12 2.2.2. Inter-Service Provider Traffic Engineering . . . . . . 10
3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 12 2.3. Summary and Feature Matrix . . . . . . . . . . . . . . . . 12
3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 13 3. Map Resolvers and Map Servers . . . . . . . . . . . . . . . . 13
4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 14 3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 15
4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 15 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 16
5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 16
5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 17 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 18
5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 18
5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 20 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 19
6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 19
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 22
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
9.1. Normative References . . . . . . . . . . . . . . . . . . . 23
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
Appendix A. Step-by-Step Example BGP to LISP Migration Appendix A. Step-by-Step Example BGP to LISP Migration
Procedure . . . . . . . . . . . . . . . . . . . . . . 22 Procedure . . . . . . . . . . . . . . . . . . . . . . 24
A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22 A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 24
A.2. Customer Activating LISP Service . . . . . . . . . . . . . 24 A.2. Customer Activating LISP Service . . . . . . . . . . . . . 26
A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 25 A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The Locator/Identifier Separation Protocol (LISP) is designed to The Locator/Identifier Separation Protocol (LISP) is designed to
address the scaling issues of the global Internet routing system address the scaling issues of the global Internet routing system
identified in [RFC4984] by separating the current addressing scheme identified in [RFC4984] by separating the current addressing scheme
into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The
main protocol specification [RFC6830] describes how the separation is main protocol specification [RFC6830] describes how the separation is
achieved, which new network elements are introduced, and details the achieved, which new network elements are introduced, and details the
packet formats for the data and control planes. packet formats for the data and control planes.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
guide for the operational community for LISP deployments in their guide for the operational community for LISP deployments in their
networks. It is expected to evolve as LISP deployment progresses, networks. It is expected to evolve as LISP deployment progresses,
and the described scenarios are better understood or new scenarios and the described scenarios are better understood or new scenarios
are discovered. are discovered.
Each subsection considers an element type, discussing the impact of Each subsection considers an element type, discussing the impact of
deployment scenarios on the protocol specification. For definition deployment scenarios on the protocol specification. For definition
of terms, please refer to the appropriate documents (as cited in the of terms, please refer to the appropriate documents (as cited in the
respective sections). respective sections).
This experimental specification has areas that require additional This experimental document describing deployment considerations and
experience and measurement. It is NOT RECOMMENDED for deployment the LISP specifications have areas that require additional experience
beyond experimental situations. Results of experimentation may lead and measurement. LISP is not recommended for deployment beyond
to modifications and enhancements of protocol mechanisms defined in experimental situations. Results of experimentation may lead to
this document. See Section 15 [of RFC 6830] for specific, known modifications and enhancements of the LISP protocol mechanisms.
issues that are in need of further work during development, Additionally, at the time of this writing there is no standardized
implementation, and experimentation. security to implement. Beware that there are no counter measures for
any of the threads identified in [I-D.ietf-lisp-threats]. See
Section 15 [of RFC 6830] for specific, known issues that are in need
of further work during development, implementation, and
experimentation, and [I-D.ietf-lisp-threats] for recommendations to
ameliorate the above-mentioned security threats.
2. Tunnel Routers 2. Tunnel Routers
The device that is the gateway between the edge and the core is The device that is the gateway between the edge and the core is
called a Tunnel Router (xTR), performing one or both of two separate called a Tunnel Router (xTR), performing one or both of two separate
functions: functions:
1. Encapsulating packets originating from an end host to be 1. Encapsulating packets originating from an end host to be
transported over intermediary (transit) networks towards the transported over intermediary (transit) networks towards the
other end-point of the communication other end-point of the communication
skipping to change at page 4, line 28 skipping to change at page 4, line 33
2. Decapsulating packets entering from intermediary (transit) 2. Decapsulating packets entering from intermediary (transit)
networks, originated at a remote end host. networks, originated at a remote end host.
The first function is performed by an Ingress Tunnel Router (ITR), The first function is performed by an Ingress Tunnel Router (ITR),
the second by an Egress Tunnel Router (ETR). the second by an Egress Tunnel Router (ETR).
Section 8 of the main LISP specification [RFC6830] has a short Section 8 of the main LISP specification [RFC6830] has a short
discussion of where Tunnel Routers can be deployed and some of the discussion of where Tunnel Routers can be deployed and some of the
associated advantages and disadvantages. This section adds more associated advantages and disadvantages. This section adds more
detail to the scenarios presented there, and provides additional detail to the scenarios presented there, and provides additional
scenarios as well. scenarios as well. Furthermore this section discusses functional
models, that is, network functions that can be achieved by deploying
Tunnel Routers in specific ways.
2.1. Customer Edge 2.1. Deployment Scenarios
2.1.1. Customer Edge
The first scenario we discuss is customer edge, when xTR The first scenario we discuss is customer edge, when xTR
functionality is placed on the router(s) that connect the LISP site functionality is placed on the router(s) that connect the LISP site
to its upstream(s), but are under its control. As such, this is the to its upstream(s), but are under its control. As such, this is the
most common expected scenario for xTRs, and this document considers most common expected scenario for xTRs, and this document considers
it the reference location, comparing the other scenarios to this one. it the reference location, comparing the other scenarios to this one.
ISP1 ISP2 ISP1 ISP2
| | | |
| | | |
skipping to change at page 5, line 7 skipping to change at page 5, line 21
| | | |
| LISP site | | LISP site |
+------------------+ +------------------+
Figure 1: xTRs at the customer edge Figure 1: xTRs at the customer edge
From the LISP site perspective the main advantage of this type of From the LISP site perspective the main advantage of this type of
deployment (compared to the one described in the next section) is deployment (compared to the one described in the next section) is
having direct control over its ingress traffic engineering. This having direct control over its ingress traffic engineering. This
makes it easy to set up and maintain active/active, active/backup, or makes it easy to set up and maintain active/active, active/backup, or
more complex TE policies, without involving third parties. more complex TE policies, adding ISPs and additional xTRs at will,
without involving third parties.
Being under the same administrative control, reachability information Being under the same administrative control, reachability information
of all ETRs is easier to synchronize, because the necessary control of all ETRs is easier to synchronize, because the necessary control
traffic can be allowed between the locators of the ETRs. A correct traffic can be allowed between the locators of the ETRs. A correct
synchronous global view of the reachability status is thus available, synchronous global view of the reachability status is thus available,
and the Locator Status Bits (Loc-Status-Bits, defined in [RFC6830]) and the Locator Status Bits (Loc-Status-Bits, defined in [RFC6830])
can be set correctly in the LISP data header of outgoing packets. can be set correctly in the LISP data header of outgoing packets.
By placing the tunnel router at the edge of the site, existing By placing the tunnel router at the edge of the site, existing
internal network configuration does not need to be modified. internal network configuration does not need to be modified.
Firewall rules, router configurations and address assignments inside Firewall rules, router configurations and address assignments inside
the LISP site remain unchanged. This helps with incremental the LISP site remain unchanged. This helps with incremental
deployment and allows a quick upgrade path to LISP. For larger sites deployment and allows a quick upgrade path to LISP. For larger sites
with many external connections, distributed in geographically diverse with many external connections, distributed in geographically diverse
points of presence (PoPs), and complex internal topology, it may points of presence (PoPs), and complex internal topology, it may
however make more sense to both encapsulate and decapsulate as soon however make more sense to both encapsulate and decapsulate as soon
as possible, to benefit from the information in the IGP to choose the as possible, to benefit from the information in the IGP to choose the
best path (see Section 2.3 for a discussion of this scenario). best path (see Section 2.2.1 for a discussion of this scenario).
Another thing to consider when placing tunnel routers is MTU issues. Another thing to consider when placing tunnel routers is MTU issues.
Encapsulation increases the amount of overhead associated with each Encapsulation increases the amount of overhead associated with each
packet. This added overhead decreases the effective end-to-end path packet. This added overhead decreases the effective end-to-end path
MTU (unless fragmentation and reassembly is used). Some transit MTU (unless fragmentation and reassembly is used). Some transit
networks are known to provide larger MTU than the typical value of networks are known to provide larger MTU than the typical value of
1500 bytes of popular access technologies used at end hosts (e.g., 1500 bytes of popular access technologies used at end hosts (e.g.,
IEEE 802.3 and 802.11). However, placing the LISP router connecting IEEE 802.3 and 802.11). However, placing the LISP router connecting
to such a network at the customer edge could possibly bring up MTU to such a network at the customer edge could possibly bring up MTU
issues, depending on the link type to the provider as opposed to the issues, depending on the link type to the provider as opposed to the
following scenario. See [RFC4459] for MTU considerations of following scenario. See [RFC4459] for MTU considerations of
tunneling protocols on how to mitigate potential issues. Still, even tunneling protocols on how to mitigate potential issues. Still, even
with these mitigations, path MTU issues are still possible. with these mitigations, path MTU issues are still possible.
2.2. Provider Edge 2.1.2. Provider Edge
The other location at the core-edge boundary for deploying LISP The other location at the core-edge boundary for deploying LISP
routers is at the Internet service provider edge. The main incentive routers is at the Internet service provider edge. The main incentive
for this case is that the customer does not have to upgrade the CE for this case is that the customer does not have to upgrade the CE
router(s), or change the configuration of any equipment. router(s), or change the configuration of any equipment.
Encapsulation/decapsulation happens in the provider's network, which Encapsulation/decapsulation happens in the provider's network, which
may be able to serve several customers with a single device. For may be able to serve several customers with a single device. For
large ISPs with many residential/business customers asking for LISP large ISPs with many residential/business customers asking for LISP
this can lead to important savings, since there is no need to upgrade this can lead to important savings, since there is no need to upgrade
the software (or hardware, if it's the case) at each client's the software (or hardware, if it's the case) at each client's
skipping to change at page 7, line 5 skipping to change at page 7, line 18
Bits (LSB) correctly on encapsulated packets. Because of this, and Bits (LSB) correctly on encapsulated packets. Because of this, and
due to the security concerns about LSB described in due to the security concerns about LSB described in
[I-D.ietf-lisp-threats] their use is discouraged (set the L-bit to [I-D.ietf-lisp-threats] their use is discouraged (set the L-bit to
0). Mapping versioning is another alternative [RFC6834]. 0). Mapping versioning is another alternative [RFC6834].
Compared to the customer edge scenario, deploying LISP at the Compared to the customer edge scenario, deploying LISP at the
provider edge might have the advantage of diminishing potential MTU provider edge might have the advantage of diminishing potential MTU
issues, because the tunnel router is closer to the core, where links issues, because the tunnel router is closer to the core, where links
typically have higher MTUs than edge network links. typically have higher MTUs than edge network links.
2.3. Split ITR/ETR 2.1.3. Tunnel Routers Behind NAT
NAT in this section refers to IPv4 network address and port
translation.
2.1.3.1. ITR
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ITR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
Figure 3: ITR behind NAT
Packets encapsulated by an ITR are just UDP packets from a NAT
device's point of view, and they are handled like any UDP packet,
there are no additional requirements for LISP data packets.
Map-Requests sent by an ITR, which create the state in the NAT table,
have a different 5-tuple in the IP header than the Map-Reply
generated by the authoritative ETR. Since the source address of this
packet is different from the destination address of the request
packet, no state will be matched in the NAT table and the packet will
be dropped. To avoid this, the NAT device has to do the following:
o Send all UDP packets with source port 4342, regardless of the
destination port, to the RLOC of the ITR. The most simple way to
achieve this is configuring 1:1 NAT mode from the external RLOC of
the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer
broadband routers).
o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in
the payload.
This setup supports only a single ITR behind the NAT device.
2.1.3.2. ETR
An ETR placed behind NAT is reachable from the outside by the
Internet-facing locator of the NAT device. It needs to know this
locator (and configure a loopback interface with it), so that it can
use it in Map-Reply and Map-Register messages. Thus support for
dynamic locators for the mapping database is needed in LISP
equipment.
Again, only one ETR behind the NAT device is supported.
_.--. _.--.
,-'' `--. +-------+ ,-'' `--.
' EID ` (Private) | NAT | (Public) ,' RLOC `.
( )---[ETR]---| |---------( )
. space ,' (Address) | Box |(Address) . space ,'
`--. _.-' +-------+ `--. _.-'
`--'' `--''
Figure 4: ETR behind NAT
2.1.3.3. Additional Notes
An implication of the issues described above is that LISP sites with
xTRs can not be behind carrier based NATs, since two different sites
would collide on the port forwarding. An alternative to static hole-
punching to explore is the use of the Port Control Protocol (PCP)
[RFC6887].
We only include this scenario due to completeness, to show that a
LISP site can be deployed behind NAT, should it become necessary.
However, LISP deployments behind NAT should be avoided, if possible.
2.2. Functional Models with Tunnel Routers
This section describes how certain LISP deployments can provide
network functions.
2.2.1. Split ITR/ETR
In a simple LISP deployment, xTRs are located at the border of the In a simple LISP deployment, xTRs are located at the border of the
LISP site (see Section 2.1). In this scenario packets are routed LISP site (see Section 2.1.1). In this scenario packets are routed
inside the domain according to the EID. However, more complex inside the domain according to the EID. However, more complex
networks may want to route packets according to the destination RLOC. networks may want to route packets according to the destination RLOC.
This would enable them to choose the best egress point. This would enable them to choose the best egress point.
The LISP specification separates the ITR and ETR functionality and The LISP specification separates the ITR and ETR functionality and
allows both entities to be deployed in separated network equipment. allows both entities to be deployed in separated network equipment.
ITRs can be deployed closer to the host (i.e., access routers). This ITRs can be deployed closer to the host (i.e., access routers). This
way packets are encapsulated as soon as possible, and egress point way packets are encapsulated as soon as possible, and egress point
selection is driven by operational policy. In turn, ETRs can be selection is driven by operational policy. In turn, ETRs can be
deployed at the border routers of the network, and packets are deployed at the border routers of the network, and packets are
skipping to change at page 7, line 46 skipping to change at page 9, line 40
| +-------+ | +-------+ +-------+ | +-------+ | +-------+ +-------+
| +-+ | | | | +-+ | | |
| |S| | IGP | | | |S| | IGP | |
| +-+ | | | | +-+ | | |
| +-------+ | +-------+ +-------+ | +-------+ | +-------+ +-------+
| | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B |
| +-------+ +-------+ +-------+ | +-------+ +-------+ +-------+
| | | |
+---------------------------------------+ +---------------------------------------+
Figure 3: Split ITR/ETR Scenario Figure 5: Split ITR/ETR Scenario
This scenario has a set of implications: This scenario has a set of implications:
o The site must carry more specific routes in order to choose the o The site must carry more specific routes in order to choose the
best egress point, and typically BGP is used for this, increasing best egress point, and typically BGP is used for this, increasing
the complexity of the network. However, this is usually already the complexity of the network. However, this is usually already
the case for LISP sites that would benefit from this scenario. the case for LISP sites that would benefit from this scenario.
o If the site is multihomed to different ISPs and any of the o If the site is multihomed to different ISPs and any of the
upstream ISPs are doing uRPF filtering, this scenario may become upstream ISPs are doing uRPF filtering, this scenario may become
skipping to change at page 8, line 34 skipping to change at page 10, line 29
may be lower (i.e., the miss ratio is higher). Another may be lower (i.e., the miss ratio is higher). Another
consequence of this is that the site may transmit a higher amount consequence of this is that the site may transmit a higher amount
of Map-Requests, increasing the load on the distributed mapping of Map-Requests, increasing the load on the distributed mapping
database. database.
o By placing the ITRs inside the site, they will still need global o By placing the ITRs inside the site, they will still need global
RLOCs, and this may add complexity to intra-site routing RLOCs, and this may add complexity to intra-site routing
configuration, and further intra-site issues when there is a configuration, and further intra-site issues when there is a
change of providers. change of providers.
2.4. Inter-Service Provider Traffic Engineering 2.2.2. Inter-Service Provider Traffic Engineering
At the time of this writing, if two ISPs want to control their At the time of this writing, if two ISPs want to control their
ingress TE policies for transit traffic between them, they need to ingress TE policies for transit traffic between them, they need to
rely on existing BGP mechanisms. This typically means deaggregating rely on existing BGP mechanisms. This typically means deaggregating
prefixes to choose on which upstream link packets should enter. This prefixes to choose on which upstream link packets should enter. This
is either not feasible (if fine-grained per-customer control is is either not feasible (if fine-grained per-customer control is
required, the very specific prefixes may not be propagated) or required, the very specific prefixes may not be propagated) or
increases DFZ table size. increases DFZ table size.
Typically, LISP is seen applicable only to stub networks, however the Typically, LISP is seen applicable only to stub networks, however the
LISP protocol can be also applied in a recursive manner, providing LISP protocol can be also applied in a recursive manner, providing
service provider ingress/egress TE capabilities without impacting the service provider ingress/egress TE capabilities without impacting the
DFZ table size. DFZ table size.
In order to implement this functionality with LISP consider the In order to implement this functionality with LISP consider the
scenario depicted in Figure 4. The two ISPs willing to achieve scenario depicted in Figure 6. The two ISPs willing to achieve
ingress/egress TE are labeled as ISP_A and ISP_B, they are servicing ingress/egress TE are labeled as ISP_A and ISP_B, they are servicing
Stub1 and Stub2 respectively, both are required to be LISP sites with Stub1 and Stub2 respectively, both are required to be LISP sites with
their own xTRs. In this scenario we assume that Stub1 and Stub2 are their own xTRs. In this scenario we assume that Stub1 and Stub2 are
communicating with each other and thus, ISP_A and ISP_B offer transit communicating with each other and thus, ISP_A and ISP_B offer transit
for such communications. ISP_A has RLOC_A1 and RLOC_A2 as upstream for such communications. ISP_A has RLOC_A1 and RLOC_A2 as upstream
IP addresses while ISP_B has RLOC_B1 and RLOC_B2. The shared goal IP addresses while ISP_B has RLOC_B1 and RLOC_B2. The shared goal
among ISP_A and ISP_B is to control the transit traffic flow between among ISP_A and ISP_B is to control the transit traffic flow between
RLOC_A1/A2 and RLOC_B1/B2. RLOC_A1/A2 and RLOC_B1/B2.
_.--. _.--.
Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2
\ | R_A1|----,' `. ---|R_B1 | / \ | R_A1|----,' `. ---|R_B1 | /
--| | ( Transit ) | |-- --| | ( Transit ) | |--
... .../ | R_A2|-----. ,' ---|R_B2 | \... ... ... .../ | R_A2|-----. ,' ---|R_B2 | \... ...
+-------+ `--. _.-' +-------+ +-------+ `--. _.-' +-------+
... ... ISP_A `--'' ISP_B ... ... ... ... ISP_A `--'' ISP_B ... ...
Figure 4: Inter-Service provider TE scenario Figure 6: Inter-Service provider TE scenario
Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively
and reach a bilateral agreement to deploy their own private mapping and reach a bilateral agreement to deploy their own private mapping
system. This mapping system contains bindings between the RLOCs of system. This mapping system contains bindings between the RLOCs of
Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and
RLOC_A1/A2 and RLOC_B1/B2. Such bindings are in fact the TE policies RLOC_A1/A2 and RLOC_B1/B2. Such bindings are in fact the TE policies
between both ISPs and the convergence time is expected to be fast, between both ISPs and the convergence time is expected to be fast,
since ISPs only have to update/query a mapping to/from the database. since ISPs only have to update/query a mapping to/from the database.
The packet flow is as follows. First, a packet originated at Stub1 The packet flow is as follows. First, a packet originated at Stub1
towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A
recursively encapsulates it and, according to the TE policies stored recursively encapsulates it and, according to the TE policies stored
in the private mapping system, the ISP_A xTR chooses RLOC_B1 or in the private mapping system, the ISP_A xTR chooses RLOC_B1 or
RLOC_B2 as the outer encapsulation destination. Note that the packet RLOC_B2 as the outer encapsulation destination. Note that the packet
transits between ISP_A and ISP_B double-encapsulated. Upon reception transits between ISP_A and ISP_B double-encapsulated. Upon reception
at the xTR of ISP_B the packet is decapsulated and sent towards Stub2 at the xTR of ISP_B the packet is decapsulated and sent towards Stub2
which performs the last decapsulation. which performs the last decapsulation.
This deployment scenario, which uses recursive LISP, includes two This deployment scenario, which uses recursive LISP, includes three
important caveats. First, it is intended to be deployed between only important caveats. First, it is intended to be deployed between only
two ISPs. If more than two ISPs use this approach, then the xTRs two ISPs. If more than two ISPs use this approach, then the xTRs
deployed at the participating ISPs must either query multiple mapping deployed at the participating ISPs must either query multiple mapping
systems, or the ISPs must agree on a common shared mapping system. systems, or the ISPs must agree on a common shared mapping system.
Furthemore, keeping this deployment scenario restricted to only two Furthermore, keeping this deployment scenario restricted to only two
ISPs maintains the solution scalable, given that only two entities ISPs maintains the solution scalable, given that only two entities
need to agree on using recursive LISP, and only one private mapping need to agree on using recursive LISP, and only one private mapping
system is involved. system is involved.
Second, the scenario is only recommended for ISPs providing Second, the scenario is only recommended for ISPs providing
connectivity to LISP sites, such that source RLOCs of packets to be connectivity to LISP sites, such that source RLOCs of packets to be
recursively encapsulated belong to said ISP. Otherwise the recursively encapsulated belong to said ISP. Otherwise the
participating ISPs must register prefixes they do not own in the participating ISPs must register prefixes they do not own in the
above mentioned private mapping system. Failure to follow these above mentioned private mapping system. This results in either
recommendations may lead to operational and security issues when requiring complex authentication mechanisms or enabling simple
deploying this scenario. traffic redirection attacks. Failure to follow these recommendations
may lead to operational security issues when deploying this scenario.
And third, recursive encapsulation models are typically complex to
troubleshoot and debug.
Besides these recommendations, the main disadvantages of this Besides these recommendations, the main disadvantages of this
deployment case are: deployment case are:
o Extra LISP header is needed. This increases the packet size and o Extra LISP header is needed. This increases the packet size and
requires that the MTU between both ISPs accommodates double- requires that the MTU between both ISPs accommodates double-
encapsulated packets. encapsulated packets.
o The ISP ITR must encapsulate packets and therefore must know the o The ISP ITR must encapsulate packets and therefore must know the
RLOC-to-RLOC binding. These bindings are stored in a mapping RLOC-to-RLOC binding. These bindings are stored in a mapping
database and may be cached in the ITR's mapping cache. Cache database and may be cached in the ITR's mapping cache. Cache
misses lead to an additional lookup latency, unless a push based misses lead to an additional lookup latency, unless a push based
mapping system is used for the private mapping system. mapping system is used for the private mapping system.
o The operational overhead of maintaining the shared mapping o The operational overhead of maintaining the shared mapping
database. database.
2.5. Tunnel Routers Behind NAT 2.3. Summary and Feature Matrix
NAT in this section refers to IPv4 network address and port
translation.
2.5.1. ITR
Packets encapsulated by an ITR are just UDP packets from a NAT
device's point of view, and they are handled like any UDP packet,
there are no additional requirements for LISP data packets.
Map-Requests sent by an ITR, which create the state in the NAT table,
have a different 5-tuple in the IP header than the Map-Reply
generated by the authoritative ETR. Since the source address of this
packet is different from the destination address of the request
packet, no state will be matched in the NAT table and the packet will
be dropped. To avoid this, the NAT device has to do the following:
o Send all UDP packets with source port 4342, regardless of the
destination port, to the RLOC of the ITR. The most simple way to
achieve this is configuring 1:1 NAT mode from the external RLOC of
the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer
broadband routers).
o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in
the payload.
This setup supports only a single ITR behind the NAT device.
2.5.2. ETR
An ETR placed behind NAT is reachable from the outside by the
Internet-facing locator of the NAT device. It needs to know this
locator (and configure a loopback interface with it), so that it can
use it in Map-Reply and Map-Register messages. Thus support for
dynamic locators for the mapping database is needed in LISP
equipment.
Again, only one ETR behind the NAT device is supported. When looking at the deployment scenarios and functional models above,
there are several things to consider when choosing the approprate
one, depending on the type of the organization doing the deployment.
2.5.3. Additional Notes For home users and small site who wish to multihome and have control
over their ISP options, the "CE" scenario offers the most advantages:
it's simple to deploy, in some cases it only requires a software
upgrade of the CPE, getting mapping serice, and configuring the
router. It ratains control of TE and choosing upstreams by the user.
It doesn't provide too many advantages to ISPs, due to the lessened
dependence on their services in case of multihomed clients. It is
also unlikely that ISP wiching to offer LISP to their customers will
choose the "CE" placement: they need to send a technician to each
customer, and potentially a new CPE. Even if they have remote
control over the router, and a software upgrade could add LISP
support, the operation is too risky.
An implication of the issues described above is that LISP sites with For a network operator a good option to deploy is the "PE" scenario,
xTRs can not be behind carrier based NATs, since two different sites unless a hardware upgrade is required for its edge routers to support
would collide on the port forwarding. An alternative to static hole- LISP (in which case upgrading CPEs may be simpler). It retains
punching to explore is the use of the Port Control Protocol (PCP) control of TE, choice of PETR, and MS/MR. It also lowers potential
[RFC6887]. MTU issues, as dicussed above. Network operators should also explore
the "Inter-SP TE" (recursive) functional model for their TE needs.
2.6. Summary and Feature Matrix Large organizations can benefit the most from the "Split ITR/ETR"
functional model, to optimize their traffic flow.
The following table gives a quick overview of the features supported The following table gives a quick overview of the features supported
by each of the deployment scenarios discussed above (marked with an by each of the deployment scenarios discussed above (marked with an
"x") in the appropriate column: "CE" for customer edge, "PE" for "x") in the appropriate column: "CE" for customer edge, "PE" for
provider edge, "Split" for split ITR/ETR, and "Recursive" for inter- provider edge, "Split" for split ITR/ETR, and "Recursive" for inter-
service provider traffic engineering. The discussed features service provider traffic engineering. The discussed features
include: include:
Control of ingress TE: The scenario allows the LISP site to easily Control of ingress TE: The scenario allows the LISP site to easily
control LISP ingress traffic engineering policies. control LISP ingress traffic engineering policies.
skipping to change at page 12, line 5 skipping to change at page 13, line 25
No modifcations to existing int. network infrastruncture: The No modifcations to existing int. network infrastruncture: The
scenario doesn't require the LISP site to modify internal network scenario doesn't require the LISP site to modify internal network
configurations. configurations.
Loc-Status-Bits sync: The scenario allows easy synchronization of Loc-Status-Bits sync: The scenario allows easy synchronization of
the Locator Status Bits. the Locator Status Bits.
MTU/PMTUD issues minimized: The scenario minimizes potential MTU and MTU/PMTUD issues minimized: The scenario minimizes potential MTU and
Path MTU Discovery issues. Path MTU Discovery issues.
Feature CE PE Split Recursive Feature CE PE Split Recursive NAT
------------------------------------------------------------- --------------------------------------------------------------------
Control of ingress TE x - x x Control of ingress TE x - x x x
No modifications to existing No modifications to existing
int. network infrastructure x x - - int. network infrastructure x x - - x
Loc-Status-Bits sync x - x x Loc-Status-Bits sync x - x x -
MTU/PMTUD issues minimized - x - - MTU/PMTUD issues minimized - x - - -
3. Map Resolvers and Map Servers 3. Map Resolvers and Map Servers
Map Resolvers and Map Servers make up the LISP mapping system and Map Resolvers and Map Servers make up the LISP mapping system and
provide a means to find authoritative EID-to-RLOC mapping provide a means to find authoritative EID-to-RLOC mapping
information, conforming to [RFC6833]. They are meant to be deployed information, conforming to [RFC6833]. They are meant to be deployed
in RLOC space, and their operation behind NAT is not supported. in RLOC space, and their operation behind NAT is not supported.
3.1. Map Servers 3.1. Map Servers
skipping to change at page 12, line 41 skipping to change at page 14, line 15
The Map Server is provided by a Mapping Service Provider (MSP). The The Map Server is provided by a Mapping Service Provider (MSP). The
MSP participates in the global distributed mapping database MSP participates in the global distributed mapping database
infrastructure, by setting up connections to other participants, infrastructure, by setting up connections to other participants,
according to the specific mapping system that is employed (e.g., ALT according to the specific mapping system that is employed (e.g., ALT
[RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping [RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping
database, and the storing of EID-to-RLOC mapping data is subject to database, and the storing of EID-to-RLOC mapping data is subject to
the policies of the "root" operators, who should check ownership the policies of the "root" operators, who should check ownership
rights for the EID prefixes stored in the database by participants. rights for the EID prefixes stored in the database by participants.
These policies are out of the scope of this document. These policies are out of the scope of this document.
The LISP DDT protocol is used by LISP Mapping Service providers to
provide reachability between those providers' Map-Resolvers and Map-
Servers. The DDT Root is currently operated by a collection of
organizations on an open basis. See [DDT-Root] for more details.
Similarly to the DNS root, it has several different server instances
using names of the letters of the Greek alphabet (alpha, delta,
etc.), operated by independent organizations. When this document was
published, there were 5 such instances, one of them being anycasted.
The Root provides the list of server instances on their web site and
configuration files for several map server implementations. The DDT
Root, and LISP Mapping Providers both rely on and abide by existing
allocation policies by Regional Internet Registries to determine
prefix ownership for use as EIDs.
It is expected that the DDT root organizations will continue to
evolve in response to experimentation with LISP deployments for
Internet edge multi-homing and VPN use cases.
In all cases, the MSP configures its Map Server(s) to publish the In all cases, the MSP configures its Map Server(s) to publish the
prefixes of its clients in the distributed mapping database and start prefixes of its clients in the distributed mapping database and start
encapsulating and forwarding Map-Requests to the ETRs of the AS. encapsulating and forwarding Map-Requests to the ETRs of the AS.
These ETRs register their prefix(es) with the Map Server(s) through These ETRs register their prefix(es) with the Map Server(s) through
periodic authenticated Map-Register messages. In this context, for periodic authenticated Map-Register messages. In this context, for
some LISP sites, there is a need for mechanisms to: some LISP sites, there is a need for mechanisms to:
o Automatically distribute EID prefix(es) shared keys between the o Automatically distribute EID prefix(es) shared keys between the
ETRs and the EID-registrar Map Server. ETRs and the EID-registrar Map Server.
skipping to change at page 16, line 11 skipping to change at page 17, line 49
still offer IPv6 to their clients, by providing a CPE device running still offer IPv6 to their clients, by providing a CPE device running
LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP
sites, with IPv6-only locators. Packets originating from the client sites, with IPv6-only locators. Packets originating from the client
LISP site for these destinations would be encapsulated towards the LISP site for these destinations would be encapsulated towards the
P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network,
decapsulating and forwarding packets. For non-LISP destination, the decapsulating and forwarding packets. For non-LISP destination, the
packet travels natively from the P-ETR. For LISP destinations with packet travels natively from the P-ETR. For LISP destinations with
IPv6-only locators, the packet will go through a P-ITR, in order to IPv6-only locators, the packet will go through a P-ITR, in order to
reach its destination. reach its destination.
For more details on P-ETRs see the [RFC6832] draft. For more details on P-ETRs see [RFC6832].
P-ETRs can be deployed by ISPs wishing to offer value-added services P-ETRs can be deployed by ISPs wishing to offer value-added services
to their customers. As is the case with P-ITRs, P-ETRs too may to their customers. As is the case with P-ITRs, P-ETRs too may
introduce path stretch (the ratio between the cost of the selected introduce path stretch (the ratio between the cost of the selected
path and that of the optimal path). Because of this the ISP needs to path and that of the optimal path). Because of this the ISP needs to
consider the tradeoff of using several devices, close to the consider the tradeoff of using several devices, close to the
customers, to minimize it, or few devices, farther away from the customers, to minimize it, or few devices, farther away from the
customers, minimizing cost instead. customers, minimizing cost instead.
Since the deployment incentives for P-ITRs and P-ETRs are different, Since the deployment incentives for P-ITRs and P-ETRs are different,
skipping to change at page 18, line 44 skipping to change at page 20, line 35
,-'' /`--. ,-'' /`--.
LISP site ---,' | v `. LISP site ---,' | v `.
( | DFZ )----- Mapping system ( | DFZ )----- Mapping system
non-LISP site ----. | ^ ,' non-LISP site ----. | ^ ,'
`--. / _.-' `--. / _.-'
| `--'' | `--''
v / v /
P-ITR P-ITR
PSP (AS64501) PSP (AS64501)
Figure 5: The P-ITR Route Distribution architecture Figure 7: The P-ITR Route Distribution architecture
The architecture described above decouples EID origination from route The architecture described above decouples EID origination from route
propagation, with the following benefits: propagation, with the following benefits:
o Can accurately represent business relationships between P-ITR o Can accurately represent business relationships between P-ITR
operators operators
o More mapping system agnostic o More mapping system agnostic
o Minor changes to P-ITR implementation, no changes to other o Minor changes to P-ITR implementation, no changes to other
skipping to change at page 19, line 19 skipping to change at page 21, line 9
In the example in the figure we have a MSP providing services to the In the example in the figure we have a MSP providing services to the
LISP site. The LISP site does not run BGP, and gets an EID LISP site. The LISP site does not run BGP, and gets an EID
allocation directly from a RIR, or from the MSP, who may be a LIR. allocation directly from a RIR, or from the MSP, who may be a LIR.
Existing PI allocations can be migrated as well. The MSP ensures the Existing PI allocations can be migrated as well. The MSP ensures the
presence of the prefix in the mapping system, and runs an EID Route presence of the prefix in the mapping system, and runs an EID Route
Server to distribute it to P-ITR service providers. Since the LISP Server to distribute it to P-ITR service providers. Since the LISP
site does not run BGP, the prefix will be originated with the AS site does not run BGP, the prefix will be originated with the AS
number of the MSP. number of the MSP.
In the simple case depicted in Figure 5 the EID-Route of LISP site In the simple case depicted in Figure 7 the EID-Route of LISP site
will be originated by the Route Server, and announced to the DFZ by will be originated by the Route Server, and announced to the DFZ by
the PSP's P-ITRs with AS path 64501 64500. From that point on, the the PSP's P-ITRs with AS path 64501 64500. From that point on, the
usual BGP dynamics apply. This way, routes announced by P-ITR are usual BGP dynamics apply. This way, routes announced by P-ITR are
still originated by the authoritative Route Server. Note that the still originated by the authoritative Route Server. Note that the
peering relationships between MSP/PSPs and those in the underlying peering relationships between MSP/PSPs and those in the underlying
forwarding plane may not be congruent, making the AS path to a P-ITR forwarding plane may not be congruent, making the AS path to a P-ITR
shorter than it is in reality. shorter than it is in reality.
The non-LISP site will select the best path towards the EID-prefix, The non-LISP site will select the best path towards the EID-prefix,
according to its local BGP policies. Since AS-path length is usually according to its local BGP policies. Since AS-path length is usually
skipping to change at page 21, line 7 skipping to change at page 22, line 46
attractive, slowing down the increase of the number of routes in the attractive, slowing down the increase of the number of routes in the
DFZ. DFZ.
Note that throughout Section 5 we focused on the effects of LISP Note that throughout Section 5 we focused on the effects of LISP
deployment on the DFZ route table size. Other metrics may be deployment on the DFZ route table size. Other metrics may be
impacted as well, but to the best of our knowlegde have not been impacted as well, but to the best of our knowlegde have not been
measured as of yet. measured as of yet.
6. Security Considerations 6. Security Considerations
Security implications of LISP deployments are to be discussed in All security implications of LISP deployments are to be discussed in
separate documents. [I-D.ietf-lisp-threats] gives an overview of separate documents. [I-D.ietf-lisp-threats] gives an overview of
LISP threat models, while securing mapping lookups is discussed in LISP threat models, while securing mapping lookups is discussed in
[I-D.ietf-lisp-sec]. [I-D.ietf-lisp-sec].
7. IANA Considerations 7. IANA Considerations
This memo includes no request to IANA. This memo includes no request to IANA.
8. Acknowledgements 8. Acknowledgements
skipping to change at page 21, line 43 skipping to change at page 23, line 36
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, Protocol (LISP) Map-Server Interface", RFC 6833,
January 2013. January 2013.
9.2. Informative References 9.2. Informative References
[DDT-Root]
"DDT Root", <http://ddt-root.org/>.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in
progress), March 2013. progress), March 2013.
[I-D.ietf-lisp-sec] [I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)", and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-04 (work in progress), October 2012. draft-ietf-lisp-sec-05 (work in progress), October 2013.
[I-D.ietf-lisp-threats] [I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-04 (work in progress), Analysis", draft-ietf-lisp-threats-08 (work in progress),
February 2013. October 2013.
[RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-
Network Tunneling", RFC 4459, April 2006. Network Tunneling", RFC 4459, April 2006.
[RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast
Services", BCP 126, RFC 4786, December 2006. Services", BCP 126, RFC 4786, December 2006.
[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.
 End of changes. 36 change blocks. 
120 lines changed or deleted 213 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/