requirement, availability, should rely on a set of ad hoc and
application-specific mechanisms.
• Authenticity: users would like to know that the data came
from the appropriate source, rather than from some spoofing
adversary. Today this requires a PKI to provide users with
the public key of the provider. Moreover, authenticity today
is typically achieved by securing the channel to the source,
rather than explicitly authenticating the data.
Thus, several of the most natural features one would want for
service access and data retrieval — persistence, availability, and
authentication — are made unnecessarily hard by the current host-
to-host model of the Internet, often requiring awkward or expensive
work-arounds. Given this discordance between historical design
(host-oriented) and current usage (data-oriented), we ask: what
would the architecture look like if we built it around service and
data access?
Somewhat surprisingly, our research suggests that most of the
necessary changes reside in how Internet names are structured and
resolved. We propose replacing DNS names with flat, self-certifying
names, and replacing DNS name resolution with a name-based
anycast primitive that lives above the IP layer. We call the resulting
design the Data-Oriented Network Architecture (DONA).
DONA improves data retrieval and service access by providing
stronger and more architecturally coherent support for persistence,
availability, and authentication. It can also be extended to provide
support for caching and RSS-like updates. However, DONA’s
impact is not limited to data and service access; we use these
applications as motivating examples because they force us to think
differently about some fundamental issues, but most of these issues
are not particular to data/service access. As a result, as we describe
below, DONA’s overall design has architectural implications that
range far beyond data/service access.
DONA’s name-based anycast primitive is useful for many kinds
of resource discovery; for instance, it can provide the basic
primitives underlying SIP, support host mobility and multihoming,
and establish forwarding state for interdomain multicast. Placing
anycast at the naming layer, rather than at the IP layer, allows us
to design for functionality rather than be limited by concerns about
scalability, since the mechanisms need not operate at link speed.
There is another issue where historical design is at odds with
current usage. The original Internet architecture, following the
end-to-end principle, intended the network to be a purely trans-
parent carrier of packets. Today, however, the various network
stakeholders (such as enterprises) use middleboxes to improve
security (e.g., firewalls, proxies) and accelerate applications (e.g.,
caches) [3]. Because DONA’s anycast name resolution process
follows essentially the same administrative path as the ensuing
data packets (we will address the subtleties in this statement later),
DONA can treat the stakeholders along the path as relevant Internet
actors. This allows DONA to provide clean support for network-
imposed middleboxes. This isn’t a repudiation of the end-to-end
principle, in that functionality is still provided at the ends; it is
merely a recognition that operators should have, at their disposal,
architecturally coherent mechanisms to control how and what traffic
traverses their network.
More recently, there has been much hand-wringing about the
scalability of routing in the current addressing paradigm [27].
DONA’s anycast primitive provides a discovery mechanism that
lives above the IP layer; as we will later describe, this enables the
use of path-labels rather than global addresses, an approach that
results in tiny interdomain routing tables.
At a m ore speculative level, DONA represents a partial shift away
from sender-based primitives to a more receiver-based approach.
One of our future research tasks is to explore how far we can go in
this direction, and what this might mean for a future Internet.
These architectural implications encouraged us that DONA
is not merely restricted to data and service access (which, by
itself, is significant as it is by far the dominant usage on the
current Internet), but rather facilitates improvements along many
dimensions. However, there are many other issues, not discussed
here, that demand attention: the Internet still needs better security
(particularly against DoS and malicious/misconfigured routers),
better manageability, better usability, and many other properties.
We aren’t proposing DONA as a solution to these problems; in fact,
we think DONA is largely orthogonal to them. We hope to eventually
incorporate work on these problems within a larger framework that
also includes DONA.
The next section presents DONA’s basic design and Section
3
describes how this design supports such tasks as server selection,
mobility, multihoming, session initiation, and interdomain multicast
state e stablishment. Section 4 discusses how DONA’s infrastructure
could be extended to support more advanced functionality, such
as content delivery, delay-tolerant networking, and a variety of
administrative access policies (including middlebox insertion).
Section 5 discusses our prototype implementation and Section 6
addresses the crucial question of DONA’s feasibility. The name-
based anycast primitive will require routing on a very large
namespace, but it need only be done at name resolution speeds,
not line s peeds; we present various estimates indicating that DONA
is within reach of today’s technology.
We delay our discussion of related work until Section 7, in order
to have enough context to make the necessary connections. For now,
we merely note that almost every aspect of our design is (proudly)
stolen from elsewhere, most notably from TRIAD [19], HIP [28],
and SFS [25]. It is the synthesis of these various ideas into a coherent
architecture that we claim as our contribution.
The paper ends, in Section 8, with some speculations on DONA’s
broader architectural implications. In particular, we discuss the
possibility of basing the interface offered to applications on DONA’s
name-based anycast primitive.
2 Basic Design
DONA involves a major redesign of Internet naming. In this section
we first motivate these changes and then present DONA’s naming
structure and name resolution mechanism. This is followed by a
brief discussion of security and addressing issues. For lack of space,
many details are omitted.
2.1 Motivation
We start with the problem of service and data access and ask how
we might easily achieve persistence, availability, and authentication,
basic tasks which today are (sometimes badly) handled by external
ad hoc mechanisms. In DONA, we propose a strict separation
of concerns between naming and name resolution in handling
these tasks: names handle persistence and authenticity, while name
resolution handles availability.
To provide persistence and authenticity, we use flat, self-certifying
names [25,28]. This form of naming is, by now, a standard technique.
As we review shortly in Section 2.2, such names will remain
invariant and enable easy authentication. The use of flat names
makes informal identification harder (since you can’t remember
your friend’s 128-bit identifier), but it makes formal authentication
easier.
High availability means that when a user requests data by name,