2006 Mar 23 DHC WG Administrivia Venaas/Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Last call requests Venaas/Droms 05 minutes Summary of documents ready for last call: dhcpv6-opt-dnsdomain-02 - passed last call; revisions need new last call vpn-option-05 - insufficient response to pass previous last call dhcpv6-agentopt-delegate-00 dhcpv6-rfc868-servers-00 Report on TAHI test suite Hideshi Enokihara 05 minutes Version 1 of the DHCPv6 to be released April 1 2006. Test suite will include Authentication Protocol. TAHI conducted interoperability and conformance tests Jan 23 - 27 conformance test. 5 implementations were tested: 2 servers 3 clients. Issues identified during testing: 1) instead of discarding the whole message if it includes not-allowed options (e.g. preference), some implementations just ignore the options. 2) what is correct location of NotOnLink status code? 3) is it acceptable that Success and NoBinding status codes coexist in Reply to a Renew? Thanks from the WG for TAHI's testing. DHCP timezone option E. Lear 10 minutes Lear presented slides describing current draft. Discussion: Hankins - detail about length of one suboption - suboptions OK Schnizlein - TZ database entry is not (mandatory) POSIX string - database update not covered Andrews - updating TZ database is easy Jean-Francoise Mule - should be bound to location more clearly Kinnear - there are situations where location and time-zone are not linked - separate options: you get the one you want - when conflict, who wins? A: anything other than mandatory wins. Ralph - consumption of options is not the issue it used to be. Polk - good draft - need this option to be separate from location Hankins - not clear if the POSIX string is NULL terminated Lemon - prefer separate options, do not link to another option Accept as WG work item? - hum was to accept Emergency dial string option J. Polk 10 minutes New proposal to download emergency dial-string at boot time. Used to confiure your device while you travel to use the local dial-string in case someone else uses your phone. Open issue - DHC operator is separate from emergency phone. ECRIT brought up dial-string approach - James wants another method also. Then there is the LoST query. Marc Linsner - ECRIT is looking at how the client gets this information - is DHC the right place because the DHC operator is quite removed from the emergency function. Henning - this proposal has not been considered yet in ECRIT - worried about too many ways to do the same thing - DHCP is often operated by someone who has no clue about emergency calling. James - dial-string is not on ECRIT charter "interesting" that ECRIT members come here to say not here. Stig - if you want to support multiple dial-strings you need to change the form of the string. Stig & Ralph - need to get with the IESG and see where this should land. ?? - voice strong support for option - why does this have to be local to a country? Peter Blatherwick - think this is a good idea even outside ECRIT for local call control. Ralph - this is even more outside the competence of the DHC WG Need to discuss with ADs where this document should go. IEEE 802.21 information service location option S. D. Park 10 minutes Slides indicate version -02 - not as of check of current lookup DHCP is one candidate for discovering MIServer. Discussion: John - 2 questions the draft should answer: why all three? why even use IP with all communication within a single subnet Ted Lemon - DHC should not pick apart other WG work - could use just a URI for other suboptions. Ralph to check with IEEE WG about status of this document. PANA Authentication Agent option L. Morand 05 minutes Morand presented slides about current rev of this draft, which defines options to locate a PAA, as a list of addresses or list of FQDNs, for IPv4 and IPv6. New version submitted, replacing container of sub-options with 2 sub-options. Open issue - are unauthenticated hosts able to reach DNS server to resolve names? PANA WG does not want to close the door on FQDN. Discussion: Ted Lemon - why do you need both addresses and FQDN? it just makes everything harder - send just the address. Ralph - is there an advantage to dynamic resolution of the FQDN? John - since the stated purpose is to discover the authentication server, the answer seems inherent. Server ID override K. Kinnear 10 minutes Kinnear led discussion of direction for resolution of broadcast/unicast issue. The server override option relay agent provides its address to the Server to be sent as the Server's address to the client. There are cases with VPNs where the client can reach the relay agent but not the DHCP server. However, the presence of GIADDR obscures if a RENEW is broadcast or unicast. When load balancing can't tell RENEW from REBIND it gets two ACKs. What to do? 1) draft position is don't worry about the fact that load balancing doesn't play well with server override, 2) add a flag byte to server-id-override sub-option to indicate unicast/broadcast, 3) add a new sub-option for unicast/broadcast, 4) move load balancing to the relay agent. Discussion: Bernie Volz - confusion of which way which information goes. Recommendation: a new draft for a sub-option to indicate broadcast/unicast - issue is interrelated docs. Ted Lemon - you need to link the two drafts, otherwise implementations could do just one. If you don't do load-balance in the relay you make the Server do twice as much work. How does a load-balance server know if it is supposed to respond. Dave Hankins - advantage of flags field in the server-override Mark Stapp - a normative reference to a new draft would block this document - prefer informative reference to future draft that includes the resolution of all this. Ted Lemon - I don't write relay agents. What about putting load balancing in the relay. Hankins - want all the decision making in one place Ralph - history includes work to resolve previous problems with relay load balancing. Discussion to continue on WG mailing list. DHCPv6 lease query K. Kinnear Since DHCPv4 lease query was so much fun, looking at doing it for DHCPv6. Specified by DOCSIS 3.0 for retrieval of IP lease information. Client, a relay agent or router, can query the Server for IPaddr, delegated prefix, DUID, link-address. No multi-criteria requests. Use cookies to allow sending remainder of information too much for what the client can get in a single exchange. Several open items. Question - why not use SNMP? Answer - we need a MIB - this was discussed in the v4 - SNMP client/server is wrong end... like translating something into a different language and then back again. Ted Lemon - it would be really difficult to do this function through SNMP. Too soon (lacking draft) to make it a WG item - thanks and solicit help. DHCP Passive DAD A. Forte Forte presented the current design fom the most recent revision of the draft. The solution is based on the observation of the relationship between the client-ID and traffic load between AUC and DHCP server, and a technique for reducing background traffic. Advantages: pDAD not performed during IP address acquisition, more reliable than current DAD, intrusion detection Open issues: authentication of relay agents (AUCs), other (non-802 MAC) devices, Changes to Relay Agent - AUC is a new logical entity - easy to integrate, IPv6 Jinmei Tatuya - The DAD for IPv6 defined in RFC 2462 is originally supposed to apply regardless of how the address is configured - whether it's via stateless autoconfiguration or DHCPv6 or manual configuration. So the issue is not stateless vs DHCPv6, but whether the proposed mechanism is better than the existing one or the already existing optimization (i.e., optimistic DAD). We should compare the proposal with optimistic DAD in this sense. Andrea Forte - Passive DAD has been introduced to solve the DAD problem in IPv4. At the end of the draft we just noted that it would also work in IPv6 when no stateless address configuration is used. Passive DAD is not meant to substitute Optimistic DAD, we wanted just to make clear that it might also be used in IPv6 under certain conditions. Mark Stapp - this seems to introduce a solution that does not solve - and might make worse - security Andrea Forte - It does not make security worse since the problems that you might have with the AUC you have them today without any AUC and passive DAD. Also, passive DAD is not meant to solve the security problem in DHCP. Passive Duplicate Address Detection addresses the Duplicate Address Detection problem and hence the name. Henning - The problem is that today DAD does not work but still introduces a big delay (a problem in mobile environments), so we get the worst of both worlds. Ralph - continue discussion on the mailing list. Dual-stack configuration information merge Chown/Venaas 30 minutes Previously documented issues of dual stack - draft-ietf-dhc-dual-stack-04. Concluded that separate v4 and v6 servers should merge their data, not send v4 in v6. Dual-stack scenarios: expect slow transition toward IPv6. Now in progress: merge draft with tools: add a DHCP preference, add a client indicator of dual-stack, recognize common DUID, use a DHCPv6 option telling client to use DHCPv4, use IPv4-mapped addresses in the DHCPv6 response. Issues: smartness in client or server? assume consistent administrative domain. Ted Lemon - might be too early, but smart client seems like the right answer - if you make a list of all the items that each configures, the potential conflict space may be small. David Hankins - agree that smart client seems right - an option in DHCPv6 could signal change from v4 to v6 Stig - anybody implementing dual-stack? Ted - working on a stupid client with a manager that decides. Peter Blatherwick - no experience but think writing things down and arguing about it is a good thing.