home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dhc / dhc-minutes-95dec.txt < prev    next >
Text File  |  1996-06-03  |  10KB  |  212 lines
  1. CURRENT MEETING REPORT
  2.  
  3.  
  4. Minutes of Dynamic Host Configuration Working Group (DHC)
  5.  
  6. Reported by Ralph Droms, Bucknell University
  7.  
  8.  
  9. The Monday meeting concentrated on a discussion of issues raised during 
  10. the review of the latest DHCPv6 draft.  These issues were listed and 
  11. discussed in turn:
  12.  
  13. o  When should DHCPv6 be used?
  14.  
  15. The issue was raised about when DHCPv6 should be used under all 
  16. circumstances when the network prefix might have changed (as in 
  17. DHCPv4) or only when the client is sure the network prefix has 
  18. changed (using IPv6 router advertisements, etc.).  The Working 
  19. Group arrived at a consensus that *some* words about this situation 
  20. are needed in the specification.  Whether those words specify that 
  21. DHCPv6 should be used only when the client knows the prefix has 
  22. changed (implementor's choice whether to use DHCPv6 at other 
  23. times), or that DHCPv6 should be used when there is some chance 
  24. the network prefix might have changed (as in DHCPv4) will be 
  25. discussed on the mailing list.
  26.  
  27.  
  28. DHCPINFORM for DHCPv6
  29.  
  30. The Working Group reached consensus that DHCPINFORM (ask for 
  31. network parameters without involving any network addresses) should 
  32. be included in DHCPv6.
  33.  
  34. o  Selecting client addresses-client classing mechanisms
  35.  
  36. The Working Group reached consensus that, based on experience 
  37. with DHCPv4, a classing mechanism should be added to DHCPv6.
  38.  
  39. o  Carrying more than one address per DHCP message
  40.  
  41. This is still an open issue.  To avoid delaying progress on 
  42. development of DHCPv6 spec, the Working Group reached consensus 
  43. that the DHCPv6 message header should carry one address and 
  44. that additional messages (if allowed) will be carried in options.
  45.  
  46.  
  47. o  Lease extension
  48.  
  49. More words may be needed to clarify how a client requests an 
  50. extension on an existing lease.
  51.  
  52. o  Retransmissions
  53.  
  54. The Working Group reached consensus on a small change in client 
  55. behavior.  Client will retransmit ACCEPT if the client does not 
  56. receive a SERVER-ACK.  If the client still does not receive a 
  57. SERVER-ACK after several retransmissions, the client will restart 
  58. the DHCP process and send a DISCOVER message.  In this model, 
  59. the client drives all retransmissions (both DISCOVER and 
  60. ACCEPT).
  61.  
  62. o  Hardware type for interface ids
  63.  
  64. DHCPv4 uses ARP types to differentiate hardware types in 
  65. interface identifiers.  This mechanism has several problems; e.g., 
  66. there are some types of interfaces (PPP, ISDN) that do not have 
  67. ARP types.  The issue needs further discussion on the mailing list.
  68.  
  69. o  Client release-early lease revocation
  70.  
  71. This is a sticky problem, with no good solution in sight.  The 
  72. discussion included some observations: if early revocation can be 
  73. made absolutely reliable, leases are unnecessary; the problem can 
  74. occur with any lease (not just infinite leases) that needs to be 
  75. revoked before its expiration, requiring clients to use DHCPv6 
  76. whenever their parameters might have changed (reboot, 
  77. reconnected to network) would provide at least a partial solution.  
  78. This issue will be discussed further on the mailing list.
  79.  
  80. o  What ports should be used by relay agents
  81.  
  82. The current DHCPv6 document specifies that relay agents should 
  83. forward DHCP messages to the UDP DHCP client port (rather than 
  84. the server port), so that servers can differentiate between messages 
  85. received directly from clients and messages forwarded by relay 
  86. agents.  The consensus of the Working Group was that the potential 
  87. gain did not outweigh the potential impact of broadcasting to the 
  88. client port, which would be received by all DHCP clients on the 
  89. subnet.  The document will be revised to specify that relay agents 
  90. will forward DHCP messages to the UDP DHCP server port.
  91.  
  92.  
  93. o  Duplicate address flag
  94.  
  95. The Working Group reached consensus that the client should always 
  96. do duplicate address detection and that the flag was not needed.  
  97. The DHCPv6 document will revised to remove the flag.
  98.  
  99. o  Dynamic updates to DNS
  100.  
  101. The Working Group reached consensus that DHCPv6 should 
  102. (probably) adopt whatever strategy is adopted by DHCPv4.
  103.  
  104. o  Relay agent and authentication
  105.  
  106. IPv6 provides for security in the IP layer.  Unfortunately, DHCP 
  107. relay agents change the contents of the DHCP message, thus the 
  108. Ipv6 end-to-end security mechanism won't work.  One possible 
  109. solution is to use authenticate the client-relay agent link and the 
  110. relay agent-server links separately.  Further discussion of the issue 
  111. will take place on the mailing list.
  112.  
  113. o  Transaction ID
  114.  
  115. Clients use the same transaction ID in all retransmissions of a DHCP 
  116. message, so the message types that indicate retransmission are 
  117. unnecessary, and will be removed from the specification.
  118.  
  119.  
  120. Tuesday's meeting focused on DHCPv4.  Several members of the 
  121. Working Group made short presentations about specific outstanding 
  122. issues.
  123.  
  124. Yakov Rekhter described a model for the coordination of dynamic 
  125. updates to DNS records through DHCP.  The basic model assigns each 
  126. record an "owner," and the owner is then responsible for performing any 
  127. DNS updates.  Clients and servers use DNS to negotiate ownership of 
  128. the DNS records.  By default, the client assumes ownership of its A 
  129. record, and the server assumes ownership of the associated PTR record.  
  130. In some situations, at the discretion of the local network administrator, 
  131. the server may retain ownership of the A record.  In any case, the owner 
  132. of the DNS record uses the dynamic DNS update protocol to make any 
  133. necessary changes.  The lifetime of these DNS records should be 
  134. coordinated with any network address lease times assigned through 
  135. DHCP, so DNS does not carry along stale information.  As the Working 
  136. Group expressed no serious objections, Yakov agreed to write up his 
  137. proposal as an I-D for review by the Working Group.  The proposal will 
  138. be implemented entirely as DHCP options and will be compatible with 
  139. the existing protocol specification; thus, there is no need to delay 
  140. progression of the current protocol specification through the standards 
  141. process.
  142.  
  143. Ralph Droms gave a brief status report.  The latest draft of the DHCP 
  144. specification has been submitted for draft standard; the latest options 
  145. document will be submitted soon.  He asked about whether RFCs 1542 
  146. and 1534 should also be submitted for draft standard (they are both 
  147. currently proposed standards and are unchanged since publication); the 
  148. consensus of the Working Group was to also move those documents 
  149. through the standards track.
  150.  
  151. Ralph also raised the issue of new options: how should new options be 
  152. reviewed and accepted as part of the DHCP specification.  The current 
  153. procedure is to contact IANA for a new option number, which is then 
  154. incorporated into a re-published version of the options document.  There 
  155. is currently no formal review of new options.  Alternatives such as 
  156. review by the DHC Working Group, or process modeled on those used by 
  157. other Working Groups (MIME or TELNET) will be discussed in the 
  158. Working Group mailing list.
  159.  
  160. Finally, the Working Group was asked to review Charlie Perkins' 
  161. proposal for support for mobile IP through DHCP options.  Charlie's I-
  162. D will be reviewed and either incorporated into the existing options 
  163. document or published as a separate RFC.
  164.  
  165. In the middle of the status report, the Working Group took a moment to 
  166. discuss the issue of passing FQDNs in options instead of 32-bit IP 
  167. addresses.  Ralph and Yakov engineered a solution they had 
  168. apparently come to in parallel: a "FQDN encapsulation" option will be 
  169. defined.  This new option will indicate that the encapsulated option 
  170. (one of the other DHCP options) contains a FQDN rather than a 32-bit 
  171. IP address.  A few details need to be worked out-how does a client 
  172. indicate it can parse the FQDN encapsulation option and what syntax 
  173. will be used to pass a list of FQDNs.  Yakov and Ralph will write up a 
  174. specification as an I-D for the Working Group╒s review.
  175.  
  176. Lowell Gilbert described a plan for "graceful renumbering" that he and 
  177. Yakov have developed.  A written description of the plan is available 
  178. from ftp://ftp.epilogue.com/pub/lowell.  This plan, similar to 
  179. the graceful renumbering procedure defined for DHCPv6, describes how 
  180. a DHCPv4 client can obtain multiple addresses that can be used for a 
  181. graceful transition.  Lowell and Yakov have carefully constructed this 
  182. plan so that it can be implemented entirely in DHCP options and it 
  183. requires no changes to the base DHCP protocol; thus, the progression of 
  184. the protocol need not be delayed while this plan is developed.
  185.  
  186. The issue of transitioning from DHCPv4 to DHCPv6 was raised: should 
  187. a client in transition run DHCPv4 to obtain its DHCPv4 addresses and 
  188. DHCPv6 to obtain its DHCPv6 addresses?  The question was 
  189. sufficiently ugly to warrant discussion on the Working Group mailing 
  190. list.
  191.  
  192. Following up on a discussion in the Working Group meeting in Danvers, 
  193. the Working Group discussed security and authentication issues.  The 
  194. consensus in the Working Group was that, while authenticated DHCP 
  195. cannot guarantee secure operation of a network, it could contribute by 
  196. only allocation IP addresses to valid clients.  Further, the ability to 
  197. authenticate servers would reduce problems caused by incorrectly 
  198. configured or malicious servers.  Laird McCulloch cited evidence that a 
  199. variety of users are interested in "secure DHCP" and will not consider 
  200. using DHCP until some form of authentication is included.  The 
  201. Working Group listed some different methods that might be employed: 
  202. RSA, IPSEC, whatever is chosen by DNSIND, CHAP, etc.  There was a 
  203. strong consensus that the Working Group choose one authentication 
  204. mechanism and avoid interoperability problems that might result from 
  205. any negotiation of alternatives between clients and servers.
  206.  
  207. Finally, there was a question about using DHCP to allocate subnets 
  208. instead of just addresses.  For example, a dial-up router might need a 
  209. subnet address for a remote subnet.  This issue will be brought to the 
  210. Working Group mailing list.
  211.  
  212.