As per Relevance of the word december, we have this rfc below:
Network Working Group C.
Request for Comments: 1383
December 1992
An Experiment in DNS Based IP
Status of this
This memo defines an Experimental Protocol for the
community. Discussion and suggestions for improvement are requested
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
Table of
1. Routing, scaling and hierarchies ...................... 1
2. Routing based on MX records ........................... 2
3. Evaluation of DNS routing ............................. 3
3.1 Loops and relays ..................................... 4
3.2 Performances and scaling ............................. 5
3.3 Tunneling or source routing .......................... 6
3.4 Choosing a gateway ................................... 6
3.5 Routing dynamics ..................................... 6
3.6 DNS connectivity ..................................... 7
3.7 On the way back ...................................... 8
3.8 Flirting with policy routing ......................... 8
4. Rationales for deployment ............................. 9
4.1 The good citizens .................................... 10
4.2 The commercial approach .............................. 10
5. The experimental development .......................... 11
5.1 DNS record ........................................... 11
5.2 Interface with the standard IP router ................ 12
5.3 The DNS query manager ................................ 12
5.4 The real time forwarder .............................. 12
5.5 Interaction with routing protocols ................... 13
6. Acknowledgments ....................................... 13
7. Conclusion ............................................ 13
8. References ............................................ 14
9. Security Considerations ............................... 14
10. Author's Address ..................................... 14
1. Routing, scaling and
Several recent studies have outlined the risk of "routing explosion
in the current Internet: there are already more than 5000
announced in the NSFNET routing tables, more than 7000 in the
Huitema [Page 1]
RFC 1383 DNS based IP routing December 1992
routing tables. As these numbers are growing, several
occur
* The size of the routing tables grows linearly with
number of connected networks; handling this larger
requires more resources in all "intelligent" routers,
particular in all "transit" and "external" routers
cannot rely on default routes
* The volume of information carried by the route
protocols such as BGP grows with the number of networks
using more network resources and making the reaction
routing events slower
* Explicit administrative decisions have to be exercised
all transit networks administrators which want
implement "routing policies" for each and
additional "multi-homed" network
The current "textbook" solution to the routing explosion problem
to use "hierarchical routing" based on hierarchical addresses.
is largely documented in routing protocols such as IDRP, and is
of the rationales for deploying the CIDR [3] addressing structure
the Internet. This textbook solution, while often perfectly adequate
as a number of inconveniences, particularly in the presence
"multihomed stubs", e.g., customer networks that are connected
more than one service providers
The current proposal presents a scheme that allows for
routing. It is complementary with the classic "hierarchical routing
approach, but provides an easy to implement and low cost solution
"multi-homed" domains. The solution is a generalization of the "
record" scheme currently used for mail routing
2. Routing based on MX
The "MX records" are currently used by the mail routing
to introduce a level of decoupling between the "domain names"
for user registration and the mailbox addresses. They
particularly useful for sending mail to "non connected" domains:
that case, the MX record points to one or several Internet hosts
accept to relay mail towards the target domain
We propose to generalize this scheme for packet routing. Suppose
routing domain D, containing several networks, subnetwork and hosts
and connected to the Internet through a couple of IP gateways.
gateways are dual homed: they each have an address within the
D -- say D1 and D2 -- and an address within the Internet -- say I
Huitema [Page 2]
RFC 1383 DNS based IP routing December 1992
and I2 --. These gateways also have a particularity: they
information, and don't try to announce to the Internet
reachibility information on the networks contained within "D".
networks however have been properly registered; a name
accessible from the Internet contains the "in-addr.arpa" records
enable reverse "address to name" lookup, and also contains
network level equivalent of "MX records", say "RX records". Given
host address Dx within D, one can get "RX records" pointing to
Internet addresses of the gateways, I1 and I2.
A standard Internet router Ix cannot in principle send a packet
the address Dx: it does not have any corresponding
information. However, if the said Internet router has been
to exploit our scheme, it will query the DNS with the name build
from "Dx" in the "in-addr.arpa" domain, obtain the RX records,
forward the packet towards I1 (or I2), using some form of "
routing". The gateway I1 (or I2) will receive the packet; its
tables contain information on the domain D and it can relay
packet to the host Dx
At this stage, the readers should be convinced that we have
a scheme that
* avoid changes in host IP addresses as topology changes
without requiring extra overhead on routing (
that the routing employs some form of
information aggregation/abstraction),
* allow to support multihomed domains without
additional overhead on routing and without
hosts to have explicit knowledge of multiple addresses
They should also forcingly scratch their head, and mumble that
can't be so simple, and that one should perhaps carefully look at
details before assuming that the solution really works
3. Evaluation of DNS
Several questions come to mind immediately when confronted to
schemes
- Should all relays access the DNS? What about
loops
- Will the performances be adequate
- How does one choose the best gateway when several
announced? What happens if the gateway is overloaded,
Huitema [Page 3]
RFC 1383 DNS based IP routing December 1992
unreachable
- What if the directory cannot be accessed
- How does it work in the reverse direction
- Should we use tunnelling or loose source routing
- Can we be more general
There may indeed be more questions, but these ones, at least,
been taken into account in the setting of our experiment
3.1. Loops and
In the introduction to DNS-IP routing, we mentioned that the
would be directed towards the access gateway I1 or I2 by means
"source routing" or "tunnelling". This is not, stricto sensu
necessary. One could imagine that the packet would simply be
"as if it was directed towards I1 or I2". The next relay would,
turn, also access the DNS to get routing information and forward
packet
Such a strategy would have the advantage of leaving the
untouched and of letting the transit nodes choose the best
towards the destination, based on their knowledge of the
status. It would however have two important disadvantages
- It would oblige all intermediate relays to access
DNS
- It would oblige all these relays to exploit
the DNS information
Obliging all intermediate gateways to access the DNS is
in the short term: it would mean that we would have to update
and every transit relay before deploying the scheme. It could
have an important performance impact: the "working set" of
relays is typical much wider than that of stub gateways, and
argument presented previously on the efficiency of caches may
apply. This would perhaps remain impractical even in the long term
as it the volume of DNS traffic could well become excessive
The second argument would apply even if the performance problem
been solved. Suppose that several RX records are registered for
given destination, such as I1 and I2 for Dx in our example, and
a "hop by hop routing" strategy is used. There would be a fair
that some relays would choose to route the packet towards I1 and
Huitema [Page 4]
RFC 1383 DNS based IP routing December 1992
others towards I2, resulting in inefficient routing and
possibility of loops
In order to ensure coherency, we propose that all routing
be made at the source, or by one of the first relays near the source
3.2. Performances and
The performance impact of using the DNS for acquiring
information is twofold
* The initial DNS exchanges required for loading
information may induce a response time penalty for
users
* The extra DNS traffic may contribute to overloading
network
We already have some experience of DNS routing in the Internet
the "mail" application. After the introduction of the "MX record",
the mail routing slowly evolved from a hardwired hierarchy, e.g.,
send all mail to the addresses in the ".FR" domain to the
gateway, towards a decoupling between a name hierarchy used
registration and the physical hierarchy used for delivery
If we consider that the mail application represent about 1/4th of
Internet traffic, and that a mail message seldom include more
half a dozen packets, we come to the point that DNS access is
needed at least once for every 24 packets. The performances are
apocalyptic -- or someone would have complained! In fact, if
generalize this, we may suppose that a given host has a "working set
of IP destinations, and that some caching strategy should
sufficient to alleviate the performance effect
In the scheme that we propose, the DNS is only accessed once,
by the source host or by an intelligent router located near
source host. The routing decision is only made once, and
routing is pursued in the Internet until reaching an access router
the remote domain
The volume of DNS traffic through the NSFNET, as collected by MERIT
is currently about 9%. When a host wants to establish
with a remote host it usually need to obtain the name - IP
mapping. Getting extra information (I1 or I2 in our example)
incur in most cases one more DNS lookup at the source. That
would at most double the volume of DNS traffic
Huitema [Page 5]
RFC 1383 DNS based IP routing December 1992
3.3. Tunneling or source
Source directed routing, as described above, can be
through one of two techniques: source routing, or a form
encapsulation protocol. For the sake of simplicity, we will
source routing, as defined in [1]: we don't have to define
particular tunnelling protocol, and we don't have to require hosts
implement a particular encapsulation protocol
3.4. Choosing a
A simplification to the previous problem would be to allow only
RX record per destination, thus guaranteeing consistent decisions
the network. This would however have a number of draw-backs. A
access point would be a single point of failure, and would
connected to only one transit network thus keeping the "
locking" effect of hierarchical routing
We propose that the RX records have a structure parallel to that
MX records, i.e., that they carry associated with each
address a preference identifier. The source host, when making
routing decision based on RX records, should do the following
- List all possible gateways
- Prune all gateways in the list which are known
"unreachable" from the local site
- If the local host is present in the list with
preference index "x", prune all gateways whose
index are larger than "x" or equal to "x".
- Choose one of the gateway in the list. If the list
empty, consider the destination as unreachable
Indeed, these evaluations should not be repeated for each and
packet. The routers should maintain a cache of the most
used destinations, in order to speed up the processing
3.5. Routing
In theory, one could hope to extract "distance" information from
local routing table and combine it with the preference index
choosing the "best" gateway. In practice, as shown in the
context, it is extremely difficult to perform this kind of test,
one has to rely on more heuristical approaches. The easiest one is
always choose a "preferred gateway", i.e., the gateway which has
minimal preference index. One could also, alternatively, choose
Huitema [Page 6]
RFC 1383 DNS based IP routing December 1992
gateway at random within the list: this would spread the traffic
several routes, which is known to introduce better load sharing
more redundancy in the network
As this decision is done only once, the particular algorithm to
can be left as a purely local matter. One domain may make
decision based purely on the RX record, another based purely on
routing information to the gateways listed in the RX record, and
the third one may employ some weighted combinations of both
Perhaps the most important feature is the ability to cope
with network errors, i.e., to detect that one of the route has
"unreachable". This is clearly an area where we lack experience,
where the experiment will help. One can think of several
solutions, e.g.,:
* Let intermediate gateways rewrite the loose source
in order to replace an unreachable access point by
better alternative
* Monitor the LSR options in the incoming packets, and
the reverse LSR
* Monitor the "ICMP Unreachable" messages received
intermediate gateways, and react accordingly
* Regularly probe the LSR, in order to check that it
still useful
A particularly interesting line would be to combine
connectivity checks with the transport control
acknowledgments; this would however require an important
of the TCP codes, and is not practical in the short term. We will
try any such interaction in the early experiments
The management of these reachability informations should be
into account when caching the results of the DNS queries
3.6. DNS
It should be obvious that a scheme relying on RX records is
valid if these records can be accessed. By definition, this is
the case of the target domain itself, which is located at the
fringes of the Internet
A domain that want to obtain connectivity using the RX scheme
have to replicate its domain name service info, and in particular
RX records, so has to provide them through servers accessible
Huitema [Page 7]
RFC 1383 DNS based IP routing December 1992
the core of the Internet. A very obvious way to do so is to
replicated name servers for the target domain in the access
"I1" and "I2".
3.7. On the way
A source located in the fringe domain, when accessing a core
host, will have to choose an access relay, I1 or I2 in our example
A first approach to the problem is to let the access gateway
the general routing information provided by the routing
through the fringe network. The fringe hosts would thus have the
connectivity as the core hosts, and would not have to use
directed routing. This approach has the advantage of leaving
packets untouched, but may pose problems should the transit
need to send back a ICMP packet: it will have to specify a
route through the access gateway for the ICMP packet. This would
guaranteed if the IP packets are source routed, as the reverse
route would be automatically used for the ICMP packet. We are
led to recommend that all IP packets leaving a fringe domain
explicitly source routed
The source route could be inserted by the access gateway when
packet exits the fringe domain, if the gateway has been made aware
our scheme. It can also be set by the source host, which would
have to explicitly choose the transit gateway, or by the first
in the path, usually the default router of the host sending
packets. As we expect that hosts will be easier to modify
routers, we will develop here suitable algorithms
The fringe hosts will have to know the set of available gateways,
which all temporarily unreachable gateways shall indeed be pruned.
the absence of more information, the gateway will be chosen
to some preference order, or possibly at random
It is very clear that if a "fringe" host wants to communicate
another "fringe" host, it will have to insert two relays in the LSR
one for the domain that sources the packet, and one for the
where the destination resides
3.8. Flirting with policy
The current memo assumes that all gateways to a fringe domain
equivalent: the objective of the experiment is to test and evaluate
simple form of directory base routing, not to provide a
"policy routing" solution. It should be pointed out, however,
some form of policy routing could be implemented as a
extension to our RX scheme
Huitema [Page 8]
RFC 1383 DNS based IP routing December 1992
In the proposed scheme, RX records are only qualified by an "order
preference". It would not be very difficult to also qualify
with a "supported policy" indication, e.g., the numeric identifier
a particular "policy". The impact on the choice of gateways will
obvious
- When going towards a fringe network, one should
from the usable list all the gateways that do not
at least one of the local policies
- When exiting a fringe network, one should try to
the policies supported by the target, and pick
corresponding exit gateway
- When going from a fringe network towards another
network, one should pick a pair of exit and
gateway that have matching policies
In fact, a similar but more general approach has been proposed
Dave Clark under the title of "route fragments". The only
here are that we don't know how to identify policies, that we don'
know whether a simple numeric identifier is good enough and that
probably need to provide a way for end users to assess the policy
a packet per packet or flow per flow basis. In short, we should
to keep the initial experiment simple. If it is shown to
successful, we will have to let it evolve towards some
service; it will be reasonable to provide policy hooks at this stage
4. Rationales for
Readers should be convinced, after the previous section, that
DNS-IP routing scheme is sleek and safe. However, they also
probably convinced that a network which is only connected through
scheme will probably enjoy somewhat less services than if they
have full traditional connectivity. We can see two major reasons
inducing users into this kind of scheme
- Because they are good network citizen and want to
their share in order to ease the general burden of
Internet
- Because they are financially induced to do so
We will examine these two rationales separately
Huitema [Page 9]
RFC 1383 DNS based IP routing December 1992
4.1. The good
A strong tradition of the Internet is the display of
spirit: individual users are ready to suffer a bit and "do the
thing" if this conduct can be demonstrated to improve the
state of the network -- and also is not overly painful
Restraining to record your internal networks in the
connectivity tables is mainly an advantage for your
partners, and in particular for the backbone managers. The normal
to relieve this burden is to follow a hierarchical addressing plan
as suggested by CIDR. However, when for some reason the plan
be followed, e.g., when the topology just changed while the
hosts have not yet been renumbered, our scheme provides
alternative to "just announcing one more network number in
tables". Thus, it can help reducing the routing explosion problem
4.2. The commercial
Announcing network numbers in connectivity tables does have
significant cost for network operators
- larger routing tables means more memory hence
expensive routres
- more networks means larger and more frequent
messages, hence consume more network resources
- more remote networks means more frequent
decisions if policies have to be implemented
These costs are very significant not only for regionals, but also
backbone networks. It would thus be very reasonable, from
economical point of view, for a backbone to charge
according to the number of networks that they announce. A
line of reasoning can be applied by the regionals, which could
give the choice to their customers between
- being charged for announcing an address of their choice
- or being allocated at a lower cost a set of addresses
an addressing space belonging to the regional
Our scheme may prove an interesting tool if the charge for
addresses, which are necessary for "multi homed" clients, becomes
high
Huitema [Page 10]
RFC 1383 DNS based IP routing December 1992
5. The experimental
The experimental software, implemented under BSD Unix in a "socket
environment, contains two tasks
- a real time forwarder, which is implemented inside
kernel and handles the source demanded routes
- a DNS query manager, which transmit to the real
forwarder the source routing information
In this section, we will describe the real time forwarder, the
manager, the format of the DNS record, and the interface with
standard IP routers
5.1. DNS
In a definitive scheme, it would be necessary to define a DNS
type and the corresponding "RX" format. In order to deploy
scheme, we would then have to teach this new format to the
name service software. While not very difficult to do, this
probably take a couple of month, and will not be used in the
experimentations, which will use the general purpose "TXT" record
This record is designed for easy general purpose extensions in
DNS, and its content is a text string. The RX record will
three fields
- A record identifier composed of the two characters "RX".
This is used to disambiguate from other experimental
of the "TXT" record
- A cost indicator, encoded on up to 3 numerical digits
The corresponding positive integer value should be
that 256, in order to preserve future evolutions
- An IP address, encoded as a text string following
"dot" notation
The three strings will be separated by a single comma. An example
record would thus be
___________________________________________________________________
| domain | type | record | value |
| - | | | |
|*.27.32.192.in-addr.arpa | IP | TXT | RX, 10, 10.0.0.7|
|_________________________|________|__________|___________________|
Huitema [Page 11]
RFC 1383 DNS based IP routing December 1992
which means that for all hosts whose IP address starts by the
octets "192.32.27" the IP host "10.0.0.7" can be used as a gateway
and that the preference value is 10.
5.2. Interface with the standard IP
We have implemented our real time forwarder "on the side" of
standard IP router, as if it were a particular subnetwork connection
we simply indicate to the IP router that some destinations should
forwarded to a particular "interface", i.e., through our real
forwarder
Of particular importance is indeed to know efficiently
destinations should be routed through our services. As the
would be useless for destinations which are directly reachable,
have to monitor the "unreachable" destinations. We do so
monitoring the "ICMP" messages which signal the
destination networks, and copying them to the DNS query manager
There are indeed situations, e.g., for fringe networks, where
router knows that destinations outside the local domain will have
be routed through the real time forwarder. In this case, it
sense to declare the real time forwarder as the "default route"
the host
5.3. The DNS query
Upon reception of the ICMP message, the query manager updates
local routing table, so that any new packet bound to the
destination becomes routed through the real time forwarder
At the same time, the query manager will send a DNS request, in
to read the RX records corresponding to the destination.
reception of the response, it will select a gateway, and pass
information to the real time forwarder
5.4. The real time
When the real time forwarder receives a packet, it will check
a gateway is known for the corresponding destination. If that is
case, it will look at the packet, and insert the necessary
routing information; it will then forward the packet, either
resending it through the general IP routing program, or by
it directly to the network interface associated to the
gateway
If the gateway is not yet known, the packet will be placed in
waiting queue. Each time the query manager will transmit to the
Huitema [Page 12]
RFC 1383 DNS based IP routing December 1992
time forwarder new gateway information, the queue will be processed
and packets for which the information has become available will
forwarded. Packets in this waiting queue will "age"; their time
live counts will be decremented at regular intervals. If it
null, the packets will be destroyed; an ICMP message may
forwarded
The DNS query manager may be in some cases unable to find
information for a particular destination. It will in that case
to the real time forwarder that the destination is unreachable.
information will be kept in the destination table; queued packet
this destination will be destroyed, and new packets will not
forwarded
The information in the destination table will not be permanent.
time to live will be associated to each line of the table, and
aging lines will be periodically removed
5.5. Interaction with routing
The monitoring of the "destination unreachable" packets
above is mostly justified by a desire to leave standard IP routing
and the corresponding kernel code, untouched
If the IP routing code can be modified, and if the local host
full routing tables, it can take the decision to transmit
packets to the real time forwarder more efficiently, e.g., as
default action for the networks that are not announced in
local tables. This procedure is better practice, as it avoids
risk of loosing the first packet that would otherwise
triggered the ICMP message
6.
We would like to thank Yakov Rekhter, which contributed a number
very helpful comments
7.
This memo suggests an experiment in directory based routing.
author believes that this technique can be deployed in the
Internet infrastructure, and may help us to "buy time" before
probably painful migration towards IPv7.
The corresponding code is under development at INRIA. It will
placed in the public domain. Interested parties are kindly asked
contact us for more details
Huitema [Page 13]
RFC 1383 DNS based IP routing December 1992
8.
[1] Postel, J., "Internet Protocol - DARPA Internet Program
Specification", STD 5, RFC 791, DARPA, September 1981.
[2] Clark, D., "Building routers for the routing of tomorrow",
Message to the "big-internet" mailing list,
<9207141905.AA06992@ginger.lcs.mit.edu>, Tue, 14 Jul 92.
[3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:
Address Assignment and Aggregation Strategy", RFC 1338, BARRNet
cisco, Merit, OARnet, June 1992.
9. Security
Security issues are not discussed in this memo
10. Author's
Christian
INRIA, Sophia-
2004 Route des
BP 109
F-06561 Valbonne
Phone: +33 93 65 77 15
EMail: Christian.Huitema@MIRSA.INRIA.
Huitema [Page 14]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
