rfc1383.txt

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

4.2.  The commercial approach

   Announcing network numbers in connectivity tables does have a
   significant cost for network operators:

      -    larger routing tables means more memory hence more
           expensive routres,

      -    more networks means larger and more frequent routing
           messages, hence consume more network resources,

      -    more remote networks means more frequent administrative
           decisions if policies have to be implemented.

   These costs are very significant not only for regionals, but also for
   backbone networks. It would thus be very reasonable, from an
   economical point of view, for a backbone to charge regionals
   according to the number of networks that they announce. A similar
   line of reasoning can be applied by the regionals, which could thus
   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 in
           an addressing space belonging to the regional.

   Our scheme may prove an interesting tool if the charge for individual
   addresses, which are necessary for "multi homed" clients, becomes too
   high.





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


5.  The experimental development

   The experimental software, implemented under BSD Unix in a "socket"
   environment, contains two tasks:

          -    a real time forwarder, which is implemented inside the
               kernel and handles the source demanded routes,

          -    a DNS query manager, which transmit to the real time
               forwarder the source routing information.

   In this section, we will describe the real time forwarder, the query
   manager, the format of the DNS record, and the interface with the
   standard IP routers.

5.1.  DNS record

   In a definitive scheme, it would be necessary to define a DNS record
   type and the corresponding "RX" format. In order to deploy this
   scheme, we would then have to teach this new format to the domain
   name service software. While not very difficult to do, this would
   probably take a couple of month, and will not be used in the early
   experimentations, which will use the general purpose "TXT" record.

   This record is designed for easy general purpose extensions in the
   DNS, and its content is a text string. The RX record will contain
   three fields:

          -    A record identifier composed of the two characters "RX".
               This is used to disambiguate from other experimental uses
               of the "TXT" record.

          -    A cost indicator, encoded on up to 3 numerical digits.
               The corresponding positive integer value should be less
               that 256, in order to preserve future evolutions.

          -    An IP address, encoded as a text string following the
               "dot" notation.

   The three strings will be separated by a single comma. An example of
   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 three
   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 router

   We have implemented our real time forwarder "on the side" of a
   standard IP router, as if it were a particular subnetwork connection:
   we simply indicate to the IP router that some destinations should be
   forwarded to a particular "interface", i.e., through our real time
   forwarder.

   Of particular importance is indeed to know efficiently which
   destinations should be routed through our services. As the service
   would be useless for destinations which are directly reachable, we
   have to monitor the "unreachable" destinations.  We do so by
   monitoring the "ICMP" messages which signal the unreachable
   destination networks, and copying them to the DNS query manager.

   There are indeed situations, e.g., for fringe networks, where the
   router knows that destinations outside the local domain will have to
   be routed through the real time forwarder. In this case, it makes
   sense to declare the real time forwarder as the "default route" for
   the host.

5.3.  The DNS query manager

   Upon reception of the ICMP message, the query manager updates the
   local routing table, so that any new packet bound to the requested
   destination becomes routed through the real time forwarder.

   At the same time, the query manager will send a DNS request, in order
   to read the RX records corresponding to the destination. After
   reception of the response, it will select a gateway, and pass the
   information to the real time forwarder.

5.4.  The real time forwarder

   When the real time forwarder receives a packet, it will check whether
   a gateway is known for the corresponding destination.  If that is the
   case, it will look at the packet, and insert the necessary source
   routing information; it will then forward the packet, either by
   resending it through the general IP routing program, or by forwarding
   it directly to the network interface associated to the intermediate
   gateway.

   If the gateway is not yet known, the packet will be placed in a
   waiting queue. Each time the query manager will transmit to the real



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 be
   forwarded. Packets in this waiting queue will "age"; their time to
   live counts will be decremented at regular intervals. If it become
   null, the packets will be destroyed; an ICMP message may be
   forwarded.

   The DNS query manager may be in some cases unable to find RX
   information for a particular destination. It will in that case signal
   to the real time forwarder that the destination is unreachable. The
   information will be kept in the destination table; queued packet for
   this destination will be destroyed, and new packets will not be
   forwarded.

   The information in the destination table will not be permanent. A
   time to live will be associated to each line of the table, and the
   aging lines will be periodically removed.

5.5.  Interaction with routing protocols

   The monitoring of the "destination unreachable" packets described
   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 has
      full routing tables, it can take the decision to transmit the
      packets to the real time forwarder more efficiently, e.g., as a
      default action for the networks that are not announced in the
      local tables. This procedure is better practice, as it avoids the
      risk of loosing the first packet that would otherwise have
      triggered the ICMP message.

6.  Acknowledgments

   We would like to thank Yakov Rekhter, which contributed a number of
   very helpful comments.

7.  Conclusion

   This memo suggests an experiment in directory based routing.  The
   author believes that this technique can be deployed in the current
   Internet infrastructure, and may help us to "buy time" before the
   probably painful migration towards IPv7.

   The corresponding code is under development at INRIA. It will be
   placed in the public domain. Interested parties are kindly asked to
   contact us for more details.




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


8.  References

   [1] Postel, J., "Internet Protocol - DARPA Internet Program Protocol
       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, reference
       <[e-mail]>, Tue, 14 Jul 92.

   [3] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Supernetting:  an
       Address Assignment and Aggregation Strategy", RFC 1338, BARRNet,
       cisco, Merit, OARnet, June 1992.

9.  Security Considerations

   Security issues are not discussed in this memo.

10.  Author's Address

   Christian Huitema
   INRIA, Sophia-Antipolis
   2004 Route des Lucioles
   BP 109
   F-06561 Valbonne Cedex
   France

   Phone: [phone]
   EMail: [e-mail]























Huitema                                                        [Page 14]