draft-ietf-ipngwg-esd-analysis-02.txt   draft-ietf-ipngwg-esd-analysis-03.txt 
INTERNET-DRAFT Matt Crawford INTERNET-DRAFT Matt Crawford
Fermilab Fermilab
<draft-ietf-ipngwg-esd-analysis-02.txt> Allison Mankin <draft-ietf-ipngwg-esd-analysis-03.txt> Allison Mankin
ISI ISI
Thomas Narten Thomas Narten
IBM IBM
John W. Stewart, III John W. Stewart, III
Juniper Juniper
Lixia Zhang Lixia Zhang
UCLA UCLA
March 13, 1998 November 18, 1998
Separating Identifiers and Locators in Addresses: Separating Identifiers and Locators in Addresses:
An Analysis of the GSE Proposal for IPv6 An Analysis of the GSE Proposal for IPv6
<draft-ietf-ipngwg-esd-analysis-02.txt> <draft-ietf-ipngwg-esd-analysis-03.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
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."
To learn the current status of any Internet-Draft, please check the To view the entire list of current Internet-Drafts, please check the
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net (US East Coast), nic.nordu.net Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim). Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This Internet-Draft expires May 7, 1998. This Internet-Draft expires May 15, 1999.
Abstract Abstract
On February 27-28, 1997, the IPng Working Group held an interim On February 27-28, 1997, the IPng Working Group held an interim
meeting in Palo Alto, California to consider adopting Mike O'Dell's meeting in Palo Alto, California to consider adopting Mike O'Dell's
"GSE - An Alternate Addressing Architecture for IPv6" proposal [GSE]. 'GSE - An Alternate Addressing Architecture for IPv6' proposal [GSE].
In GSE, 16-byte IPv6 addresses are split into distinct portions for In GSE, 16-byte IPv6 addresses are split into distinct portions for
global routing, local routing and end-point identification. GSE global routing, local routing and end-point identification. GSE
includes the feature of configuring a node internal to a site with includes the feature of configuring a node internal to a site with
only the local routing and end-point identfication portions of the only the local routing and end-point identification portions of the
address, thus hiding the full address from the node. When such a node address, thus hiding the full address from the node. When such a
generates a packet, only the low-order bytes of the source address node generates a packet, only the low-order bytes of the source
are specified; the high-order bytes of the address are filled in by a address are specified; the high-order bytes of the address are filled
border router when the packet leaves the site. in by a border router when the packet leaves the site.
There is a long history of a vague assertion in certain circles that There is a long history of a vague assertion in certain circles that
IPv4 "got it wrong" by treating its addresses simultaneously as IPv4 'got it wrong' by treating its addresses simultaneously as
locators and identifiers. Despite these claims, however, there was locators and identifiers. Despite these claims, however, there was
never a complete proposal for a scaleable network protocol which never a complete proposal for a scaleable network protocol which
separated the functions. As a result, it wasn't possible to do a separated the functions. As a result, it wasn't possible to do a
serious analysis comparing and contrasting a "separated" architecture serious analysis comparing and contrasting a 'separated' architecture
and an "overloaded" architecture. The GSE proposal serves as a and an 'overloaded' architecture. The GSE proposal serves as a
vehicle for just such an analysis, and that is the purpose of this vehicle for just such an analysis, and that is the purpose of this
paper. paper.
We conclude that an architecture that clearly separates locators and We conclude that an architecture that clearly separates locators and
indentifiers in addresses introduces new issues and problems that do identifiers in addresses introduces new issues and problems that do
not have an easy or clear solution. Indeed, the alleged disadvantages not have an easy or clear solution. Indeed, the alleged
of overloading addresses turn out to provide some significant disadvantages of overloading addresses turn out to provide some
benefits over the non-overloaded approach. significant benefits over the non-overloaded approach.
Contents Contents
Status of this Memo.......................................... 1 Status of this Memo.......................................... 1
1. Introduction............................................. 3 1. Introduction............................................. 3
2. Definitions and Terminology.............................. 4 2. Definitions and Terminology.............................. 4
3. Addressing and Routing in IPv4........................... 5 3. Addressing and Routing in IPv4........................... 5
3.1. The Need for Aggregation............................ 7 3.1. The Need for Aggregation............................ 7
3.2. The Pre-CIDR Internet............................... 7 3.2. The Pre-CIDR Internet............................... 7
3.3. CIDR and Provider-Based Addressing.................. 8 3.3. CIDR and Provider-Based Addressing.................. 9
3.4. Multi-Homing and Aggregation........................ 12 3.4. Multi-Homed Sites and Aggregation................... 12
4. The GSE Proposal......................................... 14 4. The GSE Proposal......................................... 15
4.1. Motivation For GSE.................................. 14 4.1. Motivation For GSE.................................. 15
4.2. GSE Address Format.................................. 15 4.2. GSE Address Format.................................. 16
4.2.1. Routing Stuff (RG and STP)..................... 15 4.2.1. Routing Stuff (RG and STP)..................... 16
4.2.2. End-System Designator.......................... 17 4.2.2. End-System Designator.......................... 18
4.3. Address Rewriting by Border Routers................. 18 4.3. Address Rewriting by Border Routers................. 19
4.4. Renumbering and Rehoming Mid-Level ISPs............. 19 4.4. Renumbering and Rehoming Mid-Level ISPs............. 20
4.5. Support for Multi-Homed Sites....................... 20 4.5. Support for Multi-Homed Sites....................... 21
4.6. Explicit Non-Goals for GSE.......................... 21 4.6. Explicit Non-Goals for GSE.......................... 22
5. Analysis: The Pros and Cons of Overloading Addresses..... 21 5. Analysis: The Pros and Cons of Overloading Addresses..... 22
5.1. Purpose of an Identifier............................ 22 5.1. Purpose of an Identifier............................ 23
5.2. Mapping an Identifier to a Locator.................. 24 5.2. Mapping an Identifier to a Locator.................. 25
5.2.1. Scalable Mapping of Identifers to Locators..... 25 5.2.1. Scalable Mapping of Identifiers to Locators.... 27
5.2.2. Insufficient Hierarchy Space in ESDs........... 26 5.2.2. Insufficient Hierarchy Space in ESDs........... 28
5.2.3. Reverse Mapping of Complete GSE Addresses...... 27 5.3. Authentication of Identifiers....................... 28
5.2.4. DNS-Like Reverse Mapping of Full GSE Addresses. 27 5.3.1. Identifier Authentication in IPv4.............. 29
5.2.5. The ICMP Who-Are-You Message................... 28 5.3.2. Identifier Authentication in GSE............... 30
5.3. Authentication of Identifiers....................... 29 5.4. Transport Layer: What Locator Should Be Used?....... 30
5.3.1. Identifier Authentication in IPv4.............. 30 5.4.1. RG Selection On An Active Open................. 31
5.3.2. Identifier Authentication in GSE............... 31 5.4.2. RG Selection On An Passive Open................ 31
5.3.3. Transport Layer: What Locator Should Be Used?.. 31 5.4.3. Mid-Connection RG Changes...................... 32
5.3.4. RG Selection On An Active Open................. 32 5.4.4. The Impact of Corrupted Routing Goop........... 33
5.3.5. RG Selection On An Passive Open................ 32 5.5. On The Uniqueness Of ESDs........................... 34
5.3.6. Mid-Connection RG Changes...................... 32 5.5.1. Impact of Duplicate ESDs....................... 34
5.3.7. The Impact of Corrupt Routing Goop............. 33 5.5.2. New Denial of Service Attacks.................. 35
5.3.8. On The Uniqueness Of ESDs...................... 35 5.6. Summary of Identifier Authentication Issues......... 36
5.3.9. New Denial of Service Attacks.................. 36
5.3.10. Summary of Identifier Authentication Issues... 36
5.4. Miscellaneous....................................... 38
5.4.1. Renumbering and Domain Name System (DNS) Issues 38
5.4.2. How Frequently Can We Renumber?................ 38
5.4.3. Efficient DNS support for Site Renumbering..... 39
5.4.4. Two-Faced DNS.................................. 40
5.4.5. Bootstrapping Issues........................... 41
6. Conclusion............................................... 41 6. Conclusion............................................... 37
7. Security Considerations.................................. 42 7. Security Considerations.................................. 38
8. Acknowledgments.......................................... 42 8. Acknowledgments.......................................... 38
9. References............................................... 43 9. References............................................... 39
10. Authors' Addresses...................................... 44 10. Authors' Addresses...................................... 40
Appendix A: Increased Reliance on Domain Name System (DNS)... 41
Appendix B: Additional Issues Related to GSE................. 45
Appendix C: Ideas Incorporated Into IPv6..................... 46
Appendix D: Reverse Mapping of Complete GSE Addresses........ 47
1. Introduction 1. Introduction
In October of 1996, Mike O'Dell published an Internet-Draft (dubbed In October of 1996, Mike O'Dell published an Internet-Draft (dubbed
"8+8") that proposed significant changes to the IPv6 addressing "8+8") that proposed significant changes to the IPv6 unicast
architecture. The 8+8 proposal was the topic of considerable addressing architecture. The 8+8 proposal was the topic of
discussion at the December 1996 IETF meeting in San Jose. Because the considerable discussion at the December 1996 IETF meeting in San
proposal offered both potential benefits (e.g., enhanced routing Jose. Because the proposal offered both potential benefits (e.g.,
scalability) and risks (e.g., changes to the basic IPv6 enhanced routing scalability) and risks (e.g., changes to the basic
architecture), the IPng Working Group held an interim meeting on IPv6 architecture), the IPng Working Group held an interim meeting on
February 27-28, 1997 to consider adopting the 8+8 proposal. February 27-28, 1997 to consider adopting the 8+8 proposal.
Shortly before the interim meeting, an updated version of the Shortly before the interim meeting, an updated version of the
Internet-Draft was produced. This version changed the name of the Internet-Draft was produced. This version changed the name of the
proposal from "8+8" to "GSE" to identify the three separate proposal from "8+8" to "GSE" to identify the three separate
components of the address: Global, Site and End-System Designator. components of a unicast address: Global, Site and End-System
Designator.
The well-attended meeting generated high caliber, focused technical The well-attended meeting generated high caliber, focused technical
discussions on the issues involved, with participation by almost all discussions on the issues involved, with participation by almost all
of the attendees. By the middle of the second day there was unanimous of the attendees. By the middle of the second day there was
agreement that the GSE proposal as written presented too many risks unanimous agreement that the GSE proposal as written presented too
and should not be adopted as the basis for IPv6. The proposal did, many risks and should not be adopted as the basis for IPv6. The
however, challenge the group to make improvements to the then proposal did, however, challenge the group to make several
existing IPv6 specifications (e.g., increasing the aggregatability of improvements to the then existing IPv6 specifications (including
addresses, having hard boundaries in addresses between routing parts increasing the aggregatability of addresses, having hard boundaries
and non-routing parts and easing the DNS aspects of renumbering). between routing and non-routing parts of the address, and easing the
DNS aspects of renumbering).
This document focuses primarily on the issue of separating addresses This document focuses primarily on the issue of separating unicast
into distinct portions for identification and location: a separation addresses into distinct portions for identification and location
that GSE has but IPv4 does not. We start with a discussion of the purposes, a separation that IPv4 does not make but that is
current architecture of IPv4 addressing and its impact on route fundamental to GSE. We start with a discussion of the current
scalability, identification, multi-homing, etc. Next, the details of architecture of IPv4 addressing and its impact on route scalability,
the GSE proposal are described. Finally, the fundamental issue of identification, multi-homing, etc. Next, the details of the GSE
proposal are described. Finally, the fundamental issue of
decomposing addresses into multiple separate functional parts is decomposing addresses into multiple separate functional parts is
analyzed in the context of the GSE proposal. Here we detail some of analyzed in the context of the GSE proposal. Here we detail some of
the practical reasons why separating addresses into locators and the practical reasons why separating addresses into locators and
identifier poses a number of challenging problems, making it clear identifier poses a number of new challenges, making it clear that
that having such a separation is no panacea. An appendix contains a having such a separation is no panacea. An appendix contains a
summary of the IPng Working Group's deliberations of GSE and the summary of the IPng Working Group's deliberations of GSE and the
results on IPv6 addressing. results on IPv6 addressing.
Finally, this document's focus on unicast issues should not be
interpreted to mean that the impact of separating identifier and
locating functions on non-unicast aspects of routing and addressing
are well understood or trivial to deal with. Specifically,
understanding how multicasting and anycast addressing [ANYCAST,
RFC1884] fits into such a model requires further work.
2. Definitions and Terminology 2. Definitions and Terminology
The following terminology is used throughout this document. The following terminology is used throughout this document.
Routing Goop --- A term defined by the GSE document that refers to Routing Goop --- A term defined by the GSE document. It refers to
first six bytes of an IPv6 GSE address. The Routing the first six bytes of a sixteen byte IPv6 GSE
Goop portion of an address identifies where a site address. The Routing Goop portion of an address
connects to the public Internet. More generally, identifies where a site connects to the public
the term refers to the portion of an address's Internet. More generally, the term refers to the
routing prefix that identifies where a site at which portion of an address's routing prefix that
an address resides connects to the public Internet. identifies where on the public Internet the site
housing the address resides.
Site Topology Partition --- A term defined by the GSE document Site Topology Partition --- A term defined by the GSE document
that refers to the two bytes of an IPv6 GSE address that refers to the two bytes of a sixteen byte IPv6
immediately to the right of the Routing Goop. The GSE address immediately to the right of the Routing
Site Topology Partition part of an address Goop. The Site Topology Partition part of an
identifies which link within a site an address address identifies which link within a site an
resides on. address resides on.
Routing Stuff --- The part of an address that identifies which Routing Stuff --- The part of an address that identifies which
link the address resides on. Within the context of link the address resides on. Within the context of
GSE, the Routing Goop and Site Topology Partition GSE, the Routing Stuff comprises the Routing Goop
parts of an address comprise the Routing Stuff. and Site Topology Partition parts of an address
(i.e., the left mots eight bytes).
identifier --- a value that indicates the sender of a packet, or identifier --- a value that indicates the sender of a packet, or
the intended recipient of a packet. Within the the intended recipient of a packet. Within the
context of GSE, the ESD portion of the address is an context of GSE, the ESD portion (i.e., the rightmost
identifier. eight bytes) of the address is an identifier.
locator --- a field in a packet header that is used by the routing locator --- a field in a packet header that is used by the routing
subsystem to deliver a packet to the link on which a subsystem to deliver a packet to the link on which a
destination resides. The terms locator and Routing destination resides. The terms locator and Routing
Stuff are similar, we use Routing Stuff when Stuff are similar, we use Routing Stuff when
referring to the specific locator in GSE. referring to the specific locator in GSE.
3. Addressing and Routing in IPv4 3. Addressing and Routing in IPv4
Before dealing with details of GSE, we present some background about Before dealing with details of GSE, we present some background about
how routing and addressing works in "classical IP" (i.e., IPv4). We how routing and addressing works in "classical IP" (i.e., IPv4). We
present this background because the GSE proposal proposes a fairly present this background because the GSE proposal proposes a fairly
major change to the base model. In order to properly evaluate GSE, major change to the base model. In order to properly evaluate GSE,
one must understand what problems in IPv4 it alleges to improve or one must understand what problems in IPv4 it alleges to improve or
fix. fix.
The structure and semantics of a network layer protocol's addresses The structure and semantics of a network layer protocol's addresses
are absolutely core to that protocol. Addressing substantially are absolutely core to that protocol. Addressing substantially
impacts the way packets are routed, the ability of a protocol to impacts the way packets are routed, the ability of a protocol to
scale and the kinds of functionality higher layer protocols can scale and the kinds of functionality higher layer protocols can count
provide. Indeed, addressing is intertwined with both routing and on. Indeed, addressing is intertwined with both routing and
transport layer issues; a change in any one of these can impact transport layer issues; a change in any one of these can impact
another. Issues of administration and operation (e.g., address another. Issues of administration and operation (e.g., address
allocation and required renumbering), while not part of the pure allocation/re-allocation and required renumbering), while not part of
exercise of engineering a network layer protocol, turn out to be the pure exercise of engineering a network layer protocol, turn out
critical to the scalability of that protocol in a global and to be critical to the scalability of that protocol in a global and
commercial network. The interaction between addressing, routing and commercial network. The interaction between addressing, routing and
especially aggregation is particularly relevant to this document, so especially aggregation is particularly relevant to this document, so
some time will be spent describing it. some time will be spent describing it.
Addresses in IPv4 serve two purposes: Addresses in IPv4 serve two purposes:
1) Unique identification of an interface. A sending host tells the 1) Unique identification of an interface. A sending host tells the
network the identity of the intended recipient by placing an IP network the identity of the intended recipient by placing an IP
address into the destination address field. In addition, the address into the destination address field. In addition, the
receiving host checks the destination address field of received receiving host checks the destination address field of received
packets to ensure that the packet is, in fact, for it. packets to ensure that the packet is, in fact, for it.
2) Location information of that interface. Routers use the packet's 2) Location information of that interface. Routers use the
destination address in deciding where to forward the packet to packet's destination address in deciding where to forward the
get it closer to its ultimate destination. That is, addresses packet to get it closer to its ultimate destination. That is,
identify "where" the intended recipient is located within the addresses identify "where" the intended recipient is located
Internet topology. within the Internet topology.
For scalability, the location information contained in addresses For scalability, the location information contained in addresses
must be aggregatable. In practice, this means that nodes must be aggregatable. In practice, this means that nodes
topologically close to each other (e.g., connected to the same topologically close to each other (e.g., connected to the same
link, residing at the same site, or customers of the same ISP) link, residing at the same site, or customers of the same ISP)
must use addresses that share a common prefix. must use addresses that share a common prefix.
What is important to note is that these identification and location What is important to note is that these identification and location
requirements have been met through the use of the same value, namely requirements have been met through the use of the same value, namely
the IP address. As will be noted repeatedly in this document, the the IP address. As will be noted repeatedly in this document, the
"overloading" of IPv4 addresses with multiple semantics has some "overloading" of IPv4 addresses with multiple semantics has some
undesirable implications. For example, the embedding of IPv4 undesirable implications. For example, the embedding of IPv4
addresses within transport protocol addresses that identify the end- addresses within transport protocol addresses that identify the end-
point of a connection couples those transport protocols with routing. point of a connection couples those transport protocols with routing
This entanglement is inconsistent with a strictly layered model in to a degree. This entanglement is inconsistent with a (too) strictly
which routing would be a completely independent function of the layered model in which routing would be a completely independent
network layer and not directly impact the transport layer. function of the network layer and not directly impact the transport
layer.
Combining locator and identifier functions also has the practical Combining locator and identifier functions also complicates the
impact of complicating the support for mobility. In a mobile support for mobility. In a mobile environment, the location of an
environment, the location of an end-station may change even though end-station may change even though its identity stays the same;
its identity stays the same; ideally, transport connections should be ideally, transport connections should be able to survive such
able to survive such changes. In IPv4, however, one cannot change the changes. In IPv4, however, one cannot change the locator without
locator without also changing the identifier. also changing the identifier since the same packet field is used for
both.
Consequently, there has been a train of thought for some time has Consequently, there has been a train of thought for some time that
been that having separate values for location and identification having separate values for location and identification could be of
could be of significant benefit. The GSE proposal, among other significant benefit. The GSE proposal, among other things, attempts
things, attempts to make such a separation. to make such a separation.
This document frequently uses mobility as an example to demonstrate This document frequently uses mobility as an example to demonstrate
the pros and cons of separating the identifier from the locator. the pros and cons of separating the identifier from the locator.
However, the reader should note the fundamental equivalence between However, the reader should note the fundamental equivalence between
the problems faced by mobile hosts and the problem faced by sites the problems faced by mobile hosts and the problem faced by sites
that change providers yet don't want to renumber their network. When that change providers yet don't want to renumber their network. When
a site changes providers, it moves topologically in much the same way a site changes providers, it moves topologically in much the same way
a mobile node does when it moves from one place to another. a mobile node does when it moves from one place to another.
Consequently, techniques that help or hinder mobility are often Consequently, techniques that help or hinder mobility are often
relevant to the issue of site renumbering. relevant to the issue of site renumbering.
3.1. The Need for Aggregation 3.1. The Need for Aggregation
IPv4 has seen a number of different addressing schemes. Since the IPv4 has seen a number of different addressing schemes. Since the
original specification, the two major additions have been subnetting original specification, the two major additions have been subnetting
and classless routing. The motivation for adding subnetting was to and classless routing. The motivation for adding subnetting was to
allow a collection of networks located at one site to be viewed from allow a collection of networks located at one site to be viewed from
afar as a single IP network (i.e., to aggregate all of the individual afar as a single IP network (i.e., to aggregate all of the individual
networks into one bigger network). The practical benefit of networks into a single bigger network). The practical benefit of
subnetting was that all of a site's hosts, even if scattered among subnetting was that all of a site's hosts, even if scattered among
tens or hundreds of LANs, could be represented with a single routing tens or hundreds of LANs, could be represented by a single routing
table entry in routers located far from the site. In contrast, prior table entry in routers located far from the site. In contrast, prior
to subnetting, a site with ten LANs would advertise ten separate to subnetting, a site with ten LANs would advertise ten separate
network entries, and all routers would have to maintain ten separate network entries, and all routers would have to maintain ten separate
entries, even though they contained essentially redundant entries, even though they contained essentially redundant
information. information.
The benefits of aggregation should be clear. The amount of work The benefits of aggregation should be clear. The amount of work
involved in constructing forwarding tables (i.e., selecting best involved in constructing forwarding tables (i.e., selecting best
routes and installing them into the switching subsystem) is dependent routes and installing them into the switching subsystem) is dependent
in part on the number of network routes (i.e., destinations) to which in part on the number of network routes (i.e., destinations) to which
skipping to change at page 7, line 36 skipping to change at page 7, line 46
each of those networks is individually advertised to the global each of those networks is individually advertised to the global
routing system, the complexity of computing forwarding tables can routing system, the complexity of computing forwarding tables can
easily be an order of magnitude greater than if each site advertised easily be an order of magnitude greater than if each site advertised
a single entry that covered all of the addresses used within the a single entry that covered all of the addresses used within the
site. site.
3.2. The Pre-CIDR Internet 3.2. The Pre-CIDR Internet
In the early days of the Internet, its topology and addressing were In the early days of the Internet, its topology and addressing were
orthogonal. Specifically, when a site wanted to connect to the orthogonal. Specifically, when a site wanted to connect to the
Internet, it approached a centralized address allocation authority to Internet, it approached the central Internet Assigned Numbers
obtain an address and then approached a provider about procuring Authority (IANA) to obtain an address block and then approached a
connectivity. This procedure for address allocation resulted in a provider about procuring connectivity. This procedure for address
system where the addresses used by customers of the same provider allocation resulted in a system where the addresses used by customers
bore little relation to the addresses used by other customers of that of the same provider bore little relation to the addresses used by
same provider. In other words, though the topology of the Internet other customers of that same provider. In other words, though the
was mostly hierarchical, the addressing was not. An example of such a actual topology of the Internet was mostly hierarchical, the
topology and addressing scheme is shown in Figure 1. addressing was not. An example of such a topology and addressing
scheme is shown in Figure 1.
+----------------+ +----------------+
| |------- Customer1 (192.2.2.0) | |------- Customer1 (192.2.2.0)
| |------- Customer2 (128.128.0.0) | |------- Customer2 (128.128.0.0)
| Provider A |------- Customer3 (18.0.0.0) | Provider A |------- Customer3 (18.0.0.0)
| |------- Customer4 (193.3.3.0) | |------- Customer4 (193.3.3.0)
| |------- Customer5 (194.4.4.0) | |------- Customer5 (194.4.4.0)
+----------------+ +----------------+
| |
| |
skipping to change at page 8, line 36 skipping to change at page 8, line 40
for each of the 5 networks. That is, the routers within Provider B for each of the 5 networks. That is, the routers within Provider B
must have explicit routing entries for each of Provider A's customers must have explicit routing entries for each of Provider A's customers
-- 5 separate routes. -- 5 separate routes.
Experience has shown that this approach scales very poorly. In the Experience has shown that this approach scales very poorly. In the
Default-Free Zone (DFZ) of the Public Internet, where routers must Default-Free Zone (DFZ) of the Public Internet, where routers must
maintain routing entries for all reachable destinations, the cost of maintain routing entries for all reachable destinations, the cost of
computing forwarding tables quickly becomes unacceptably large. A computing forwarding tables quickly becomes unacceptably large. A
large part of the cost is related to the seemingly redundant large part of the cost is related to the seemingly redundant
computations that must be made for each individual network, even computations that must be made for each individual network, even
though the reality is that many reside in the same topological though many of them reside in the same topological location (e.g.,
location (e.g., under the same provider). Looking at Figure 1, the under the same provider). Looking at Figure 1, the problem is that
problem is that provider B performs 5 separate calculations to provider B performs 5 separate calculations to construct the
construct the forwarding table needed to reach each of A's customers. forwarding table needed to reach each of A's customers, even though
Said another way, from Provider B's perspective, it doesn't matter it is going to take the same path for all of them; in other words,
where Provider A's customers connect to Provider A because Provider B there is an opportunity to do data abstraction.
is going to take the same path for all of them; in other words, there
is an opportunity to do data abstraction. Figure 1 shows network numbers using the older "classful" notation.
Since 1981, the first few bits of an address syntactically identified
which parts of an address identified the "network" and "local"
portions of an address. There were a small number of Class A
addresses (intended for very large sites), a medium number of Class B
addresses (for medium-sized sites) and a very large number of Class C
addresses (for very small sites). In practice, the actual size of
real networks didn't match the original allocation of Class A, B, and
C addresses. Class B addresses were bigger than most sites needed
(and there weren't enough of them), and Class C addresses were too
small (i.e., typical sites would need to get 10 or more C blocks to
cover all of the hosts on their networks). Consequently, classless
addressing was developed [CIDR], which made the boundaries between
the network and local parts of an address more flexible. With
classless addressing, a separate prefix-length (i.e., network mask)
specifies how many of the left-most bits of an address identify the
network part of the address.
3.3. CIDR and Provider-Based Addressing 3.3. CIDR and Provider-Based Addressing
One of the reasons CIDR (Classless Inter-Domain Routing) and its One of the reasons CIDR (Classless Inter-Domain Routing) and its
associated provider-assigned address allocation policy were associated provider-assigned address allocation policy were
introduced was to help reduce the size of a routing table and the introduced was to help reduce the cost of computing a routing table
complexity of computing a forwarding table from that routing table. and the size of the forwarding table computed from the routing table.
To achieve this goal CIDR aggressively aggregates network addresses.
CIDR does this by aggressively aggregating network addresses.
Aggregating network addresses means "merging" multiple addresses into Aggregating network addresses means "merging" multiple addresses into
a single "bigger" one. In CIDR, this means that addresses share a a single "bigger" one, that is to use a common prefix to provide
common prefix. The common prefix provides location information for location information for all addresses sharing that same prefix.
all addresses sharing that same prefix.
With CIDR, sites that want to connect to the Internet approach a With CIDR, sites that want to connect to the Internet approach a
provider to procure both connectivity and a network address. provider to procure both connectivity and a network address.
Individual providers have a block of address space covered by one Individual providers have a block of address space covered by one
prefix and assign pieces of that space to customers. Consequently, prefix and assign pieces of that space to customers. Consequently,
customers of the same provider have addresses that share the same customers of the same provider have addresses that share the same
prefix. Note that CIDR started to use the term "prefix" to refer to a prefix. The combination of CIDR and provider-based addressing
classless network. The combination of CIDR and provider-based results in the ability of a provider to address many hundreds of
addressing results in the ability of a provider to address many sites while introducing just one network address into the global
hundreds of sites while introducing just one network address into the routing system. An example of such a topology and addressing scheme
global routing system. An example of such a topology and addressing is shown in Figure 2.
scheme is shown in Figure 2.
+----------------+ +----------------+
| |------- Customer1 (204.1.0.0/19) | |------- Customer1 (204.1.0.0/19)
| |------- Customer2 (204.1.32.0/23) | |------- Customer2 (204.1.32.0/23)
| Provider A |------- Customer3 (204.1.34.0/24) | Provider A |------- Customer3 (204.1.34.0/24)
| |------- Customer4 (204.1.35.0/24) | |------- Customer4 (204.1.35.0/24)
| |------- Customer5 (204.1.36.0/23) | |------- Customer5 (204.1.36.0/23)
+----------------+ +----------------+
| |
| A announces | A announces
| 204.1/16 to B | 204.1/16 to B
| |
+----------------+ +----------------+
| Provider B | | Provider B |
+----------------+ +----------------+
Figure 2 Figure 2
In Figure 2, Provider A has been assigned the classless block, or In Figure 2, Provider A has been assigned the classless block, or
"aggregate," 204.1.0.0/16 (i.e., a prefix with the high-order 16 bits "aggregate", 204.1.0.0/16 (i.e., a prefix with the high-order 16 bits
denoting a single network). Provider A has 5 customers, each of which denoting a single network). Provider A has 5 customers, each of
has been assigned a prefix subordinate to the aggregate. In order which has been assigned a prefix subordinate to the aggregate. In
for Provider B to be able to reach Customers1-5, Provider A only order for Provider B to be able to reach Customers1-5, Provider A
needs to announce the single prefix 204.1.0.0/16. The benefit for only needs to announce the single prefix 204.1.0.0/16, and Provider
Provider B is that its routers need only a single routing table entry B's routers need only a single routing table entry to reach all of
to reach all of Provider A's customers. Note the difference between Provider A's customers. Note the important difference between the
the cases described in Figures 1 and 2. The important difference in cases described in Figures 1 and 2; the latter example uses fewer
the two Figures is that the latter example uses fewer entries in the entries in the routing table to reach the same number of
routing table to reach the same number of destinations. destinations.
CIDR was a critical step for the Internet: in the early 1990s the CIDR was a critical step for the Internet: in the early 1990s the
size of default-free routing tables required to support the classful size of default-free routing tables required to support the classful
Internet was almost more than the commercially-available hardware and Internet was almost more than the commercially-available hardware and
software of the day could handle. The introduction of BGP4's software of the day could handle. The introduction of BGP4's
classless routing and provider-based address allocation policies classless routing and provider-based address allocation policies
resulted in an immediate relief. At the same time, however, CIDR resulted in a significant decrease in the growth rate of the routing
introduced some new weaknesses. First, the Internet addressing model tables. At the same time, however, CIDR introduced some new
had to shift from one of "address owning" to "address lending." In weaknesses. First, the Internet addressing model had to shift from
pre-CIDR days sites acquired addresses from a central authority one of "address owning" to "address lending" [RFC2008]. In pre-CIDR
independent of their provider, and a site could assume it "owned" the days sites acquired addresses from a central authority independent of
address it was given. Owning addresses meant that once one had been their provider, and a site could assume it "owned" the address block
given a set of network addresses, one could always use them and it was given. Owning addresses meant that once one had been given a
assume that no matter where a site connected to the Internet, the set of network addresses, one could always use them; no matter where
prefix for that network could be injected into the public routing one's site connected to the Internet, the prefix for that network
system. Today, however, it is simply no longer possible for each could be injected into the public routing system. Today, however, it
individual site to have its own private prefix injected into the DFZ; is simply not possible for all individual sites to have their own
there would simply be too many of them. Consequently, if a site prefixes injected into the DFZ; there would be too many of them.
decides to change providers, then it needs to renumber all of its Consequently, if a site decides to change providers, it needs to
nodes using address space given to it by the new provider. The "old" renumber all of its nodes using address space given to it by the new
addresses it had used are returned back to its previous provider. To provider. The "old" addresses it had used are returned back to its
understand this, consider if, from Figure 2, Customer3 changes its previous provider. To understand this, consider if, from Figure 2,
provider from Provider A to Provider C, but does not renumber. The Customer3 changes its provider from Provider A to Provider C, but
picture would be as follows: does not renumber. The picture would be as follows:
+----------------+ +----------------+
| |---- Customer1 (204.1.0.0/19) | |---- Customer1 (204.1.0.0/19)
| |---- Customer2 (204.1.32.0/23) | |---- Customer2 (204.1.32.0/23)
| Provider A | | Provider A |
+---------------| |---- Customer4 (204.1.35.0/24) +---------------| |---- Customer4 (204.1.35.0/24)
| A announces | |---- Customer5 (204.1.36.0/23) | A announces | |---- Customer5 (204.1.36.0/23)
| 204.1/16 to B +----------------+ | 204.1/16 to B +----------------+
| | | |
| | | |
skipping to change at page 11, line 4 skipping to change at page 11, line 33
| | | |
| | | |
| | | |
| C announces | | C announces |
| 204.1.34/24 | | 204.1.34/24 |
| to B +----------------+ | to B +----------------+
+---------------| Provider C |---- Customer3 (204.1.34.0/24) +---------------| Provider C |---- Customer3 (204.1.34.0/24)
+----------------+ +----------------+
Figure 3 Figure 3
In Figure 3, Providers A, B and C are all directly connected to each In Figure 3, Providers A, B and C are all directly connected to each
other. In order for Provider B to reach Customers 1, 2, 4 and 5, other. In order for Provider B to reach Customers 1, 2, 4 and 5,
Provider A still only announces the 204.1.0.0/16 aggregate. However, Provider A still only announces the 204.1.0.0/16 aggregate. However,
in order for Provider B to reach Customer 3, Provider C must announce in order for Provider B to reach Customer 3, Provider C must announce
the prefix 204.1.34.0/24. Prefix 204.1.34.0/24 is called a "more- the prefix 204.1.34.0/24. Prefix 204.1.34.0/24 is called a "more-
specific" of 204.1.0.0/16; another term used is that Customer3 and specific" of 204.1.0.0/16; another term used is that Customer3 and
Provider C have "punched a hole in" Provider A's block. The result Provider C have "punched a hole" in Provider A's address block. From
of this is that from Provider B's view, the address space underneath Provider B's view, the address space underneath 204.1.0.0/16 is no
204.1.0.0/16 is no longer cleanly aggregated into a single prefix and longer cleanly aggregated into a single prefix and instead the
instead the aggregation has been broken because the addressing is aggregation has been broken because the addressing is inconsistent
inconsistent with the topology; in order to maintain reachability to with the topology; in order to maintain reachability to Customer1-5,
Customer3, Provider B must carry two prefixes where it used to have Provider B must carry two prefixes where it used to have to carry
to carry only one. only one.
The example in Figure 3 explains why sites must renumber if existing The example in Figure 3 explains why sites must renumber if existing
levels of aggregation are to be maintained. While it is certainly levels of aggregation are to be maintained. While a small number of
clear that a small number of exceptions can be tolerated, the reality new exceptions could be tolerated, and certain prefixes have been
in today's Internet is that there are thousands of providers, many grandfathered, the reality in today's Internet is that there are
with thousands of individual customers. It is generally accepted that thousands of providers, many with thousands of individual customers.
renumbering of sites is essential for maintaining sufficient It is generally accepted that renumbering of sites is essential for
aggregation. maintaining sufficient aggregation.
The empirical cost of renumbering a site in order to maintain The empirical cost of renumbering a site in order to maintain
aggregation has been the subject of much discussion. The practical aggregation has been the subject of much discussion. The practical
reality, however, is that forcing all sites to renumber is difficult reality, however, is that forcing all sites to renumber is difficult
given the size and wealth of companies that now depend on the given the size and wealth of companies that now depend on the
Internet for running their business. Thus, although the technical Internet for running their business. Thus, although the technical
community came to consensus that address lending was necessary in community came to consensus that, with the current practice of
order for the Internet to continue to operate and grow, the reality provider-based addressing, address lending was necessary in order for
has been that some of CIDR's benefits have been lost because not all the Internet to continue to operate and grow, the reality has been
sites renumber. It is worth noting that a number of providers do that some of CIDR's benefits have been lost because not all sites
renumber. It is worth noting that a number of providers today do
route filtering based, in part, on prefix length; as a result, a site route filtering based, in part, on prefix length; as a result, a site
which does not renumber may have, at best, partial connectivity to which does not renumber may have only partial connectivity to the
the Internet. Internet. That is, a site may advertise a long prefix into the
routing system, but there is no assurance that all parts of the
Internet will accept the route; some simply ignore it.
One unfortunate characteristic of CIDR at an architectural level is One unfortunate characteristic of CIDR at an architectural level is
that the pieces of the infrastructure that benefit from the that the pieces of the infrastructure that benefit from the
aggregation (i.e., the providers which make up the DFZ) are not the aggregation (i.e., the providers which make up the DFZ) are not the
pieces that incur the cost (i.e., the end site). The logical pieces that incur the renumbering cost (i.e., the end site). The
corollary of this statement is that the pieces of the infrastructure logical corollary of this statement is that the pieces of the
that do incur cost to achieve aggregation (e.g., sites which renumber infrastructure that do incur cost to achieve aggregation (e.g., sites
when they change providers) don't directly see the benefit. (The word which renumber when they change providers) don't directly see the
"directly" is used here because the continued operation of the benefit. (The word "directly" is used here because the continued
Internet is a benefit, though it requires selflessness on the part of operation of the Internet is a benefit, though it requires
the site to recognize.) selflessness on the part of the site to recognize.) This can lead to
a "tragedy of the commons" situation, where everyone agrees that some
sites should renumber, but they themselves want to be one of those
that do not.
3.4. Multi-Homing and Aggregation 3.4. Multi-Homed Sites and Aggregation
As sites become more dependent on the Internet, they have begun to As sites become more dependent on the Internet, they have begun to
install additional connections to the Internet to improve robustness install additional connections to the Internet to improve robustness
and performance. Such sites are called "multi-homed." Unfortunately, and performance. Such sites are called "multi-homed".
when a site connects to the Internet at multiple places, the impact Unfortunately, when a site connects to the Internet at multiple
on routing can be much like a site that switches providers but places, the impact on routing can be much like a site that switches
refuses to renumber. providers but refuses to renumber.
In the pre-CIDR days, multi-homed sites were typically known by only In the pre-CIDR days, multi-homed sites were typically known by only
one network prefix. When that site's providers announced the site's one network prefix, the prefix of their own address block. When that
network into the global routing system, a "shortest path" type of site's providers announced the site's network into the global routing
routing would occur so that pieces of the Internet closest to the system, a "shortest path" type of routing would occur so that pieces
first provider would use the first provider while other pieces of the of the Internet closest to the first provider might use the first
Internet would use the second provider. This allowed sites to use the provider while other pieces of the Internet would use the second
routing system itself to load balance traffic across their multiple provider. This allowed sites to use the routing system itself to
connections. This type of multi-homing assumes that a site's prefix load balance traffic across their multiple connections. This type of
can be propagated throughout the DFZ, an assumption that is no longer multi-homing assumes that a site's prefix can be propagated
universally true. throughout the DFZ, an assumption that is no longer universally true.
With CIDR, issues of addressing and aggregation complicate matters With CIDR, issues of addressing and aggregation complicate matters
significantly. At the highest levels, there are three possible ways significantly. At the highest level, there are three possible ways
to deal with multi-homed sites. The first approach is for multi- to deal with multi-homed sites. The first possibility is to stay
homed sites to receive address space directly from a registry, with pre-CIDR approach, allowing each multi-homed site to receive its
independent of its providers. The problem with this approach is address block directly from a registry, independent of its providers.
that, because the address space is obtained independent of either The problem with this approach is that, because the address block is
provider, it is not aggregatable and therefore has a negative impact obtained independent of either provider, it is not aggregatable and
on the scaling of global routing. therefore has a negative impact on the scaling of global routing.
The second approach is for a multi-homed site to receive an The second approach is for a multi-homed site to receive an
allocation from one of its providers and just use that single prefix. allocation from one of its providers and just use that single prefix.
The site would advertise its prefix to all of the providers to which The site would advertise its prefix to all of the providers to which
it connects. There are two problems with this is approach. First, it connects. There are two problems with this approach. First,
although the prefix is aggregatable by the provider which made the although the prefix is aggregatable by the provider which made the
allocation, it is not aggregatable by the other providers. To the allocation, it is not aggregatable by the other providers. To the
other providers, the site's prefix poses the same problem that a other providers, the site's prefix poses the same problem that a
provider-independent address would. This has a negative impact on provider-independent address would. Second, due to CIDR's rule for
the scaling of global routing. Second, due to CIDR's rule for
longest-match routing, it turns out that the site's prefix is not longest-match routing, it turns out that the site's prefix is not
always aggregatable in practice even by the provider that made the always aggregatable in practice even by the provider that made the
allocation. Consider Figure 4. Provider C has two paths for reaching allocation, if you want shortest-path routing load-spreading.
Customer 1. Provider A advertises 204.1/16, an aggregate which Consider Figure 4. Provider C has two paths for reaching Customer1.
includes Customer 1. But Provider C will also receive an Provider A advertises 204.1/16, an aggregate which includes
advertisement for prefix 204.1.0/19 from Provider B, and because the Customer1. But Provider C will also receive an advertisement for
prefix match through B is longer, C will choose that path. In order prefix 204.1.0/19 from Provider B, and because the prefix match
for Provider C to be able to choose between the two paths, Provider A through B is longer, C will choose that path. In order for Provider
would also have to advertise the longer prefix for 204.1.0/19 in C to be able to choose between the two paths, Provider A would also
addition to the shorter 204.1/16. At this point, from the routing have to advertise the longer prefix for 204.1.0/19 in addition to the
perspective, the situation is very similar to the general problem shorter 204.1/16. At this point, from the routing perspective, the
posed by the use of provider-independent addresses. situation is very similar to the general problem posed by the use of
provider-independent addresses.
It should be noted that the above example simplifies a very complex It should be noted that the above example simplifies a very complex
issue. For example, consider the example in Figure 4 again. Provider issue. For example, consider the example in Figure 4 again.
A could choose not to propagate a route entry for the longer Provider A could choose not to propagate a route entry for the longer
204.1.0/19 prefix, advertising only the shorter 204.1/16. In such 204.1.0/19 prefix, advertising only the shorter 204.1/16. In such
cases, provider C would always select Provider B. Internally, cases, provider C would always select Provider B. Internally,
Provider A would continue to route traffic from its other customers Provider A would continue to route traffic from its other customers
to Customer 1 directly. If Provider A had a large enough customer to Customer 1 directly. If Provider A had a large enough customer
base, effective load sharing might be achieved. base, effective load sharing might be achieved.
A advertises A advertises
+------------+ 204.1/16 to C +------------+ +------------+ 204.1/16 to C +------------+
___| Provider A |-----------------| Provider C | ___| Provider A |-----------------| Provider C |
/ +------------+ +------------+ / +------------+ +------------+
skipping to change at page 13, line 31 skipping to change at page 14, line 20
/ / / /
Customer 1 --- / B advertises 204.1.0/19 to C Customer 1 --- / B advertises 204.1.0/19 to C
204.1.0.0/19 | / 204.1.0.0/19 | /
| +------------+ | +------------+
----- | Provider B | ----- | Provider B |
+------------+ +------------+
Figure 4 Figure 4
The third approach is for a multi-homed site to receive an allocation The third approach is for a multi-homed site to receive an allocation
from each of its providers. This approach has advantages from the from each of its providers and not advertise the prefix obtained from
perspective of route scaling because both allocations are one provider to any of its other providers. This approach has
aggregatable. Unfortunately, the approach doesn't necessarily meet advantages from the perspective of route scaling because both
the demands of the multi-homed site. A site that has a prefix from allocations are aggregatable. Unfortunately, the approach doesn't
each of its providers has a number of choices about how to use that necessarily meet the demands of the multi-homed site. A site that
address space. Possibilities include: has a prefix from each of its providers faces a number of choices
about how to use that address space. Possibilities include:
1) The site can number a distinct set of hosts out of each of the 1) The site can number a distinct set of hosts out of each of the
prefixes. Consider a configuration where a site is connected to prefixes. Consider a configuration where a site is connected to
ISP-A and ISP-B. If the link to ISP-A goes down, then unless the ISP-A and ISP-B. If the link to ISP-A goes down, then unless
ISP-A prefix is announced to ISP-B (which breaks aggregation), the ISP-A prefix is announced to ISP-B (which breaks
the hosts numbered out of the ISP-A prefix would be unreachable. aggregation), the hosts numbered out of the ISP-A prefix would
be unreachable.
2) The site could assign each host multiple addresses (i.e., one 2) The site could assign each host multiple addresses (i.e., one
address for each ISP connection). There are two problems with address for each ISP connection). There are two problems with
this. First, it accelerates the consumption of the address this. First, it accelerates the consumption of the address
space. Second, when the connection to ISP-A goes down, space, albeit this is less problematic for the IPv6 address
space, and the related important problem is overall size of the
routing tables. Second, when the connection to ISP-A goes down,
addresses numbered out of ISP-A's space become unreachable. addresses numbered out of ISP-A's space become unreachable.
Remote peers would have to have sufficient intelligence to use Remote peers would have to have sufficient intelligence to use
the second address. For example, when initiating a connection to the second address. For example, when initiating a connection
a host, the DNS would return multiple candidate addresses. to a host, the DNS would return multiple candidate addresses.
Clients would need to try them all before concluding that a Clients would need to try them all before concluding that a
destination is unreachable (something not all hosts currently destination is unreachable (something not all network
do). In addition, a site's hosts would need a significant amount applications currently do). In addition, a site's hosts would
of intelligence for choosing the source addresses they use. A need a significant amount of intelligence for choosing the
host shouldn't choose a source address corresponding to a link source addresses they use. A host shouldn't choose a source
that is down. At present, hosts do not have such sophistication. address corresponding to a link that is down. At present, hosts
do not have such sophistication.
In summary, how best to achieve multi-homing with IPv4 in the face of In summary, how best to support multi-homing with IPv4/CIDR faces a
CIDR is an unsolved problem. There is a delicate balance between the delicate balance between the scalability of routing versus the site's
scalability of routing versus the site's requirements of robustness requirements of robustness and load-sharing. At this point in time,
and load-sharing. At this point in time, no solution has been no solution has been discovered that satisfies the competing
discovered that satisfies the competing requirements of route scaling requirements of route scaling and robustness/performance. It is
and robustness/performance. It is worth noting, however, that some worth noting, however, that some people are beginning to study the
people are beginning to study the issue more closely and propose issue more closely and propose novel ideas [BATES].
novel ideas [BATES].
4. The GSE Proposal 4. The GSE Proposal
This section provides a description of GSE with the intent of making This section provides a description of GSE with the intent of making
this document stand-alone with respect to the GSE "specification." We this document stand-alone with respect to the GSE "specification".
begin by reviewing the motivation for GSE. Next we review the salient We begin by reviewing the motivation for GSE. Next we review the
technical details, and we conclude by listing the explicit non-goals salient technical details, and we conclude by listing the explicit
of the GSE proposal. non-goals of the GSE proposal.
4.1. Motivation For GSE 4.1. Motivation For GSE
The primary motivation for GSE was the fact that the chief initial The primary motivation for GSE was the concern that the chief initial
IPv6 global unicast address structure, provider-based [RFC 2073], was IPv6 global unicast address structure, provider-based [RFC 2073], was
fundamentally the same as IPv4 with CIDR and provider-based fundamentally the same as IPv4 with CIDR and provider-based
aggregation. Provider-based addressing requires that sites renumber aggregation. Provider-based addressing requires that sites renumber
when they switch providers, so that sites are always aggregated when they switch providers, so that sites are always aggregated
within their provider's prefix. In practice, the cost of renumbering within their provider's prefix. In practice, the cost of renumbering
(which can only grow as a site grows in size and becomes more (which can only grow as a site grows in size and becomes more
dependent on the Internet for day-to-day business) is high enough dependent on the Internet for day-to-day business) is high enough
that an increasing number of sites refuse to renumber. This cost is that an increasing number of sites refuse to renumber when they
particularly relevant in cases where end-users are asked to renumber change providers. This cost is particularly relevant in cases where
because an upstream provider has changed its transit provider (i.e., end-users are asked to renumber because an upstream provider has
the end site is asked to renumber for reasons outside of its control changed its transit provider (i.e., the end site is asked to renumber
and for which it sees no direct benefit). Consequently, the GSE for reasons outside of its control and for which it sees no direct
draft asserted that IPv4 with CIDR has not achieved the aggressive benefit). Consequently, the GSE draft asserts that IPv4 with CIDR
aggregation required for the route computation functions of the DFZ has not achieved the aggressive aggregation required for the route
of the Internet to scale for IPv4 and that the larger addresses of computation functions of the DFZ of the Internet to scale for IPv4
IPv6 simply exacerbate the problem. and that the much larger address space of IPv6 simply exacerbates the
problem.
The GSE proposal did not propose to eliminate the need for The GSE proposal does not propose to eliminate the need for
renumbering. Indeed, it asserted that end sites will have to be renumbering. Indeed, it asserts that end sites will have to renumber
renumbered more frequently in order to continue scaling the Internet. more frequently in order to continue scaling the Internet. However,
However, GSE proposed to make the cost of such a renumbering so small GSE proposes to make the cost of renumbering small enough that sites
that sites could be renumbered at essentially any time with little or can be renumbered at essentially any time with little or no
no disruption. disruption to its network connectivity, and in particular with no
impact on communications that are strictly within the site.
Finally, GSE dealt significantly with sites that have multiple Finally, GSE attempts to address the problem of sites that have
Internet connections. In some addressing schemes (e.g., CIDR), this multiple Internet connections. In CIDR, the pressure for better
"multi-homing" can create exceptions to the aggregation and result in multi-homing support can create exceptions to route aggregation and
poor scaling. That is, the public routing infrastructure needs to result in poor scaling. That is, the public routing infrastructure
carry multiple distinct routes for the multi-homed site, one for each may have to carry multiple distinct routes for some demanding multi-
independent path. GSE recognized the "special work done by the global homed sites, one for each independent path. GSE recognizes the
Internet infrastructure on behalf of multi-homed sites," [GSE] and "special work done by the global Internet infrastructure on behalf of
proposed a way for multi-homed sites to gain some benefit without multi-homed sites" [GSE], and proposes a way for multi-homed sites to
impacting global scaling. This included a specific mechanism that gain certain benefit without impacting global scaling. This includes
providers could use to support multi-homed sites, presumably at a a specific mechanism that providers can use to support multi-homed
cost that the site would consider when deciding whether or not to sites, presumably at a cost that the site would consider when
become multi-homed. deciding whether or not to become multi-homed.
4.2. GSE Address Format 4.2. GSE Address Format
The key departure of GSE from classical IP addressing (both v4 and The key departure of GSE from classical IP addressing (both v4 and
v6) was that rather than over-loading addresses with both locator and v6) was that rather than over-loading addresses with both locator and
identifier purposes, it split the address into two elements: the identifier functions, it splits the address into two elements: the
high-order 8 bytes for routing (called "Routing Stuff" throughout the high-order 8 bytes used for routing purposes (called "Routing Stuff"
rest of this document) and the low-order 8 bytes for unique throughout the rest of this document) and the low-order 8 bytes for
identification of an end-point. The structure of GSE addresses was: unique identification of an end-point. The structure of GSE
addresses is:
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| Routing Goop | STP| End System Designator | | Routing Goop | STP| End System Designator |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
6+ bytes ~2 bytes 8 bytes 6+ bytes ~2 bytes 8 bytes
Figure 5 Figure 5
4.2.1. Routing Stuff (RG and STP) 4.2.1. Routing Stuff (RG and STP)
The Routing Goop (RG) identifies the place in the Internet topology The Routing Goop (RG) identifies where within the public Internet
where a site connects and is used to route datagrams to the site. RG topology a site connects and is used to route datagrams to the site.
is structured as follows: RG is structured as follows:
1 2 3 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| xxx | 13 Bits of LSID | Upper 16 bits of Goop | | xxx | 13 Bits of LSID | Upper 16 bits of Goop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
3 4 3 4
2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bottom 18 bits of Routing Goop | | Bottom 18 bits of Routing Goop |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6 Figure 6
The RG describes the location of a site's connection by identifying The RG describes the location of a site's connection by identifying
smaller and smaller regions of topology until finally it identifies smaller and smaller regions of topology until finally it identifies
the link which connects the site. Before interpreting the bits in the the link which connects the site. Before interpreting the bits in
RG, it is important to understand that routing with GSE depends on the RG, it is important to understand that routing with GSE depends
decomposing the Internet's topology into a specific graph. At the on decomposing the Internet's topology into a specific graph. At the
highest level, the topology is broken into Large Structures (LSs). An highest level, the topology is broken into Large Structures (LSs).
LS is basically a region that can aggregate significant amounts of An LS is a region that can aggregate significant amounts of topology.
topology. Examples of potential LSs are large providers and exchange Examples of potential LSs are large providers and exchange points.
points. Within an LS the topology is further divided into another Within an LS the topology is further divided into another graph of
graph of structures, with each LS dividing itself however it sees structures, with each LS dividing itself however it sees fit. This
fit. This division of the topology into smaller and smaller division of the topology into smaller and smaller structures can
structures can recurse for a number of levels, where the trade-off is recurse for a number of levels, where the trade-off is "between the
"between the flat-routing complexity within a region and minimizing flat-routing complexity within a region and minimizing total depth of
total depth of the substructure." [ESD] the substructure" [ESD].
Having described the decomposition process, we can now examine the Having described the decomposition process, we now examine the bits
bits in the RG. After the 3-bit prefix identifying the address as in the RG. After the 3-bit prefix identifying the address as having
GSE, the next 13 bits identify the LS. By limiting the field to 13 a GSE format, the next 13 bits identify the LS. By limiting the
bits, a ceiling is defined on the complexity of the top-most routing field to 13 bits, a ceiling is defined on the complexity of the top-
level (i.e., what we currently call the DFZ). In the next 34 bits, a most routing level (i.e., what we currently call the DFZ). In the
series of subordinate structure(s) are identified until finally the next 34 bits, a series of subordinate structure(s) are identified
leaf subordinate structure is identified, at which point the until finally the leaf subordinate structure is identified, at which
remaining bits identify the individual link within that leaf point the remaining bits identify the individual link within that
structure. leaf structure.
The remaining 14 bits of the Routing Stuff (i.e., the low-order 14 The remaining 14 bits of the Routing Stuff (i.e., the low-order 14
bits of the high-order 8 bytes) comprise the STP and are used for bits of the high-order 8 bytes) comprise the STP and are used for
routing structure within a site, similar to subnetting with IPv4. routing structure within a site, similar to subnetting with IPv4.
These bits are not part of the Routing Goop per se. The distinction These bits are not part of the Routing Goop per se. The distinction
between Routing Stuff and Routing Goop is that RG controls routing in between Routing Stuff and Routing Goop is that RG controls routing in
the Public Internet, while Routing Stuff includes the RG plus the the Public Internet, while Routing Stuff includes the RG plus the
Site Topology Partition (STP). The STP is used for routing structure Site Topology Partition (STP). The STP is used for routing structure
within a site. [Note that the term "Routing Stuff" was a creation of within a site.
the author's of this analysis document and was not used in the GSE
document.]
The GSE proposal formalized the ideas of sites and of public versus The GSE proposal formalized the ideas of sites and of public versus
private topology. In the first case, a site is a set of hosts, private topology. In the first case, a site is a set of hosts,
routers and media under the same administrative control which have routers and media under the same administrative control which have
zero or more connections to the Internet. A site can have an zero or more connections to the Internet. A site can have an
arbitrarily complicated topology, but all of that complexity is arbitrarily complicated topology, but all of that complexity is
hidden from everyone outside of the site. A site only carries hidden from everyone outside of the site. A site only carries
packets which originated from, or are destined to, that site; in packets which originated from, or are destined to, that site; in
other words, a site cannot be a transit network. A site is private other words, a site cannot be a transit network. A site is private
topology, while the transit networks form the public topology. topology, while the transit networks form the public topology.
skipping to change at page 17, line 27 skipping to change at page 18, line 25
A datagram is routed through public topology using just the RG, but A datagram is routed through public topology using just the RG, but
within the destination site, routing is based on the Site Topology within the destination site, routing is based on the Site Topology
Partition (STP). Partition (STP).
4.2.2. End-System Designator 4.2.2. End-System Designator
The End-System Designator (ESD) is an unstructured 8-byte field that The End-System Designator (ESD) is an unstructured 8-byte field that
uniquely identifies an interface from all others. The most important uniquely identifies an interface from all others. The most important
feature of the ESD is that it alone identifies an interface; the feature of the ESD is that it alone identifies an interface; the
Routing Stuff portion of an address, although used to help deliver a Routing Stuff portion of an address, although used to help deliver a
packet to its destination, is not used to actually identify an end packet to its destination, is not used to identify an end point.
point. End-points of communication care about the ESD; as examples, End-points of communication care about the ESD; as examples, TCP
TCP peers could be identified by the source and destination ESDs peers could be identified by the source and destination ESDs alone
alone (together with port numbers), checksums would exclude the RG (together with port numbers), checksums would exclude the RG (the
(the sender doesn't know its RG, as described later) and on receipt sender doesn't even know its RG, as described later) and on receipt
of a datagram only the ESD would be used in testing whether a packet of a packet only the ESD would be used in testing whether the packet
is intended for local delivery. is intended for local delivery.
The leading contender for the role of a 64-bit globally unique ESD is The leading contender for the role of a 64-bit globally unique ESD is
the recently defined "EUI-64" identifier. [EUI64] These identifiers the recently defined "EUI-64" identifier [EUI64]. These identifiers
consist of a 24-bit "company_id" concatenated with a 40-bit consist of a 24-bit "company_id" concatenated with a 40-bit
"extension." (Company_id is just a new name for the "extension". (Company_id is a new name for the "Organizationally
"Organizationally Unique Identifier" that forms the first half of an Unique Identifier" that forms the first half of an 802 MAC address).
802 MAC address.) Manufacturers are expected to assign locally unique Manufacturers are expected to assign locally unique values to the
values to the extension field, guaranteeing global uniqueness for the extension field, guaranteeing global uniqueness for the complete 64-
complete 64-bit identifier. bit identifier. A range of the EUI-64 space is reserved to cover
pre-existing 48-bit MAC addresses, and a defined mapping insures that
A range of the EUI-64 space is reserved to cover pre-existing 48-bit an ESD derived from a MAC address will not duplicate the ESD of a
MAC addresses, and a defined mapping insures that an ESD derived from device that has a built-in EUI-64.
a MAC address will not duplicate the ESD of a device that has a
built-in EUI-64.
In some cases, interfaces may not have access to an appropriate MAC In some cases, interfaces may not have an appropriate MAC address or
address or EUI-64 identifier. A globally unique ESD must then be EUI-64 identifier. A globally unique ESD must then be obtained
obtained through some alternate mechanism. Several possible through some alternate mechanism. Several possible mechanisms can be
mechanisms can be imagined (e.g., the IANA could hand out addresses imagined (e.g., the IANA could hand out addresses from the company_id
from the company_id it has been allocated), but we do not explore it has been allocated). Although we do not explore them in detail
them in detail here. here, we note that a global coordination structure is required here
to control the allocation of globally unique identifiers.
4.3. Address Rewriting by Border Routers 4.3. Address Rewriting by Border Routers
GSE site border routers rewrite addresses of the packets they forward To obviate the need to renumber devices within sites because of
across the boundary between the site and public topology. Within a changing providers, the GSE design hides the global Routing Goop (RG)
site, nodes need not know the RG associated with their addresses. from hosts in each site by having site border routers rewrite
They simply use a designated "Site-Local RG" value for internal addresses of the packets they forward across the boundary between the
addresses. When a packet is forwarded to the public topology, the site and public topology. Within a site, nodes need not know the RG
border router replaces the Site-Local RG portion of the packet's associated with their addresses. They simply use a designated
source address with an appropriate value. Likewise, when a packet "Site-Local RG" value for internal addresses. When a packet is
from the public topology is forwarded into a site, the border router forwarded to the public topology, the border router replaces the
replaces the RG part of the destination address with the designated Site-Local RG portion of the packet's source address with an
Site-Local RG. appropriate value. Likewise, when a packet from the public topology
is forwarded into a site, the border router replaces the RG part of
the destination address with the designated Site-Local RG.
To simplify discussion, the following text uses the singular term RG To simplify discussion, the following text uses the singular term RG
as if a site could have only one RG value (i.e., one connection to as if a site could have only one RG value (i.e., one connection to
the Internet). In fact, a site could have multiple Internet the Internet). In fact, a site could have multiple Internet
connections and consequently multiple RGs. connections and consequently multiple RGs.
Having border routers rewrite addresses obviates the need to renumber GSE's approach to easing renumbering isn't so much to ease
devices within sites because of changing providers --- GSE's approach renumbering as to make it transparent to end users. The RG by which
wasn't so much to ease renumbering as to make it transparent. To a site is known is hidden from nodes within that site. Instead, the
achieve transparency, the RG by which a site is known is hidden RG for the site would be known only by the exit router, either
(i.e., kept secret) from nodes within that site. Instead, the RG for through static configuration or through a dynamic protocol with an
the site would be known only by the exit router, either through upstream provider.
static configuration or through a dynamic protocol with an upstream
provider.
Because end hosts don't know their RG, they don't know their entire Because end hosts don't know their RG, they don't know their entire
16-byte address, so they can't specify the full address in the source 16-byte address, so they can't specify the full address in the source
fields of packets they originate. Consequently, when a datagram fields of packets they originate. Consequently, when a datagram
leaves a site, the egress border router fills in the high-order leaves a site, the egress border router fills in the high-order
portion of the source address with the appropriate RG. portion of the source address with the appropriate RG.
The point of keeping the RG hidden from nodes within the core of a The point of keeping the RG hidden from nodes within the core of a
site was to insure the changeability of the RG without impacting the site is to insure the changeability of the RG without impacting the
site itself. It was expected that the RG would need to change site itself. It is expected that the RG would need to change
relatively frequently (e.g., several times a year) in order to relatively frequently (e.g., several times a year) in order to
support scalable aggregation as the topology of the Internet changes. support sufficient aggregation as the topology of the Internet
A change to a site's RG would only require a change at the site's changes. A change to a site's RG would only require a change at the
egress point, and it's well possible that this change could be site's egress point, and it's well possible that this change could be
accomplished through a dynamic protocol with the upstream provider. accomplished through a dynamic protocol with the upstream provider.
Hiding a site's RG from its internal nodes does not, however, mean Hiding a site's RG from its internal nodes does not, however, mean
that changes to RG have no impact on end sites. Since the full 16- that changes to RG have no impact on end sites. Since the full 16-
byte address of a node isn't a stable value (the RG portion can byte address of a node isn't a stable value (the RG portion can
change), a stored address may contain invalid RG and be unusable if change), a stored address may contain invalid RG and be unusable if
it isn't "refreshed" through some other means. For example, opening a it isn't "refreshed" through some other means. For example, opening
TCP connection, writing the address of the peer to a file and then a TCP connection, writing the address of the peer to a file and then
later trying to reestablish a connection to that peer is likely to later trying to reestablish a connection to that peer may well fail.
fail. For intra-site communication, however, it is expected that For intra-site communication, however, it is expected that only the
only the Site-Local RG would be used (and stored) which would Site-Local RG would be used (and stored) which would continue to work
continue to work for intra-site communication regardless of changes for intra-site communication regardless of changes to the site's
to the site's external RG. This has the benefit of shielding a site's external RG. This shields a site's intra-site traffic from any
intra-site traffic from any instabilities resulting from renumbering. instabilities resulting from renumbering.
In addition to rewriting source addresses upon leaving a site, In addition to rewriting source addresses that leave a site,
destination addresses are rewritten upon entering a site. To destination addresses must be rewritten upon entering a site. To
understand the motivation behind this, consider a site with understand the motivation behind this, consider a site with
connections to three Internet providers. Because each of those connections to three Internet providers. Because each of those
connections has its own RG, each destination within the site would be connections has its own RG, each destination within the site would be
known by three different 16-byte addresses. As a result, intra-site known by three different 16-byte addresses. As a result, intra-site
routers would have to carry a routing table three times larger than routers would have to carry a routing table three times larger than
expected. To work around this, GSE proposed replacing the RG in expected. To work around this, GSE proposed replacing the RG in
inbound packets with the special "Site-Local RG" value to reduce inbound packets with the special "Site-Local RG" value to reduce
intra-site routing tables to the minimum necessary. intra-site routing tables to the minimum necessary.
In summary, when a node initiates a flow to a node at another site, In summary, when a node initiates a flow to a node at another site,
the initiating node knows the full 16-byte address for the the initiating node is expected to know the full 16-byte address for
destination through some mechanism like a DNS query. The initiating the destination through mechanisms such as a DNS query. The
node does not, however, know its RG, so uses the Site-Local RG values initiating node does not, however, know its own RG, and uses the
in the RG part of the source address. When the datagram reaches the Site-Local RG values in the RG part of the source address. When the
exit border router, the router replaces the RG of the packet's source datagram reaches the exit border router, the router replaces the RG
address. When the datagram arrives at the entry router at the of the packet's source address. When the datagram arrives at the
destination site, the router replaces the RG portion of the entry router at the destination site, the router replaces the RG
destination address with the distinguished "Site-Local RG" value. portion of the destination address with the distinguished "Site-Local
When the destination host needs to send return traffic, that host RG" value. When the destination host needs to send return traffic,
knows the full 16-byte address for the other host because it appeared that host knows the full 16-byte address for the other host because
in the source address field of the arriving packet. it appeared in the source address field of the arriving packet.
4.4. Renumbering and Rehoming Mid-Level ISPs 4.4. Renumbering and Rehoming Mid-Level ISPs
One of the most difficult-to-solve components of the renumbering One of the most difficult-to-solve components of the renumbering
problem with CIDR is that of renumbering mid-level service providers. problem with CIDR is that of renumbering mid-level service providers.
Specifically, if SmallISP1 changes its transit provider from BigISP1 Specifically, if SmallISP1 changes its transit provider from BigISP1
to BigISP2, then in order for the overall size of the routing tables to BigISP2, then in order for the overall size of the routing tables
to stay the same, all of SmallISP1's customers would have to renumber to stay the same, all of SmallISP1's customers would have to renumber
into address space covered by an aggregate of BigISP2. GSE dealt into address space covered by an aggregate of BigISP2. GSE deals
with this problem by handling the RG in DNS with indirection. with this problem by handling the RG in DNS with indirection.
Specifically, a site's DNS server specifies the RG portion of its Specifically, a site's DNS server specifies the RG portion of its
addresses by referencing the "name" of its immediate provider, which addresses by referencing the "name" of its immediate provider, which
is a resolvable DNS name (this implies a new Resource Record type). is a resolvable DNS name (this implies a new Resource Record type).
That provider may define some of the low-order bits of the RG and That provider may define some of the low-order bits of the RG and
then reference its immediate provider. This chain of reference allows then reference its immediate provider. This chain of reference
mid-level service providers to change transit providers, and the allows mid-level service providers to change transit providers, and
customers of that mid-level will simply "inherit" the change in RG. the customers of that mid-level will simply "inherit" the change in
RG. Note that this mechanism does not depend on the GSE address
format per se and can also be applied to IPv4 addressing.
4.5. Support for Multi-Homed Sites 4.5. Support for Multi-Homed Sites
GSE defined a specific mechanism for providers to use to support GSE defines a specific mechanism for providers to use to support
multi-homed customers that gives those customers more reliability multi-homed customers that gives those customers more reliability
than singly-homed sites, but without a negative impact on the scaling than singly-homed sites, but without a negative impact on the scaling
of global routing. This mechanism is not specific to GSE and could be of global routing. This mechanism is not specific to GSE and could
applied to any multi-homing scenario where a site is known by be applied to any multi-homing scenario where a site is known by
multiple prefixes (including provider-based addressing). Assume the multiple prefixes (including provider-based addressing). Assume the
following topology: following topology:
Provider1 Provider2 Provider1 Provider2
+------+ +------+ +------+ +------+
| | | | | | | |
| PBR1 | | PBR2 | | PBR1 | | PBR2 |
+----x-+ +-x----+ +----x-+ +-x----+
| | | |
RG1 | | RG2 RG1 | | RG2
skipping to change at page 20, line 42 skipping to change at page 21, line 38
+-----------------+ +-----------------+
Site Site
Figure 7 Figure 7
PBR1 is Provider1's border router while PBR2 is Provider2's border PBR1 is Provider1's border router while PBR2 is Provider2's border
router. SBR1 is the site's border router that connects to Provider1 router. SBR1 is the site's border router that connects to Provider1
while SBR2 is the site's border router that connects to Provider2. while SBR2 is the site's border router that connects to Provider2.
Imagine, for example, that the line between Provider1 and the site Imagine, for example, that the line between Provider1 and the site
goes down. Any already existing flows that use a destination address goes down. Any already existing flows that use a destination address
including RG1 would stop working. In addition, any DNS queries that including RG1 would stop working. In addition, any addresses
return addresses including RG1 would not be viable addresses. If PBR1 returned from DNS queries that include RG1 would not be viable
and PBR2 knew about each other, however, then in this case PBR1 could addresses. If PBR1 and PBR2 knew about each other, however, then in
tunnel packets destined for RG1-prefixed addresses to PBR2, thus this case PBR1 could tunnel packets destined for RG1-prefixed
keeping the communication working. (Note that true tunneling, i.e., addresses to PBR2, thus keeping the communication working. (Note
re-encapsulation, is necessary since routers between PBR1 and PBR2 that IP-in-IP encapsulation is necessary since routers between PBR1
would forward RG1 addresses towards PBR1.) and PBR2 would forward packets destined for addresses with PBR1's
prefix back towards PBR1.)
4.6. Explicit Non-Goals for GSE 4.6. Explicit Non-Goals for GSE
It is worth noting explicitly that GSE did not attempt to address the It is worth noting explicitly that GSE did not attempt to address the
following issues: following issues:
1) Survival of TCP connections through renumbering events. If a 1) Survival of TCP connections through renumbering events. If a
site is renumbered, TCP connections using a previous address site is renumbered, TCP connections using a previous address
will continue to work only as long as the previous address still will continue to work only as long as the previous address still
works (i.e., while it is still "valid" using RFC 1971 works (i.e., while it is still "valid" using RFC 1971
terminology). No attempt is made to have existing connections terminology). No attempt is made to have existing connections
switch to the new address. switch to the new address. In contrast, TCP on hosts with IPv6
mobility features can survive renumbering events [MOBILITY6].
2) It is not known how mobility can be made to work under GSE. 2) It is not known how multicast can be made to work under GSE.
3) It is not known how multicast can be made to work under GSE. 3) It is not known how mobility can be made to work under GSE.
4) The performance impact of having routers rewrite portions of the 4) The performance impact of having routers rewrite portions of the
source and destination address in packet headers requires source and destination address in packet headers requires
further study. further study.
That GSE didn't address the above does not mean they cannot be That GSE didn't address 2-4 above does not mean they cannot be
solved. Rather the issues weren't studied in sufficient depth. solved. Rather, the issues simply weren't studied in sufficient
depth.
5. Analysis: The Pros and Cons of Overloading Addresses 5. Analysis: The Pros and Cons of Overloading Addresses
At this point we have given complete descriptions of two addressing At this point we have given complete descriptions of two addressing
architectures: IPv4, which uses the overloading technique, and GSE, architectures: IPv4, which uses the overloading technique, and GSE,
which uses the separated technique. We now compare and contrast the which uses the separated technique. We now compare and contrast the
two techniques. two techniques.
The following discussion is organized around three fundamental The following discussion is organized around three fundamental
points: points:
1) Identifiers indicate who the intended recipient of a packet is, 1) Identifiers indicate who the intended recipient of a packet is.
At the network layer, an identifier refers to an interface, at
the transport layer it refers to a process or other endpoint of
a "connection".
2) Identifiers must be mapped into a locator that the network layer 2) Identifiers must be mapped into a locator that the network layer
uses to actually deliver a packet to its intended destination, can use to actually deliver a packet to its intended
and destination.
3) There must be a suitable way to sufficiently authenticate the 3) There must be a suitable way to adequately authenticate the user
user of an identifier, so that peers using identifiers have of an identifier, so that communicating peers have sufficient
sufficient confidence that packets sent to or received from a confidence that packets sent to or received from a particular
particular identifier correspond to the intended recipient. identifier correspond to the intended recipient.
5.1. Purpose of an Identifier 5.1. Purpose of an Identifier
An identifier gives an entity the ability to refer to a communication An identifier gives an entity the ability to refer to a communication
end point and to refer to the same endpoint over an extended period end point and to refer to the same endpoint over an extended period
of time. In terms of semantics, two or more packets sent to the same of time. In terms of semantics, two or more packets sent to the same
identifier should be delivered to the same end point. Likewise, one identifier should be delivered to the same end point. Likewise, one
expects multiple packets received from the same identifier to have expects multiple packets received from the same identifier to have
been originated by the same sending entity. That is, a source been originated by the same sending entity. That is, a source
identifier indicates who the packet is from and a destination identifier indicates who the packet is from and a destination
identifier indicates who the packet is intended for. identifier indicates who the packet is intended for.
When applications communicate, "identifiers" consist of addresses and In IPv4, when applications communicate, transport "identifiers"
port numbers. For the purposes of this discussion, the term consist of addresses and port numbers. For the purposes of this
"identifier" means the identifier of an interface. It is assumed that discussion, we use the term "identifier" to mean the identifier of an
port numbers will be present when higher layer entities communicate; interface. It is assumed that port numbers will be present when
the exact port numbers used are not relevant to this discussion. higher layer entities communicate; the exact port numbers used are
not relevant to this discussion.
In small networks, flat routing can be used to deliver packets to In small networks, flat routing can be used to deliver packets to
their destination based only on the destination identifier carried in their destination based only on the destination identifier carried in
a packet header (i.e., the identifier is the locator and is not a packet header (i.e., the identifier is the locator and is not
required to have any structure). However, in such systems, a distinct required to have any structure). However, in such systems, a
route entry is required for every destination, an approach that does distinct route entry is required for every destination, an approach
not scale. In larger networks, packet addresses include a locator that does not scale. In larger networks, packet addresses include a
that helps the network layer deliver a packet to its destination. locator that helps the network layer deliver a packet to its
Such a locator typically has structure (i.e., is an aggregate for destination. Such a locator typically has a structure to keep
many destinations) that keeps routing tables small relative to the routing tables small relative to the total number of reachable
total number of reachable destinations. In IPv4, the identifier and destinations. In IPv4, the identifier and locator are combined in a
locator are combined in a single address; it is not possible to single address; it is not possible to separate the locator portion of
separate the locator portion of an address from the identifier an address from the identifier portion. In contrast, the ESD portion
portion. In contrast, the ESD portion of a GSE address (which can of a GSE address (which can easily be extracted from the address)
easily be extracted from the address) serves as an identifier, while serves as an identifier, while the Routing Stuff plays the role of a
the Routing Stuff plays the role of a locator. locator.
Having a clear separation between the locator and the identifer Having a clear separation between the locator and the identifier
portion of an address appears to give protocols some additional portion of an address appears to provide protocols some additional
flexibility. Once a packet has been delivered to its intended flexibility. Once a packet has been delivered to its intended
destination interface (i.e., node), for example, the locator has destination interface (i.e., node), for example, the locator has
served its purpose and is no longer needed to further demultiplex a served its purpose and is no longer needed to further demultiplex a
packet to its higher-layer end point. This means that if a packet is packet to its higher-layer end point. This means that if a packet is
delivered to the correct destination node, the node will accept the delivered to the correct destination node (that is the identifier
packet, regardless of how the packet got there. The exact locator carried in the packet address matches to one interface identifier of
used does not matter, so long as it corresponds to one that delivers the node), the node will accept the packet, regardless of how the
a packet to its proper destination. packet got there. The exact locator used does not matter, within
most Internet circumstances, so long as it gets the packet delivered
to its proper destination.
The most obvious example that could benefit from the separation of The most obvious example that could benefit from the separation of
locators and indentifiers involves communication with a mobile host. locators and identifiers involves communication with a mobile host.
Transport protocols such as TCP are unable to keep connections open Transport protocols such as TCP are unable to keep connections open
if either of the endpoint identifiers for an open connection changes. if either of the two endpoint identifiers for an open connection
changes. Fundamentally, the endpoint identifiers indicate the two
Fundamentally, the endpoint identifiers indicate the two endpoint endpoint entities that are communicating. If a node were to receive
entities that are communicating. If a node were to receive a packet a packet from a node with which it had been communicating previously,
from a node with which it had been communicating previously, but the but the identifier used by the sending node has changed, the
identifier used by the sending node has changed, the recipient would recipient would be unable to distinguish this case from that of a
be unable to distinguish this case from that of a packet received packet received from a completely different node.
from a completely different node.
In the specific case of TCP and IPv4, connections are identified In the specific case of TCP and IPv4, connections are identified
uniquely by the tuple: (srcIPaddr, dstIPaddr, srcport, dstport). uniquely by the tuple: (srcIPaddr, dstIPaddr, srcport, dstport).
Because IPv4 addresses contain a combined locator/identifier, it is Because IPv4 addresses contain a combined locator/identifier, it is
not possible to have a node's location change without also having its not possible to have a node's location change without also having its
identifier change. Consequently, when a mobile node moves, its identifier change. Consequently, when a mobile node moves, its
existing connections no longer work, in the absence of special existing connections no longer work, in the absence of special
protocols such as Mobile IP [RFC2002]. protocols such as Mobile IP [MOBILITY]. Note that in IPv4 mobility,
the mobile host's address is preserved, but in IPv6 mobility
[MOBILITY6], the mobile host can functionally have a new address,
because the packet includes an option storing the old and the
correspondent's IP rewrites it transparently to the transport
protocol. The identifier of the mobile's packet remains its original
address.
In contrast, connections in GSE are identified by the ESDs rather In contrast, connections in GSE are identified by the ESDs rather
than full IPv6 addresses. That is, connections are identified than full IPv6 addresses. That is, connections are identified
uniquely by the tuple: (srcESD, dstESD, srcport, dstport). uniquely by the tuple: (srcESD, dstESD, srcport, dstport).
Consequently, when demultiplexing incoming packets to their proper Consequently, when demultiplexing incoming packets to their proper
end point, TCP would ignore the Routing Stuff portions of addresses. end point, TCP would ignore the Routing Stuff portions of addresses.
Because the Routing Stuff portion of an address is ignored during Because the Routing Stuff portion of an address is ignored during
demultiplexing operations, a mobile node is free to move -- and demultiplexing operations, a mobile node is free to move -- and
change its Routing Stuff -- without consequences for the change its Routing Stuff -- without changing its identification.
demultiplexing operation.
As a side note, it is a requirement in GSE that packets be As a side note, it is a requirement in GSE that packets be
demultiplexed on ESDs alone independent of the Routing Stuff. If a demultiplexed to higher layer endpoints on ESDs alone independent of
site is multi-homed, the packets it sends may exit the site at the Routing Stuff. If a site is multi-homed, the packets it sends
different egress border routers during the lifetime of a connection. may exit the site at different egress border routers during the
Because each border router will place its own RG into the source lifetime of a connection. Because each border router will place its
addresses of outgoing packets, the receiving TCP must ignore (at own RG into the source addresses of outgoing packets, the receiving
least) the RG portion of addresses when demultiplexing received TCP must ignore (at least) the RG portion of addresses when
packets. The alternative would be to make TCP unable to cope with demultiplexing received packets. The alternative would make TCP
common routing changes, i.e., if the path changed, packets delivered unable to cope with common routing changes, i.e., if the path
correctly would be discarded by the receiving TCP rather than changed, packets delivered correctly would be discarded by the
processed. receiving TCP rather than accepted.
Not surprisingly, having separate locator and identifiers in Not surprisingly, having separate locator and identifiers in
addresses leads to some additional problems. First, an identifier by addresses leads to additional problems as well. First, an identifier
itself provides only limited value. In order to actually deliver by itself provides only limited value. In order to actually deliver
packets to a destination identifier, a corresponding locator must be packets to a destination identifier, a corresponding locator must be
known. The general problem of mapping identifiers into locators is known. The general problem of mapping identifiers into locators is
non-trivial to solve, and is the topic of the next Section. Second, non-trivial to solve, and is the topic of the next Section. Second,
because the Routing Stuff is ignored when demultiplexing packets because the Routing Stuff is ignored when packets being demultiplexed
upward in the protocol stack, it becomes much easier for an intruder upward in the protocol stack, it becomes much easier for an intruder
to masquerade as someone else. to masquerade as someone else.
5.2. Mapping an Identifier to a Locator 5.2. Mapping an Identifier to a Locator
The idea of using addresses that cleanly separate location and The idea of using addresses that cleanly separate location and
identification information is not new [references XXX]. However, identification information is not new. However, there are several
there are several different flavors. In its pure form, a sender need different flavors. In its pure form, a sender need only know the
only know the identifier of an end-point in order to send packets to identifier of an end-point in order to send packets to it. When
it. When presented with a datagram to send, network software would be presented with a datagram to send, network software would be
responsible for finding the locator associated with an identifier so responsible for determining the locator associated with an identifier
that the packet can be delivered. A key question is: "who is so that the packet can be delivered. A key question is: "who is
responsible for finding the Routing Stuff associated with a given responsible for finding the Routing Stuff associated with a given
identifier"? There are a number of possibilities, each with a identifier"? There are a number of possibilities, each with a
different set of implications: different set of implications:
1) The network layer could be responsible for doing the mapping. 1) The network layer could be responsible for doing the mapping.
The advantage of such a system is that an ESD could be stored The advantage of such a system is that an ESD could be stored
essentially forever (e.g., in configuration files), but whenever essentially forever (e.g., in configuration files), but whenever
it is actually used, network layer software would automatically it is actually used, network layer software would automatically
perform the mapping to determine the appropriate Routing Stuff perform the mapping to determine the appropriate Routing Stuff
for the destination. Likewise, should an existing mapping become for the destination. Likewise, should an existing mapping
invalid, network layer software could dynamically determine the become invalid, network layer software could dynamically
updated value. Unfortunately, building such a mapping mechanism determine the updated value. Unfortunately, building such a
that scales is a hard problem. mapping mechanism that scales is difficult if not impossible
with a flat identifier space (e.g., the ESD identifier).
2) The transport layer could be responsible for doing the mapping. 2) The transport layer could be responsible for doing the mapping.
It could perform the mapping when a connection is first opened, It could perform the mapping when a connection is first opened,
periodically refreshing the binding for long-running periodically refreshing the binding for long-running
connections. Implementing such a scheme would change the connections. Implementing such a scheme would change the
existing transport layer protocols TCP and UDP significantly. existing transport layer protocols TCP and UDP significantly.
However, in the case of TCP, such a scheme would have the
benefit that applications would probably not need to be
modified. For UDP-based applications, this may not hold, since
most UDP-based protocols are implemented within applications.
3) Higher-layer software (e.g., the application itself) could be 3) Higher-layer software (e.g., the application itself) could be
responsible for performing the mapping. This potentially responsible for performing the mapping. This potentially
increases the burden on application programmers significantly, increases the burden on application programmers significantly,
especially if long-running connections are required to survive especially if long-running connections are required to survive
renumbering and/or deal with mobile nodes. renumbering and/or deal with mobile nodes.
It should be noted that the GSE proposal does not embrace the general The GSE proposal uses the last approach. The network and transport
model, it uses the last. The network and transport layers are always layers are always presented with both the Routing Stuff (RG + STP)
presented with both the Routing Stuff (RG + STP) and the ESD together and the ESD together in one IPv6 address. It is neither of these
in one IPv6 address. It is neither of these layers' jobs to determine layers' jobs to determine the Routing Stuff given only the ESD or to
the Routing Stuff given only the ESD or to validate that the Routing validate that the Routing Stuff is correct. When an application has
Stuff is correct. When an application has data to send, it queries data to send, it queries the DNS to obtain the IPv6 AAAA record for a
the DNS to obtain the IPv6 AAAA record for a destination. The destination. The returned AAAA record contains both the Routing
returned AAAA record contains both the Routing Stuff and the ESD of Stuff and the ESD of the specified destination. While such an
the specified destination. While such an approach eliminates the need approach eliminates the need for the lower layers to be able to map
for the lower layers to be able to map ESDs into corresponding ESDs into corresponding Routing Stuff, it also means that when
Routing Stuff, it also means that when presented with an address presented with an address containing an incorrect (i.e., no longer
containing an incorrect (i.e., no longer valid) Routing Stuff, the valid) Routing Stuff, the network is unable to deliver the packet to
network is unable to deliver the packet to its correct destination. its correct destination. Note that addresses containing invalid
Routing Stuff will result any time when cached addresses are used
It is up to applications themselves to deal with such failures. Note after the Routing Stuff of the address becomes invalid. This may
that addresses containing invalid Routing Stuff will result any time happen if addresses are stored in configuration files, a mobile node
cached addresses are used after the Routing Stuff of the address moves to a new location, long-running applications (clients and
becomes invalid. This may happen if addresses are stored in servers) cache the result of DNS queries, a long-running connection
configuration files, a mobile node moves to a new location, long- attempts to continue operating during a site renumbering event, etc.
running applications (clients and servers) cache the result of DNS Whatever the causes, the failures are fundamentally due to dynamic
queries, a long-running connection attempts to continue operating topological changes at the network layer, yet in GSE such failures
during a site renumbering event, etc. are left to be dealt with at the application level (through DNS),
because neither the transport nor the network level has the ability
to re-mapping identifiers to corresponding locators.
A network architecture must provide the ability to map an identifier To avoid the above problem a network architecture must provide the
to a locator. In IPv4, this mapping is trivial (the identity ability to map an identifier to a locator. In IPv4, this mapping is
function), since the identifier and locator are combined in a single trivial, since the identifier and locator are combined in a single
quantity (i.e., the IPv4 address). GSE does not provide mapping quantity (i.e., the IPv4 address). GSE does not provide this mapping
functionality directly. Indeed, GSE uses two different identifiers. functionality directly. Instead, GSE assumes that a node's DNS name
At the highest level, a node's DNS name serves as its identifer, with serves as its stable identifier, and uses normal DNS queries to map
normal DNS queries used to map the DNS "identifier" into a locator the DNS "identifier" into an IPv6 address. The IPv6 address contains
(i.e., the first 8 bytes of the IPv6 address). At a lower layer, the both the ESD identifier together with its Routing Stuff, that is an
IPv6 address contains the ESD identifier together with its Routing initial binding/mapping between the identifier and locator. When
Stuff (i.e., locator). Note that the DNS name is expected to be the this binding breaks (for example due to dynamic topological changes),
stable identifier that can be mapped into an appropriate locator at the ESD identifier cannot be mapped into a new locator by itself.
any time. In contrast, the ESD identifier, cannot be mapped into a Instead one must resort back to application level, hoping another DNS
locator by itself. query would provide rescue to the broken binding between identifier
to locator that is needed for network delivery.
The use of two identifiers contributes to making GSE appear simple. The use of DNS to provide identifier to locator mapping contributes
However, there are two fundamental problems with this approach, if to GSE's apparent simplicity. However, there are two fundamental
the intention is to make it transparently easy to change locators problems with this approach, if the intention is to make it
over time. First, the burden of performing the mapping from transparently easy to change locators over time. First, the burden
identifier to locator is placed directly on the application, of performing the mapping from identifier to locator is placed
requiring active participation from the application. Second, The directly on the application, because lower layers (i.e., transport
lower layers (i.e., transport and network layers) cannot make use of and network layers) cannot perform the mapping themselves due to
this mapping themselves due to layering violation concerns (i.e., TCP layering violation concerns (i.e., TCP and UDP can't perform a DNS
and UDP can't depend on the DNS to perform a query). query). Second, following all RG changes the DNS database must be
promptly updated and all expired information must be flushed out of
all DNS caches. This stringent timing requirement imposed by lower
level operation would represent a departure from the original DNS
design, which provides DNS names to address mappings that only change
slowly over time if at all, and which relies heavily on caching over
relatively long time periods to scale well.
The following subsections discuss a number of issues related to The following subsections discuss a number of issues related to
keeping track of or determining the locator associated with an keeping track of or determining the locator associated with an
identifier. identifier.
5.2.1. Scalable Mapping of Identifers to Locators 5.2.1. Scalable Mapping of Identifiers to Locators
It is not difficult to construct a mapping from an identifier (such It is not difficult to construct a mapping from an identifier (such
as an ESD) to a locator (as well as other information such as a name, as an ESD) to a locator (as well as other information such as a name,
cryptographic keys, etc.) provided one can structure the identifier cryptographic keys, etc.) provided one can structure the identifier
appropriately to support such lookups. In particular, identifiers space appropriately to support scalable lookups. In particular,
must have sufficient structure to support the delegating mechanism of identifiers must have sufficient structure to support the delegating
a distributed database such as DNS. On the other hand, no scalable mechanism of a distributed database such as DNS. On the other hand,
mechanism is known for performing such a mapping on arbitrary no scalable mechanism is known for performing such a mapping on
identifiers taken from a flat space lacking structure. arbitrary identifiers taken from a flat space lacking any structure.
Imposing a heirarchy on identifiers poses the following difficulties: Imposing a hierarchy on identifiers poses the following difficulties:
- it increases the size of the identifier. The exact size - - It increases the size of the identifier. The exact size
necessary to support sufficient heirarchy is unclear, though it necessary to support sufficient hierarchy is unclear, though it
is likely to be roughly the same as that used for the routing is likely to be roughly the same as that used for the routing
hierarchy. Analysis done during the original IPng debates hierarchy. Analysis done during the original IPng debates
[RFC1752] suggests that close to 48-bits of hierarchy are needed [RFC1752] suggests that close to 48-bits of hierarchy are needed
to identify all the possible sites 30-40 years from now. to identify all the possible sites 30-40 years from now.
- the assignment of identifiers must be tied to the delegation - - The assignment of identifiers must be tied to the delegation
structure. That is, the site that "owns" an identifier is the structure. That is, the site that "owns" an identifier is the
one responsible for maintaining the identifier-to-locator one responsible for maintaining the identifier-to-locator
mapping information about it. mapping information about it.
- a mechanism would be needed to make it possible for a node to - - Due to the requirement of tying an identifier to the
determine what its identifier is. To be practical, such a delegation structure the identifier of a node cannot be burned
in during manufacturing. Instead a mechanism is needed to allow
a node to learn its identifier. To be practical, such a
mechanism would need to be automated and avoid the need for mechanism would need to be automated and avoid the need for
manual configuration. manual configuration.
5.2.2. Insufficient Hierarchy Space in ESDs 5.2.2. Insufficient Hierarchy Space in ESDs
In the case of GSE's 8-byte ESD, the size of the identifier is not In the case of GSE's 8-byte ESD, the size of the identifier is not
large enough to contain sufficient heirarchy to both create DNS-like large enough to contain sufficient hierarchy to both create DNS-like
delegation points and support stateless address autoconfiguration. delegation points and support stateless address autoconfiguration.
Stateless address autoconfiguration [RFC1971] already assumes that an Stateless address autoconfiguration [RFC1971] already assumes that an
interface's 6-byte link-layer (i.e., MAC) address can be appended to interface's 6-byte link-layer (i.e., MAC) address can be appended to
a link's routing prefix to produce a globally unique IPv6 address. a link's routing prefix to produce a globally unique IPv6 address.
With GSE, only two bytes would be available for hierarchy and With GSE, only two bytes would be available for hierarchy and
delegation. delegation.
It is also the case that the sorts of built-in identifiers now found It is also the case that the sorts of built-in identifiers now found
in computing hardware, such as "EUI-48" and "EUI-64" addresses in computing hardware, such as "EUI-48" and "EUI-64" addresses
[IEEE802, IEEE1212], do not have the structure required for this [IEEE802, IEEE1212], do not have the structure required for this
delegation. Such identifiers have only two-levels of heirarchy; the delegation. Such identifiers have only two-levels of hierarchy; the
top-level typically identifies a manufacturer, with the remaining top-level typically identifies a manufacturer, with the remaining
part of the address being the equivalent of the serial number unique part of the address being the equivalent of the serial number unique
to the manufacturer. In addition, the delegation of the two-level to the manufacturer. The delegation of the two-level hierarchy
heirarchy (i.e., equipment manufacturer) does not correspond to the (i.e., equipment manufacturer) does not correspond to the
administrator under which the end-user operates. Hence, stateless administrator under which the end-user operates. Hence, stateless
autoconfiguration [RFC1971] cannot create addresses with the autoconfiguration [RFC1971] cannot create addresses with the
necessary hierarchical property in the ESD portion of an address. necessary hierarchical property in the ESD portion of an address.
Finally, imposing a required hierarchical structure on identifiers Finally, imposing a required hierarchical structure on identifiers
such as an ESD would also introduce a new administrative burden and a such as an ESD would also introduce a new administrative burden and a
new or expanded registry system to manage ESD space (i.e., to insure new or expanded registry system to manage ESD space (i.e., to insure
that ESDs are globally unique). While the procedures for assigning that ESDs are globally unique). While the procedures for assigning
ESDs, which need only organizational and not topological ESDs, which need only organizational and not topological
significance, would be simpler than the procedures for managing IPv4 significance, would be simpler than the procedures for managing IPv4
addresses (or DNS names), it is hard to imagine such a process being addresses, it seems a laudable goal to avoid the problem altogether
universally well-received or without controversy; it seems a laudable if possible. In addition, it would likely increase the complexity
goal to avoid the problem altogether if possible. In addition, it for connecting new nodes to the Internet, a goal inconsistent with
would likely increase the complexity for connecting new nodes to the Stateless Address autoconfiguration [RFC1971].
Internet, a goal inconsistent with Stateless Address
autoconfiguration [RFC1971].
5.2.3. Reverse Mapping of Complete GSE Addresses
The following two sections describe techniques for mapping a full
IPv6 address back into some quantity (e.g., a DNS name or locator).
We include these descriptions for completeness even though they do
not address the fundamental problem of how to perform the mapping on
an identifier alone. It should also be noted that because both
techniques operate on complete IPv6 addresses, they are both directly
applicable to provider-based addressing schemes and are not specific
to GSE.
5.2.4. DNS-Like Reverse Mapping of Full GSE Addresses
Although it seems infeasible to have a global scale, reverse mapping
of ESDs, within a site, one could imagine maintaining a database
keyed on unstructured 8-byte ESDs. However, it is a matter of debate
whether such a database can be kept up-to-date at reasonable cost,
without making unreasonable assumptions as to how large sites are
going to grow, and how frequently ESD registrations will be made or
updated. Note that the issue isn't just the physical database itself,
but the operational issues involved in keeping it up-to-date. For the
rest of this section, however, let us assume that such a database can
be built.
A mechanism supporting a lookup keyed on a flat-space ESD from an
arbitrary site requires having sufficient structure to identify the
site that needs to be queried. In practice, an ESD will almost always
be used in conjunction with Routing Stuff (i.e., a full 16-byte
address). Since the Routing Stuff is organized hierarchically, it
becomes feasible to maintain a DNS-like tree that maps full GSE
addresses into DNS names, in a fashion analogous to what is done with
IPv4 PTR records today.
It should be noted that a GSE address lookup will work only if the
Routing Stuff portion of the address is correctly entered in the DNS
tree. Because the Routing Stuff portion of an address is expected to
change over time, this assumption will not be valid indefinitely. As
a consequence, a packet trace recorded in the past might not contain
enough information to identify the off-Site sources of the packets in
the present. This problem can be addressed by requiring that the
database of RG delegations be maintained for some period of time
after the RG is no longer usable for routing packets.
Finally, it should be noted that the problem where an address's RG
"expires" with the implication that the mapping of "expired"
addresses into DNS names may no longer hold is not a problem specific
to the GSE proposal. With provider-based addressing, the same issue
arises when a site renumbers into a new provider prefix and releases
the allocation from a previous block. The authors are aware of one
such renumbering in IPv4 where a block of returned addresses was
reassigned and reused within 24 hours of the renumbering event.
5.2.5. The ICMP Who-Are-You Message
Although there is widespread agreement on the utility of being able
to determine the DNS name one is communicating with, there is also
widespread concern that repeating the experience of the "IN-
ADDR.ARPA" domain is undesirable. In practice, the IN-ADDR.ARPA
domain is not fully populated and poorly maintained. Consequently,
an old proposal to define an ICMP Who-Are-You message was resurrected
[RFC1788]. A client would send such a message to a peer, and that
peer would return an ICMP message containing its DNS name.
Asking a remote host to supply its own name in no way implies that
the returned information is accurate. However, having a remote peer
provide a piece of information that a client can use as input to a
separate authentication procedure provides a starting point for
performing strong authentication. The actual strength of the
authentication depends on the authentication procedure invoked,
rather than the untrustable piece of information provided by a remote
peer.
Reconsidering the "cheap" authentication procedure described earlier,
the ICMP Who-Are-You replaces the DNS PTR query used to obtain the
DNS name of a remote peer. The second DNS query, to map the DNS name
back into a set of addresses, would be performed as before. Because
the latter DNS query provides the strength of the authentication,
the use of an ICMP Who-Are-You message does not in any way weaken the
strength of the authentication method. Indeed, it can only make it
more useful in practice, because virtually all hosts can be expected
to implement the Who-Are-You message.
The Who-Are-You message is robust against renumbering, since it
follows the paths of valid routable prefixes. Essentially, it uses
the Internet routing system in place of the DNS delegation scheme. It
is attractive in the context of GSE-style renumbering, since no host
or DNS server needs to be updated after a renumbering event for Who-
Are-You-based lookups to work. It has advantages outside the context
of GSE as well, including a more decentralized, and hence more
scalable, administration and easier upkeep than a DNS reverse-lookup
zone. It also has drawbacks: it requires the target node to be up and
reachable at the time of the query and to know its fully qualified
domain name. It is also not possible to resolve addresses once those
addresses become unroutable. In contrast, the DNS PTR mirrors, but is
independent of, the routing hierarchy. The DNS can maintain mappings
long after the routing subsystem stops delivering packets to certain
addresses.
The requirement that the target node be up and reachable at the time The topic of mapping full 16-byte GSE addresses to a locator or other
of the query makes it very uncertain that one would be able to take information is discussed in Appendix D.
addresses from a packet log and translate them to correct domain
names at a later date. One can argue that this is a design flaw in
the logging system, as it violates the architectural principle,
"Avoid any design that requires addresses to be ... stored on non-
volatile storage." [RFC1958] A better-designed system would look up
domain names promptly from logged addresses. Indeed, one of the
authors has been doing that for some years.
5.3. Authentication of Identifiers 5.3. Authentication of Identifiers
The true value of a globally unique identifier lies not on its The true value of a globally unique identifier lies not on its
uniqueness but on an ability to use the same identifier repeatedly uniqueness but on an ability to use the same identifier repeatedly
and have it refer to the same end point. That is, when an identifier and have it refer to the same end point. That is, there is an
is used, there is an expectation that repeated and subsequent use of expectation that repeated and subsequent use of the same identifier
the identifier results in continued communication with the same end results in continued communication with the same end point. To be
point. To be useful then, a valid identifier must either be easily useful then, a valid identifier must either be easily distinguishable
distinguishable from a fraudulant one, or the system must have a way from a fraudulent one, or the system must have a way to prevent
to prevent identifiers from being used in an unauthorized manner. identifiers from being used in an unauthorized manner.
The remainder of this section discusses how identifer authentication The remainder of this section discusses how identifier authentication
is done in both IPv4 and GSE, and shows how overloading an address is done in both IPv4 and GSE, and shows how overloading an address
with both an identifier and a locator provides automatic identifier with both an identifier and a locator provides a significant
authentication. In contrast, there is essentially no identifier automatic identifier authentication. In contrast, there is
authentication in GSE. It should be noted that the actual strength essentially no identifier authentication in GSE. It should be noted
of authentication that would be considered sufficient is a topic in that the actual strength of authentication that would be considered
its own right, and we do not spent much time on it. Instead, we focus sufficient is a topic in its own right, and we do not cover it here.
on the relative strengths in the two schemes. Instead, we focus on the relative strengths in the two schemes.
5.3.1. Identifier Authentication in IPv4 5.3.1. Identifier Authentication in IPv4
As described earlier, an IPv4 address simultaneously plays two roles: As described earlier, an IPv4 address simultaneously plays two roles:
a unique identifier and a locator. Using an overloaded address as an a unique identifier and a locator. Using an overloaded address as an
identifier has the side-effect of insuring that (for all practical identifier has the side-effect of insuring that (for all practical
purposes) the identifier is globally unique. Furthermore, because purposes) the identifier is globally unique. Furthermore, because
the same number is used both to identify an interface and to deliver the same number is used both to identify an interface and to deliver
data to that interface, it is impossible for some interface A to use data to that interface, it is impossible for some interface A to use
the identification of another interface B in an attempt to receive the identification of another interface B in an attempt to receive
data destined to B without being detected, unless the routing system data destined to B without being detected, unless the routing system
is compromised. is compromised.
When both interfaces A and B claim the same unicast address, the When both interfaces A and B claim the same unicast address, the
routing subsystem generally delivers packets to only one of them. The routing subsystem generally delivers packets to only one of them.
other node will quickly realize that something is wrong (since The other node will quickly realize that something is wrong (since
communication using the duplicate address fails) and take corrective communication using the duplicate address fails) and take corrective
actions, either correcting a misconfiguration or otherwise detecting actions, either correcting a misconfiguration or otherwise detecting
and thwarting the intruder. To understand how the routing subsystem and thwarting the intruder. To understand how the routing subsystem
prevents the same address from being used in multiple locations, prevents the same address from being used in multiple locations,
there are two cases to consider, depending on whether the two there are two cases to consider, depending on whether the two
interfaces using duplicate addresses are attached to the same or to interfaces using duplicate addresses are attached to the same or to
different links. different links.
When two interfaces on the same link use the same address, a node When two interfaces on the same link use the same address, a node
(host or router) sending traffic to the duplicate address will in (host or router) sending traffic to the duplicate address will in
skipping to change at page 31, line 9 skipping to change at page 30, line 19
because only one of the links has the right subnet corresponding to because only one of the links has the right subnet corresponding to
the IP address. Consequently, the node using the address on the the IP address. Consequently, the node using the address on the
"wrong" link will generally never receive any packets sent to it and "wrong" link will generally never receive any packets sent to it and
will be unable to communicate with anyone. For obvious reasons, this will be unable to communicate with anyone. For obvious reasons, this
condition is usually detected quickly. condition is usually detected quickly.
It should be noted that although an address containing a combined It should be noted that although an address containing a combined
identifier and locator can be forged, the routing subsystem identifier and locator can be forged, the routing subsystem
significantly limits communication using the forged address. First, significantly limits communication using the forged address. First,
return traffic will be sent to the correct destination and not the return traffic will be sent to the correct destination and not the
originator of the forged address. Second, routers performing ingress originator of the forged address. This alone prevents certain types
filtering can refuse to forward traffic claiming to originate from a of spoofing attacks. For example, if a destination receives an
source whose claimed address does not match the expected addresses unexpected packet corresponding to a TCP connection that it is
(from a topology perspective) for sources located within a particular unaware of, it may return at TCP segment resetting the connection.
region [RFC 2267]. To effectively masquerade as someone else Second, routers performing ingress filtering can refuse to forward
requires subverting the intermediate routing subsystem. traffic claiming to originate from a source whose claimed address
does not match the expected addresses (from a topology perspective)
for sources located within a particular region [RFC 2267]. To
effectively masquerade as someone else requires subverting the
intermediate routing subsystem.
5.3.2. Identifier Authentication in GSE 5.3.2. Identifier Authentication in GSE
In GSE, it is not possible for the routing subsystem to provide any In GSE, it is not possible for the routing subsystem to provide any
enforcement on the authenticity of identifiers with respect to their enforcement on the authenticity of identifiers with respect to their
corresponding Routing Stuff, since the Routing Stuff and ESD portions corresponding Routing Stuff, since the Routing Stuff and ESD portions
of an address are by definition completely orthogonal quantities. of an address are by definition completely orthogonal quantities.
This fundamental problem is compounded by the fact that GSE provides This fundamental problem is compounded by the fact that GSE provides
no way (at the transport or network layer) to map an ESD into its no way (at the transport or network layer) to map an ESD into its
corresponding Routing Stuff. Thus, when looking at the source address corresponding Routing Stuff. Thus, when looking at the source
of a received packet, there is no way to ascertain whether the address of a received packet, there is no way to ascertain whether
Routing Stuff portion of the address corresponds to legitimate the Routing Stuff portion of the address corresponds to legitimate
Routing Stuff with respect to the corresponding ESD. Consequently, it Routing Stuff with respect to the corresponding ESD. Consequently,
becomes trivial in many cases for one node to masquerade as another. it becomes trivial in many cases for one node to masquerade as
another.
5.3.3. Transport Layer: What Locator Should Be Used? 5.4. Transport Layer: What Locator Should Be Used?
In the following, we focus on what Routing Stuff to use with TCP. In the following, we focus on what Routing Stuff to use with TCP; UDP
UDP-based protocols also depend on the Routing Stuff in similar way. also depends on the Routing Stuff in similar way. Indeed, we believe
Indeed, we believe that TCP is the "easier" case to deal with, for that TCP is the "easier" case to deal with, for two reasons. First,
two reasons. First, TCP is a stateful protocol in which both ends of TCP is a stateful protocol in which both ends of the connection can
the connection can negotiate with each other. Some UDP-based negotiate with each other. UDP-based communications are stateless,
protocols are stateless, and remember nothing from one packet to the and remember nothing from one packet to the next. Consequently,
next. Consequently, changing UDP-based protocols may require the changing UDP to remember locator information in addition to the
introduction of "session" features, perhaps as part of a common identifier of the peer may require the introduction of "session"
"library", for use by applications whose transport protocol is features, perhaps as part of a common "library". Second, changes to
relatively stateless. Second, changes to UDP-based protocols in UDP in practice mean changing individual applications themselves,
practice mean changing individual applications themselves, raising raising deployability questions.
deployability questions.
There are three cases of interest from TCP's perspective: There are three cases of interest from TCP's perspective:
- the sending side of an active open - - the sending side of an active open
- the sending side of a passive open (i.e., how to respond to an - - the sending side of a passive open (i.e., how to respond to an
active open) active open)
- changes to the Routing Stuff during an open connection. - - changes to the Routing Stuff during an open connection.
5.3.4. RG Selection On An Active Open 5.4.1. RG Selection On An Active Open
If the host is performing a TCP "active open", the application first If the host is performing a TCP "active open", the application first
queries the DNS to obtain the destination address, which contains queries the DNS to obtain the destination address, which contains the
appropriate RG. That is, the initiator of communication is assumed to appropriate RG for the remote peer. That is, the initiator of
provide the correct Routing Stuff when initiating communication to a communication is assumed to provide the correct Routing Stuff when
specific destination. initiating communication to a specific destination.
5.3.5. RG Selection On An Passive Open 5.4.2. RG Selection On An Passive Open
When a server passively accepts connections from arbitrary clients, When a server passively accepts connections from arbitrary clients,
it has no choice but to assume that the Routing Stuff in the source it has no choice but to assume that the Routing Stuff in the source
address of a received packet that initiated the communication is address of a received packet that initiated the communication is
correct, because it has no way to authenticate its validity. Note correct, because it has no way to authenticate its validity. Note
that the Routing Stuff is "correct" only in the sense that it that the Routing Stuff is "correct" only in the sense that it
corresponds to the site originating the connection. Whether the corresponds to the site originating the connection, which the server
Routing Stuff paired with the received ESD is actually located at will send the reply to. Whether the Routing Stuff paired with the
that site where the legitimate owner of the ESD currently resides is received ESD actually matches the Routing Stuff located at the site
not known. Because the ESD alone cannot be mapped into a locator (or where the legitimate owner of the ESD currently resides is not known
some other quantity that can provide input to an authentication and cannot be determined. Because the ESD alone cannot be mapped
procedure), there is no way to determine whether the received Routing into a locator (or some other quantity that can provide input to an
Stuff corresponds to that legitimately associated with the source authentication procedure), there is no way to determine whether the
identifier of the received packet. The issue of spoofing is received Routing Stuff corresponds to that legitimately associated
discussed in more detail later. with the source identifier of the received packet. The issue of
spoofing is discussed in more detail later.
5.3.6. Mid-Connection RG Changes 5.4.3. Mid-Connection RG Changes
While packets are flowing as part of an open connection, the RG While packets are flowing as part of an open connection, the RG
appearing on subsequent packets is susceptible to change through appearing on subsequent packets is susceptible to change through
renumbering events, or as a result of site-internal routing changes renumbering events, or as a result of site-internal routing changes
that cause the egress point for off-site traffic to change. It is that cause the egress point for off-site traffic to change. It is
even possible (in the worst case) that traffic-balancing schemes even possible that traffic-balancing schemes could result in the use
could result in the use of two egress routers, with roughly every of two egress routers, with roughly every other packet exiting
other packet exiting through a different egress router. In GSE, the through a different egress router.
RG does not change once a connection has been opened.
Because TCP under GSE demultiplexes packets using only ESDs, packets Because TCP under GSE demultiplexes packets using only ESDs, newly
will be delivered to the correct end-point regardless of what source arrived packets will be delivered to the correct end-point regardless
RG is used. However, in GSE return traffic continues to be sent via of whether their source RG have changed. The GSE proposal calls for
the "old" RG, even though it may have been deprecated or become less return traffic to continue to be sent via the "old" RG, even though
optimal because the peer's border router has changed. It would seem it may have been deprecated or become less optimal because the peer's
highly desirable for TCP connections to be able to survive such border router has changed. That is, the RG to use for reaching a
events. However, the completion of renumbering events (so that an peer is bound to a connection when the connection is established and
earlier RG is now invalid) and certain topology changes would require does not change thereafter. However, the completion of renumbering
TCP to switch sending to a new RG mid-connection. To explore the events (so that an earlier RG is now invalid) and certain topology
whole space, we considered ways of allowing this mid-connection RG changes would require TCP to switch sending to a new RG mid-
change to happen. connection. To explore the scenario, we consider ways of allowing
the RG change to be made to existing established connections.
If TCP connection identifiers are based on ESDs rather than full If TCP connection identifiers are based on ESDs rather than full
addresses, traffic from the same ESD would be viewed as coming from addresses, traffic from the same ESD would be viewed as coming from
the same peer, regardless of its source RG. Because this the same peer, regardless of the source RG. Because this
vulnerability is already present in today's Internet (forging full vulnerability is already present in today's Internet (forging the
source addresses is trivial), the mere delivery of incoming datagrams source address of a packet is trivial), the mere delivery of incoming
with the same ESD but a different RG does not introduce new datagrams with the same ESD but a different RG does not introduce new
vulnerability to TCP. In today's Internet, any node can already vulnerability to TCP. In today's Internet, any node can already
originate FINs/RSTs from an arbitrary source address and potentially originate FINs/RSTs from an arbitrary source address and potentially
or definitely disrupt the connection. Therefore, changing RG for or definitely disrupt the connection. Therefore, acceptance of
acceptance, or acceptance of traffic independent of its source RG, traffic independent of its source RG does not appear to significantly
does not appear to significantly worsen existing robustness. (See the worsen existing robustness. Note, however, that ingress filtering as
comment on ingress filtering in Section 5.3.1, however.) described in Section 5.3.1, cannot be performed on packets containing
GSE addresses. This does make it more difficult to prevent certain
types of attacks.
We also considered allowing TCP to reply to each segment using the RG We also considered allowing TCP to reply to each segment using the RG
of the most recently-received segment. Although this allows TCP to of the most recently-received segment. Although this allows TCP
survive some important events (e.g., renumbering), it also makes it connections to survive certain important events (e.g., renumbering),
trivial to hijack connections, unacceptably weakening robustness it also makes it trivial for anyone to hijack connections,
compared with today's Internet. A sender simply needs to guess the unacceptably weakening robustness compared with today's Internet. A
sequence numbers in use by a given TCP connection [Bellovin 89] and sender simply needs to guess the sequence numbers in use by a given
send traffic with a bogus RG to hijack a connection to an intruder at TCP connection [Bellovin 89] and send traffic with a bogus RG to
an arbitrary location. hijack a connection to an intruder at an arbitrary location.
Providing protection from hijacking implies that the RG used to send Providing protection from hijacking implies that the RG used to send
packets must be bound to a connection end-point (e.g., it is part of packets must be bound to a connection end-point (e.g., it is part of
the connection state). Although it may be reasonable to accept the connection state). Although it may be reasonable to accept
incoming traffic independent of the source RG, the choice of sending incoming traffic independent of the source RG, the choice of sending
RG requires more careful consideration. Indeed, any subsequent change RG requires more careful consideration. Indeed, any subsequent
in what RG is used for sending traffic must be properly authenticated change in the RG used for sending traffic must be properly
(e.g., using cryptographic means). In the GSE proposal, it is not authenticated (e.g., using cryptographic means). In the GSE
clear how to authenticate such a change, since the remote peer proposal, the is no apparent way to authenticate such a change, since
doesn't even know its own RG. Consequently, the only reasonable the remote peer doesn't even know its own RG. Consequently, the only
approach in GSE is to send to the peer using the first RG used for reasonable approach in GSE is to send to the peer using the first RG
the entire life of a connection. That is, always use the first RG used for the entire life of a connection. That is, always use the
seen. first RG seen, and accept the loss of connectivity whenever the RG
changes.
5.3.7. The Impact of Corrupt Routing Goop 5.4.4. The Impact of Corrupted Routing Goop
Another interesting issue that arises is what impact corrupted RG Another interesting issue that arises is what impact corrupted RG
would have on robustness. Because the RG is not covered by the TCP would have on robustness. Because the RG is not covered by the TCP
checksum (the sender doesn't know what source RG will be inserted), checksum (the sender doesn't know what source RG will be inserted),
it would be difficult to detect such corruption at the receiver. no TCP mechanism can detect such corruption at the receiver.
Moreover, once a specific RG is in use, it does not change for the Moreover, once a specific RG is in use, it does not change for the
duration of a connection. The interesting case occurs on the passive duration of a connection. One interesting case occurs on the passive
side of a TCP connection, where a server accepts incoming connections side of a TCP connection, where a server accepts incoming connections
from remote clients. If the initial SYN from the client includes from remote clients. If the initial SYN from the client includes a
corrupted RG, the server TCP will create a TCP connection (in the corrupted RG, the server TCP will create a TCP connection (in the
SYN-RECEIVED state) and cache the corrupted RG with the connection. SYN-RECEIVED state) and cache the corrupted RG with the connection.
The second packet of the 3-way handshake, the SYN-ACK packet, would The second packet of the 3-way handshake, the SYN-ACK packet, would
be sent to the wrong RG and consequently not reach the correct be sent to the wrong RG and consequently not reach the correct
destination. Later, when the client retransmits the unacknowledged destination. Later, when the client retransmits the unacknowledged
SYN, the server will continue to send the SYN-ACK using the bad RG. SYN, the server will continue to send the SYN-ACK using the bad RG.
Eventually the client times out, and the attempt to open a TCP Eventually the client times out, and the attempt to open a TCP
connection fails. connection fails.
We next consider relaxing the restriction on switching RGs in an We next consider relaxing the restriction on switching RGs in an
attempt to avoid the previous failure scenario. The situation is attempt to avoid the previous failure scenario. The situation is
complicated by the fact that the RG on received packets may change complicated by the fact that the RG on received packets may change
for legitimate reasons (e.g., a multi-homed site load-shares traffic for legitimate reasons (e.g., a multi-homed site load-shares traffic
across multiple border routers). The key question is how one can across multiple border routers). The key question is how one can
determine which RG is valid and which is not. That is, for each of determine which RG is valid and which is not. That is, for each of
the RGs a sender attempts to use, how can it determine which RG the destination RGs a sender attempts to use, how can it determine
worked and which did not? Solving this problem is more difficult than which RG worked and which did not? Solving this problem is more
first appears, since one must cover the cases of delayed segments, difficult than first appears, since one must cover the cases of
lost segments, simultaneous opens, etc. If a SYN-ACK is retransmitted delayed segments, lost segments, simultaneous opens, etc. If a SYN-
using different RGs, it is not possible to determine which of those ACK is retransmitted using different RGs, it is not possible to
RGs worked correctly. We conclude that the only way TCP could determine which of the two RGs worked correctly. We conclude that
determine that a particular RG is correct is by receiving an ACK for the only way TCP can determine that a particular RG is correct is by
a specific sequence number in which all transmissions of that receiving an ACK for a specific sequence number in which all
sequence number used the same RG (a non-trivial addition to TCP). transmissions of that sequence number used the same RG. This would
involve non-trivial changes to TCP implementations.
At best, an RG selection algorithm for TCP would be relatively At best, an RG selection algorithm for TCP would require new logic in
straightforward but would require new logic in implementations of implementations of TCP's opening handshake --- a significant
TCP's opening handshake --- a significant transition/deployment transition and deployment issue. We are not certain that a valid
issue. We are not certain that a valid algorithm is attainable, algorithm is attainable, however. RG changes would have to be
however. RG changes would have to be handled in all cases handled by handled in all cases handled by the opening handshake: delayed
the opening handshake: delayed segments, lost segments, undetected segments, lost segments, undetected bit errors in RG, simultaneous
bit errors in RG, simultaneous opens, old segments, etc. opens, old segments, etc.
In the end, we conclude that although the corrupted SYN case In the end, we conclude that although the corrupted SYN case
introduces potential problems, the changes that would need to be made introduces potential problems, the changes that would need to be made
to TCP to robustly deal with such corruption would be significant, if to TCP to robustly deal with such corruption would be significant, if
tractable at all. This would result in a transition to GSE also tractable at all. This would result in a transition to GSE also
having a significant TCPng component, a significant drawback. having a significant TCPng component, a significant drawback.
5.3.8. On The Uniqueness Of ESDs 5.5. On The Uniqueness Of ESDs
The uniqueness requirements for ESDs depends on what purpose they Although ESDs are expected to be globally unique, their uniqueness
serve and how they are used. In GSE, ESDs identify interfaces, property may be violated either due to mistakes in allocation or by
requiring that they be globally unique. It does not make sense for malicious attacks. The exact uniqueness requirements for ESDs
two different interfaces to use the same ESD; every interface must depends on what purpose they serve and how they are used. If the
have its own ESD to distinguish it from others. correctness of some applications relies on the global uniqueness of
ESDs, then active checking and enforcement will be necessary. On the
other hand if ESDs are used only to uniquely identify individual
endpoints within a session, then one may consider global uniqueness
as unnecessary.
If ESDs are only used to identify session endpoints, the situation 5.5.1. Impact of Duplicate ESDs
becomes more complex. At first glance it might appear that two nodes
using the same ESD cannot communicate. However, this is not
necessarily the case. In the GSE proposal, for example, a node
queries the DNS to obtain an IPv6 address. The returned address
includes the Routing Stuff of an address (the RG+STP portions). Since
the sending host transmits packets based on the entire destination
IPv6 address, the sender may well forward the packet to a router that
delivers the packet to its correct destination (using the information
in the Routing Stuff). It is only on receipt of a packet that a node
would extract the ESD portion of a datagram's destination address and
ask "is this for me?" That is, a sender may not notice the
destination ESD is the same as the sending ESD because of the Routing
Stuff part of the address.
A more problematic case occurs if two nodes using the same ESD Consider what happens when two nodes using the same ESD attempt to
communicate with each other. In the GSE proposal, a node queries the
DNS to obtain an IPv6 address. The returned address includes the
Routing Stuff of an address (the RG+STP portions). The sender may
not notice the destination ESD is the same as its own ESD and may
well forward the packet to a router that delivers the packet to its
correct destination (using the information in the Routing Stuff). On
receipt of the packet, however, the destination node would extract
the ESD portion of the destination address and detect the conflict.
A more problematic case occurs if two nodes having the same ESD
communicate with a third party. To the third party, packets received communicate with a third party. To the third party, packets received
from either machine might appear to be coming from the same machine from either machine might appear to be coming from the same machine
since they are both using the same ESD. Consequently, at the since they all carry the same ESD. Consequently, at the transport
transport level, if both machines choose the same source and level, if both machines choose the same source and destination port
destination port numbers (one of the ports --- a server's well-known numbers (one of the ports --- a server's well-known port number ---
port number --- will likely be the same), packets belonging to two will likely be the same), packets belonging to two distinct transport
distinct transport connections will be demultiplexed to a single connections will be demultiplexed to a single transport end-point.
transport end-point.
When packets from different sources using the same source ESD are When packets from different sources using the same source ESD are
delivered to the same transport end-point, a number of possibilities delivered to the same transport end-point, a number of possibilities
come to mind: come to mind:
1) The transport end-point could accept the packet, without regard 1) Following the GSE specification, the transport end-point would
to the Routing Stuff of the source address. This may lead to a accept the packet, without regard to the Routing Stuff of the
number of robustness problems, if data from two different source address. This may lead to a number of robustness
sources mistakenly using the same ESD are delivered to the same problems (and at best will confuse the application).
transport or application end-point (which at best will confuse
the application).
2) The transport end-point could verify that the Routing Stuff of 2) The transport end-point could verify that the Routing Stuff of
the source address matches one of a set of expected values the source address matches one of a set of expected values
before processing the packet further. If the Routing Stuff before processing the packet further. If the Routing Stuff
doesn't match any expected value, the packet could be dropped. doesn't match any expected value, the packet could be dropped.
This would result in a connection from one host operating This would result in a connection from one host operating
correctly, while a connection from another host (using the same correctly, while a connection from another host (using the same
ESD) would fail. ESD) would fail.
3) When a packet is received with an unexpected Routing Stuff the 3) When a packet is received with an unexpected Routing Stuff the
receiver could invoke special-purpose code to deal with this receiver could invoke special-purpose code to deal with this
case. Possible actions include attempting to verify whether the case. Possible actions include attempting to verify whether the
Routing Stuff is indeed correct (the saved values may have Routing Stuff is indeed correct (the saved values may have
expired) or attempting to verify whether duplicate ESDs are in expired) or attempting to verify whether duplicate ESDs are in
use (e.g., by inventing a protocol that sends packets using both use (e.g., by inventing a protocol that sends packets using both
skipping to change at page 36, line 18 skipping to change at page 35, line 34
3) When a packet is received with an unexpected Routing Stuff the 3) When a packet is received with an unexpected Routing Stuff the
receiver could invoke special-purpose code to deal with this receiver could invoke special-purpose code to deal with this
case. Possible actions include attempting to verify whether the case. Possible actions include attempting to verify whether the
Routing Stuff is indeed correct (the saved values may have Routing Stuff is indeed correct (the saved values may have
expired) or attempting to verify whether duplicate ESDs are in expired) or attempting to verify whether duplicate ESDs are in
use (e.g., by inventing a protocol that sends packets using both use (e.g., by inventing a protocol that sends packets using both
Routing Stuff and verifies that they are delivered to the same Routing Stuff and verifies that they are delivered to the same
end-point). end-point).
5.3.9. New Denial of Service Attacks. 5.5.2. New Denial of Service Attacks.
It is clear that there are potential problems if identifiers are not It is clear that there are potential problems if identifiers are not
globally unique. How common such problems would actually occur in globally unique. How common such problems would actually occur in
practice depends on how many duplicates there are actually are. Thus, practice depends on how many duplicates there actually are. Thus,
one might be tempted to make the argument that a scheme for assigning one might be tempted to make the argument that a scheme for assigning
identifiers could be made to be "unique enough" in practice. This identifiers could be made to be "unique enough" in practice. This
would be a dangerous and naive assumption, because intruders will would be a dangerous and naive assumption, because in the absence of
actively impersonate other sites for the sole purpose of invalidating any ESD enforcement (i.e. ensuring each host use only the assigned
the uniqueness assumption. For example, one could deny service to ESD), intruders will actively impersonate other sites for the sole
host foo.bar.com by querying the DNS for its corresponding ESD, and purpose of invalidating the uniqueness assumption. For example, one
then impersonaiting that ESD. could deny service to host foo.bar.com by querying the DNS for its
corresponding ESD, and then impersonating that ESD.
As a specific example, one GSE-specific denial-of-service attack As a specific example, one GSE-specific denial-of-service attack
would be for an intruder to masquerade as another host and "wedge" would be for an intruder to masquerade as another host and "wedge"
connections in a SYN-RECEIVED state by sending SYN segments connections in a SYN-RECEIVED state by sending SYN segments
containing an invalid RG in the source IP address for a specific ESD. containing an invalid RG in the source IP address for a specific ESD.
Subsequent connection attempts to the wedged host from the legitimate Subsequent connection attempts to the wedged host from the legitimate
owner of the ESD (if they used the same TCP port numbers) would then owner of the ESD (if they used the same TCP port numbers) would then
not complete, since return traffic would be sent to the wrong place. not complete, since return traffic would be sent to the wrong place.
5.3.10. Summary of Identifier Authentication Issues 5.6. Summary of Identifier Authentication Issues
In summary, changing the RG dynamically in a safe way for a In summary, changing the RG dynamically in a safe way for a
connection requires that an originator of traffic be able to connection requires that an originator of traffic be able to
authenticate a proposed change in the RG before sending to a authenticate a proposed change in the RG before sending to a
particular ESD via that RG. This is difficult for several reasons: particular ESD via that RG. This is difficult for several reasons:
1) It can't be done on an end-to-end basis in GSE (e.g., via IPSec) 1) It can't be done on an end-to-end basis in GSE (e.g., via IPSec)
because the sender doesn't know what the RG portion of the because the sender doesn't know what value the RG portion of the
address will be when it reaches the sender. address will have when it reaches the receiver.
2) It can't easily be done in GSE because there is no mechanism at 2) It can't be easily done in GSE because there is no mechanism at
or below the transport layer to map ESDs into a quantity that or below the transport layer to map ESDs into a quantity that
can be used as a key to jump start the authentication process can be used as a key to jump start the authentication process
(using the DNS would be problematic due to layering circularity (using the DNS would be problematic due to layering circularity
considerations). considerations).
3) Any scheme that uses the full IPv6 address to do the 3) Any scheme that uses the full IPv6 address to do the
authentication can be used with standard provider-based authentication can be used with today's standard provider-based
addressing, raising the question of what benefit is retained addressing, raising the question of what benefit is retained
from having separate identifiers and locators. from having separate identifiers and locators.
Our final conclusion is that with the GSE approach, transport Our final conclusion is that with the GSE approach, transport
protocol end-points must make an early, single choice of the RG to protocol end-points must make an early, single choice of the RG to
use when sending to a peer and stick with that choice for the use when sending to a peer and stick with that choice for the
duration of the connection. Specifically: duration of the connection. Specifically:
1) The demultiplexing of arriving packets to their transport end 1) The demultiplexing of arriving packets to their transport end
points should use only the ESD, and not the Routing Stuff. points should use only the ESD, and not the Routing Stuff.
2) If the application chooses an RG for the remote peer (i.e., an 2) If the application chooses an RG for the remote peer (i.e., an
active open), use the provided RG for all traffic sent to that active open), use the provided RG for all traffic sent to that
peer, even if alternative RGs are received on subsequent peer, even if alternative RGs are received on subsequent
incoming datagrams from the same ESD. incoming datagrams from the same ESD. For all other cases, use
the first RG received with a given ESD for all sending.
3) For all other cases, use the first RG received with a given ESD 3) Simultaneously, we understand that, with the above rules, there
for all sending. Simultaneously, we understand that with this are still open issues with regard to invalid RGs, either through
rule, there are still open issues with regard to invalid RGs, corruption or through a active hostile attacks.
either through corruption or through a active hostile attacks.
With the above recommendation, there does not appear to be a One difficulty With the above recommendation is that there does not
straightforward way to use ESDs in conjunction with mobility or site appear to be a straightforward way to use ESDs in conjunction with
renumbering (in which existing connections survive the renumbering). mobility or site renumbering (in which existing connections survive
This presents a quandry. The main benefit of separating identifiers the renumbering). This presents a quandary. The main benefit of
and locators is the ability to have communication (e.g., a TCP separating identifiers and locators is the ability to have
connection) continue transparently, even when the Routing Stuff communication (e.g., a TCP connection) continue transparently, even
associated with a particular ESD changes. However, switching to a new when the Routing Stuff associated with a particular ESD changes.
Routing Stuff without properly authenticating it makes it trivial to However, switching to a new Routing Stuff without properly
hijack connections. authenticating it makes it trivial to hijack connections.
We cannot emphasize enough that the use of an ESD independent of an We cannot emphasize enough that the use of an ESD independent of an
associated RG can be very dangerous. That is, communicating with a associated RG can be very dangerous. That is, communicating with a
peer implies that one is always talking to the same peer for the peer implies that one is always talking to the same peer for the
duration of the communication. But as has been described in previous duration of the communication. But as has been described in previous
sections, such assurance can only come from properly authenticated sections, such assurance can only come from properly authenticating
RG. the RG associated with an ESD. That is not possible in GSE.
5.4. Miscellaneous
5.4.1. Renumbering and Domain Name System (DNS) Issues
Because any mapping scheme is complicated by renumbering, and because
recent IPv4 experience has shown a requirement for renumbering at
some frequency, it is worthwhile to explore the general renumbering
issue.
5.4.2. How Frequently Can We Renumber?
One premise of the GSE proposal [GSE] is that an ISP can renumber the
Routing Goop portion of a site's addresses transparently to the site
(i.e., without coordinating the change with the site). This would
make it possible for backbone providers to aggressively renumber the
Routing Goop part of addresses and achieve a high degree of route
aggregation. On closer examination, frequent (e.g., daily)
renumbering turns out to be difficult in practice because of a
circular dependency between the DNS and routing. Specifically, if a
site's Routing Stuff changes, nodes communicating with the site need
to obtain the new Routing Stuff. In the GSE proposal, one queries the
DNS to obtain this information. However, in order to reach a site's
DNS servers, the pointers controlling the downward delegation of
authoritative DNS servers (i.e., DNS "glue records") must use
addresses with Routing Stuff that are reachable. That is, in order to
find the address for the web server "www.foo.bar.com", DNS queries
might need to be sent to a root DNS server, as well as DNS servers
for "bar.com" and "foo.bar.com". Each of these servers must be
reachable from the querying client. Consequently, there must be an
overlap period during which both the old Routing Stuff and the new
Routing Stuff can be used simultaneously. During the overlap period,
DNS glue records would need to be updated to use the new addresses
(including Routing Stuff). Only after all relevant DNS servers have
been updated and older cached RRs containing the old addresses have
timed out can the old address be deleted.
An important observation is that the above issue is not specific to
GSE: the same requirement exists with today's provider-based
addressing architecture. When a site is renumbered (e.g., it switches
ISPs and obtains a new set of addresses from its new provider), the
DNS must be updated in a similar fashion.
5.4.3. Efficient DNS support for Site Renumbering
When a site renumbers to satisfy its ISP, only the site's routing
prefix needs to change. That is, the prefix reflects where within the
Internet the site resides.
In the current Internet, when a site is renumbered, the addresses of
all the site's internal nodes change. This requires a potentially
large update to the RR database for that site. Although Dynamic DNS
[DDNS] could potentially be used, the cost is likely to be large due
to the large number of individual records that would need to be
updated. In addition, when DHCP and DDNS are used together [DHCP-
DDNS], it may be the case that individual hosts "own" their own A or
AAAA records, further complicating the question of who is able to
update the contents of DNS RRs.
One change that could reduce the cost of updating the DNS when a site
is renumbered is to split addresses into two distinct portions: a
Routing Goop that reflects where a node attaches to the Internet and
a STP-plus-ESD that is the site-specific part of an address. During a
renumbering, the Routing Goop would change, but the "site internal
part" would remain fixed. Furthermore, the two parts of the address
could be stored in the DNS as separate RRs. That way, renumbering a
site would only require that the Routing Goop RR of a site be
updated; the "site-internal part" of individual addresses would not
change.
To obtain the address of a node from the DNS, a DNS query for the
name would return two quantities: the "site internal part" and the
DNS name of the Routing Stuff for the site. An additional DNS query
would then obtain the specific RR of the site, and the complete
address would be synthesized by concatenating the two pieces of
information.
Implementing these DNS changes increases the practicality of using
Dynamic DNS to update a site's DNS records as it is renumbered. Only
the site's Routing Goop RRs would need updating.
Finally, it may be useful to divide a node's AAAA RR into the three
logical parts of the GSE proposal, namely RG, STP and ESD. Whether or
not it is useful to have separate RRs for the STP and ESD portions of
an address or a single RR combining both is an issue that requires
further study.
If AAAA records are comprised of multiple distinct RRs, then one
question is who should be responsible for synthesizing the AAAA from
its components: the resolver running on the querying client's machine
or the queried name server? To minimize the impact on client hosts
and make it easier to deploy future changes, it is recommended that
the synthesis of AAAA records from its constituent parts be done on
name servers rather than in client resolvers.
5.4.4. Two-Faced DNS
The GSE proposal attempts to hide the RG part of addresses from nodes
within a site. If the nodes do not know their own RG, then they can't
store or use them in ways that cause problems should the site be
renumbered and its RG change (i.e., the cached RG become invalid). A
site's DNS servers, however, will need to have more information about
the RG its site uses. Moreover, the responses it returns will depend
on who queries the server. A query from a node within the site should
return an address with a Site Local RG, whereas a query for the same
name from a client located at a different site should return the
global scope RG. This facilitates intra-site communication to be
more resilient to failures outside of the site. Such context-
dependent DNS servers are commonly referred as "two-faced" DNS
servers.
Some issues that must be considered in this context:
1) A DNS server may recursively attempt to resolve a query on
behalf of a requesting client. Consequently, a DNS query might
be received from a proxy rather than from the client that
actually seeks the information. Because the proxy may not be
located at the same site as the originating client, a DNS server
cannot reliably determine whether a DNS request is coming from
the same site or a remote site. One solution would be to
disallow recursive queries for off-site requesters, though this
raises additional questions.
2) Since cached responses are, in general, context sensitive, a
name server may be unable to correctly answer a query from its
cache, since the information it has is incomplete. That is, it
may have loaded the information via a query from a local client,
and the information has a site-local prefix. If a subsequent
request comes in from an off-site requester, the DNS server
cannot return a correct response (i.e., one containing the
correct RG).
5.4.5. Bootstrapping Issues
If Routing Stuff information is distributed via the DNS, key DNS
servers must always be reachable. In particular, the addresses
(including Routing Stuff) of all root DNS servers are, for all
practical purposes, well-known and assumed to never change. It is not
uncommon for the addresses of root servers to be hard-coded into
software distributions. Consequently, the Routing Stuff associated
with such addresses must always be usable for reaching root servers.
If it becomes necessary or desirable to change the Routing Stuff of
an address at which a root DNS server resides, the routing subsystem
will likely need to continue carrying "exceptions" for those
addresses. Because the total number of root DNS servers is relatively
small, the routing subsystem is expected to be able to handle this
requirement.
All other DNS server addresses can be changed, since their addresses
are typically learned from an upper-level DNS server that has
delegated a part of the name space to them. So long as the delegating
server is configured with the new address, the addresses of other
servers can change.
6. Conclusion 6. Conclusion
The GSE proposal provides a concrete example of a network protocol The GSE proposal provides a concrete example of a network protocol
design that separates identifiers from locators in addresses. In design that separates identifiers from locators in addresses. In
this paper we compared GSE with IPv4 to better understand the pro's this paper we compared GSE with IPv4's CIDR-style addressing to
and con's of the respective design approaches. better understand the pros and cons of the respective design
approaches.
Functionally speaking, identifiers and locators each have a logically Functionally speaking, identifiers and locators each have a logically
different role to play. Thus overloading both in one field causes different role to play. Thus overloading both in one field causes
problems whenever the location of a node changes but its identity problems whenever the location of a node changes but its identity
does not. However, our analysis shows that overloading also presents does not. However, our analysis shows that overloading also presents
two critically important benefits. two critically important benefits.
First, for network entity A to send data to network entity B, A must First, for network entity A to send data to network entity B, A must
not only know B's end identifier but also B's locator. No scalable not only know B's end identifier but also B's locator. No scalable
way is known at this time to provide this mapping at the network way is known at this time to provide this mapping at the network
layer, other than overloading the two quantities into an address as layer, other than overloading the two quantities into an address as
is done in IPv4. Fundamentally, a scalable mapping algorithm strongly is done in IPv4. Fundamentally, a scalable mapping algorithm
suggests that the identifier space be structured hierarchically, yet strongly suggests that the identifier space be structured
identifiers in GSE are not sufficiently large to both contain hierarchically, yet identifiers in GSE are not sufficiently large to
sufficient heirarchy and support stateless address autoconfiguration. both contain sufficient hierarchy and support stateless address
Instead, GSE forces applications to supply up-to-date locators. autoconfiguration. Instead, GSE forces applications to supply up-
However, relying on the locator provided at the time communication is to-date locators. However, relying on the locator provided at the
established as GSE does is inadequate when the remote locator can time communication is established as GSE does is inadequate when the
change dynamically, precisely the scenario that is supposed to remote locator can change dynamically, precisely the scenario that is
benefit from the separation. That is, the benefits of separating the supposed to benefit from the separation. That is, the benefits of
identifier from the locator are largely lost, if the changes in the separating the identifier from the locator are largely lost, if the
identifier to locator binding are not tracked quickly. changes in the identifier to locator binding are not tracked quickly.
Secondly, when communicating with a remote site, a receiver must be Secondly, when communicating with a remote site, if the RG changes
there begins to be uncertainty as to whether a reliable TCP handshake
is possible (because of the need for passively opened TCP to use the
RG's it obtains from the packets). There cannot be an reliable byte
stream without the TCP handshake, and this technology seems strongly
tied to locator/identifier coupling in one address.
Finally, when communicating with a remote site, a receiver must be
able to insure (with reasonable certainty) that received data does able to insure (with reasonable certainty) that received data does
indeed come from the expected remote entity. In IPv4, it is possible indeed come from the expected remote entity. In IPv4, it is possible
to receive packets from a forged source, but the potential for to receive packets from a forged source, but the potential for
mischief between communicating peers is significantly limited because mischief between communicating peers is significantly limited because
return traffic will not reach the source of the forged traffic. That return traffic will not generally reach the source of the forged
is, communication involving packets sent in both directions will not traffic. That is, communication involving packets sent in both
succeed. In contrast, architectures like GSE that decouple the directions will not succeed. In contrast, architectures like GSE
identifier and locator functions have great difficulty assuring that that decouple the identifier and locator functions lose the built-in
traffic from a source identified only by an identifer actually comes protection available in classical IP and thus face great difficulty
from the correct source. Short of using cryptographic techniques in assuring that traffic from a source identified only by an identifier
which both end points share a private secret (e.g., using IPSec), actually comes from the correct source. Short of using cryptographic
there is no known mechanism that can use an identifier alone to techniques (e.g. IPsec, which would encounter its own difficulties
perform this remote entity authentication in a scalable way. That with the separation of locator from identifier), there is no known
is, using an identifier alone for authentication of received packets mechanism that can use an identifier alone to perform this remote
is dangerously unsafe. entity authentication. Using an identifier alone for authentication
of received packets is dangerously unsafe.
In summary, although overloading the address field with a combined In summary, although overloading the address field with a combined
identifier and locator leads to difficulties in retaining the identifier and locator leads to difficulties in retaining the
identity of a node whenever its address changes, analysis in this identity of a node whenever its address changes, analysis in this
paper suggests that the benefit of the overloading actually out- paper suggests that the benefit of the overloading actually out-
weighs its cost. Completely separating an identifier from its weighs its cost. Completely separating an identifier from its
locator renders the identifier untrustworthy, thus useless, in the locator renders the identifier untrustworthy, thus useless, in the
absence of an accompanying authentication system. absence of an accompanying authentication system.
7. Security Considerations 7. Security Considerations
The primary security consideration with GSE or, more generally, a The primary security consideration with GSE or, more generally, a
network layer with addresses split into locator and identifier parts, network layer with addresses split into locator and identifier parts,
is that of one node impersonating another by copying the is that of one node impersonating another by copying the
identification without the location. identification without the location. Indeed, the main conclusion of
this paper is that a GSE-like addressing structure introduces new
security vulnerabilities that are not present in IP, and that those
problems are serious enough to question the benefits of an
architecture that separates locaters and identifiers in addresses.
8. Acknowledgments 8. Acknowledgments
Thanks go to Steve Deering and Bob Hinden (the Chairs of the IPng Thanks go to Steve Deering and Bob Hinden (the Chairs of the IPng
Working Group) as well as Sun Microsystems (the host for the PAL1 Working Group) as well as Sun Microsystems (the host for the interim
meeting) for the planning and execution of the interim meeting. meeting) for the planning and execution of the interim meeting.
Thanks also go to Mike O'Dell for writing the 8+8 and GSE drafts; by Thanks also go to Mike O'Dell for writing the 8+8 and GSE drafts; by
publishing these documents and speaking on their behalf, Mike was the publishing these documents and speaking on their behalf, Mike was the
catalyst for some valuable discussions, both for IPv6 addressing and catalyst for some valuable discussions, both for IPv6 addressing and
for addressing architectures in general. Special thanks to the for addressing architectures in general. Special thanks to the
attendees of the PAL1 meeting whose high caliber discussions helped attendees of the interim meeting whose high caliber discussions
motivate and shape this document. helped motivate and shape this document.
9. References 9. References
[ANYCAST] "Host Anycasting Service", C. Partridge, T. Mendez, & W.
Milliken, RFC 1546.
[BATES] Scalable support for multi-homed multi-provider [BATES] Scalable support for multi-homed multi-provider
connectivity, Internet Draft, Tony Bates & Yakov Rekhter, connectivity, Tony Bates & Yakov Rekhter, RFC 2260,
draft-bates-multihoming-01.txt. January, 1998.
[Bellovin 89] "Security Problems in the TCP/IP Protocol Suite", [Bellovin 89] "Security Problems in the TCP/IP Protocol Suite",
Bellovin, Steve, Computer Communications Review, Vol. 19, Bellovin, Steve, Computer Communications Review, Vol. 19,
No. 2, pp32-48, April 1989. No. 2, pp32-48, April 1989.
[CERT] CERT(sm) Advisory CA-96.21 [CIDR] "Classless Inter-Domain Routing (CIDR): an Address
(ftp://info.cert.org/pub/cert_advisories) Assignment and Aggregation Strategy". V. Fuller, T. Li, J.
Yu, & K. Varadhan, RFC 1519, September 1993.
[DANVERS] Minutes of the IPNG working Group, April 1995.
ftp://ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/
95apr/area.and.wg.reports/ipng/ipngwg/ ipngwg-minutes-
95apr.txt.
[DHCP-DDNS] Interaction between DHCP and DNS, Internet Draft, Yakov [DHCP-DDNS] Interaction between DHCP and DNS, Internet Draft, Yakov
Rekhter, draft-ietf-dhc-dhcp-dns-04.txt. Rekhter, (Work in Progress.)
[DDNS] "Dynamic Updates in the Domain Name System (DNS UPDATE)", [DDNS] "Dynamic Updates in the Domain Name System (DNS UPDATE)",
Paul Vixie (Editor), draft-ietf-dnsind-dynDNS-11.txt, Paul Vixie (Editor), RFC 2136, April, 1997.
November, 1996.
[EUI64] 64-Bit Global Identifier Format Tutorial. [EUI64] 64-Bit Global Identifier Format Tutorial.
http://standards.ieee.org/db/oui/tutorials/EUI64.html. http://standards.ieee.org/db/oui/tutorials/EUI64.html.
Note: "EUI-64" is claimed as a trademark by an organization Note: "EUI-64" is claimed as a trademark by an organization
which also forbids reference to itself in association with which also forbids reference to itself in association with
that term in a standards document which is not their own, that term in a standards document which is not their own,
unless they have approved that reference. However, since unless they have approved that reference. However, since
this document is not standards-track, it seems safe to name this document is not standards-track, it seems safe to name
that organization: the IEEE. that organization: the IEEE.
[GSE] "GSE - An Alternate Addressing Architecture for IPv6", Mike [GSE] "GSE - An Alternate Addressing Architecture for IPv6", Mike
O'Dell, draft-ietf-ipngwg-gseaddr-00.txt. O'Dell, (Work in progress).
[IEEE802] IEEE Std 802-1990, Local and Metropolitan Area Networks: [IEEE802] IEEE Std 802-1990, "Local and Metropolitan Area Networks:
IEEE Standard Overview and Architecture. IEEE Standard Overview and Architecture."
[IEEE1212] IEEE Std 1212-1994, Information technology-- [IEEE1212] IEEE Std 1212-1994, "Information technology--
Microprocessor systems: Control and Status Registers (CSR) Microprocessor systems: Control and Status Registers (CSR)
Architecture for microcomputer buses. Architecture for microcomputer buses."
[RFC1122] "Requirements for Internet hosts - communication layers", [IPv6-ADDRESS] "An IPv6 Aggregatable Global Unicast Address
R. Braden, 10/01/1989. Format", R. Hinden, M. O'Dell, S. Deering, RFC 2374, July,
1998.
[RFC1715] The H Ratio for Address Assignment Efficiency. C. [MOBILITY] "IP Mobility Support", C. Perkins, RFC 2002, October,
Huitema. 1996.
[RFC1726] Technical Criteria for Choosing IP:The Next Generation [MOBILITY6] "Mobility Support in IPv6", D. Johnson, C. Perkins, ,
(IPng). F. Kastenholz, C. Partridge. (Work in progress).
[RFC1752] "The Recommendation for the IP Next Generation Protocol," [RFC1752] "The Recommendation for the IP Next Generation Protocol",
S. Bradner, A. Mankin, 01/18/1995. S. Bradner, A. Mankin, RFC 1752, January, 1995.
[RFC1788] "ICMP Domain Name Messages", W. Simpson, 04/14/1995 [RFC1788] "ICMP Domain Name Messages", W. Simpson, RFC 1788, April,
1995.
[RFC1958] Architectural Principles of the Internet. B. Carpenter. [RFC1884] "IP Version 6 Addressing Architecture", R. Hinden & S.
Deering, Editors, RFC 1884.
[RFC1971] IPv6 Stateless Address Autoconfiguration. S. Thomson, T. [RFC1958] "Architectural Principles of the Internet", B. Carpenter,
Narten. RFC 1958, June, 1996.
[RFC2002] "IP Mobility Support", C. Perkins, RFC 2002, October, [RFC1971] "IPv6 Stateless Address Autoconfiguration", S. Thomson,
1996. T. Narten, RFC 1971, August, 1996.
[RFC2008] "Implications of Various Address Allocation Policies for [RFC2008] "Implications of Various Address Allocation Policies for
Internet Routing", Y. Rekhter, T. Li. Internet Routing", Y. Rekhter, T. Li, RFC 2008, October
1996.
[RFC2065] Domain Name System Security Extensions. D. Eastlake, C.
Kaufman.
[RFC2073] An IPv6 Provider-Based Unicast Address Format. Y. [RFC2073] An IPv6 Provider-Based Unicast Address Format. Y.
Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. RFC
2073, January, 1997.
[RFC2267] Network Ingress Filtering: Defeating Denial of Service [RFC2267] Network Ingress Filtering: Defeating Denial of Service
Attacks which employ IP Source Address Spoofing, P. Attacks which employ IP Source Address Spoofing, P.
Ferguson, D. Senie, January 1988. Ferguson, D. Senie, RFC 2267.
[ROUTER-RENUM] "Router Renumbering for IPv6", M. Crawford, draft-
ietf-ipngwg-router-renum-06.txt.
10. Authors' Addresses 10. Authors' Addresses
Matt Crawford John Stewart Matt Crawford John Stewart
Fermilab MS 368 Juniper Networks, Inc. Fermilab MS 368 Juniper Networks, Inc.
PO Box 500 385 Ravendale Drive PO Box 500 385 Ravendale Drive
Batavia, IL 60510 USA Mountain View, CA 94043 Batavia, IL 60510 USA Mountain View, CA 94043
Phone: 630-840-3461 Phone: +1 650 526 8000 Phone: 630-840-3461 Phone: +1 650 526 8000
EMail: crawdad@fnal.gov EMail: jstewart@juniper.net EMail: crawdad@fnal.gov EMail: jstewart@juniper.net
Allison Mankin Lixia Zhang Allison Mankin Lixia Zhang
USC/ISI UCLA Computer Science Department USC/ISI UCLA Computer Science Department
4350 North Fairfax Drive 4531G Boelter Hall 4350 North Fairfax Drive 4531G Boelter Hall
Suite 620 Los Angeles, CA 90095-1596 USA Suite 620 Los Angeles, CA 90095-1596 USA
Arlington, VA 22203 USA Phone: 310-825-2695 Arlington, VA 22203 USA Phone: 310-825-2695
skipping to change at page 45, line 7 skipping to change at page 41, line 16
Batavia, IL 60510 USA Mountain View, CA 94043 Batavia, IL 60510 USA Mountain View, CA 94043
Phone: 630-840-3461 Phone: +1 650 526 8000 Phone: 630-840-3461 Phone: +1 650 526 8000
EMail: crawdad@fnal.gov EMail: jstewart@juniper.net EMail: crawdad@fnal.gov EMail: jstewart@juniper.net
Allison Mankin Lixia Zhang Allison Mankin Lixia Zhang
USC/ISI UCLA Computer Science Department USC/ISI UCLA Computer Science Department
4350 North Fairfax Drive 4531G Boelter Hall 4350 North Fairfax Drive 4531G Boelter Hall
Suite 620 Los Angeles, CA 90095-1596 USA Suite 620 Los Angeles, CA 90095-1596 USA
Arlington, VA 22203 USA Phone: 310-825-2695 Arlington, VA 22203 USA Phone: 310-825-2695
EMail: mankin@isi.edu EMail: lixia@cs.ucla.edu EMail: mankin@isi.edu EMail: lixia@cs.ucla.edu
Phone: 703-807-0132 Phone: 703-812-3706
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
3039 Cornwallis Ave. 3039 Cornwallis Ave.
PO Box 12195 - F11/502 PO Box 12195 - F11/502
Research Triangle Park, NC 27709-2195 Research Triangle Park, NC 27709-2195
Phone: 919-254-7798 Phone: 919-254-7798
EMail: narten@raleigh.ibm.com EMail: narten@raleigh.ibm.com
Appendix B -- Ideas Incorporated Into IPv6 Appendix A: Increased Reliance on Domain Name System (DNS)
As we've discussed in previous sections, the motivation for
separating identifiers from locators in IP address is to allow the
locator portion to change more easily. However because GSE does not
provide a mapping from an ESD to its locator, whenever the locator
changes, GSE falls back on DNS to provide such mapping.
Because any mapping scheme is complicated by renumbering, and because
recent IPv4 experience has shown a requirement for renumbering at
some frequency, it is worthwhile to explore the general renumbering
issue.
A.1: Renumbering and DNS: How Frequently Can We Renumber?
One premise of the GSE proposal [GSE] is that an ISP can renumber the
Routing Goop portion of a site's addresses transparently to the site
(i.e., without coordinating the change with the site). This would
make it possible for backbone providers to aggressively renumber the
Routing Goop part of addresses to achieve a high degree of route
aggregation. On closer examination, frequent (e.g., daily)
renumbering turns out to be difficult in practice because of a
circular dependency between the DNS and routing. Specifically, if a
site's Routing Stuff changes, nodes communicating with the site need
to obtain the new Routing Stuff. In the GSE proposal, one queries
the DNS to obtain this information. However, in order to reach a
site's DNS servers, the pointers controlling the downward delegation
of authoritative DNS servers (i.e., DNS "glue records") must use
addresses with Routing Stuff that are reachable. That is, in order
to find the address for the web server "www.foo.bar.com", DNS queries
might need to be sent to a root DNS server, as well as DNS servers
for "bar.com" and "foo.bar.com". Each of these servers must be
reachable from the querying client. Consequently, there must be an
adequate overlap period after the RG changes, during which both the
old Routing Stuff and the new Routing Stuff can be used
simultaneously. During the overlap period, DNS glue records will
need to be updated to use the new addresses (including Routing Stuff)
and DNS RR's needs to be updated. Only after all relevant DNS
servers have been updated and all previously cached RRs containing
the old addresses have timed out can the old RG be deleted.
An important observation is that the above issue is not specific to
GSE; the same requirement exists with today's provider-based
addressing architecture. When a site is renumbered (e.g., it
switches ISPs and obtains a new set of addresses from its new
provider), the DNS must be updated in a similar fashion.
A.2: Efficient DNS support for Site Renumbering
In the current Internet, when a site is renumbered, the addresses of
all the site's internal nodes change. This requires a potentially
large update to the RR database for that site. Although Dynamic DNS
[DDNS] could potentially be used, the cost is likely to be large due
to the large number of individual records that would need to be
updated. In addition, when DHCP and DDNS are used together [DHCP-
DDNS], it may be the case that individual hosts "own" their own A or
AAAA records, further complicating the question of who is able to
update the contents of DNS RRs.
With GSE, When a site renumbers to satisfy its ISP, only the site's
routing prefix needs to change. That is, the prefix reflects where
within the Internet the site resides. One DNS modification that
could reduce the cost of updating the DNS when a site is renumbered
is to store addresses in two distinct RR's: one for the Routing Goop
that reflects where a node attaches to the Internet and the other for
STP-plus-ESD that is the site-specific part of an address. During a
renumbering, the Routing Goop would change, but the "site internal
part" would remain fixed. That way, renumbering a site would only
require that the Routing Goop RR of a site be updated; the "site-
internal part" of individual addresses would not change.
To obtain the address of a node from the DNS, a DNS query for the
name would return two quantities: the "site internal part" and the
DNS name of the Routing Stuff for the site. An additional DNS query
would then obtain the specific RR of the site, and the complete
address would be synthesized by concatenating the two pieces of
information.
Implementing these DNS changes increases the practicality of using
Dynamic DNS to update a site's DNS records as it is renumbered. Only
the site's Routing Goop RRs would need updating.
Finally, it may be useful to divide a node's AAAA RR into the three
logical parts of the GSE proposal, namely RG, STP and ESD. Whether
or not it is useful to have separate RRs for the STP and ESD portions
of an address or a single RR combining both is an issue that requires
further study.
If AAAA records are comprised of multiple distinct RRs, then one
question is who should be responsible for synthesizing the AAAA from
its components: the resolver running on the querying client's machine
or the queried name server? To minimize the impact on client hosts
and make it easier to deploy future changes, it is recommended that
the synthesis of AAAA records from its constituent parts be done on
name servers rather than in client resolvers.
A.2.1: Two-Faced DNS
The GSE proposal attempts to hide the RG part of addresses from nodes
within a site. If the nodes do not know their own RG, then they
can't store or use them in ways that cause problems should the site
be renumbered and its RG change (i.e., the cached RG become invalid).
A site's DNS servers, however, will need to have more information
about the RG its site uses. Moreover, the responses it returns will
depend on who queries the server. A query from a node within the
site should return an address with a Site Local RG, whereas a query
for the same name from a client located at a different site should
return the global scope RG. This facilitates intra-site
communication to be more resilient to failures outside of the site.
Such context-dependent DNS servers are commonly referred as "two-
faced" DNS servers.
Some issues that must be considered in this context:
1) A DNS server may recursively attempt to resolve a query on
behalf of a requesting client. Consequently, a DNS query might
be received from a proxy rather than from the client that
actually seeks the information. Because the proxy may not be
located at the same site as the originating client, a DNS server
cannot reliably determine whether a DNS request is coming from
the same site or a remote site. One solution would be to
disallow recursive queries for off-site requesters, though this
raises additional questions.
2) Since cached responses are, in general, context sensitive, a
name server may be unable to correctly answer a query from its
cache, since the information it has is incomplete. That is, it
may have loaded the information via a query from a local client,
and the information has a site-local prefix. If a subsequent
request comes in from an off-site requester, the DNS server
cannot return a correct response (i.e., one containing the
correct RG).
A.2.2: Bootstrapping Issues
If Routing Stuff information is distributed via the DNS, key DNS
servers must always be reachable. In particular, the addresses
(including Routing Stuff) of all root DNS servers are, for all
practical purposes, well-known and assumed to never change. It is
not uncommon for the addresses of root servers to be hard-coded into
software distributions. Consequently, the Routing Stuff associated
with such addresses must always be usable for reaching root servers.
If it becomes necessary or desirable to change the Routing Stuff of
an address at which a root DNS server resides, the routing subsystem
will likely need to continue carrying "exceptions" for those
addresses. Because the total number of root DNS servers is
relatively small, the routing subsystem is expected to be able to
handle this requirement.
All other DNS server addresses can be changed, since their addresses
are typically learned from an upper-level DNS server that has
delegated a part of the name space to them. So long as the
delegating server is configured with the new address, the addresses
of other servers can change.
Appendix B: Additional Issues Related to GSE
This paper focused primarily on the issues of separating identifiers
and locators in unicast addresses. It is worth noting that a number
of additional issues were identified during the IPng interim meeting
with respect to the GSE proposal that would need to be considered
before an architecture such as GSE could be deployed. Specifically:
- - it is not known how multicast would work under GSE. One
identified issue is that a site with multiple egress routers
would (by default) inject multicast traffic through each of all
the egress routers, each would then replace the source Routing
Goop with a differing value. This would lead to multiple copies
of the same packet each carrying a different IPv6 address, thus
being considered as from different sources.
- - It would be more difficult to create tunnels. Any tunnel that
crosses a site boundary (i.e., the entry and exit points are in
differing sites) would in effect require that both tunnel
endpoints be border routers to insure that the addresses in the
inner headers were rewritten correctly.
- - In order for the DNS to hide a site's Routing Goop from
internal nodes yet make it visible to external nodes requires a
two-faced DNS. The current DNS model assumes a single global
database in which all queries are answered the same way,
irregardless of who issued the query. It is unclear how to make
the DNS answer queries in a context-sensitive manner without
also negatively impacting its caching model.
Appendix C: Ideas Incorporated Into IPv6
This section summarizes changes made to IPv6 specifications which This section summarizes changes made to IPv6 specifications which
originated in the GSE proposal or in the discussions arising from it. originated in the GSE proposal or in the discussions arising from it.
First and most visible was the change to the unicast address format. The unicast address format was changed to improve the aggregability
Instead of an topologically insignificant Registry ID immediately of unicast addresses. Instead of a topologically insignificant
following the Format Prefix, there is now a Top-Level Aggregation Registry ID immediately following the Format Prefix [RFC2073], there
Identifier. This field will identify a large routable aggregate to is now a Top-Level Aggregation Identifier [IPv6-ADDRESS]. This field
which an address belongs rather than an administrative unit by which identifies a large routable aggregate to which an address belongs
an address was assigned. The TLA corresponds to the "Large rather than an administrative unit that assigned the address. The
Structure" of GSE. The IPv6 Next-Level Aggregation Identifier (NLA) TLA corresponds to the "Large Structure" of GSE. The IPv6 Next-Level
is roughly the rest of the GSE "Routing Goop" and the Site-Level Aggregation Identifier (NLA) is roughly the rest of the GSE "Routing
Aggregation Identifier (SLA) is a slightly expanded GSE Site Topology Goop" and the Site-Level Aggregation Identifier (SLA) is a slightly
Partition. expanded GSE Site Topology Partition.
The decision to put fixed boundaries between parts of the unicast The decision to put fixed boundaries between parts of the unicast
address (TLA, NLA, SLA, Interface Identifier) also came from GSE. address (TLA, NLA, SLA, Interface Identifier) into IPv6 addresses
The previous "provider-based" addressing architecture for IPv6 had [IPv6-ADDRESS] also came from GSE. The previous "provider-based"
fluid boundaries between Registry ID, Provider ID, Subscriber ID and addressing architecture for IPv6 [RFC2073] had fluid boundaries
the Intra-Subscriber part, as well as undefined divisions within the between Registry ID, Provider ID, Subscriber ID and the Intra-
Provider-ID and Intra-Subscriber part. (On subnetworks with a MAC- Subscriber part, as well as undefined divisions within the Provider-
layer address, the latter boundary was generally placed to ID and Intra-Subscriber part. (On subnetworks with a MAC-layer
accommodate use of that address as an Interface ID.) The new address, the latter boundary was generally placed to accommodate use
addressing architecture still expects divisions within the NLA of that address as an Interface ID.) The new addressing architecture
portion of the address, placed to reflect topological aggregation still expects divisions within the NLA portion of the address, placed
points. to reflect topological aggregation points.
Defining a fixed boundary between the routable portion of the address Defining a fixed boundary between the routable portion of the address
and the node-on-link identifier required the specification of an and the part indicating an interface on a specific link required
Interface Identifier which would be as suitable as possible for all specifying an Interface Identifier that would be suitable for all
subnetwork technologies. The IEEE "EUI-64" identifier was selected, subnetwork technologies. The IEEE "EUI-64" identifier was selected,
having the advantages of an easy mapping from 48 bit MAC addresses having the advantages of an easy mapping from 48 bit MAC addresses
and a defined escape flag into locally-administered values. and a defined escape flag into locally-administered values.
The second change to come out of the GSE discussions relates to Another change was the redefinition of the interface identifier to be
reducing the number of DNS record changes required in the event of a 64-bit quantity. In the common case where a node has at least one
site renumbering. This work is not finalized as of this writing, but IEEE interface, the interface identifier is constructed from an IEEE
the result may be that individual IPv6 addresses are stored (and identifier (i.e., a MAC address) in such a way that there is a very
signed, in the case of Secure DNS) as a partial address and an high probability that the identifier will be globally unique. In the
indirect pointer which leads to the high-order part of the address. case where a globally unique identifier can't easily be constructed
There may be multiple levels of indirection and a changed record at automatically, a bit in the identifier indicates that the address is
any one level would suffice to update the DNS's record of the IPv6 not globally unique. At present, there are no plans for transport
addresses of every node in a given branch of the addressing protocols such as TCP to exploit interface identifiers, but the door
hierarchy. has been left open for a future protocol (e.g., TCPng) to take
advantage of the ESD concept.
Another change to come out of the GSE discussions relates to reducing
the number of DNS record changes required in the event of site
renumbering. This work is not finalized as of this writing, but the
result may be that individual IPv6 addresses are stored (and signed,
in the case of Secure DNS) as a partial address and an indirect
pointer which leads to the high-order part of the address. There may
be multiple levels of indirection and a changed record at any one
level would suffice to update the DNS's record of the IPv6 addresses
of every node in a given branch of the addressing hierarchy.
A change in the method of doing DNS address-to-name lookups is also A change in the method of doing DNS address-to-name lookups is also
in the works. This may be a change in the form and/or operation of in the works. This may be a change in the form and/or operation of
the ip6.int domain or some new mechanism which involves participation the ip6.int domain or some new mechanism which involves participation
by the routers or the end-nodes themselves. by the routers or the end-nodes themselves.
Two other changes arising from GSE will not affect the IPv6 base Two other changes arising from GSE will not affect the IPv6 base
specifications themselves, but do direct additional work. Those are specifications themselves, but do direct additional work. Those are
the injection of global prefix information into a site from a the injection of global prefix information into a site from a
provider or exchange, and some inter-provider cooperative method of provider or exchange [ROUTER-RENUM], and some inter-provider
providing multihoming to mutual customers with minimal impact on cooperative method of providing multihoming to mutual customers with
routing tables in distant parts of the network. minimal impact on routing tables in distant parts of the network.
Appendix D: Reverse Mapping of Complete GSE Addresses
The ability to map an IP address into its corresponding DNS name is
used in several contexts:
1) Network packet tracing utilities (e.g., tcpdump) display the
contents of packets. Printing out the DNS names appearing in
those packets (rather than dotted IP addresses) requires access
to an address-to-name mapping mechanism.
2) Some applications perform a "poor-man's" authentication by using
the DNS to map the source address of a peer into a DNS name.
The client then queries the DNS a second time, this time asking
for the address(es) corresponding to the peer's DNS name. Only
if one of the addresses returned by the DNS matches the peer
address of the TCP connection is the source of the TCP
connection accepted as being from the indicated DNS name.
It is important to note that although two DNS queries are made
during the above operation, it is the second one --- mapping the
peer's DNS name back into an IP address --- that provides the
authentication property. The first transaction simply obtains
the peer's DNS name, but no assumption is made that the returned
DNS name is correct. Thus, the first DNS query could be
replaced by an alternate mechanism without weakening the already
weak authentication check described above. One possible
alternate mechanism, an ICMP "Who Are You" message, is described
below
3) Applications that log all incoming network connections (e.g.,
anonymous FTP servers) may prefer logging recognizable DNS names
to addresses.
4) Network administrators examining logs or other trace data
containing addresses may wish to determine the DNS name of some
addresses. Note that this may occur sometime after those
addresses were actually used.
The following subsections describe techniques for mapping a full IPv6
address back into some quantity (e.g., a DNS name or locator). We
include these descriptions for completeness even though they do not
address the fundamental problem of how to perform the mapping on an
identifier alone. It should also be noted that because both
techniques operate on complete IPv6 addresses, they are both directly
applicable to provider-based addressing schemes and are not specific
to GSE.
D.1: DNS-Like Reverse Mapping of Full GSE Addresses
Although it seems infeasible to have a global scale, reverse mapping
of ESDs, within a site, it may be feasible to maintain a database
keyed on unstructured 8-byte ESDs. However, it is an open question
whether such a database can be kept up-to-date at reasonable cost,
without making unreasonable assumptions as to how large sites are
going to grow, and how frequently ESD registrations will be made or
updated. Note that the issue isn't just the physical database
itself, but the operational issues involved in keeping it up-to-date.
For the rest of this section, however, let us assume that such a
database can be built.
A mechanism supporting a lookup keyed on a flat-space ESD from an
arbitrary site requires having sufficient structure to identify the
site that needs to be queried. In practice, since the Routing Stuff
is organized hierarchically, if an ESD is always used in conjunction
with Routing Stuff (i.e., a full 16-byte address), it becomes
feasible to maintain a DNS-like tree that maps full GSE addresses
into DNS names, in a fashion analogous to what is done with IPv4 PTR
records today.
It should be noted that a GSE address lookup will work only if the
Routing Stuff portion of the address is correctly entered in the DNS
tree. Because the Routing Stuff portion of an address is expected to
change over time, this assumption will not hold valid indefinitely.
As a consequence, a packet trace recorded in the past might not
contain enough information to identify the off-Site sources of the
packets in the present. This problem can be addressed by requiring
that the database of RG delegations be maintained, together with
accurate timing information, for some period of time after the RG is
no longer usable for routing packets.
Finally, it should be noted that the problem where an address's RG
"expires" with the implication that the mapping of "expired"
addresses into DNS names may no longer hold is not a problem specific
to the GSE proposal. With provider-based addressing, the same issue
arises when a site renumbers into a new provider prefix and releases
the allocation from a previous block. The authors are aware of one
such renumbering incidence in IPv4 where a block of returned
addresses was reassigned and reused within 24 hours of the
renumbering event.
D.2: The ICMP Who-Are-You Message
There is widespread agreement on the utility of being able to
determine the DNS name one is communicating with from the address
being used. In addition to the fact that DNS names are more
meaningful to human users and more stable than addresses, many users
use this reverse mapping as part of a poor-man's authentication for
the remote peer; if one can map the obtained DNS name back to the
same address, one has an increased confidence of the peer being a
legitimate one.
In practice, however, the IN-ADDR.ARPA domain is not fully populated
and poorly maintained. Consequently, an old proposal to define an
ICMP Who-Are-You message was resurrected [RFC1788]. A client would
send such a message to a peer, and that peer would return an ICMP
message containing its DNS name. Asking a remote host to supply its
own name in no way implies that the returned information is accurate.
However, having a remote peer provide a piece of information that a
client can use as input to a separate authentication procedure
provides a starting point for performing strong authentication. The
actual strength of the authentication depends on the authentication
procedure invoked, rather than the untrustable piece of information
provided by a remote peer.
Reconsidering the "cheap" authentication procedure described earlier,
the ICMP Who-Are-You replaces the DNS PTR query used to obtain the
DNS name of a remote peer. The second DNS query, to map the DNS name
back into a set of addresses, would be performed as before. Because
the latter DNS query provides the strength of the authentication, the
use of an ICMP Who-Are-You message does not in any way weaken the
strength of the authentication method. Indeed, it can only make it
more useful in practice, because virtually all hosts can be expected
to implement the Who-Are-You message.
The Who-Are-You message has advantages outside the context of GSE as
well, including a more decentralized, and hence more scalable,
administration and easier upkeep than a DNS reverse-lookup zone. It
also has drawbacks: it requires the target node to be up and
reachable at the time of the query and to know its fully qualified
domain name. It is also not possible to resolve addresses once those
addresses become unroutable. In contrast, the DNS PTR mirrors, but
is independent of, the routing hierarchy. The DNS can maintain
mappings long after the routing subsystem stops delivering packets to
certain addresses.
The requirement that the target node be up and reachable at the time
of the query makes it very uncertain that one would be able to take
addresses from a packet log and translate them to correct domain
names at a later time. One can argue that this is a design flaw in
the logging system, as it violates the architectural principle,
"Avoid any design that requires addresses to be ... stored on non-
volatile storage" [RFC1958]. A better-designed system would look up
domain names promptly from logged addresses. Indeed, one of the
authors has been doing that for some years.
 End of changes. 207 change blocks. 
1089 lines changed or deleted 1118 lines changed or added

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