home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / dhc / dhc-minutes-97apr.txt < prev    next >
Text File  |  1997-05-29  |  12KB  |  287 lines
  1. Editor's Note:  These minutes have not been edited.
  2.  
  3.  
  4. The DHC WG met for four one-hour sessions.  One session was used for each
  5. of old business, DHCPv6, new business and ongoing discussion.
  6.  
  7. Note that all internet draft names in these minutes
  8. are published with the "draft-ietf" prefix and ".txt" suffix elided.
  9.  
  10.  
  11. Old business:
  12. =============
  13.  
  14. Glenn Stump discussed three related options: user class (dhc-userclass-01),
  15. server selection (dhc-sso-00) and server identification (dhc-sio-00)
  16. options.  The WG agreed that the user class option could be considered for
  17. Proposed Standard.  Glenn agreed to write a BCP document to accompany the
  18. server selection and server identification options prior to review for
  19. submission as Proposed Standards.
  20.  
  21. Ralph Droms asked for comments on the most recent version of the DHCP-DNS
  22. interaction document (dhc-dhcp-dns-03).  There were concerns raised about
  23. the requirement that a DHCP server wait until the DNS update completes
  24. before responding to the DHCP client; this delay may cause significant
  25. performance problems.  The WG asked for the following revisions:
  26.  
  27. * Allow the DHCP server to respond to the client without waiting for the
  28.   update
  29. * Additional response code to indicate DHCP server timed out waiting for
  30.   the DNS update to complete
  31. * Additional words about administrative control; e.g., DHCP server may want
  32.   to do all updates within its domain, but allow the DHCP client to do
  33.   updates on names outside the server's domain.
  34.  
  35. Michael Patrick spoke about the agent options (dhc-agent-options-00):
  36.  
  37. * circuit ID (identifies the circuit to which the DHCP client is
  38.   attached; used for reverse routing back to the client)
  39. * remote ID (additional identifier for the remote agent)
  40. * subnet mask (used to pass the subnet mask for the client from the
  41.   remote agent to the DHCP server)
  42.  
  43. The WG raised authentication as an issue; any options added by the remote
  44. agent would not be included in a message digest computation from the
  45. DHCP client.  There are also some details to be worked out about whether a
  46. client can insert agent options and whether the remote agent should strip
  47. any agent options out of DHCP messages returned to the DHCP client.
  48.  
  49. Charlie Perkins discussed the Service Location Protocol option.  The WG
  50. asked that the option be extended to carry FQDNs as well as IP addresses;
  51. otherwise, the option is ready for Proposed Status.
  52.  
  53. Ralph Droms (for Don Provan) asked if there was any final discussion
  54. about the NDS options (draft-provan-dhcp-options-dir-serv-00.txt).
  55. Absent any discussion, the option was recommended for Proposed Standard
  56. status.
  57.  
  58. Mike Carney described changes in the POSIX timezone option
  59. (dhc-timezone), made in response to comments from discussion at a
  60. previous WG meeting.  The WG approved submission of the POSIX timezone
  61. option for Proposed Standard status.
  62.  
  63.  
  64. DHCPv6:
  65. =======
  66.  
  67. The DHCPv6 spec and extensions docs (dhc-dhcpv6, dhc-v6exts) had been
  68. posted to the WG mailing list for WG last call prior to the WG meeting.  A
  69. minor problem with the pad extension was discussed.  The WG also
  70. suggested that there were editorial corrections that must be made prior
  71. to submission to IETF last call.  Jeff Schiller raised a question about
  72. security and key management - in an environment with potentially many
  73. keys, how does the DHCP client know which key to use?  The authors will
  74. revise the spec and extensions docs to address this issue.
  75.  
  76.  
  77. New business:
  78. =============
  79.  
  80. Pratik Gupta proposed a domain search option.  The WG pointed out
  81. potential confusion between option 15 (domain name) and the
  82. domain search option and suggested that text be included to avoid
  83. any potential confusion.  The WG requested a draft be written for the
  84. proposed domain search option.
  85.  
  86. Pratik Gupta then opened what turned out to be a wide-ranging
  87. discussion no the development of a DHCP MIB.  Issues in the discussion
  88. included:
  89.  
  90. * previous work (CMU, et al.)
  91. * scope of the MIB
  92.   - monitor only
  93.   - monitor and some control
  94.   - complete configurability
  95. * notifications
  96.   - low water mark on free addresses per subnet
  97.   - unauthorized address use detected
  98.   - failed to give out address because pool exhausted
  99.   - failed to give out address because of authorization failure
  100.   - failed DNS update
  101. * should MIB include per-client binding for all clients (yes)
  102. * should relay agents have section in MIB or a separate MIB?
  103.  
  104. Stuart Kwan discussed a proposal for an option to supply a URL for a
  105. proxy configuration file (kwan-proxy-client-conf-00.txt).  There was
  106. no WG consensus to either move forward or reject.  Several objections
  107. were raised:
  108.  
  109. * vendor-specificity,
  110. * requires new mode of DHCP operation to return application-specific
  111.   information
  112. * should this be a SVRLOC function?
  113.  
  114. * Clarification for mixed-media subnets
  115.  
  116. Ralph Droms (for Sam Martel and Walt Wimer) discussed a
  117. clarification for the use of DHCP and BOOTP over mixed-media subnets
  118. (martel-bootp-mixedlinklayers-00.txt).  The draft had not been widely
  119. read; WG consensus was to publish as separate clarification or to
  120. integrate the material into the next revision of the DHCP spec.
  121.  
  122. Takeshi Nikida initiated a preliminary discussion on dynamic subnet
  123. allocation (dhc-dyn-subnet-conf).  The WG expressed interest and suggested
  124. continued development.
  125.  
  126. Munil Shah discussed options and modifications to DHCP for support
  127. of multicast addresses (dhc-mdhcp, dhc-multopt).  Although there was some
  128. sentiment within the WG that this is an orthogonal problem and a
  129. separate protocol might be more appropriate, the WG consensus was to
  130. suggest continued development.
  131.  
  132. Kester Fong initiated a preliminary discussion on dial-up clients and
  133. DHCP.  The primary issue is handing out multiple addresses to a
  134. dial-up subnet.  Possible solutions include a DHCP proxy, agent
  135. options, or implementing a DHCP server in the dial-up server.
  136.  
  137.  
  138. Ongoing discussion:
  139. ===================
  140.  
  141. Mike Carney gave a quick review of the results of DHCP testing at the
  142. latest Connectathon.  He reported that there were no major issues in
  143. the protocol specification, and that vendors are glad to see that the
  144. DHCP spec and options have been issued as Draft Standard RFCs.
  145. Outstanding issues in DHCP identified at Connectathon include multiple
  146. subnets on a wire, authentication and a protocol validation suite.
  147.  
  148. Bob Cole (dhc-interserver) and Kim Kinnear (dhc-interserver-alt) led
  149. a discussion on their two (somewhat complementary) drafts.  There was
  150. much discussion about what the inter-server protocol should do and how
  151. it should do it.  Bob and Kim will get together and try to merge ideas
  152. into unified draft.
  153.  
  154. Olafur Gudmundsson (dhc-security-arch-00.txt) led a spirited
  155. discussion on DHCP security.  The new security architecture ID was
  156. discussed, which addresses fundamental problems with earlier
  157. authentication draft (dhc-authentication-03.txt).  Concern was
  158. expressed that the new architecture would be too expensive
  159. computationally to scale well.  The WG consensus was to continue the
  160. discussion on the mailing list.
  161.  
  162.  
  163. ______________
  164.  
  165. Editor's Note:  These minutes were submitted separately.
  166.  
  167.        draft-ietf-dhc-interserver-alt-00.txt
  168.  
  169.                The "ALT" draft
  170.  
  171.                  Kim Kinnear
  172.             American Internet Corp.
  173.               kinnear@american.com
  174.  
  175. Key Features/Issues:
  176.  
  177.  1. Use of "lazy" update removes requirement for inter-server
  178.  messages between DHCPREQUEST/SELECTING and DHCPACK.
  179.  
  180.  2. Servers will continue to service client requests even in the
  181.  event of network partition.  If a client can talk to *any* DHCP
  182.  server -- even if "its" DHCP server is gone -- it can continue to
  183.  use its address and will experience *no* interruption of service.
  184.  
  185.  3. Administrator can add/remove server from the group at will.
  186.  Identification and removal of failed server is responsibility of
  187.  administrator.
  188.  
  189.  
  190.  -------------------------------------------------------------
  191.  
  192.                     Failure Scenario
  193.  
  194.                         _________
  195.                         | bridge |
  196.     -----------------------------------------------------
  197.     |           |                         |             |
  198.     |           |                         |             |
  199.     |           |                         |             |
  200.   +------+      |                         |          +------+
  201.   |server|      |                         |          |server|
  202.   |  A   |      |                         |          |  B   |
  203.   +------+      |                         |          +------+
  204.                 |                         |
  205.                 |                         |
  206.              +------+      |          +------+
  207.              |client|      |          |client|
  208.              |  X   |      |          |  Y   |
  209.              +------+      |          +------+
  210.                            |
  211.  
  212.                        partition
  213.                         boundary
  214.  
  215. Suppose that client Y receives a lease from server A.  Then the
  216. bridge fails, partitioning the network. Due to the "lazy" update
  217. the DHCPACK made it to client Y prior to the partition of the
  218. network, but the "PUSH" operation from server A to server B did
  219. not complete.
  220.  
  221. Client Y will attempt to renew several times, and fail since it
  222. can't talk to server A.  Eventually, client Y will broadcast a
  223. rebinding which server B will receive.  Since server B knows nothing
  224. about client Y, it will ask the other servers in the group (in this
  225. case server A) about client Y.  When it fails to get an answer,
  226. server B will renew client Y's lease on its IP address.
  227.  
  228. This works because an IP address cannot change the client to which
  229. it is bound without the entire server group's awareness.  (It *can*
  230. become bound for the first time to a client without full knowledge
  231. -- it just cannot *change* to be bound to a different client without
  232. full knowledge by all servers).
  233.  
  234. During the partition event, client X can still DISCOVER and receive
  235. an address from server A.
  236.  
  237. -----------------------------------------------------------------
  238.  
  239.                 Why have configuration messages?
  240.  
  241.         Don't we want the administrator to configure the group?
  242.  
  243.                               YES!
  244.  
  245.         ... and in order to provide a long-term reliable DHCP service,
  246.         we need to give the adminstrator the tools necessary to
  247.         administer the group.
  248.  
  249. Functions required:
  250.  
  251.     1. Add a server to a group (or single group-capable server)
  252.     "already in progress".
  253.  
  254.     2. Remove a server from a group (either operational or failed).
  255.  
  256.     3. Servers verify basic configuration information.  (Should we
  257.     verify not just subnets, but actual addresses in subnets?)
  258.  
  259.  
  260. -----------------------------------------------------------------------
  261.  
  262.   Could SCSP be used to support the general "semantics" of the ALT draft?
  263.  
  264.        Well ... let's try to map ALT operations into SCSP operations.
  265.  
  266.     ALT Operations                      SCSP Operations
  267.     --------------                      ---------------
  268.  
  269. Address Information Messages:
  270.  
  271.   POLL & COMPLETE POLL             Client State Update Solicit (CSUS)
  272.   PUSH                             Client State Update (CSU)
  273.   DUMP                             CSUS
  274.   TRANSFER                         ?
  275.  
  276. Configuration Messages:
  277.  
  278.   Determine the available groups   ?
  279.   GROUP JOIN                       ?
  280.   GROUP LEAVE                      ?
  281.  
  282.  
  283.                 ANSWER:  It is certainly worth a try!
  284.  
  285.  
  286.  
  287.