Minutes for the DHC WG Meeting @ IETF 74 1300-1500 PDT 2009-03-25 Thanks to Suresh Krishnan for taking notes. These minutes were prepared by the WG co-chairs: John Brzozowski and Ted Lemon. Initial announcements ------------------------------------------------------------------------ Agenda is very agressive. Drafts ready for WGLC will present only 1 slide. Ralph has been chosen to become the new Internet AD. The WG is looking for a replacement chair. Ralph will continue working with the WG as the AD and IESG advisor Today is the 20th anniversary of the first meeting of the dhc WG. It has been a great example of collaboration between competing vendors. Ralph went through the WG document status and solicited more reviews for documents in or approaching working group last call. Richard Johnson presented Bulk Leasequery draft-ietf-dhc-dhcpv4-bulk-leasequery-00.txt ------------------------------------------------------------------------ Two independent drafts were written that described methods for doing bulk leasequery. They have been merged into one. Extensive editorial changes have been made to the draft and some changes to make it more palatable to the IESG. Ralph asked for more people to review the document. ** David Miles volunteered to review the document David Hankins presenting Softwire Tunnel Option draft-dhankins-softwire-tunnel-option-02.txt ------------------------------------------------------------------------ No major changes.There are some scenarios that require further discussion in the softwire wg. ** Document will be progressed in softwire. David Hankins presenting Option Guidelines draft-ietf-dhc-option-guidelines-05.txt ------------------------------------------------------------------------ Extensive editorial changes for readability and usability. Specifies guidelinesfor people trying to design new DHCP options. Not enough people in the room have read the document. ** Suresh Krishnan, Ted Lemon and Richard Johnson will review the document in working group last call. David Hankins presenting DHCP Inform Clarify draft-ietf-dhc-dhcpinform-clarify-03.txt ------------------------------------------------------------------------ Subnet selection option completely removed from server evaluation after discussion with Bernie Volz. This document explicitly acknowledges the fact that DHCPINFORM is not just for manually configured hosts. and documents the "de facto" standard of clients that zero htype/chaddr/ciaddr. New text added to security section on use of this mechanism as an amplification vector. Ted wants to know if it would be interesting for the server to respond to the source port of the packet and David H agrees. Not many people have read this document. ** Chairs to nag more people into reading the document. Frank Xia presenting Host Generated IIDs draft-xia-dhc-host-gen-id-01.txt ------------------------------------------------------------------------ Ted wants to know if the client can generate the iid first and put it in the SOLICIT. Suresh Krishnan thinks that this is not possible since the prefix feeds into the generation of the interface identifier part of a CGA. David H explains a different mechanism for doing this: Solicit prefix, generate another address and suggest this in an IA option. David Miles is worried about the applicability statement that does not restrict to CGAs Frank talks about using this for point-to-point links as well. Frank wants adoption as wg item. Ralph thinks that it is premature to even ask the question since it is not clear whether dhc or csi should take this up. Jean Michel Combes wants to know if DHCP-PD can be used in this case. Ted and Ralph think it cannot be used. Jari Arkko thinks something like this is needed. He thinks that it also needs to be able to work with Router Advertisements in addition to the default router and prefix options specified in Default Router and Prefix Advertisement Options for DHCPv6 (draft-droms-dhc-dhcpv6-default-router-00.txt) Vincent Zimmer presenting DHCPv6 Option for Network Boot draft-ietf-dhc-dhcpv6-opt-netboot-03.txt ------------------------------------------------------------------------ This document is the merge of two drafts. Provides a network boot mechanism for DHCPv6 that has existed for a long time in DHCPv4. Mark Millet wants to know if https is supported in the URL. Vincent says yes. David H. wants to know if it is better to just send out a config file that lists and describes bootable files. He also wants to know how access control is performed. How is the initrd sent over? Vince has not thought about these yet and they are not handled in the current draft. Ted L wants to strongly recommended http in the document. Vincent agrees. Rob Austein thinks [in response to Dave Hankins' comment] that what goes on between the provider of the boot service and the boot loader is highly variable and the wg should not define what the URL means. Mark Millet wants to know if there would be a length limit on the URL Vincent will add it in a later revision. ** Document will be adopted as wg item pending confirmation on the mailing list. Evan Hunt presenting DHCPv6 MRC Clarification draft-hunt-dhcpv6-clarify-mrc-00.txt ------------------------------------------------------------------------ Minor clarification of the Maximum Retransmission Count defined in RFC3315. This was causing some issues in compliance tests like TAHI. Jinmei Tatuya wants to know if it is time to start revising RFC3315 since there are a lot of clarifications. David wants to progress the draft as is instead of including it in the errata ** Document will be adopted as wg item pending confirmation on the mailing list. David Miles presenting Forcerenew Key Authentication draft-miles-dhc-forcerenew-key-01.txt ------------------------------------------------------------------------ Tries to bring similar functionality into DHCPv4 as exists in DHCPv6. Distributes a forcerenew key to the client in initial dhcp exchange for subsequent use. Francis mentions that the DHCPv6 mechanism referenced this document is well known to be supported by nobody in DHCPv6. David M mentions that there is demand from some operators (he names 2). Glen Zorn wants to rename the key to be called a nonce since it is not really a key He also does not see this document as providing any security. Ted Lemon clarifies this only protects against off-link attackers. Glen Zorn wants some text in the security considerations to mention this. ** Document will be adopted as wg item pending confirmation on the mailing list. David Miles presenting L2RA (DHCPv4) and LDRA (DHCPv6) draft-ietf-dhc-l2ra-03.txt draft-miles-dhc-dhcpv6-ldra-02.txt ------------------------------------------------------------------------ The main intent of both drafts is to insert relay agent options on non-routing devices without any IP configuration. David Hankins wants to know if link local addresses could work, and David Miles clarifies that the goal is to have no IP addresses at all on the relays. Jinmei wants to know if the wg agreed whether layer violating devices like these were a good thing. Ralph mentions that the wg only acknowledges the existence of these devices without taking a position on whether they are good or not. David Miles says L2RA is already implemented and deployed. LDRA does not exist yet and can be tailored appropriately. Woj wants to know why the L2RA needs to check for the relay agent information option David H clarifies that the Relay Agent Info option was defined long ago in RFC3046 and not by this draft. Woj wants to know if L2RA needs to define an option to identify the relay agent? Discussion will be taken to the mailing list. Ralph wants to co-ordinate these two drafts so that they solve the exact same problem and the L2RA draft accurately describes the existing implementations ** The LDRA draft will be adopted as wg item pending confirmation on the mailing list. Woj presenting DHCPv6 route option draft-dec-dhcpv6-route-option-01.txt ------------------------------------------------------------------------ This mechanism is needed by broadband operators to provision static routes on Residential Gateways and CPEs. Francis wants to ensure that complete prefixes are sent in the routes without any compression. Alan Kavanagh mentions that there are no known Broadband (DSL) Residential gateways that have multiple uplinks, and Woj agrees. Alan also wants to know if this is applicable only to shared (n:1) vlan scenarios and Woj says no. Alan thinks that RIPng or OSPF would be a better solution for this. Woj says that the base assumption is that IGPs are not being used. Erik Nordmark mentions that this is going down the road of conflicting with RAs. He also thinks that this should use the same format and the semantics as the RA options for prefixes and routes. He thinks that there should be a shared container option for carrying RA options over DHCPv6. Ralph disagrees with Erik and wants to specify each option separately Erik thinks conflicting info is hard enough to merge and conflicting formats could make it harder Sanjay Wadhwa is not clear how downstream routing (NAS->RG) works with this option. This will be discussed offline. David H disagrees with Erik since there is also manual configuration is in play. He does not want DHCP specified info to be merged with the manual configuration. Dave Thaler completely agrees with Erik. Ralph has talked about this issue at the routing area meeting and he would like this draft to be evaluated with those criteria. ** Ralph thinks that the draft is not ready for adoption as a WG item. David Hankins wants to talk about the default router option and Ralph wants to leave it till the end. Ralph Droms - DHCPv6 RAAN Option and SRSN Option draft-ietf-dhc-dhcpv6-agentopt-delegate-03.txt draft-ietf-dhc-dhcpv6-srsn-option-02.txt ------------------------------------------------------------------------ This draft discusses how an edge router acting as a relay agent can learn the prefix delegated to a home gateway. Ted Lemon mentions that the information in the relay part will always match the information in the client part. Ralph thinks it is possible that it would be different and explains how the lifetime sent to the relay agent could be longer than that sent to the client in order to prevent route flaps near the time of expiry of the address. Jason thinks that this wg needs to at least provide guidance on what the implementations need to do to solve this problem. Ted thinks that is fine but he does not agree in duplicating information in both the relay and client messages. He wants to discuss use cases first before going any further David H mentions that DHCPv6 does not provide a way to talk to a relay agent in a reliable fashion. He does not think that srsn is the right way to do so. Frank Xia wants to know if the HG and the ER need to run IGP. Ralph says no, they do not run IGP between each other. David M thinks this comes too late and vendors are already snooping the packets to infer the prefix. Mark Andrews mentions that in some cases it may make sense for the DHCP server to provide a wider prefix to the relay agent than to the router in order to optimize the routing table. * NO DECISION Hui Deng presenting Extension of DHCP Relay Agent Information Option draft-huang-dhcp-su-00 ------------------------------------------------------------------------ This draft allows multiple relay agents to add information to the message so that the server can infer the path of the message. Ted Lemon mentions that this functionality originally existed before RFC3046 and he thinks that the right way to solve this is to add multiple relay agent options to the message instead of appending to existing option. David H is not sure if implementations follow option concatenation properly. Ted thinks this option is handled completely differently from any other options and everything should be fine unless the option ends up being very long. [I seem to recall someone saying they knew of implementations that would fail if multiple relay agent information options appeared in the same packet. --Ted] * NO DECISION Glen Zorn presenting DHCP Authentication draft-pruss-dhcp-auth-dsl-04.txt ------------------------------------------------------------------------ The analysis draft regarding DHCP authentication has been posted today. Jari wants to know if the draft is ready for the working group to make a decision or if there are still open issues as identified by the analysis draft. Jason mentions that one more round of revisions is probably required to address this analysis. The latest version of the draft has been rewritten to use vendor specific options. Richard Johnson has made changes to the DHCP server on IOS to support this and he also has an open source linux client implementation. Frank Xia has an alternate solution and he would like this to be considered. * NO DECISION