dhc WG meeting, IETF 69 Meeting Minutes ----------------------- Thanks to John Schnizlein for taking notes during the meeting and to the Jabber scribe, Alexandru Petrescu. * Draft last call and adoption announcements The chairs gave an update on the status of dhc WG documents and noted that two drafts are in WG last call: draft-ietf-dhc-vpn-option draft-ietf-dhc-agent-vpn-id * Progressing two drafts under RFC 3942 The chairs announced that two drafts, which had been taken on as WG work items before the publication of RFC 3942, will now be published as Informational RFCs, under the guidelines of RFC 3942: draft-ietf-dhc-subnet-alloc draft-raj-dhc-tftp-addr-option * Update to DHCP options guideline draft-dhankins-dhcp-option-guidelines-00 has been published as a revision to draft-dhankins-atomic-dhcp-00. The revised document has been reorganized and several sections have been extended. The chairs will ask the WG for consensus to take this document as a WG work item when it is available at the IETF I-D repository. * Using DHCPv6 and AAA Server for mobile station PD Bechet Sarikaya gave a presentation on draft-sarikaya-16ng-prefix-delegation-01, which requires dhc WG input as it proposes changes to the definition of the IAID for address assignment and prefix delegation. The 16nf WG proposes to use DHCPv6 prefix delegation for assignment of a prefix to a mobile station. draft-sarikaya-16ng-prefix-delegation-01 proposes changing the IAID to 6 bytes, which would accommodate the remote station MAC address as an identifier. David Hankins and Jari Arkko opposed redefining the IAID. John Schnizlein asked for a clarification about the prefix requested through prefix delegation: does the access router request the prefix for use on the AR<->mobile link, or for use on additional links attached to mobile link? The WG will be asked to discuss the use of prefix delegation in the 16nf scenario and how to identify clients within the 4 byte IAID. * Layer 2 relay agent and relay agent chaining Pavan Kurapati discussed two drafts: draft-joshi-dhc-layer2-relay-agent-01 and draft-kurapati-dhc-relay-chaining-dhcpv4-01. The first of these drafts describes guidelines for interpretations of existing DHCP specifications to successfully allow L2 relay agents to participate in DHCPv4 message exchanges. Hankins commented that this draft is needed to formalize existing deployment scenarios, which have yielded unexpected results. The second draft describes extensions to DHCPv4 to allow both an L2 relay agent and an L3 relay agent to insert relay agent options into a message from a DHCP client to the server. John Schnizlein noted that this proposal violates RFC 3046, which allows only one set of relay agent options, and which requires trust of the L2 relay agent on the part of the L3 relay agent. The members of the WG at the meeting expressed interest in continuing discussion of these drafts of the dhc WG mailing list. * TAHI DHCPv6 Test tool for IPv6 Ready Logo Hideshi Enokihara gave a brief summary of the TAHI DHCPv6 test tool and the results of DHCPv6 testing at the most recent TAHI test event. There is now an IPv6 Ready (phase 1) logo for DHCPv6, and a phase 2 program started earlier this year. Ted Lemon asked if there are any common client failures. Hideshi responded that the problem most frequent problem with clients is sending RFC-compliant messages. Extensions to DHCPv6 for prefix and default router information Tim Chown led a discussion of handling rogue RAs in an IPv6 deployment. The motivation for this presentation is that administrators of operational networks, mostly universities are comfortable with DHCP, but are finding problems with 'rogue Router Advertisments'. One possible alternative is to avoid RAs and use DHCP for prefix and default router information. Bogus RAs can originate from several sources: 1) configuration error - sometimes with long lifetime 2) User-induced accidents: host acting as 6to4 router from home 3) malice Arkko said that it's not clear DHCP is the right way to deal with these problems. Dave Thaler pointed out that SeND is the official solution to this problem, so creating another solution does not improve the situation. Thaler also pointed out that, with the revision to the "on-link assumption" in RFC 2461bis, there may be a need for passing prefix information in DHCP. Alain Durand expressed interest in using DHCP for prefix and default router information. Tim Chown promised to publish a draft documenting the problem.