home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dhc / dhc-minutes-95apr.txt < prev    next >
Text File  |  1995-05-26  |  4KB  |  96 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Ralph Droms/Bucknell University
  5.  
  6. Minutes of the Dynamic Host Configuration Working Group (DHC)
  7.  
  8.  
  9. The Current Mobile IP Protocol
  10.  
  11. Charlie Perkins gave a presentation about the current Mobile IP
  12. protocol, and about the use of DHCP in giving HA (Home Agent) addresses
  13. to Mobile IP hosts.  This use of DHCP will require the use of a new DHCP
  14. option.  Charlie has contacted IANA, which has allocated DHCP Option 68
  15. for HA address distribution.  Charlie will publish an RFC describing the
  16. use of Option 68; the working group suggested a separate RFC as the use
  17. of Option 68 is more complicated than the use of the other DHCP options.
  18.  
  19.  
  20. Two New Messages
  21.  
  22. Ralph Droms spoke to the group about two new messages, DHCPREVALIDATE
  23. and DHCPINFORM, that were proposed in San Jose.  Weak response from the
  24. working group indicated that DHCPREVALIDATE was a bad idea (and will be
  25. deleted from the protocol specification) and DHCPINFORM was a good idea.
  26.  
  27.  
  28. DHCPv6
  29.  
  30. Jim Bound talked to the working group about DHCPv6.  The majority of the
  31. group had not read the IPv6 specification which resulted in some
  32. questions due to lack of familiarity with IPv6.  The group discussed the
  33. following issues:
  34.  
  35.  
  36.    o What opaque identifier should be used for the Interface Token (as
  37.      defined in the IPv6 stateless autoconfig specification)?
  38.  
  39.    o Transaction ID - is it really needed for the request/response
  40.      protocol, and what are the precise semantics of its use?  The
  41.      consensus was that the transaction ID will be needed and the
  42.      details of its definition will be included in the DHCPv6
  43.      specification.
  44.  
  45.    o The ``addrs available'' field was considered, as currently
  46.      specified, to be of uncertain utility as the number of available
  47.      addresses may change between client queries.
  48.  
  49.    o Bit field versus integer values as specifying the contents of a
  50.      particular message.  The consensus was that bit fields would meet
  51.      the technical requirements.
  52.  
  53.    o The request/response model was reviewed and no objections were
  54.      raised.
  55.  
  56.  
  57. Further discussion of the DHCPv6 specification will take place in the
  58. mailing list, to allow, if possible, completion of the specification
  59. prior to the Stockholm IETF.
  60.  
  61.  
  62. Greg Minshall's Model
  63.  
  64. Greg Minshall gave an encore description of his model for server-server
  65. interaction in support of reliable operation of replicated DHCP servers.
  66. There was sufficient interest to warrant the formation of a new mailing
  67. list; the list will be set up and announced to the host-conf mailing
  68. list.
  69.  
  70.  
  71. Client and Server Authentication in DHCP
  72.  
  73. Laird McCulloch made a pitch for client and server authentication in
  74. DHCP. There was some lively discussion about the utility of such
  75. authentication; any malicious host can simply guess or deduce the
  76. parameters handed out by DHCP, so denying DHCP parameters to a
  77. non-authenticated client gives no additional protection against those
  78. malicious hosts.  However, after some discussion of the merits of not
  79. introducing any additional security holes through DHCP, protection
  80. against accidental initialization of unwanted hosts, and the need for
  81. protection against spoofing servers, the working group agreed that an
  82. authentication mechanism would be of some value.  The consensus was that
  83. a three-way private key exchange, perhaps CHAP from PPP, would be easy
  84. to add to DHCP through the use of option fields.  A discussion of this
  85. authentication scheme will take place on the host-conf mailing list.
  86.  
  87.  
  88. Items From The Floor
  89.  
  90. There was discussion of ``freely available'' DHCP implementations --
  91. there is an implementation from the WIDE project in Japan, and hints
  92. that a freely available implementation may be considered by another
  93. group -- and an expression of interest in a bake-off in the San
  94. Francisco area some time in June.
  95.  
  96.