rfc1383.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 787 行 · 第 1/3 页

   In the scheme that we propose, the DNS is only accessed once, either
   by the source host or by an intelligent router located near the
   source host. The routing decision is only made once, and consistent
   routing is pursued in the Internet until reaching an access router to
   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 communication
   with a remote host it usually need to obtain the name - IP address
   mapping. Getting extra information (I1 or I2 in our example) should
   incur in most cases one more DNS lookup at the source. That lookup
   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 routing

   Source directed routing, as described above, can be implemented
   through one of two techniques: source routing, or a form of
   encapsulation protocol. For the sake of simplicity, we will use
   source routing, as defined in [1]: we don't have to define a
   particular tunnelling protocol, and we don't have to require hosts to
   implement a particular encapsulation protocol.

3.4.  Choosing a gateway

   A simplification to the previous problem would be to allow only one
   RX record per destination, thus guaranteeing consistent decisions in
   the network. This would however have a number of draw-backs. A single
   access point would be a single point of failure, and would be
   connected to only one transit network thus keeping the "customer
   locking" effect of hierarchical routing.

   We propose that the RX records have a structure parallel to that of
   MX records, i.e., that they carry associated with each gateway
   address a preference identifier. The source host, when making the
   routing decision based on RX records, should do the following:

          -    List all possible gateways,

          -    Prune all gateways in the list which are known as
               "unreachable" from the local site,

          -    If the local host is present in the list with a
               preference index "x", prune all gateways whose preference
               index are larger than "x" or equal to "x".

          -    Choose one of the gateway in the list. If the list is
               empty, consider the destination as unreachable.

   Indeed, these evaluations should not be repeated for each and every
   packet. The routers should maintain a cache of the most frequently
   used destinations, in order to speed up the processing.

3.5.  Routing dynamics

   In theory, one could hope to extract "distance" information from the
   local routing table and combine it with the preference index for
   choosing the "best" gateway. In practice, as shown in the mail
   context, it is extremely difficult to perform this kind of test, and
   one has to rely on more heuristical approaches. The easiest one is to
   always choose a "preferred gateway", i.e., the gateway which has the
   minimal preference index. One could also, alternatively, choose one



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


   gateway at random within the list: this would spread the traffic on
   several routes, which is known to introduce better load sharing and
   more redundancy in the network.

   As this decision is done only once, the particular algorithm to use
   can be left as a purely local matter. One domain may make this
   decision based purely on the RX record, another based purely on the
   routing information to the gateways listed in the RX record, and yet
   the third one may employ some weighted combinations of both.

   Perhaps the most important feature is the ability to cope rapidly
   with network errors, i.e., to detect that one of the route has become
   "unreachable". This is clearly an area where we lack experience, and
   where the experiment will help. One can think of several possible
   solutions, e.g.,:

      *    Let intermediate gateways rewrite the loose source route
           in order to replace an unreachable access point by a
           better alternative,

      *    Monitor the LSR options in the incoming packets, and use
           the reverse LSR,

      *    Monitor the "ICMP Unreachable" messages received from
           intermediate gateways, and react accordingly,

      *    Regularly probe the LSR, in order to check that it is
           still useful.

   A particularly interesting line would be to combine these
   connectivity checks with the transport control protocol
   acknowledgments; this would however require an important modification
   of the TCP codes, and is not practical in the short term. We will not
   try any such interaction in the early experiments.

   The management of these reachability informations should be taken
   into account when caching the results of the DNS queries.

3.6.  DNS connectivity

   It should be obvious that a scheme relying on RX records is only
   valid if these records can be accessed. By definition, this is not
   the case of the target domain itself, which is located at the outer
   fringes of the Internet.

   A domain that want to obtain connectivity using the RX scheme will
   have to replicate its domain name service info, and in particular the
   RX records, so has to provide them through servers accessible from



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 locate
   replicated name servers for the target domain in the access gateways
   "I1" and "I2".

3.7.  On the way back

   A source located in the fringe domain, when accessing a core Internet
   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 relay
   the general routing information provided by the routing domains
   through the fringe network. The fringe hosts would thus have the same
   connectivity as the core hosts, and would not have to use source
   directed routing.  This approach has the advantage of leaving the
   packets untouched, but may pose problems should the transit network
   need to send back a ICMP packet: it will have to specify a source
   route through the access gateway for the ICMP packet. This would be
   guaranteed if the IP packets are source routed, as the reverse source
   route would be automatically used for the ICMP packet. We are thus
   led to recommend that all IP packets leaving a fringe domain be
   explicitly source routed.

   The source route could be inserted by the access gateway when the
   packet exits the fringe domain, if the gateway has been made aware of
   our scheme. It can also be set by the source host, which would then
   have to explicitly choose the transit gateway, or by the first router
   in the path, usually the default router of the host sending the
   packets. As we expect that hosts will be easier to modify than
   routers, we will develop here suitable algorithms.

   The fringe hosts will have to know the set of available gateways, of
   which all temporarily unreachable gateways shall indeed be pruned. In
   the absence of more information, the gateway will be chosen according
   to some preference order, or possibly at random.

   It is very clear that if a "fringe" host wants to communicate with
   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 domain
   where the destination resides.

3.8.  Flirting with policy routing

   The current memo assumes that all gateways to a fringe domain are
   equivalent: the objective of the experiment is to test and evaluate a
   simple form of directory base routing, not to provide a particular
   "policy routing" solution. It should be pointed out, however, that
   some form of policy routing could be implemented as a simple
   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 of
   preference".  It would not be very difficult to also qualify them
   with a "supported policy" indication, e.g., the numeric identifier of
   a particular "policy". The impact on the choice of gateways will be
   obvious:

      -    When going towards a fringe network, one should prune
           from the usable list all the gateways that do not support
           at least one of the local policies,

      -    When exiting a fringe network, one should try to assess
           the policies supported by the target, and pick a
           corresponding exit gateway,

      -    When going from a fringe network towards another fringe
           network, one should pick a pair of exit and access
           gateway that have matching policies.

   In fact, a similar but more general approach has been proposed by
   Dave Clark under the title of "route fragments". The only problem
   here are that we don't know how to identify policies, that we don't
   know whether a simple numeric identifier is good enough and that we
   probably need to provide a way for end users to assess the policy on
   a packet per packet or flow per flow basis. In short, we should try
   to keep the initial experiment simple. If it is shown to be
   successful, we will have to let it evolve towards some standard
   service; it will be reasonable to provide policy hooks at this stage.

4.  Rationales for deployment

   Readers should be convinced, after the previous section, that the
   DNS-IP routing scheme is sleek and safe. However, they also are
   probably convinced that a network which is only connected through our
   scheme will probably enjoy somewhat less services than if they add
   have full traditional connectivity.  We can see two major reasons for
   inducing users into this kind of scheme:

      -    Because they are good network citizen and want to suffer
           their share in order to ease the general burden of the
           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 citizens

   A strong tradition of the Internet is the display of cooperative
   spirit: individual users are ready to suffer a bit and "do the right
   thing" if this conduct can be demonstrated to improve the global
   state of the network -- and also is not overly painful.

   Restraining to record your internal networks in the international
   connectivity tables is mainly an advantage for your Internet
   partners, and in particular for the backbone managers. The normal way
   to relieve this burden is to follow a hierarchical addressing plan,
   as suggested by CIDR. However, when for some reason the plan cannot
   be followed, e.g., when the topology just changed while the target
   hosts have not yet been renumbered, our scheme provides an
   alternative to "just announcing one more network number in the
   tables". Thus, it can help reducing the routing explosion problem.