One document matched: draft-wang-ietf-efit-00.txt
Network Working Group D. Massey
Internet-Draft Colorado State
Intended status: Informational L. Wang
Expires: August 29, 2007 U. Memphis
B. Zhang
U. Arizona
L. Zhang
UCLA
February 25, 2007
A Proposal for Scalable Internet Routing & Addressing
draft-wang-ietf-efit-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 29, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Massey, et al. Expires August 29, 2007 [Page 1]
Internet-Draft eFIT February 2007
Abstract
Our measurement studies of the global Internet routing system show
that prefix de-aggregation has led to the DFZ routing table size
growing at a rate which is much faster than the Internet itself. The
main causes of prefix de-aggregation include user site multihoming
and traffic engineering. We propose to move Internet service
providers to a separate address space as an effective solution to the
routing scalability problem. We discuss different means to provide
the mapping service between user and provider address spaces and the
pros and cons of each approach, as well as why we believe such an
architectural change is necessary to solve the routing scalability
problem.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The eFIT Proposal . . . . . . . . . . . . . . . . . . . . . . 5
3. How To Bridge The Two Spaces? . . . . . . . . . . . . . . . . 7
4. The Mapping Service . . . . . . . . . . . . . . . . . . . . . 8
5. Handling Border Link Failures . . . . . . . . . . . . . . . . 10
6. Related Efforts . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Putting users and providers into separate IP address
spaces . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. Location-Based Addressing . . . . . . . . . . . . . . . . 13
6.3. Summary of Previous and Ongoing Efforts . . . . . . . . . 13
7. Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
10. Security Considerations . . . . . . . . . . . . . . . . . . . 19
11. Informative References . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
Intellectual Property and Copyright Statements . . . . . . . . . . 22
Massey, et al. Expires August 29, 2007 [Page 2]
Internet-Draft eFIT February 2007
1. Introduction
Analysis of the routing tables in the default free zone (DFZ) reveals
important problems for Internet routing. The first and most
noticeable aspect is the growth in the table size. Our analysis of
data collected by RouteViews and RIPE BGP monitoring projects shows
that the DFZ routing table size has been growing at a much higher
rate than that of the routable address space in the Internet. At the
same time, it is well known that IPv4 address allocations are
constrained by the shortage of remaining IPv4 address space. An
(unintended) side effect of this shortage may be limiting the speed
of route table growth. When IPv6 deployment starts rolling out in a
wide scale and removes the current address space limits, we envision
that the DFZ routing table could substantially accelerate its growth.
By raising concerns over table size, we do not mean to imply that
growth is inherently bad. When managed correctly, growth in the
table size can reflect the increasing importance and increasing scale
of the network and is a sign of a healthy network. But the current
situation is an example of poorly managed growth. In today's
Internet routing and addressing architecture, both user sites and
Internet service providers share the same address and routing space.
But user sites and service providers do not share the same goals and
same challenges. From a provider perspective, the routing system
needs topologically aggregatable address assignment and usage. The
assignment and use of topologically aggregatable addresses could not
only reduce the table size, but enable better network routing by
creating more meaningful entries in the table. However enterprise
customers desire Provider-Independent (PI) address blocks in order to
maintain the freedom to switch between ISPs while avoiding
renumbering, and to ease multihoming which has become a universal
practice. From the perspective of a user site, multihoming is
necessary and should be encouraged to help provide a more robust
Internet. In fact, our data suggests that a main cause of the rapid
routing table growth is site multihoming. Transit providers and user
sites effectively seek opposite approaches to address allocation and
routing announcements with both sides supported by valid technical
and economic reasons. Overall, the global routing system is losing
the ground of topologically aggregatable address usage, as evidenced
by increasingly fragmented prefixes in BGP routing announcements.
These issues have also been identified in the report of IAB Workshop
on Routing and Addressing [RAWS].
Recognizing the direct conflicts between Internet users and ISPs with
regard to the IP address allocation and usage, we propose to solve
the global routing scalability problem by putting the ISPs in a
separate IP address space, where the addresses can be allocated in a
topologically aggregatable way to enable scalable routing. Data
Massey, et al. Expires August 29, 2007 [Page 3]
Internet-Draft eFIT February 2007
traffic between Internet users can be tunneled over the transit core,
in a way similar to VPNs which are widely used today for
interconnecting multiple sites of the same enterprise network across
the global Internet backbone. Our proposed solution is to tunnel all
data traffic between all user sites across the backbone. The
separate address spaces allows both providers and user sites to move
forward in a way that meets their respective technical and economic
objectives. It has further advantages for facilitating the roll-out
of IPv6 addresses since data is now tunneled across the core,
irrespective of whether the user site has deployed IPv4 or IPv6
addresses. Overall, we believe the approach has great promise for
both provider and user site view address allocations, route
announcements, and routing in general.
In the rest of this draft we describe the proposed solution in more
detail and outline the open issues in its implementation. We also
identify the pros and cons of different solutions to the open issues.
Massey, et al. Expires August 29, 2007 [Page 4]
Internet-Draft eFIT February 2007
2. The eFIT Proposal
The Internet is comprised of two types of networks: user networks and
transit provider networks. User networks correspond to business,
universities, and organizations. To them, the Internet is a means to
some end(s), i.e., they run applications to communicate with other
user networks over the Internet. On the other hand, transit networks
are ISPs, whose goal is to realize and sell end-to-end data delivery
service. The number of user networks is much larger than that of
transit networks. Moreover, user networks are growing at a faster
rate than transit networks which actively adjust their connectivity
in order to accommodate the growing user networks. These two types
of networks have different purposes, different growth trends, and
different operational goals. Putting them in the same address and
routing space has been the root cause for many problems as the
Internet grows substantially.
We propose to separate user networks and transit provider networks in
terms of both addressing and routing. First, user networks and
transit networks use separate address spaces, and their address
formats can be different. Second, their routing spaces are
separated. A provider routing protocol is operated among routers
inside the transit core to maintain routes to all the provider
networks only. The provider routing fundamentally differs from the
current BGP as it is confined within the provider space. Each user
network runs its own routing protocol to maintain routes to reach
internal subnets and its immediate neighbors (its providers or other
directly connected user networks). There is no routing protocol
operating across the links between the user networks and the transit
core.
A network becomes part of the provider space if it obtains a provider
address prefix and runs the provider routing protocol with other
transit providers. A user network can continue using its current
provider independent address block if it has one or it can obtain one
from a regional Internet registry. It can also use its current
intra-domain routing protocol.
End-to-end data delivery is achieved by tunneling user packets across
the provider space. When a user packet reaches the border of the
transit core, the ingress edge router will map the destination user
address to a provider address that directly connects to the
destination user network. The ingress edge router encapsulates the
user packet and sends it to the destination provider address. Once
the packet arrives at the other end of the tunnel, the egress edge
router will decapsulate it and send the original data packet into the
destination user network. A mapping service is needed to map user
addresses to corresponding provider addresses. It will be discussed
Massey, et al. Expires August 29, 2007 [Page 5]
Internet-Draft eFIT February 2007
in Section 4.
On the surface the encapsulation step in crossing the transit core
may bear a resemblance to NAT (Network Address Translation); however,
our proposal differs from NAT in fundamental ways. We assign unique
and provider-independent addresses to all hosts in user space, thus
they can be reached in the face of individual provider failures. Any
user host can directly talk to any other user host by simply putting
the destination address in the packet. Therefore our proposal helps
reinstall the end-to-end transparency model in the Internet.
Viewed from user networks, the provider space is a single logical hop
connecting all user networks, very much like a single "wire"
providing data transit service. Therefore, we call our proposal eFIT
(enable Future Internet innovation through Transit wire). In this
architecture, user networks and transit provider networks are
decoupled in both addressing and routing. It helps scale global
routing and also allow user networks and transit networks to evolve
independently.
With this separation, the routing table size of global DFZ routers is
under control, because it only needs to record routes to each
provider network, whose number is small and grows slowly. One
provider network may announce multiple prefixes. However, since the
addressing is separated from that of user networks, we can design the
format of provider addresses and allocate them in a way to encourage
aggregation. More importantly, the routing table will not be
inflated by user networks' multi-homing and traffic engineering
practices or the fast increase of user networks. Another benefit is
that the number of routing updates is under control for DFZ routers,
because the instability from user networks is insulated from the
transit core. Considering that there is a large and increasing
number of user networks, and some of them are the sources of frequent
routing instability, the separation will reduce the routing updates
in the transit core significantly. In short, since the global
routing is confined among provider networks only, its scalability
will be much better than that of today's Internet, and will also be
able to sustain Internet growth in the near future.
The separation is also beneficial to user networks. They will have
truly provider-independent addresses, which enable them to change
providers without renumbering. They may also have an address format
that is designed to best facilitate their internal routing. They can
explore different site multihoming and traffic engineering techniques
without affecting the scalability of the global routing system.
Massey, et al. Expires August 29, 2007 [Page 6]
Internet-Draft eFIT February 2007
3. How To Bridge The Two Spaces?
Separating the user networks and provider networks makes the global
routing system scale. But at the same time, end-to-end data delivery
also requires bridging the two spaces. Three mechanisms are
essential to the bridging.
First, a mapping service is needed to map each user address to its
provider attachment points, i.e., the egress transit router(s)
through which data packets can be delivered to the user address.
These egress transit routers are directly connected to the user
network that owns the particular user address.
Second, end-to-end data delivery across the transit core is achieved
by encapsulating user data packets in a provider space packet header,
whose source address is the ingress transit router connected to the
source user network, and whose destination address is the egress
transit router connected to the destination user network.
Third, the failures of links between user space and provider space
must be handled by a mechanism external to the routing system. In
eFIT, provider network routing and user network routing are confined
to their own space, while links between them are in neither space.
Therefore, failures of such border links are not reflected in either
provider routing or user routing. A mechanism is needed so that the
ingress transit router can stop sending data packets destined to the
failed link until it is up again.
In the next two section, we will discuss potential approaches to
implement the mapping service and handle border link failures.
Massey, et al. Expires August 29, 2007 [Page 7]
Internet-Draft eFIT February 2007
4. The Mapping Service
The basic functionality of the mapping service is that, given a
destination user address, it should return one or more destination
provider addresses so that the packet can be encapsulated and
forwarded across the transit core to reach the destination user
network.
The mapping service should be implemented by the transit core;
otherwise it will introduce another dependency between the two
spaces. Since the transit service providers are responsible for data
delivery between user networks, they have the incentive to provide
quick and secure mapping service.
In general, there are two types of approaches to implement this
service.
Flooding: This approach simply floods the mapping data through all
transit service providers; Each provider can then decide how it
may further distribute the information to its own edge routers.
An advantage of this approach is that the mapping information is
readily available locally at the edge routers, therefore packet
forwarding should not experience any significant delay from
looking up the mapping information. The disadvantage is that any
change in the mapping information must be proactively propagated
to all providers, even when the change may not affect any data
traffic. Given the number of user networks may grow at a rapid
rate, the dissemination system can potentially face a scalability
challenge.
Distributed Servers: this approach builds a system of distributed
servers that make the mapping information available through query
and reply. This system of servers can be implemented either in a
hierarchy such as that of the DNS, or in a flat structure such as
distributed hash tables (DHTs). One advantage is that a change in
the mapping information only results in a change to some servers,
rather than being proactively propagated globally. Another
advantage is that individual responsible parties can selectively
enhance their own mapping service through more replications or
fast servers. The disadvantage of this approach is that the
lookup process may add extra delay to packet forwarding. Caching
and prefetching popular mapping entries can provide effective
performance improvement, but with associated increase in system
complexity.
Overall, there are interesting trade-offs in each approach and
further research is needed.
Massey, et al. Expires August 29, 2007 [Page 8]
Internet-Draft eFIT February 2007
The basic mapping service essentially provides the binding between a
user address and its provider attachment points. This binding can be
used to support the migration from IPv4 to IPv6. For example, a user
network can move to IPv6 independently from whether its ISPs have
deployed IPv6, as long as the mapping service supports the mapping
between the IPv6 user address to the IPv4 provider addresses. The
mapping service also opens the door to new services or functionality.
For example, the mapping information could specify the address
owner's preferred traffic distribution among its multiple provider
attachment points, in order to load balance incoming traffic.
Massey, et al. Expires August 29, 2007 [Page 9]
Internet-Draft eFIT February 2007
5. Handling Border Link Failures
In this section, we discuss how to handle the failures of border
links between user networks and their providers effectively and
efficiently. We note that these failures could be treated as mapping
changes and thus handled by the mapping service directly, i.e.,
treating every link up and down as a change of the mapping
information. However, the link failures could occur much more
frequently than changes in business relationship such as a user
network subscribing to a new ISP. If the link failures are
propagated as mapping changes, a damping mechanism must be in place
to prevent a flapping link from overloading the mapping service with
its frequent status changes.
Below we discuss other options that do not necessarily involve the
mapping service, i.e., the link failures are not treated as mapping
changes.
1. Masking the failure via tunneling: This approach lets the egress
transit router mask the link failure by redirecting the packet to
another router that is also connected to the destination user
network; The first router can use the mapping service to find the
second router. This is a viable approach if both routers belong
to the same provider, or otherwise the first router may not have
the economic incentive to redirect the packet to a competitor.
2. Notifying ingress transit routers after the failure: this
approach notifies ingress transit routers about the link failure
so that they will stop sending data packets towards the failed
link for a period of time specified in the notification messages.
The propagation of such notification messages can be proactive or
reactive.
* In the proactive mode, the egress transit router sends the
failure notification to all the ingress transit routers
whenever the failure occurs, e.g., through a flooding
mechanism. However, this mode is appropriate only if the link
fails occasionally. Otherwise, a flapping link could lead to
frequent waves of failure notification messages flooded
everywhere. Note that if the mapping service is implemented
using flooding, this function could be (but does not have to
be) provided by the mapping service, except that the receiver
needs to know that this is a temporary failure, not a long-
term change. If the mapping service is implemented using a
network of servers, the proactive propagation of the
notification messages to the ingress transit routers needs to
be handled by a separate mechanism.
Massey, et al. Expires August 29, 2007 [Page 10]
Internet-Draft eFIT February 2007
* In the reactive mode, the router propagates the information
only to the ingress transit routers that are currently
communicating with the affected destination users. For
example, whenever the router receives a packet destined to the
other side of a failed link, it sends an ICMP packet back to
the the ingress transit router in the source provider network.
This approach has a lower control traffic overhead than the
proactive mode because it limits the impact to only active
sources. On the flip side, it incurs extra delay for the
first few packets sent to the destination, because the packets
get dropped and retransmissions will not succeed until the
notification message is received. Moreover, it could lead to
a lot of notification traffic if the egress router does not
keep track of which ingress routers have received its
notifications.
Overall, The tradeoff depends on the scale of the system and
failure impact. Proactive notification is more suitable where
the overhead of propagating updates everywhere is manageable and
when the destination is very popular. Reactive notification is
more suitable when the system is very large and the destination
has only a few active sources. Another critical problem is
security: How does the receiving router trust that the failure
notification message indeed comes from the egress transit router?
More research is needed to design an efficient and scalable
mechanism to handle border link failures.
Massey, et al. Expires August 29, 2007 [Page 11]
Internet-Draft eFIT February 2007
6. Related Efforts
The scalability problem of the existing addressing and routing
architecture has long been recognized. Over the years a number of
alternate routing designs have been proposed. The proposed solutions
share major goals of scalable support for multihoming and avoiding
user renumbering when switching providers, and their approaches fall
into one of the two categories, 1) putting user and provider into
separate address spaces and 2) encoding location information into IP
addresses. Although these designs were not (or have yet to be)
adopted for deployment, they offer important insights on the reasons
why they have yet to materialize.
6.1. Putting users and providers into separate IP address spaces
Recognizing the fundamental conflict between providers' desire for
prefix aggregation for routing scalability and user sites' desire for
provider-independent addresses to ease multihoming and avoid
renumbering, Hinden & Deering proposed ENCAPS in 1996 ([RFC1955],
[ENCAPS]). The basic idea is to separate provider networks and user
sites into two address spaces, and to use IP-in-IP tunnels to carry
packets from source user networks over the provider space to reach
destination user networks. Our eFIT proposal shares the same
solution direction with ENCAPS, so is another more recent effort LISP
[LISP] which sketched out an instantiation of ENCAPS implementation.
O'Dell made another new routing design, named GSE [GSE], in 1997.
The basic idea is to divide IPv6's 16-byte address into two parts,
with the lower N bytes being used for the End System Designator (ESD)
and local routing, and the higher (16 - N) bytes used for routing
between providers. [GSEOverview] provides a comprehensive analysis
of GSE's pros and cons, as well as the open issues in its
implementation.
In essence GSE uses the upper (16-N) bytes of IPv6 address to
represent the address space in the provider domain, hence GSE shares
the fundamental idea with ENCAPS in envisioning a network where
customers and providers live on separate address spaces. As such it
also shares with ENCAPS the need for a mapping service. ENCAPS needs
this mapping service to map the destination user address to the
address of the tunnel exit point which should be a router of the
provider serving the destination user, while GSE needs this mapping
service to map ESDs to the corresponding upper (16 - N) bytes of IPv6
addresses.
Massey, et al. Expires August 29, 2007 [Page 12]
Internet-Draft eFIT February 2007
6.2. Location-Based Addressing
Another way to allocate addresses in an aggregatable manner is to
base the allocation on locations, which was proposed by Deering in
early 90's [MetroAddr]. This approach can avoid user renumbering
when they change providers, as long as they stay in the same
location.
More recently a similar proposal, Geo-based addressing [GeoAddr] has
been made. Although this proposal has certain differences from
[MetroAddr], for example encoding latitude and longitude information
into the address instead of metro-area ID, the two proposals bear
fundamental similarities. They are both proposed as one of the ways,
but not necessarily the only way, to allocate IPv6 addresses, both
envisioned coexistence of location-based and provider-based
addresses, and which type to use would be based on the need of
individual parties.
However location-based addressing imposes two infeasible conditions
to the routing system. First, routing over location-based addresses
requires that ISPs interconnect at each location. Second, location-
based addresses do not reflect interconnectivity among providers to
enable routing policies.
6.3. Summary of Previous and Ongoing Efforts
As time goes, multiple solution development efforts have pointed to
the same direction of separating user sites and provider networks
into distinct address spaces in order to solve routing scalability
problem. We believe that this is not coincidental, but rather
showing a convincing sign that the separation is a right way forward.
We also believe that encoding location information into IP address
can serve very useful purposes. However solely location-based
addressing is problematic as it is unable to support routing
policies. We have an ongoing effort which proposes a new address
structure for the provider address space and utilizes location
information to facilitate scalable routing and traffic engineering.
Massey, et al. Expires August 29, 2007 [Page 13]
Internet-Draft eFIT February 2007
7. Summary
In concluding this draft we would like to clarify three important
points: (1) exactly what need to be separated, (2) the impact on
existing implementations, and (3) why we believe it is necessary to
separate ISPs from the user address space in order to solve the
routing scalability problem.
As far as the global routing scalability is concerned, the root cause
of the problem is due to user sites and ISPs live on the same address
and routing space, while each has goals conflicting with that of the
other. Thus our proposed solution calls for a separation of the
provider and user address spaces. The IAB workshop report [RAWS]
identified the same problem, although it phrased the problem as "the
overloading of IP address semantics". We would like to clarify that
the problem is not overloading address and identifier, but
overloading providers and end users on the same address space.
There may exist a need for host identifiers. For example a multi-
connected host may have multiple IP addresses, one for each of its
interfaces, and it may desire to move a running TCP connection from
one interface to another. This would require a host identifier that
is independent from IP addresses, such as the one defined by HIP
[HIP]. However deploying HIP alone is not a solution to the routing
scalability problem, even though it offers each host an identifier.
Both provider networks and user sites need IP addresses to manage
their networks and forward packets. One can envision a host
identifier solution being deployed on top of, but not in place of,
user IP addresses.
The second point is about the impact of our proposed solution on
currently deployed systems and protocols. eFIT and similar solutions
introduce a new component into the Internet architecture, the mapping
service. If we design the mapping service right, then by and large
all user sites and ISPs should be able to stay with their current
operational practice regarding packet transmission and forwarding,
with all user sites using provider-independent addresses and all ISPs
using topologically aggregatable addresses. The edge routers
connecting user sites to the transit core will need to be changed to
use the mapping service and tunnel packets over the transit core.
The last point we would like to stress is the necessity for deploying
our proposed solution (or a similar one in the same direction).
Putting ISPs in a separate IP address space for a scalable global
routing system requires a new mapping component to bridge the two
address spaces. Research efforts are needed to develop a reliable
and robust mapping service. This new mapping service will
necessarily bring additional complexity into the Internet
Massey, et al. Expires August 29, 2007 [Page 14]
Internet-Draft eFIT February 2007
architecture, thus a question naturally arises: why is it necessary
to change the existing addressing and routing architecture?
We believe the answer lies in the fact that the Internet has grown by
orders of magnitude. The existing address architecture of having all
the IP boxes living in the same address space was designed at the
birth of the Internet when it was very small in size. Today the
Internet has become the largest cohesive system we have ever built,
and perhaps the most important infrastructure for the society.
Different parts of Internet have become specialized to serve
different purposes, for example user sites are multi-homed for
enhanced reliability and performance, while service provider networks
are specialized for high performance, yet economical, packet delivery
service. The different goals of different parties brought different
and conflicting requirements to the shared address space. Thus the
original address architecture can no longer meet the functional
requirements of today's grown up Internet.
In a 1928 article by J. B. S. Haldane, "being the right size"
[RIGHTSIZE], the author illustrated the relation between the size and
complexity of biological entities through a vivid example. As stated
in the article, "a typical small animal, say a microscopic worm or
rotifer, has a smooth skin through which all the oxygen it requires
can soak in." However, "increase its dimensions tenfold in every
direction, and its weight is increased a thousand times, so that if
it is to use its muscles as efficiently as its miniature counterpart,
it will need a thousand times as much food and oxygen per day. Now
if its shape is unaltered its surface will be increased only a
hundredfold, and ten times as much oxygen must enter per minute
through each square millimeter of skin." That is why all large size
animals have lung, an organ specialized for soaking oxygen. The
author concludes that "for every type of animal there is a most
convenient size, and a large change in size inevitably carries with
it a change of form."
We believe the same is true for Internet. As it grows large in user
population size, it is no longer feasible for its transit core to
deliver packets by maintaining the reachability information of end
users. In addition, the transit core is also under competitive
market forces to maintain a modest cost in carrying out packet
delivery service. The growth makes it necessary for the transit core
to operate in a separate address space than the edge users, so that
each can evolve independently to fulfill its own role. We also
believe that this separation opens the door for adding new functions
and capabilities to the routing system; we will elaborate in more
detail in our future documents.
We would like to solicit the community's input and comments regarding
Massey, et al. Expires August 29, 2007 [Page 15]
Internet-Draft eFIT February 2007
moving the Internet routing and addressing architecture towards this
proposed direction. Comments can be sent directly to the authors.
Massey, et al. Expires August 29, 2007 [Page 16]
Internet-Draft eFIT February 2007
8. Acknowledgments
Our efforts on global routing system studies have been supported by
research fundings from DARPA and NSF.
Massey, et al. Expires August 29, 2007 [Page 17]
Internet-Draft eFIT February 2007
9. IANA Considerations
This document requires no actions by IANA.
Massey, et al. Expires August 29, 2007 [Page 18]
Internet-Draft eFIT February 2007
10. Security Considerations
The security of the global routing system is of great concern. This
document introduces a proposed solution to routing scalability
problem. The proposed solution has a potential to enhance routing
system security, although the specific design and evaluation are yet
to be carried out. The document is informational and it proposes no
new protocol or protocol usage, and as such presents no new security
issues.
Massey, et al. Expires August 29, 2007 [Page 19]
Internet-Draft eFIT February 2007
11. Informative References
[ENCAPS] Deering, S., "The Map & Encap Scheme for scalable IPv4
routing with portable site prefixes",
http://irl.cs.ucla.edu/references/Deering-encap.pdf,
March 1996.
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture
for IPv6", Internet Draft, http://www.watersprings.org/
pub/id/draft-ietf-ipngwg-gseaddr-00.txt, 1997.
[GSEOverview]
Zhang, L., "An Overview of Multihoming and Open Issues in
GSE", IETF Journal http://www.isoc.org/tools/blogs/
ietfjournal/?p=98#more-98, 2006.
[GeoAddr] Hain, T., "An IPv6 Provider-Independent Global Unicast
Address Format", Internet Draft, http://www.ietf.org/
internet-drafts/draft-hain-ipv6-pi-addr-10.txt,
August 2006.
[HIP] Moskowitz et al., R., "Host Identity Protocol", http://
www.ietf.org/internet-drafts/draft-ietf-hip-base-07.txt,
2007.
[LISP] Farinacci, D., Fuller, V., and D. Oran, "Locator/ID
Separation Protocol (LISP)", Internet Draft, http://
www.ietf.org/internet-drafts/draft-farinacci-lisp-00.txt,
2007.
[MetroAddr]
Deering, S. and R. Hinden, "IPv6 Metro Addressings",
http://irl.cs.ucla.edu/references/Deering-metro.txt,
March 1996.
[RAWS] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
Workshop on Routing and Addressing", Internet Draft, http:
//www.ietf.org/internet-drafts/
draft-iab-raws-report-01.txt, 2007.
[RFC1955] Hinden, R., "New Scheme for Internet Routing and
Addressing (ENCAPS) for IPNG", RFC 1955 , June 1996.
[RIGHTSIZE]
Haldane, J., "Being the Right Size",
http://irl.cs.ucla.edu/papers/right-size.html, 1928.
Massey, et al. Expires August 29, 2007 [Page 20]
Internet-Draft eFIT February 2007
Authors' Addresses
Dan Massey
Colorado State
Email: massey@cs.colostate.edu
Lan Wang
U. Memphis
Email: lanwang@memphis.edu
Beichuan Zhang
U. Arizona
Email: bzhang@cs.arizona.edu
Lixia Zhang
UCLA
Email: lixia@cs.ucla.edu
Massey, et al. Expires August 29, 2007 [Page 21]
Internet-Draft eFIT February 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Massey, et al. Expires August 29, 2007 [Page 22]
| PAFTECH AB 2003-2026 | 2026-04-22 04:47:19 |