home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dhc / dhc-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  9KB  |  189 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Walt Wimer/CMU
  5.  
  6. Minutes of the Dynamic Host Configuration Working Group (DHC)
  7.  
  8. The DHC Working Group met on 7 December and 9 December at the 31st IETF.
  9.  
  10.  
  11. Document Status
  12.  
  13. The most recent Internet-Draft of the DHCP specification includes
  14. several changes based on the results of the latest interoperability
  15. testing.  Based on the results of that testing, and a review of the
  16. Standards process RFC, the working group decided it would be appropriate
  17. to ask that DHCP be considered for ``Draft Standard'' status.  As soon
  18. as a revision of the current Internet-Draft is completed, the
  19. specification for DHCP will be submitted for review.
  20.  
  21. A few, minor changes have been made to RFC 1541 based on questions
  22. raised during the latest interoperability testing.  Two new options have
  23. been defined since RFC 1533:  62, NetWare/IP domain and 63, NetWare/IP
  24. option.
  25.  
  26. The working group agreed that the minimum lease requirement (one hour)
  27. should be made advisory rather than mandatory.
  28.  
  29.  
  30. Implementations
  31.  
  32. The following list of implementations was compiled from information
  33. given by working group attendees.
  34.  
  35.  _____________________________________________________________________
  36.  ||                   |                   |               |             ||
  37.  || Vendor            |Client             |Server         |Relay agent  ||
  38.  ||___________________|___________________|_______________|_____________||
  39.  || FTP Software      |DOS/Windows        |Windows        |             ||
  40.  ||___________________|___________________|NT_(beta)______|_____________||
  41.  || SunSoft           |DOS/Windows        |Solaris 2.0    |in server    ||
  42.  ||___________________|Solaris_(beta?)____|_______________|_____________||
  43.  || Microsoft         |DOS/Windows        |NT             |in server    ||
  44.  ||                   |NT                 |               |             ||
  45.  ||___________________|Windows95_beta_____|_______________|_____________||
  46.  || Competitive       |???                |Solaris        |             ||
  47.  ||_Automation________|___________________|_______________|_____________||
  48.  || Apple             |Newton             |               |             ||
  49.  ||___________________|Mac_(beta)_________|_______________|_____________||
  50.  || WIDE project      |Unix, BSD386       |Unix, BSD386   |Unix, BSD386 ||
  51.  ||_(free,_avail_2/95)|News,_SunOS________|News,_SunOS____|News,_SunOS_ ||
  52.  ||_Silicon_Graphics__|IRIX_(soon)________|IRIX___________|_____________||
  53.  || Hewlett Packard   |X-terminal         |HP/UX (June 95)|in server    ||
  54.  ||___________________|___________________|_______________|HP_router____||
  55.  || IBM               |OS/2 (soon)        |OS/2 (soon)    |             ||
  56.  ||                   |AIX (soon)         |AIX (soon)     |             ||
  57.  ||___________________|___________________|AS/400_(soon)__|_____________||
  58.  || cisco Systems     |Terminal server?   |               |routers      ||
  59.  ||                   |(proxy for         |               |             ||
  60.  ||___________________|terminal_clients?)_|_______________|_____________||
  61.  || Novell            |NetWare/IP         |NetWare/IP     |             ||
  62.  ||___________________|(spring)___________|(later)________|_____________||
  63.  || Shiva             |Proxy for          |               |             ||
  64.  ||___________________|dial-in_clients____|_______________|_____________||
  65.  
  66.  
  67. Future Interoperability Test
  68.  
  69. There was some discussion of a future interoperability test.  Suggested
  70. venues include Bucknell University (summer '95), CMU (no specific time),
  71. next IETF (March '95) and remote via the Internet (?!?!).  The working
  72. group will hold a discussion about the next interoperability testing via
  73. electronic mail.
  74.  
  75.  
  76. Outstanding Issues
  77.  
  78. The working group discussed some outstanding issues and generated some
  79. solutions:
  80.  
  81.  
  82.    o New options:  TFTP server address, bootfile name, to be registered
  83.      with IANA.
  84.  
  85.    o Some clients will already have an IP address, not otherwise
  86.      registered or managed by DHCP. Those clients will only want local
  87.      configuration parameters, not an address.  A new DHCP message,
  88.      DHCPINFORM, will be defined for parameter requests.
  89.  
  90.    o There was some question about the definition and interpretation of
  91.      ``client identifiers.''  The working group confirmed that a
  92.      ``client identifier'' is an opaque, unique identifier.  Text will
  93.      be added to the protocol specification to clarify this issue and to
  94.      advise that ``client identifiers'' must be unique.  ``Client
  95.      identifier'' type 0 will indicate ``an opaque string of
  96.      characters.''
  97.  
  98.  
  99. The issue of security was discussed.  The primary concern is to detect
  100. and avoid spoof/unauthorized servers.  Some sites are also concerned
  101. about unauthorized clients.  The consensus was that a public key
  102. identification and authorization mechanism should be developed as an
  103. optional DHCP service.
  104.  
  105. Ralph Droms presented a preliminary proposal for a server-server
  106. protocol to allow automatic management of DHCP bindings by multiple DHCP
  107. servers at a single site.  The goals are to increase availability and
  108. reliability through redundancy of address allocation and binding
  109. servers, and through load sharing.  The basic model, based on a proposal
  110. by Jeff Mogul, is to assign each allocatable address and allocated
  111. binding to a specific ``owner'' server.  That owner has modification
  112. privileges, while all other servers have read-only privileges.  Servers
  113. use TCP connections and a simple protocol to replicate copies of new
  114. bindings and transfer ownership of addresses to balance the pool of
  115. available addresses.
  116.  
  117. The hard part is bindings that are released early, prior to expiration.
  118. Those released bindings must be reported to all other servers, so those
  119. servers do not respond with stale data in the future.  However, servers
  120. may be inaccessible.  The proposed solution was to add an ``owner''
  121. option; clients would select responses from the ``owner'' in favor of
  122. all other responses.
  123.  
  124. The suggestion was made that multiple DHCP servers might be able to use
  125. an underlying distributed database like DNS, NIS+ or Oracle.  Questions
  126. were raised about the scalability of the proposed scheme -- suppose many
  127. clients send simultaneous update requests, how often should updates be
  128. replicated, what about combinatoric explosion with the number of
  129. servers?
  130.  
  131.  
  132. IPv6 Issues
  133.  
  134. The second meeting began with a discussion of several IPv6 issues.  IPv6
  135. address configuration has three basic forms:
  136.  
  137.  
  138.   1. Intra-link scope address (client forms address all on its own)
  139.  
  140.   2. ``Stateless'' servers (e.g., in routers using some simple
  141.      assignment algorithm)
  142.   3. Stateful servers (`a la IPv4 DHCP)
  143.  
  144.  
  145. Regardless of how addresses are managed, IPv6 will need some other
  146. mechanism(s) to obtain other configuration parameters.  Some members of
  147. the IPv6 design team claim there will be no other parameters.
  148.  
  149. The following action items were identified:
  150.  
  151.  
  152.    o Someone to enumerate all IPv6 network layer parameters.
  153.      Mike Carney volunteered.
  154.  
  155.    o Extensions/changes to DHCP protocol format for IPv6.
  156.      Walt Wimer volunteered.
  157.  
  158.  
  159. Dynamic Addressing
  160.  
  161. Next, the working group discussed the problem of dynamic updates to DNS
  162. from DHCP information (dynamic addressing).  For simple registration of
  163. DNS hostnames for individual DHCP clients, what should we do?  Should
  164. client be responsible for contacting DNS server directly, or should DHCP
  165. server contact DNS on behalf of client?  It will be necessary to clarify
  166. DNS configuration/update mechanism with DNS Working Group.  One solution
  167. to the question of who does the update would be to define a DHCP option
  168. for client to say whether it will do the registration with DNS directly
  169. or whether client wants DHCP server to take care of it.  DHCP server may
  170. need a way to veto the client's preference.  This permits a simple
  171. client (such as an embedded hub, probe, etc.)  to let the DHCP server do
  172. everything (DHCP server probably has necessary credentials to update DNS
  173. while client probably does not).  Or, a more sophisticated client can
  174. update its ``home'' DNS directly (for example, a mobile notebook
  175. computer belonging to XYZ, Inc.  can be taken to an IETF get a local IP
  176. address from the IETF DHCP server, but then directly update XYZ.COM's
  177. DNS server in order to maintain an XYZ.COM name).  The problem of name
  178. collisions was unresolved - should the client or the server be
  179. responsible?  Masataka Ohta volunteered to do a DHCP-to-DNS interaction
  180. proposal
  181.  
  182.  
  183. DHCP and SNMP
  184.  
  185. Finally, the working group considered DHCP and SNMP. The working group
  186. chair asked if there were any MIB writers in the audience.  The scribe
  187. thought there was a volunteer but did not catch the name.
  188.  
  189.