rfc1383.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                         C. Huitema
Request for Comments: 1383                                         INRIA
                                                           December 1992


                 An Experiment in DNS Based IP Routing

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  Discussion and suggestions for improvement are requested.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Table of Contents

   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 hierarchies

   Several recent studies have outlined the risk of "routing explosion"
   in the current Internet: there are already more than 5000 networks
   announced in the NSFNET routing tables, more than 7000 in the EBONE



Huitema                                                         [Page 1]

RFC 1383                  DNS based IP routing             December 1992


   routing tables.  As these numbers are growing, several problems
   occur:

      *    The size of the routing tables grows linearly with the
           number of connected networks; handling this larger tables
           requires more resources in all "intelligent" routers, in
           particular in all "transit" and "external" routers that
           cannot rely on default routes.

      *    The volume of information carried by the route exchange
           protocols such as BGP grows with the number of networks,
           using more network resources and making the reaction to
           routing events slower.

      *    Explicit administrative decisions have to be exercised by
           all transit networks administrators which want to
           implement "routing policies" for each and every
           additional "multi-homed" network.

   The current "textbook" solution to the routing explosion problem is
   to use "hierarchical routing" based on hierarchical addresses. This
   is largely documented in routing protocols such as IDRP, and is one
   of the rationales for deploying the CIDR [3] addressing structure in
   the Internet. This textbook solution, while often perfectly adequate,
   as a number of inconveniences, particularly in the presence of
   "multihomed stubs", e.g., customer networks that are connected to
   more than one service providers.

   The current proposal presents a scheme that allows for simple
   routing. It is complementary with the classic "hierarchical routing"
   approach, but provides an easy to implement and low cost solution for
   "multi-homed" domains. The solution is a generalization of the "MX
   record" scheme currently used for mail routing.

2.  Routing based on MX records

   The "MX records" are currently used by the mail routing application
   to introduce a level of decoupling between the "domain names" used
   for user registration and the mailbox addresses. They are
   particularly useful for sending mail to "non connected" domains: in
   that case, the MX record points to one or several Internet hosts that
   accept to relay mail towards the target domain.

   We propose to generalize this scheme for packet routing.  Suppose a
   routing domain D, containing several networks, subnetwork and hosts,
   and connected to the Internet through a couple of IP gateways. These
   gateways are dual homed: they each have an address within the domain
   D -- say D1 and D2 -- and an address within the Internet -- say I1



Huitema                                                         [Page 2]

RFC 1383                  DNS based IP routing             December 1992


   and I2 --. These gateways also have a particularity: they retain
   information, and don't try to announce to the Internet any
   reachibility information on the networks contained within "D". These
   networks however have been properly registered; a name server
   accessible from the Internet contains the "in-addr.arpa" records that
   enable reverse "address to name" lookup, and also contains the
   network level equivalent of "MX records", say "RX records". Given any
   host address Dx within D, one can get "RX records" pointing to the
   Internet addresses of the gateways, I1 and I2.

   A standard Internet router Ix cannot in principle send a packet to
   the address Dx: it does not have any corresponding routing
   information. However, if the said Internet router has been modified
   to exploit our scheme, it will query the DNS with the name build up
   from "Dx" in the "in-addr.arpa" domain, obtain the RX records, and
   forward the packet towards I1 (or I2), using some form of "source
   routing". The gateway I1 (or I2) will receive the packet; its routing
   tables contain information on the domain D and it can relay the
   packet to the host Dx.

   At this stage, the readers should be convinced that we have presented
   a scheme that:

      *    avoid changes in host IP addresses as topology changes,
           without requiring extra overhead on routing (provided
           that the routing employs some form of hierarchical
           information aggregation/abstraction),

      *    allow to support multihomed domains without requiring
           additional overhead on routing and without requiring
           hosts to have explicit knowledge of multiple addresses.

   They should also forcingly scratch their head, and mumble that things
   can't be so simple, and that one should perhaps carefully look at the
   details before assuming that the solution really works.

3.  Evaluation of DNS routing

   Several questions come to mind immediately when confronted to such
   schemes:

       -    Should all relays access the DNS? What about possible
            loops?

       -    Will the performances be adequate?

       -    How does one choose the best gateway when several are
            announced? What happens if the gateway is overloaded, or



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, have
   been taken into account in the setting of our experiment.

3.1.  Loops and relays

   In the introduction to DNS-IP routing, we mentioned that the packets
   would be directed towards the access gateway I1 or I2 by means of
   "source routing" or "tunnelling". This is not, stricto sensu,
   necessary. One could imagine that the packet would simply be routed
   "as if it was directed towards I1 or I2". The next relay would, in
   turn, also access the DNS to get routing information and forward the
   packet.

   Such a strategy would have the advantage of leaving the header
   untouched and of letting the transit nodes choose the best routing
   towards the destination, based on their knowledge of the reachability
   status. It would however have two important disadvantages:

          -    It would oblige all intermediate relays to access the
               DNS,

          -    It would oblige all these relays to exploit consistently
               the DNS information.

   Obliging all intermediate gateways to access the DNS is impractical
   in the short term: it would mean that we would have to update each
   and every transit relay before deploying the scheme. It could also
   have an important performance impact: the "working set" of transit
   relays is typical much wider than that of stub gateways, and the
   argument presented previously on the efficiency of caches may not
   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 had
   been solved. Suppose that several RX records are registered for a
   given destination, such as I1 and I2 for Dx in our example, and that
   a "hop by hop routing" strategy is used. There would be a fair risk
   that some relays would choose to route the packet towards I1 and some



Huitema                                                         [Page 4]

RFC 1383                  DNS based IP routing             December 1992


   others towards I2, resulting in inefficient routing and the
   possibility of loops.

   In order to ensure coherency, we propose that all routing decisions
   be made at the source, or by one of the first relays near the source.

3.2.  Performances and scaling

   The performance impact of using the DNS for acquiring routing
   information is twofold:

      *    The initial DNS exchanges required for loading the
           information may induce a response time penalty for the
           users,

      *    The extra DNS traffic may contribute to overloading the
           network.

   We already have some experience of DNS routing in the Internet for
   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 french
   gateway, towards a decoupling between a name hierarchy used for
   registration and the physical hierarchy used for delivery.

   If we consider that the mail application represent about 1/4th of the
   Internet traffic, and that a mail message seldom include more than
   half a dozen packets, we come to the point that DNS access is already
   needed at least once for every 24 packets. The performances are not
   apocalyptic -- or someone would have complained! In fact, if we
   generalize this, we may suppose that a given host has a "working set"
   of IP destinations, and that some caching strategy should be
   sufficient to alleviate the performance effect.