DHC WG - IETF 67 0900-1130 2007-03-21 (Wed) MEETING MINUTES -------------------------- The chairs appreciate the minutes taken by Shane Kerr and the jabber scribe, Mark Andrews. These minutes are based on their input. Administrivia The chairs opened the meeting with agenda bashing, circulation of blue sheets and identification of scribes. Draft last call and adoption announcements The chairs gave a status update on WG documents and work items. * Submitted to IESG draft-ietf-dhc-server-override draft-ietf-dhc-relay-agent-flags draft-ietf-dhc-dhcpv6-opt-dnsdomain draft-ietf-dhc-dhcvp6-leasequery * In or through WG last call draft-ietf-dhc-dhcpv6-ero (ready to submit to IESG) draft-ietf-dhc-dhcpv6-reconfigure-rebind (revision required) Authors to submit revision based on last call comments; then requires new WG last call draft-ietf-dhc-subnet-alloc (insufficient response) Need to determine WG consensus for standards track or informational; then requires new WG last call * Ready for WG last call draft-ietf-dhc-pxelinux (will start WG last call next week) draft-ietf-dhc-vpn-option (pending review of final comments) Reclassifying DHCPv4 Options - RFC 3942 Bernie Volz gave an update on the process to reclassify DHCPv4 options as specified in RFC 3942. In May, 2006, IANA moved all options that were not announced as "in use" to "Available". Reports were received on the following option codes: 128-135: PXE (only formal submission received; other uses reported anecdotally) 150: TFTP server addresses documented in draft-raj-dhc-tftp-addr-option; no documents received for two other reported uses 175-177: Uses reported but no documents received 208-211: PXELinux options; documented in draft-ietf-dhc-pxelinux 220: Subnet allocation; documented in draft-ietf-dhc-subnet-alloc 221: Subnet selection; documented in draft-ietf-dhc-agent-vpn-id Bernie proposed assigning option codes 128-135, 150, 208-211 and 220-221 as "Tentatively Assigned", and reclassifying 175-177 as ""Available". Bernie will write an I-D summarizing progress on RFC 3942 progress for WG review and approval before requesting the changes from IANA. Report from DHCPv6 interoperability test event Alain Durand reported on an interoperability test event sponsored by Comcast, which was held the week before the IETF meeting. The primary objectives were to test interoperability and test some specific deployment scenarios. Participating were: 7 vendors, 14 participants (one remote), 13 implementations (5 clients, 5 servers, 3 relays). Alain will publish an I-D with a summary of the test results (subject to NDA constraints). The WG chairs will set up issues tracker for issues identified in Alain's I-D DHCPv6 RAAN Option, draft-ietf-dhc-dhcpv6-agentopt-delegate-02.txt Work on the DOCSIS 3.0 specification revealed a problem with DHCPv6 prefix delegation: if the PD delegating router is not on the same link as the requesting router (implying a relay agent), how can routes to the delegated prefix be injected into the routing infrastructure. Bernie Volz described the DHCPv6 RAAN option, which allows the DHCP server to inform the router (which provides the relay agent function) on the same link ("first hop router") with the requesting router about delegated prefixes; that router can then advertise the new prefix in the appropriate routing protocols. The WG discussed some of the requirements. Bernie Volz pointed out that the first hop router needs information from both the server and from the requesting router (Release/Decline for the latter source). Ted Lemon suggested validating RAs from the requesting router; Ralph Droms responded that in some deployments the requesting routers will not be configured to issue RAs. Alain Durand asked about recovery of state generated by the RAAN option; Bernie responded that state recovery is a separate issue, addressed, for example, by leasequery. The draft for this option did not pass dhc WG call. Issues raised during the last call include: - Requires use of sequence numbering for reliability - Release/Decline Reply may be lost so relay agent may not get RAAN information and does not know to remove routes Ted said that the only case we are worried about losing data is Release/Decline, which could be solved by a new message from the server direct to the relay. Ralph pointed out that Ted's suggestion would represent a new paradigm for DHCP communication: server to relay. Ted said another advantage would be to obviate the need for message numbering to provide reliable delivery to the relay agent. - General dislike of idea of piggybacking Dave Hankins said he thinks there will be lots of use cases outside of this. The SRSN feels like a "slippery slope" in complexity. Bernie suggested that reliable server to relay reliable communication means the SRSN option is unnecessary. Fred Templin said server-relay communication could solve the problem of clients that disappear and require state change in the relay agent. The chairs will start further discussion of requirements and solutions on dhc WG mailing list Container Option for Server Configuration, draft-droms-dhc-container-opt-00.txt Ralph Droms described a DHCP "container" option, through which a DHCP server can pass specific options to a DHCP server, for forwarding to specific clients. The use case is STB CPEs in a subscriber network, which use the subscriber DHCP server. The SP DHCP server may have some specific options, such as addresses of servers for the STB, that need to be delivered to the STB. There was insufficient support to take on this proposal as a WG work item. Ralph will revise I-D based on mailing list discussion; WG to be asked to consider I-D as dhc WG work item DHCPv6 Vendor-specific Message, draft-volz-dhc-dhcpv6-vendor-message-00.txt Bernie Volz presented this proposal, which defines vendor-specific DHCP message codes, similar to vendor-specific options, for experimentation and development. Ted Lemon and Thomas Narten were opposed to the proposal as a mechanism for promoting non-interoperability. Bernie responded that we've had trouble with open "site-specific" codes, and gave server-server protocols and the RAAN server-relay messages as use cases. There was insufficient support to take on this proposal as a WG work item. The WG chairs will start further discussion on dhc WG mailing list Principles of Internet Host Configuration, draft-aboba-ip-config-00.txt Dave Thaler gave an informational presentation about this draft; no action required by dhc WG. Authentication Extensions for the DHCP, draft-pruss-dhcp-auth-dsl-00.txt Ric Pruss presented this proposal as a way to use DHCP for user authentication. The problem space is the transition by DSL providers from PPP to IP. The PPP session semantics must be now provided as "IP session", but there is no single "IP session" protocol. Relay agent information option contents is sometimes used for this purpose today, but it is not always sufficient. Proposal option 1 uses no new DHCP messages but requires a second DHCPDISCOVER message (for a total of six messages). Proposal option 2 defines new DHCP messages that integrate authentication as a separate mechanism within the usual DHCP message exchange. Ted Lemon asked why RFC 3118 is not sufficient. Ric responded that RFC 3118 requires pre-distribution of keys. Ralph pointed out that, while draft-pruss-dhcp-auth-dsl uses pre-distributed subscriber passwords, those passwords are different from RFC 3118 keys and not immediately usable with RFC 3118. Also, in the abstract, RFC 3118 is a way of securing DHCP messages, not of authenticating user identity. Ted asked why the change to the state machine was necessary. Ric replied that the user identity must be authenticated before an IP address can be assigned. Also, there may be intermediate devices in the path which will learn the address and only activate it on DHCPACK. Hannes Tschoefinig said that inserting EAP into DHCP violates the EAP applicability statement. Ted said that changing the DHCP state machine is hard and the 4-way handshake should be enough. Mark Townsley said that one goal is to authenticate the user identity before giving any information in a DHCPOFFER. Ted asked if that information is sensitive? Ric responded no, but its hard to predict how the user will be authenticated to give correct information. Ralph pointed out that this proposal is predicated on the assumption that user authentication should be accomplished in DHCP. In fact, the user authentication architecture needs to be agreed upon first. If user authentication goes into DHCP, then the dhc WG can design the protocol to meet the architecture requirements. Jari Arkko said that the first step is agreeing that DHCP protocol is right place for this. That discussion needs more people than in this room, like DSL community. He will talk to chairs and post something on the list. Ric will get concrete requirements from DSL Forum. The chairs will announce a discussion of the user authentication issues on the int-area mailing list. The Internet ADs and the chairs will decide how to have the user authentication architecture discussion.