[dhcwg] Minutes from dhc WG meeting at IETF 63
Ralph Droms <rdroms@cisco.com> Mon, 29 August 2005 18:15 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oA7-0008DU-2h; Mon, 29 Aug 2005 14:15:15 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1E9oA4-0008DB-SL for dhcwg@megatron.ietf.org; Mon, 29 Aug 2005 14:15:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24823 for <dhcwg@ietf.org>; Mon, 29 Aug 2005 14:15:11 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1E9oBO-0008FP-IJ for dhcwg@ietf.org; Mon, 29 Aug 2005 14:16:36 -0400
Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 29 Aug 2005 11:14:54 -0700
X-IronPort-AV: i="3.96,150,1122879600"; d="scan'208"; a="336816875:sNHT32212480"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j7TIEEQm010675 for <dhcwg@ietf.org>; Mon, 29 Aug 2005 11:14:47 -0700 (PDT)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 29 Aug 2005 14:13:54 -0400
Received: from 161.44.65.118 ([161.44.65.118]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.38]) with Microsoft Exchange Server HTTP-DAV ; Mon, 29 Aug 2005 18:13:54 +0000
Received: from localhost.localdomain by email.cisco.com; 29 Aug 2005 18:13:56 +0000
From: Ralph Droms <rdroms@cisco.com>
To: dhcwg@ietf.org
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Mon, 29 Aug 2005 14:13:56 -0400
Message-Id: <1125339236.15275.58.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-2)
X-OriginalArrivalTime: 29 Aug 2005 18:13:54.0923 (UTC) FILETIME=[6ABCF3B0:01C5ACC5]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4b66a1e94d7d92973ece9e5da449ff80
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] Minutes from dhc WG meeting at IETF 63
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: dhcwg.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
Sender: dhcwg-bounces@ietf.org
Errors-To: dhcwg-bounces@ietf.org
Included below are draft minutes from the dhc WG meeting at IETF 63. Please review and respond with additions/corrections before 1700EDT on Aug 31. - Ralph ===== Administrivia from the chairs ----------------------------- A revision of draft-ietf-geopriv-dhcp-civil-06 will be published soon that gives details about "security concerns related to using DHCP to update the database." Members of the WG are asked to review the changes in the new revision, relative to draft-ietf-geopriv-dhcp-civil-04, which was reviewed in a dhc WG last call. The chairs asked for volunteers to restart two initiatives: DHCP threat analysis, DHCP implementation experience. The chairs are reviewing draft-ietf-dhc-failover-12.txt prior to submission to the IESG. The WG discussed the status of draft-ietf-dhc-bcmc-options-02.txt. There are some IESG Discuss issues outstanding. Ted Lemon said that he had commented during the WG last call that he would prefer that the BCMC option specify only IP addresses and not FQDNs. Elwyn Davies reviewed issues raised by the General Area review team. Stig Venaas will post a summary of outstanding issues to the WG mailing list. The authors will publish a revision that addresses the outstanding issues. DHCP Option for Proxy Server Configuration <draft-ietf-dhc-proxyserver-opt-02.txt> ------------------------------------------ Michael Alexander presented and raised a couple of issues: use RDF or XML encoding; push or pull Javascript? Ted Lemon noted that XML encoding may be too large to fit in a DHCP message. David Hankins said he is satisfied with the responses to his earlier comments about the draft. Mark Stapp asked if there are any expected uses of this option. Hankins respnded that the RedHat "network manager" would likely use it. The WG came to consensus use a URI that could be used to obtain additional configuration information. The authors will revise the draft to specify the use of URIs. Merging of data from DHCP4 and DHCPv6 <draft-venaas-dhc-dual-stack-merge> ------------------------------------- Stig Venaas presented and explained that this draft gives solutions to some of the issues raised in draft-ietf-dhc-dual-stack-03. Examples of solutions include using FQDNs in options (returning both IPv4 and IPv6 addresses) and depend on implementation of address selection rules (RFC 3484) for selection between IPv4 and IPv6. Alain Durand noted that there is some urgency in coming to a solution, and that the client's DUID might be useful to a merged DHCP server to correlate the DHCPv4 and DHCPv6 clients from the same host. Tim Chown responded that a solution is needed quickly, but the WG must be sure to review all possible solutions. Another suggestion was to use IPv4-mapped addresses in IPv6 options. Ted Lemon said that the draft doesn't actually say what's going on before talking about how to solve the problem. There was unanimous consensus at the WG meeting to accept the draft as a WG work item. WG consensus will be confirmed on the WG mailing list. DHCPv6 Default Address Selection Policy option <draft-fujisaki-dhc-addr-select-opt-00.txt> ---------------------------------------------- T. Fujisaki presented. The WG discussed which WG should be responsible for this draft. Ted Lemon asked why we are waiting if we are addressing control of a mechanism that is already specified in an RFC? Margaret Wasserman said there needs to be a demonstrated requirement, and the option should be developed with those requirements in mind. The ipv6 WG discussed RFC 3484; specifically, should RFC 3484 be revised because some text is obsolete (e.g., text referring to site-local addresses) and is the address selection mechanism is useful. There are some scenarios in which centralized control of address selection would be useful: if RFC 3484bis defaults are not appropriate; shim6 WG would find centralized control useful. Greg Daley suggested the selection mechanism could also be controlled through router advertiesements. The dhc WG decided to defer consideration of the draft until the ipv6 WG decides (a) what to do about RFC 3484; (b) is centralized control of address selection useful and (c) should it be controlled through a DHCP option. Zone Suffix Option for DHCPv6 <draft-yan-dhc-dhcpv6-opt-dnszone-02.txt> ------------------------------------------- R. Yan presented. This option addresses the deployment scenario in which hosts need to learn about domain suffix (not "zone suffix") in a network that has acquired IPv6 addresses through prefix delegation. Ted Lemon asked that text restricted use to a particular deployment scenario be deleted, as the option may have broader application. There was consensus at the WG meeting to accept the draft as a WG work item. WG consensus will be confirmed on the WG mailing list. DHCP Option for CLF/NASS <draft-lijun-dhc-clf-nass-option-00.txt> ------------------------------------------ Spencer Dawkins presented. This option addresses configuration of NGN terminals (TE) with a network identifer. The identifier may be an IPv4 address, an FQDN or a string (for networks that don't tie identification to IP). Dawkins said that there is no need for an IPv6 encoding today. Ted Lemon said the draft uses many undefined acronyms. The WG then discussed the problem of data encoding in DHCP options. Various DHCP server implementers came to consensus that representing different data encodings as sub-options would be the easiest to implement. There was insufficient WG review and response to take the draft on as a WG work item. The WG will review the next revision and reconsider its status. TAHI DHCPv6 test tool --------------------- Nobumichi Ozoe presented. TAHI expects to have a beta release of DHCPv6 test tools available October 2005, and 1.0 release April 2006. Announcements of availability will be posted to the dhcwg@ietf.org mailing list. Also watch www.tahi.org/dhcpv6. DHCPv6 client ------------- Ted Lemon announced that he has been developing a DHCPv6 client based on the ISC DHCPv4 client. The protocol work is done and he is now working on stack integration. Rob Austein said that ISC is interested in the client. Status report on option code registration ----------------------------------------- Bernie Volz reported on option code registration as specified by RFC 3942. He has discovered many clashes; details available at iana.org. 18 options have been described as "tentatively assigned" in 128-223 space; 10 of those options have multiple uses. The good news is that 78 out of the possible 96 option codes have not been claimed and are available for assignment to new DHCP options. Those claiming usage of options will be asked to document that usage in an Informational RFC. DHCPv4 option for PANA Authentication Agents <draft-suraj-dhcpv4-paa-option-00.txt> ---------------------------------------- Suraj Kumar presented. Mark Stapp pointed out that this option also uses multiple encodings (see earlier discussion) and should be redefined to use sub-options. Greg daley noted that the DNS name might not be useful because a host cannot use DNS if it is not authenticated. There was unanimous consensus at the WG meeting to accept the draft as a WG work item. WG consensus will be confirmed on the WG mailing list. Review of RA M/O bits discussion -------------------------------- S. D. Park presented a summary of the discussion about the ND RA M/O bits that has been on the ipv6 mailing list and at the ipv6 WG meeting at IETF 63. The ipv6 WG has three requirements (from http://www1.ietf.org/mail-archive/web/dhcwg/current/msg05255.html): 1) Ability to indicate to a host "DHCP is not available on this link", with the expectation that the host won't send any DHCP messages 2) Ability for a host to get all desired and available DHCP configuration with a single DHCP message exchange 3) Ability to do DHCP without having to configure routers (e.g., by ignoring RA with M=0 and/or O=0 and invoking HCB and/or ICB anyway) Requirement 1 is acceptable, the dhc WG will need to investigate requirement 2 and requirement 3 is not suitable. Mark Stapp pointed out that the use of the M/O bits should be to indicate availability of a service. DHCPv6<->DNA interaction ------------------------ Brett Pentland presented work from the dna WG that may have an impact on DHCPv6. DNA would eliminate the need for DHCPv6 Confirm/Reply message exchange (which is itself a form of "DNA"). There will be a discussion on the dhc WG mailing list about whether DNA would require a chnage to RFC 3315. Route Injection for DHCPv6 Prefix Delegation -------------------------------------------- Ralph Droms summarized a discussion about injecting routes for delegated prefixes when the delegating router (DR) and requesting router (RR) are not on the same link. Alternatives: 1. RR injects the route (generic routing protocol) 2. Relay agent injects the route 2a. Relay agent learns about delegated prefix through relay agent option 2b. Relay agent learns about delegated prefix by snooping messages to clients 2c. Network element on which relay agent resides (that must perofrm route injection) learns about route through some out-of-band mechanism (some other configuration protocol) 3. DR (really, DHCPv6 server) injects the route Option 1 involves trusting the RR: authenticate its identity, authenticate the contents of the update message, confirm the RR has the right to advertise the prefix. Options 2 require something like leasequery so the relay agent cna recover state. Option 3 is probably not viable. The WG will continue discussion on the mailing list. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg
- [dhcwg] Minutes from dhc WG meeting at IETF 63 Ralph Droms