rfc1395.txt

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


RFC 1395                    BOOTP Extensions                January 1993


         Domain Name  (Tag: 15, Data: N bytes of domain name)

            Specifies the domain name of the client for Domain Name
            Server (DNS) resolution [RFC-1034].

         Swap Server (Tag: 16, Data: 4 address bytes)

            An IP address to hold the IP address of a swap server.

         Root Path  (Tag: 17, Data: N bytes of path name)

            A string to specify a pathname to mount as a root disk.

         Reserved Fields (Tag: 128-254, Data: N bytes of undefined
         content)

            Specifies additional site-specific information, to be
            interpreted on an implementation-specific basis.  This
            should follow all data with the preceding generic tags 0-
            127).

Extensions

   Additional generic data fields may be registered by contacting:

          Internet Assigned Numbers Authority (IANA)
          Information Sciences Institute
          University of Southern California
          4676 Admiralty Way
          Marina del Rey, California  90292-6695

          or by email as: [e-mail]

   Implementation specific use of undefined generic types (those in the
   range 18-127) may conflict with other implementations, and
   registration is required.

   When selecting information to put into the vendor specific area, care
   should be taken to not exceed the 64 byte length restriction.
   Nonessential information (such as host name and quote of the day
   server) may be excluded, which may later be located with a more
   appropriate service protocol, such as RLP or the WKS resource-type of
   the domain name system.  Indeed, even RLP servers may be discovered
   using a broadcast request to locate a local RLP server.







Reynolds                                                        [Page 5]

RFC 1395                    BOOTP Extensions                January 1993


Comparison to Alternative Approaches

   Extending BOOTP to provide more configuration information than the
   minimum required by boot PROMs may not be necessary.  Rather than
   having each module in a host (e.g., the time module, the print
   spooler, the domain name resolver) broadcast to the BOOTP server to
   obtain the addresses of required servers, it would be better for each
   of them to multicast directly to the particular server group of
   interest, possibly using "expanding ring" multicasts.

   The multicast approach has the following advantages over the BOOTP
   approach:

    - It eliminates dependency on a third party (the BOOTP server) that
    may be temporarily unavailable or whose database may be incorrect or
    incomplete.  Multicasting directly to the desired services will
    locate those servers that are currently available, and only those.

    - It reduces the administrative chore of keeping the (probably
    replicated) BOOTP database up-to-date and consistent.  This is
    especially important in an environment with a growing number of
    services and an evolving population of servers.

    - In some cases, it reduces the amount of packet traffic and/or the
    delay required to get the desired information.  For example, the
    current time can be obtained by a single multicast to a time server
    group which evokes replies from those time servers that are
    currently up.  The BOOTP approach would require a broadcast to the
    BOOTP server, a reply from the BOOTP server, one or more unicasts to
    time servers (perhaps waiting for long timeouts if the initially
    chosen server(s) are down), and finally a reply from a server.

   One apparent advantage of the proposed BOOTP extensions is that they
   provide a uniform way to locate servers.  However, the multicast
   approach could also be implemented in a consistent way across
   multiple services.  The V System naming protocol is a good example of
   this; character string pathnames are used to name any number of
   resources (i.e., not just files) and a standard subroutine library
   looks after multicasting to locate the resources, caching the
   discovered locations, and detecting stale cache data.

   Another apparent advantage of the BOOTP approach is that it allows an
   administrator to easily control which hosts use which servers.  The
   multicast approach favors more distributed control over resource
   allocation, where each server decides which hosts it will serve,
   using whatever level of authentication is appropriate for the
   particular service.  For example, time servers usually don't care who
   they serve (i.e., administrative control via the BOOTP database is



Reynolds                                                        [Page 6]

RFC 1395                    BOOTP Extensions                January 1993


   unnecessary), whereas file servers usually require strong
   authentication (i.e., administrative control via the BOOTP database
   is insufficient).

   The main drawback of the multicast approach, of course, is that IP
   multicasting is not widely implemented, and there is a need to locate
   existing services which do not understand IP multicasts.

   The BOOTP approach may be most efficient in the case that all the
   information needed by the client host is returned by a single BOOTP
   reply and each program module simply reads the information it needs
   from a local table filled in by the BOOTP reply.

Acknowledgments

   The following people provided helpful comments on the first edition
   of this memo: Drew Perkins, of Carnagie Mellon University, Bill
   Croft, of Stanford University, and co-author of BOOTP, and Steve
   Deering, also of Stanford University, for contributing the
   "Comparison to Alternative Approaches" section.

References

   [RFC-951]   Croft, B., and J. Gilmore, "Bootstrap Protocol (BOOTP)",
               Stanford and SUN Microsystems, September 1985.

   [RFC-903]   Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A
               Reverse Address Resolution Protocol", RFC 903, Stanford,
               June 1984.

   [RFC-887]   Accetta, M., "Resource Location Protocol", RFC 887, CMU,
               December 1983.

   [RFC-1034]  Mockapetris, P., "Domain Names - Concepts and
               Facilities", STD 13, RFC 1034, USC/Information Sciences
               Institute, November 1987.

   [RFC-950]   Mogul, J., and J. Postel, "Internet Standard Subnetting
               Procedure", STD 5, RFC 950, USC/Information Sciences
               Institute, August 1985.

   [RFC-868]   Postel, J., "Time Protocol", STD 26, RFC 868,
               USC/Information Sciences Institute, May 1983.

   [IEN-116]   Postel, J., "Internet Name Server", USC/Information
               Sciences Institute, August 1979.





Reynolds                                                        [Page 7]

RFC 1395                    BOOTP Extensions                January 1993


   [LOGGING]   Clark, D., "Logging and Status Protocol", Massachusetts
               Institute of Technology Laboratory for Computer Science,
               Cambridge, Massachusetts, 1981.

   [RFC-865]   Postel, J., "Quote of the Day Protocol", STD 23, RFC 865,
               USC/Information Sciences Institute, May 1983.

   [LPD]       Campbell, R., "4.2BSD Line Printer Spooler Manual", UNIX
               Programmer's Manual, Vol II,  University of California at
               Berkeley, Computer Science Division, July 1983.

   [IMAGEN]    "Image Server XT Programmer's Guide", Imagen Corporation,
               Santa Clara, California, August 1986.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address:

   Joyce K. Reynolds
   Information Sciences Institute
   University of Southern California
   4676 Admiralty Way
   Marina del Rey, CA 90292

   Phone:  [phone]

   EMail: [e-mail]






















Reynolds                                                        [Page 8]