Meeting Summary dhc WG, IETF 60 2004-08-03, 0900 ---------------- Administrivia ------------- The chair gratefully acknowledges Kim Kinnear, John Schnizlein for providing notes and Tim Chown for acting as jabber scribe, which the chair used in preparing these minutes. The chair announced that Samung has published a zero-cost licensing IPR claim on draft-ietf-dhc-rapid-commit-opt-05.txt. There was no objection in the WG to moving the draft draft forward. The chair announced that there was no response from PacketFront to a request from the IETF for clarification of IPR claim and a request from the chair for a zero-cost licensing IPR claim on draft-ietf-dhc-subscriber-id-06.txt. The consensus of the WG was to move the draft forward despite the current IPR claim. The DHCPv6 Client FQDN Option <draft-volz-dhc-dhcpv6-fqdn> ---------------------------------------------------------- The author gave a short presentation on the draft and asked for comments. Kim Kinnear suggested that we spell out how to handle the case(s) where the client doesn't send in the FQDN option. One issue is, can the server reply with the FQDN to the client if the client doesn't send it in? The draft currently says no. Another issue is what to do if the client send in an FQDN option, and then doesn't for one time, what should the server do? Pekka Savloa asked what about a client that tries to update DNS itself, and what is the operational reasons for the DHCP server to do the update instead of the DHCP client. Bernie and Mark suggested that using the client FQDN option doesn't change the fact that you have opened up the DNS server to dynamic updates. Ted suggested that this DHCPv6 approach parallels the DHCPv4 approach, and that the questioner should perhaps review the DHCPv4 drafts on this subject to better understand how the entire approach operates. Ted Lemon asked if there is a potential explosion of sending lots of names back with a single request? Bernie said yes, the server might offer multiple names. Margaret Waasserman asked if review of this draft would this be coordinated with the dnsext WG? The chair answered yes along with the others in this package (see below for list) that are being coordinated. After some discussion of the technical details, the consensus of the WG at the meeting was to accept draft-volz-dhc-dhcpv6-fqdn as a WG work item. It will be part of a package of drafts to be submitted to the IESG: draft-volz-dhc-dhcpv6-fqdn draft-ietf-dhc-fqdn-option draft-ietf-dnsext-dhcid-rr-07.txt draft-ietf-dhc-ddns-resolution-07.txt draft-ietf-dhc-3315id-for-v4-03.txt The consensus to accept the draft will be confirmed on the WG mailing list. The DHCP Client FQDN Option <draft-ietf-dhc-fqdn-option> --------------------------------------------------------- The author summarized the editorial changes. The WG meeting consensus was that this draft is ready for WG last call. It will go to last call when other drafts in the package are ready. The consensus that the draft is ready for WG last call will be confirmed on the WG mailing list. DHCP Option for Configuring IPv6-over-IPv4 Tunnels <draft-daniel-dhc-ipv6in4-opt> Configured Tunnel End-Point Config. using DHCPv4 <draft-daniel-dhc-dhcpv4-tep-conf> ----------------------------------------------------------------------------------- Discussion focused on <draft-daniel-dhc-ipv6in4-opt>. Ted Lemon suggested that the draft specificaly require that this option only be sent when the client has requested the option. The WG meeting concensus was to table discussion until dhc and v6ops WG chairs discuss which WG should take on these drafts and how the drafts fit into the v6ops WG discussion of tunnel discovery methods. Vendor-Specific Information Suboption for RAIO <draft-stapp-dhc-vendor-suboption> --------------------------------------------------------------------------------- The WG meeting consensus was to accept this draft as a dhc WG work item. The consensus will be confirmed on the WG mailing list. Renumbering Requirements for Stateless DHCPv6 <draft-ietf-dhc-stateless-dhcpv6-renumbering> ------------------------------------------------------------------------------------------- The author summarized the changes since the draft was last discussed in Seoul. It is related to the renumbering draft by Baker, et al., in the v6ops WG. The WG meeting consensus was that the draft is to be submitted to the IESG independent of any specific solution, for publication as an Informational RFC. The WG meeting consensus was that draft is ready for WG last call (to be confirmed on the WG mailing list). Lifetime Option for DHCPv6 <draft-ietf-dhc-lifetime> ---------------------------------------------------- The author presented the updated draft and asked three questions: What if the client asks for option and doesn't get it from the server? Stig's answer is that if you get it once and don't get it again, it should be like it never came in. What should happen if the client can't renew information. Don't forget what you've got while you are waiting for the update. Should we support stateful DHCP? If you get this option when doing stateful along with a lease time, what should you do? If this time is different than the lease time, how does a DHCP client handle it. These questions will be taken to the WG mailing list. The WG meeting consensus was to accept this draft as the solution chosen by the WG to meet the requirements defined in draft-ietf-dhc-stateless-dhcpv6-renumbering. The author will publish a revision based on comments from the meeting and the WG mailing list before consideration for WG last call. DHCP Option for Home Agent Discovery in MIPv6 <draft-jang-dhc-haopt> -------------------------------------------------------------------- This draft addresses the MIPv6 bootstrapping problem - how does a mobile node learn the address of its home agent? The WG suggested that the draft should specificy use of RFC 1035 encoding when carrying an FQDN. The chair will have a discussion with the mip6 chairs to determine which WG should take on this draft. Is there interest in 3GPP2 to use this option as well? Issues in DHCPv6 authentication <draft-jinmei-dhc-dhcpv6-clarify-auth> ---------------------------------------------------------------------- The author presented a summary of the draft, which clarifies issues in DHCPv6 authentication based on implmenetation experience. The WG meeting consensus was to take on this draft as a WG work item, to be published as PS, updating RFC 3315. The contents will be merged with RFC 3315 for DS. IPv6 multicast address assignment with DHCPv6 <draft-jdurand-assign-addr-ipv6-multicast-dhcpv6> ----------------------------------------------------------------------------------------------- This draft describes multicast address management using DHCPv6, because the author considers MADCAP (RFC 2970), SAP (RFC 2974), random choice, GLOP and ZMAAP inadequate. The draft describes a new identity association, IA_MA, that carries multicast addresses. The scope option allows the request to specific scope for the assigned addresses. Some mailing list discussion issues: 1. Should it be split into two drafts? 2. Range for group-id usefullness. 3. Timers specified with a new DHCPv6 option? 4. Scope option mandatory? 5. DHCPv6 in userspace - not in kernel? Problems? 6. IPv4 multicast address assignment? Should this be considered? 7. Prefix delegation for IPv6 multicast addresses? Dave Thaler suggested MADCAP provides multicast address assignment, is there a need for a new mechanism? The author responded that MADCAP exists, but people haven't actually deployed it. Thaler asked if that is a reason to try to do this with DHCPv6, or should MADCAP be required? Dave also asked if we do this with DHCPv6, then what do we about IPv4 multicast? Chair to discuss this draft with mboned chairs to determine where the draft should be reviewed and how to move forward. DHCPv4 Opts. for B-cast and M-cast Control Servers <draft-chowdhury-dhc-bcmcv4-option> DHCPv6 Opts. for B-cast and M-cast Control Servers <draft-chowdhury-dhc-bcmcv6-option> -------------------------------------------------------------------------------------- These two drafts were discussed together. The chair will discuss these drafts with the Internet ADs and the 3GPP2 liaison to determine how to move the drafts forward. IPv4 and IPv6 Dual-Stack Issues for DHCPv6 <draft-ietf-dhc-dual-stack> ---------------------------------------------------------------------- The WG Meeting consensus was to choose separate servers as the solution to dual-stack DHCP service. Discussion of other questions will move to the WG mailing list.