home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1993 July / Disc.iso / inet / ietf / dhc / 90jun.min < prev    next >
Encoding:
Text File  |  1993-02-17  |  6.6 KB  |  154 lines
  1.  
  2. CURRENT MEETING REPORT (June 8, 1990)
  3.  
  4. Reported by Ralph Droms/ Bucknell University
  5.  
  6. Introduction
  7. ------------
  8.  
  9. John Veizades, Jeff Mogul, Greg Minshall, Bob Morgan, Leo McLaughlin
  10. and Ralph Droms attended a ``mid-term'' meeting of the Dynamic Host
  11. Configuration working group.  Jeff Mogul was kind enough to host the
  12. meeting at DEC's Western Research Lab.  The purpose of the meeting was
  13. to discuss the mechanism for network address allocation proposed at
  14. the Pittsburgh IETF plenary.  The participants were chosen to
  15. represent the two mechanisms as presented at the Pittsburgh meeting.
  16. The time and location were chosen for the convenience of the
  17. participants.
  18.  
  19. The allocation mechanism under discussion at this meeting describes
  20. the way in which DHC servers allocate and transmit network addresses
  21. to DHC clients.  This new mechanism was first proposed by Leo and Jeff
  22. at the Pittsburgh meeting.  In this mechanism, the DHC servers
  23. allocate and return a single network address to a requesting client.
  24.  
  25. Discussion
  26. ----------
  27.  
  28. The DHC WG generally agrees that the new DHC protocol should be based
  29. on the existing BOOTP protocol.  The primary motivations behind this
  30. decision are the desire to capture BOOTP forwarding agent code in
  31. existing routers and the desire to avoid inventing a new protocol when
  32. an existing protocol can be used.
  33.  
  34. The WG further agrees that the new protocol should be first defined to
  35. carry network layer configuration parameters to the client: network
  36. address, subnet mask, broadcast address and local network MTU. The
  37. question arises: how shall the DHC server select a network address to
  38. return to the client?  There are several points on which one can
  39. compare the two network address allocation mechanisms discussed in the
  40. introduction:
  41.  
  42.    o Relative complexity of client and server code
  43.    o Accuracy/correctness of allocated addresses
  44.    o Compatibility with existing BOOTP clients
  45.    o Ability to maintain coherent distributed information about
  46.      allocated addresses
  47.  
  48. The explicit allocation mechanism has appeal because it captures
  49. existing BOOTP clients and because it can make the client code much
  50. simpler.  However, at the Pittsburgh meeting there was much discussion
  51. about whether the central allocation mechanism could be made to work;
  52. would it be too complex and would it be possible to maintain the
  53. global database required for distributed allocation of addresses?
  54.  
  55.                                    1
  56.  
  57.  
  58. New Mechanism
  59. --------------
  60.  
  61. At the June meeting, we developed an outline of the specific address
  62. mechanism, which we present for comment here.  From the client's point
  63. of view, the new DHC protocol works the same as the existing BOOTP
  64. mechanism.  In fact, we expect existing BOOTP clients to interoperate
  65. with DHC servers without requiring any change to initialization
  66. software.  There are some new, optional transactions that optimize the
  67. interaction between DHC clients and servers:
  68.  
  69.    o Client sends DHC request for network parameters
  70.    o Server sends response with network parameters and explicit network
  71.      address (Note:  This assumes the client receives at least one
  72.      reply.  If no replies arrive, the client may, at the discretion of
  73.      local administration, enter ``genesis state'' [see below for
  74.      details].)
  75.    o (Opt.)  Client updates local network ARP caches with an ARP
  76.      broadcast reply
  77.    o (Opt.)  Client releases unused addresses from duplicate server
  78.      responses
  79.    o (Opt.)  Client releases selected address during orderly close
  80.  
  81.  
  82. Problem Areas with Explicit Allocation
  83. --------------------------------------
  84.  
  85. The first problem area encountered by a server when explicitly
  86. allocating a specific network address rather than a range of addresses
  87. is determining which addresses are already in use and which may be
  88. allocated or reallocated.  Because the server may not be on the same
  89. subnet as the client, the server must use an ICMP echo message to
  90. probe for hosts already using a specific address.  Thus all
  91. participants using network addresses in the dynamic allocation range
  92. (whether statically or dynamically allocated) must implement ICMP echo
  93. message processing.
  94.  
  95. Some hosts, while implementing ICMP echo processing, may go into a
  96. state where ICMP echo requests are ignored for extended periods.  The
  97. client request protocol includes two new extensions to help the server
  98. handle such clients:
  99.  
  100.    o ``brain damage'' - indicating that the client may ignore ICMP
  101.      requests
  102.    o ``reserve forever'' - requesting permanent allocation of a network
  103.      address
  104.  
  105. To meet the goal of reissuing the same network address to a host
  106. whenever possible, while allowing more hosts on a subnet than
  107. addresses available for allocation (obviously, not all hosts can be
  108. active simultaneously), the server must be able to timeout the
  109. allocation of an address to a host, and reuse addresses in LRU order.
  110. The optional
  111.  
  112.                                    2
  113.  
  114.  
  115. ``release address'' message from the client to the server also helps
  116. the server determine when a network address may be reallocated
  117.  
  118. The second problem area, which was discussed at some length in
  119. Pittsburgh, is the mechanism through which multiple servers can
  120. coordinate the allocation of addresses.  We believe this is not a
  121. difficult problem.  First, note that the problem only arises when
  122. multiple servers share responsibility for allocation of addresses on a
  123. single subnet.  Second, the servers need not interact dynamically,
  124. after every network address is allocated.  Rather, the address space
  125. for the target subnet can be partitioned among the servers, which each
  126. only allocate addresses from its own partition.  Periodically, the
  127. servers exchange allocation information, possibly repartitioning the
  128. currently unallocated addresses to reflect client request load.
  129.  
  130. Genesis State
  131. --------------
  132.  
  133. In the absence of any servers, clients may choose to enter ``genesis
  134. state''.  This state is intended for use in small networks in which
  135. resources for support of DHC servers may not be available (the
  136. ``dentist's office'' network).  In genesis state, the client picks an
  137. IP address, probes for any current use of that address and then
  138. defends the selected address using ARP. The genesis state mechanism
  139. looks much like the Athena NIP address allocation mechanism.
  140.  
  141. Conclusion
  142. ----------
  143.  
  144. The problem areas in a protocol where network addresses are explicitly
  145. selected by a possibly remote server seem to be identifiable and can
  146. be surmounted by careful design of the protocol and server behavior.
  147. The advantages of explicit network address allocation appear to
  148. outweigh the disadvantages, and I recommend the DHC WG further
  149. investigate the new address allocation mechanism.
  150.  
  151.  
  152.  
  153.                                    3
  154.