home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dhc / dhc-minutes-96jun.txt < prev    next >
Text File  |  1996-10-07  |  5KB  |  101 lines
  1. Editor's note:  These minutes have ont been edited.
  2.  
  3. DHCPv4
  4.  
  5. Ralph Droms gave a status report on the DHCPv4 documents. The four 
  6. core documents - DHCP specification, DHCP options, BOOTP 
  7. clarification and DHCP-BOOTP interaction - are on track for promotion 
  8. to Draft Standard. The FQDN option and extension option documents 
  9. are on track for acceptance as Proposed Standard. The graceful 
  10. renumbering (from Lowell Gilbert) and DHCP-DNS interaction (from 
  11. Yakov Rekhter) documents are in revision. The authentication and 
  12. server-to-server protocol documents are in development. 
  13.  
  14. The WG agreed on several small changes to the DHCP documents prior 
  15. to publication as Draft Standards:
  16.  
  17. * Clarify text so "user class" interpretation is not a MUST requirement 
  18. for 
  19. servers
  20. * Change text so lease time MUST NOT/SHOULD NOT requirements in 
  21. DHCPINFORM 
  22. are consistent
  23. * Change text in section 4.4.2 so that the known IP address MUST be 
  24. inserted (to match table)
  25.  
  26. Several other protocol details and extensions were discussed: 
  27.  
  28. * Should DHCPDECLINE be unicast (NO! WG has concluded [several 
  29. times!} that 
  30. DHCPDECLINE must be broadcast (DECLINE implies client has no IP 
  31. address) * In response to an inquiry about ISP/session-oriented 
  32. parameters, there 
  33. will be a discussion on the mailing list to begin development of options 
  34. for such parameters
  35. * After a discussion of an mechanism to indicate the "preference" of 
  36. configuation parameters - e.g., existing vs. new lease, primary vs. 
  37. backup server, static vs. dynamic allocation - the WG concluded that 
  38. such a mechanism could be developed as an option. This option will be 
  39. proposed in a separate I-D through the new option acceptance 
  40. procedure. * Jim Bound discussed hs proposed solutions to the problem of 
  41. configuring 
  42. remote subnets through, e.g., on-demand, dial-up router service. A 
  43. document will be developed that will either be added to the DHCP 
  44. FAQ or published as a DHCP-related RFC.
  45. * Discussion of a DHCP MIB will be started on the DHCP mailing list. 
  46.  
  47. The server-to-server and authentication protocols were discussed. An 
  48. ad hoc group met briefly right after the WG meeting to review the 
  49. presentation about the server-to-server protocol given at the WG 
  50. meeting in Los Angeles. Ted Lemon volunteered to begin an I-D defining 
  51. the server-to-server protocol. Ralph Droms will expand the 
  52. authentication I-D into an option specification; this specification will 
  53. allow for other authentication mechanisms in addition to the private 
  54. key mechanism described in the authentication I-D.
  55.  
  56. DHCPv6
  57.  
  58. Jim Bound and Charlie Perkins have issued new versions of the 
  59. DHCPv6 protocol spec and extensions I-Ds. The specification I-D 
  60. includes bug and architecture fixes, authentication extensions, 
  61. movement of the "L" bit, multicast RECONFIGURE message handling, 
  62. multicast address for server addresses and a comparison between 
  63. DHCPv6 and DHCPv4. The extensions I-D includes bug fixes, inclusion 
  64. of each address/name as a separate extension, specification of the 
  65. multicast RECONFIGURE extension, an extension for renumbering 
  66. servers and a description of the authentication extension. 
  67.  
  68. The WG discussed a couple of proposed features: 
  69.  
  70. * Unsolicited advertisements by servers/relay agents - rejected as 
  71. unneeded.
  72. * Hints to client about preference levels (as in DHCPv4) - seems to be 
  73. needed
  74. * Relay agents check off-link servers periodically - needed to prevent 
  75. forwarding stale information about servers to clients 
  76.  
  77. There was a discussion of the DHCPv6 relay agent architecture in 
  78. which relay agents cache server information rather than passing 
  79. solicit requests through to servers. As there is no implementation 
  80. experience on which to make a decision (based on traffic, difficulty of 
  81. implementation, etc.), the WG agreed to accept the mechanism as 
  82. described in the current I-D; however, this architecture may be 
  83. reconsidered in the future. 
  84.  
  85. Authentication is seen as crucial, especially in preventing attacks 
  86. through the RECONFIGURE message. The DHCPv6 authentication 
  87. mechanism is based on IPv6 mecahnisms and will prevent 
  88. authentication, verification and replay protection.
  89.  
  90. Future plans for DHCPv6:
  91.  
  92. * Begin implementation - including DNSIND, IPSEC and the 
  93. authentication 
  94. extension)
  95. * Inlcude DHCP in the UNH bakeoff in November, 1996 * Revise the 
  96. specification and submit for Proposed Standard after San Jose 
  97. IETF meeting (December, 1996)
  98.  
  99. Once again, thanks to Shawn Mamros for taking the notes on which 
  100. these minutes are based.
  101.