From owner-dhcp-v4@bucknell.edu Tue Jan 2 15:51:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA22584 for ; Tue, 2 Jan 2001 15:51:25 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f02Kj3928592; Tue, 2 Jan 2001 15:45:03 -0500 (EST) Received: from matrix.cjnetworks.com (matrix.cjnetworks.com [206.52.159.19]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f02Kip900779 for ; Tue, 2 Jan 2001 15:44:52 -0500 (EST) Received: from topeka.cjnetworks.com (topeka.cjnetworks.com [206.52.158.250]) by matrix.cjnetworks.com (8.9.3/8.9.3) with SMTP id OAA37107 for ; Tue, 2 Jan 2001 14:45:14 -0600 (CST) (envelope-from eblank@cjnetworks.com) Date: Tue, 2 Jan 2001 14:44:49 -0600 (CST) From: "Erik M. Blankenship" To: DHCPv4 discussion list Subject: DHCP / FreeBSD Problems Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: eblank@cjnetworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm having a real problem with FreeBSD 4.2-release, and getting dhcpd version 2.0pl5 to work with it. But for some odd reason, it works on an old Slackware box that I am using for DHCP. This is a long story, so I'll try to make it short and sweet. We are running DHCP dynamically for our ADSL customers. We're using a Cisco 3640 to do the routing. Here is what we put in on the router for the Slackware box (I've removed the actual IP numbers for my own sake): config t ip dhcp-server SLACKWARE-IP interface ATM3/0.20 multipoint ip helper-address SLACKWARE-IP interface BVI2 ip helper-address SLACKWARE-IP end wr mem And I know it's screwed up, but it works! But here's the dhcpd.conf file that runs on my Slackware machine: # Sample /etc/dhcpd.conf # (add your comments here) default-lease-time 2200; max-lease-time 7200; option subnet-mask 255.255.252.0; option broadcast-address 192.168.3.255; option routers 192.168.1.254; option domain-name-servers 206.52.158.251; option domain-name "cjnetworks.com"; subnet 192.168.0.0 netmask 255.255.252.0 { range 192.168.2.1 192.168.3.254; } I have a real IP address for the slackware machine under the 'ed0' device in Linux. I setup an alias for the 192.168.0.0 subnet like this: ifconfig eth0:1 192.168.0.1 netmask 255.255.252.0 up After I do my ifconfig, and run 'dhcpd', everything works just fine. Everyone can route on the machine, and everything. It's pretty. By the way, we're doing NAT on the router to translate the 192.168.0.0 subnet to a real IP. We use fake IPs for our ADSL low-end customers so they can't run servers... However, I want to replicate this working DHCP server on a newer FreeBSD 4.2 machine, so I can nuke the old Slackware linux box because it is ancient. However, I find the above working configurations to fail horribly on the FreeBSD box. I'm guessing because Slackware is so old, that I'm using a bad configuration above, and it's using it anyway because it doesn't know any better? And perhaps since FreeBSD is a newer version, it is saying "hey, this doesn't work...but I can't tell you why!"...? With the same router entries, but a different IP, we point the helper address to the FreeBSD's IP number. And this time, instead of doing NAT and using a 192.168.0.0 subnet, we use a real subnet. Here's my configuration on the FreeBSD box: # ADSL dhcpd.conf 12/21/00 default-lease-time 2200; max-lease-time 7200; option subnet-mask 255.255.255.0; option broadcast-address 199.240.152.255; option routers 199.240.152.254; option domain-name-servers 206.52.158.251; option domain-name "cjnetworks.com"; subnet 199.240.152.0 netmask 255.255.255.0 { range 199.240.152.2 199.240.152.200; } And here's the ifconfig I do: ifconfig vx0 alias 199.240.152.1 netmask 255.255.255.0 broadcast 199.240.152.255 up I run 'dhcpd -d' in debug mode to see any entries connecting...and nothing. When we call up some of our ADSL customers to see if they can get a new lease, nothing goes. They can't find the new DHCP server. I removed the ifconfig, and stopped the DHCP server on the Slackware machine, and started everything up on the FreeBSD machine. It will NOT work at ALL on the FreeBSD machine. What in the world could I possibly be doing wrong to not be able to have DHCP run on this new machine? I'm at a complete loss, and this mailing list is my last resort. I'm begging for someone to help me. I look forward to hearing from someone that has a clue, unlike myself. Regards, --- Erik M. Blankenship eblank@cjnetworks.com Systems Administrator http://www.cjnetworks.com CJNetWorks voice: 785.270.1301 From owner-dhcp-v4@bucknell.edu Wed Jan 3 04:10:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA11740 for ; Wed, 3 Jan 2001 04:10:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f038pP912461; Wed, 3 Jan 2001 03:51:26 -0500 (EST) Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f038pE921673 for ; Wed, 3 Jan 2001 03:51:14 -0500 (EST) Received: from mbb5.ericsson.se (mbb5.ericsson.se [136.225.151.210]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f038pCG03707 for ; Wed, 3 Jan 2001 09:51:13 +0100 (MET) Received: from CONVERSION-DAEMON by mbb1.ericsson.se (PMDF V5.2-29 #39352) id <0G6K00301WLC0G@mbb1.ericsson.se> for dhcp-v4@bucknell.edu; Wed, 3 Jan 2001 09:51:12 +0100 (MET) Received: from era.ericsson.se (wcsw476.wrn.ki.sw.ericsson.se [147.214.137.119]) by mbb1.ericsson.se (PMDF V5.2-29 #39352) with ESMTP id <0G6K00A6DWLCRN@mbb1.ericsson.se> for dhcp-v4@bucknell.edu; Wed, 03 Jan 2001 09:51:12 +0100 (MET) Date: Wed, 03 Jan 2001 09:51:11 +0100 From: Patrik Carlsson Subject: IP reconfiguration Sender: owner-dhcp-v4@bucknell.edu To: DHCPv4 discussion list Message-id: <3A52E7FF.A55375CA@era.ericsson.se> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (X11; I; SunOS 5.6 sun4u) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Reply-To: patrik.x.carlsson@ERA.ERICSSON.SE X-Sender: qrappca@mbb1.ericsson.se X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi! I have a few questions how DHCP can handle reconfiguration of a client's IP address. Consider the following scenario. There are a few clients connected to a router A (which act as a bootp relay agent) which in it's turn is connected to antoher router etc. Because of OSPF summarisation, it will be necessary to change the subnet where the clients are located. The clients can not be managed from a remote location and the only way to change the IP address of the clients is to use DHCP. Is this possible? Case 1; What happens if the subnet of the router A is changed but the clients still belong to the old subnet with the old IP addresses? When its time for renewal, the packet sent to the DHCP server is a unicast and will therefore not reach the server (since the clients information about def. router are invalid). How does the client handle this? Does it start to send broadcast? Case 2; the router A keeps the old subnet but the clients negotiates about new IP addressess. Is it possible to configure a client with a completely new IP address (out of the existing subnet range)? In that case, will information such as IP address, subnet mask, def router take hange in exactly the same moment? Can this be done in a different way? Thanks! /Patrik From owner-dhcp-v4@bucknell.edu Wed Jan 3 15:58:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04823 for ; Wed, 3 Jan 2001 15:58:04 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f03Kpe916271; Wed, 3 Jan 2001 15:51:40 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f03KpZ924663 for ; Wed, 3 Jan 2001 15:51:35 -0500 (EST) Received: from grosse.bisbee.fugue.com (PPPa40-ResaleWesternMa2-1R7201.dialinx.net [4.54.146.69]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f03KmYE28055; Wed, 3 Jan 2001 12:48:40 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f03KnT800395; Wed, 3 Jan 2001 15:50:03 -0500 (EST) Message-Id: <200101032050.f03KnT800395@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: DHCP / FreeBSD Problems In-Reply-To: Message from "Erik M. Blankenship" of "Tue, 02 Jan 2001 14:44:49 CST." Date: Wed, 03 Jan 2001 15:49:29 -0500 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > subnet 192.168.0.0 netmask 255.255.252.0 { > range 192.168.2.1 192.168.3.254; > } > > I have a real IP address for the slackware machine under the 'ed0' device > in Linux. I setup an alias for the 192.168.0.0 subnet like this: > > ifconfig eth0:1 192.168.0.1 netmask 255.255.252.0 up You need to write subnet declarations for all the subnets that are connected to the wire to which you are connecting vx0, and enclose all of those subnet declarations in a shared-network declaration. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Jan 3 22:02:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13752 for ; Wed, 3 Jan 2001 22:02:33 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f042v9918946; Wed, 3 Jan 2001 21:57:09 -0500 (EST) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f042uw931517 for ; Wed, 3 Jan 2001 21:56:58 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA27579 for ; Wed, 3 Jan 2001 18:56:58 -0800 (PST) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f042url18824 for ; Wed, 3 Jan 2001 18:56:53 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id SAA12205 for ; Wed, 3 Jan 2001 18:56:39 -0800 (PST) Message-Id: <4.3.1.2.20010103214659.00bc2310@mail.bucknell.edu> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Wed, 03 Jan 2001 21:48:28 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: list DHCP-V4: Message Ignored In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN (Forwarded for Ted - RD) I sent a message to dhcp-v4 just now, and got *five* responses from peoples' broken autoresponders. Come on, folks! We're all IETFers - we're supposed to know better. The offending mail software is: X-Mailer: Internet Mail Service (5.5.2650.21) Everybody had the same version. I don't know if more recent versions of this software work better (I don't even know whose software it is) but if you are using this software at your site, puhleeze don't use the vacation responder feature. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Jan 5 08:56:45 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12595; Fri, 5 Jan 2001 08:56:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f05Do2932215; Fri, 5 Jan 2001 08:50:02 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f05Dnw905312; Fri, 5 Jan 2001 08:49:58 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA20508; Fri, 5 Jan 2001 08:49:42 -0500 (EST) Message-Id: <4.3.1.2.20010105083715.00b0b9a0@localhost> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 05 Jan 2001 08:49:54 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Minutes from DHC WG meetings in San Diego (REMINDER!!) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN (Note that there is a small change to the notes about the "Addition of Device Class to Agent Options" I-D; see change bars. - RD) Included below is a draft of the minutes from the San Diego meetings. Please get back to me by the end of next week (1/5) if you have any additions, corrections or other questions. - Ralph ===== The DHC WG met twice in San Diego. The WG discussed DHCPv4 issues in the first meeting: Ralph Droms (chair) opened the meeting with a summary of recent WG activities and document publications: New RFCs: * Procedure for Defining New DHCP Options and Message Types (RFC2939) * The Name Service Search Option for DHCP (RFC2937) * The User Class Option for DHCP (RFC3004) * The Subnet Selection Option for DHCP (RFC3011) * DHCP Relay Agent Information Option (Accepted for Proposed Standard) I-D Actions and Status: * Authentication for DHCP Messages: republished; requires minor edits before submission for Proposed Standard * Dynamic host configuration : DHCP reconfigure extension: ready for submission for Proposed Standard; awaiting authentication draft * Several new drafts to be considered for WG action DHCPv6 Activities: * Teleconference 8/31 List of issues generated Solutions added to spec I-D Discussion on mailing list * -16 rev of I-D published * Teleconference 12/5 Issues in -16 rev Some solutions defined Some issues to be discussed in WG meeting * WG meeting on DHCPv6 12/12 DHCP Option for PacketCable VoIP Client Configuration Burcak Beser In packet cable equipment, there may be multiple personalities within a single device such as a VoIP device. Each personality may need a separate IP address and obtain that address through a different DHCP server. Beser's draft, draft-ietf-dhc-packetcable-01.txt, proposes a new option that would support the PacketCable standard for configuring a DHCP server in a packet cable device. The WG asked if it is necessary for packet cable devices to have an architecture with multiple personalities that is configured with a special option. Kim Kinnear clarified that this option will support the standard of another standards body (PacketCable) without mandating its use by all DHCp clients. There was another question about the use of unicast versus multicast, which was clarified by pointing out the the initially configured packet cable device can act as a relay agent for the second device and unicast messages directly to the second level DHCP server. Action item: Beser will redraft to clarify format of options. Droms will review use of option specific to packet cable devices with PacketCable standard. DHCP Lease Query Kim Kinnear Issues with current draft, draft-ietf-dhc-leasequery-00.txt: Security - Kinnear suggested configuration of server with list of acceptable queriers would be an acceptable solution. Bulk, subnet-basis query - Kinnear has investigated bulk queries, but s of the opinion that the extra complexity does not justify the efficiency gain. What has Cisco implemented - In response to query from Ted Lemon, Kinnear will post summary of current Cisco implementation to DHC WG mailing list. Lease query and failover - Bernie Volz suggested draft should discuss use of lease query with failover partners; Kinnear agreed to add text to the draft about failover. Reservation - Kinnear will add bit to message to explicitly identify reservations. Different message types - Lemon suggested new message types rather than ACK/NAK. Kinnear agreed to this change. Action items: Kinnear will revise draft according to changes discussed during WG meeting. WG will review new draft at next meeting (Minneapolis) and then draft will go to last call. DHCP failover protocol Kim Kinnear Kinnear discussed what changed in most recent draft, draft-ietf-dhc-failover-08.txt. Lemon suggested we do interoperability testing between two independent implementations. Richard Jones said he would have an implementation by late January. Action item: Draft to go to last call prior to Minneapolis (either -08 or -09 draft at authors' discretion). Addition of Device Class to Agent Options Rich Woundy Woundy describes a new relay agent suboption in draft-ietf-dhc-agentoptions-device-class-00.txt. The new suboption allows the relay agent to identify the device class to the DHCP server. Lemon pointed out that suboption code 3 should not be used | and new options should be assigned suboption code 4. Current draft | specifies suboption code 4 but will be revised to TBD. Action item: Author will resubmit and WG will review new draft. Dynamic Host Configuration Protocol (DHCP) Server MIB Glenn Waters Waters announced that the DHCP server MIB in draft-ietf-dhc-server-mib-05.txt will be reviewed by the MIB doctors and then will be ready for last call. Action item: Authors to submit draft to MIB doctors and then draft (revised if necessary) will got to last call. DHC Load Balancing Algorithm Bernie Volz Now at IESG for last call. The Classless Static Route Option for DHCP Ted Lemon Action items: Lemon to clarify draft. Revised draft then ready for last call. DHCP Domain Search Option Bernard Aboba Issue of DNS compression as "evil" was raised. In this option, because compression reference point is well-known (beginning of option), compression is not a problem. Action items: Lemon to write draft describing concatenation of DHCP options. Aboba to revise draft to reference Lemon doc. Domain Search Option draft then ready for last call. DHCP Authentication Via Kerberos V Ted Lemon Lemon opined that this draft is the Kerberos-based authentication scheme that is the most likely to be deployed. Droms suggested that a quick summary of the differences between this scheme and the Lalwaney-Smedvinsky scheme would be useful; Lalwaney-Smedvinsky draft has such a comparison. See notes on Lalwaney-Smedvinsky draft (below) for more information. Triggering AAA from DHCP Relay Agents George Tsirtsis This draft describes a mechanism in which relay agents use AAA to validate DHCP request. Draft triggered discussion about whether this issue is within DHC WG charter. WG consensus is that it *should* be. Action items: Author to revise and WG will consider draft. Droms to add AAA/DHCP interaction to WG charter. Kerberos V Authentication Mode for Uninitialized Clients Sasha Medvinsky The Lalwaney-Medvinsky scheme for Kerberos-based DHCP authentication involves the use of "Kerberos Proxy' that assists a Kerberos exchange before the DHCP message exchange. Action item: Authors of two Kerberos authentication drafts will meet to devise single scheme to bring to WG. The WG discussed DHCPv6 issues in the second meeting: * Recent protocol spec activities: - 8/31 teleconference - Publication of draft-ietf-dhc-dhcpv6-16.txt based on issues resolved in 8/31 teleconference - 12/5 teleconference The following people participated in the 8/31 teleconference: Ralph Droms, Mark Stapp, Rich Woundy, Michael Carney, Jim Bound, Bernie Volz, Richard Jones, Thomas Narten, Ted Lemon, Barr Hibbs, Bernard Aboba, Richard Johnson, Josh Littlefield, Subir Das, Tony McAuley, Franics DuPont The group identified the following changes to be made in DHCPv6 spec; Droms presented this list to the WG and the WG accepted the changes except where noted: Issue: Understanding spec requires reading two documents Solution: Combine protocol spec and definitions for options that are part of base protocol operation into single document Issue: Releasable resources defined in DHCPv6; only real example is IPv6 addresses Solution: Discard all references to releasable resources and refer only to IPv6 addresses WG discussion: What about IPv4 addresses? Should IPvn addresses be carried on;y in DHCPvn; i.e., a dual-stack client uses both DHCPv4 and DHCPv6? Issue: Address model needed to allow for multiple addresses on an interface, multiple interface, roaming client identification Solution: define "Identity Association" to be a labeled collection of addresses Outstanding issues: - How to label? - Semantics of address management WG discussion: Additional discussion reserved for end of WG meeting Issue: Client behavior for address lifetime extension undefined Solution: Added description of address lifetime extension through IAs, controlled by parameters T1 and T2 Issue: Cleaner and simpler message formats Solution: Redefined message headers; all messages share same header format Related: Servers no longer advertise prefixes WG discussion: What about prefix advertisements if not in a routed environment? Consensus in WG was that prefixes not needed in this case. Issue: What were called "options" in DHCPv4 are called "extensions" in DHCPv6 Solution: Rename "extensions" to be "options" Issue: Where appropriate, coordinate DHCPv4 and DHCPv6 options (e.g., option codes, data formats, specifications) Solution: TBD Issue: Reduce number of ways to release addresses Solution: Release message is only way to release addresses Issue: Simplify reconfiguration Solution: Use DHCPv4-style reconfiguration; include multicast reconfiguration with no reliability guarantees WG discussion: When using multicast reconfigure, should reconfigure message be multicast once or more than once. If the server has a list of the clients it is trying to reconfigure, the server can manage retransmission for reliability. However, if the clients are not using DHCP for address assignment (i.e., using DHCPINFORM-like function), server may not have a list of clients. In any event, clients must be able to detect duplicates and respond (or not respond) appropriately. To mitigate "multicast implosion" due to synchronized responses to multicast reconfigure messages, Erik Nordmark suggested including delay parameters in the reconfigure message. This new parameter would specify a random delay to be used by clients to spread out the responses sent to the server. Issue: Authentication Solution: Use DHCPv4-style authentication framework Issue: Relay agents function (carried forward from BOOTP) is cumbersome Solution: Use encapsulation, in which client message is carried as payload in relay agent message Issue: Clients unicast some messages and multicast others (on local link) Solution: Clients multicast Solicit and Request messages; are not required to explicitly learn of relay agents WG discussion: Consider control from server to require client to multicast all messages, which would enable relay agents to examine all client messages. Draft will be left as is; if all-multicast mode is desired, text will be drafted and added to the spec before last call Issue: Avoid stateful server operation so that correct server operation does not depend on XID Solution: Redefined message exchanges so that server always returns same reply to retransmitted client message Details of -16 Rev of Spec I-D * Implemented solutions from 8/32 teleconference * Published just before I-D cutoff * Lots of typos; report them off-line to rdroms@cisco.com There was another teleconference of 12/5 to discuss the 16 rev of the protocol spec. The following people participated in the 12/5 teleconference: Michael Carney, Jim Bound, Bernie Volz, Thomas Narten, Ted Lemon, Ralph Droms, Mark Stapp, Kim Kinnear, Matt Williamson, Mike Dooley, Vijaya Bhaskar Here is a list of issues and resolutions from the 12/5 teleconference; again with any WG discussion or outstanding issues: Issue: Definition of label for IA Solution: Define UUID - "Universally Unique IDentifier" for each client; client assigns label to each IA: (UUID, binding-id) Outstanding issues: How is UUID defined? How does server use UUID to identify an IA? Volz suggested the identifier should be called DUID - "DHCP Unique IDentifier". More discussion deferred to end of WG meeting. Issue: Should Advertise message include addresses and configuration parameters from server? Solution: Yes WG discussion: Jim Bound asked if DHCPv4 semantics, in which server must mark offered address for later assignment to the client, must be adhered to. Droms believes this is an implementation issue not specified in the DHCPv4 spec. Kinnear suggested that if the client explicitly wants the addresses from the Advertise message, there should be an option through which it can request those addresses. Issue: What additional options should be included in base protocol spec or in separate doc? Solution: - Base spec: Status code, DHCP operational parameters (timeouts, etc.) - Separate doc: DNS name, DNS search order, DNS servers, client class, vendor class, TFTP server, boot file name, static routes Outstanding issues: Base spec or separate doc? Others options? WG discussion: Kinnear suggested that the base spec doc should include a definition of standard data types for use in future options. Droms said he would put framework and data types for option definitions in base spec. Kinnear suggested relay agent option numbers should come from the same number space as client option numbers. There was some discussion about this suggestion but no consensus about a resolution. Issue: Should client be allowed to include requested or preferred option values in Solicit message? Solution: Yes. WG discussion: Lemon wants to allow clients to request specific options but not values for those options. Richard Jones suggested placing general prohibition on requesting specific values but allowing exceptions for individual options, to be specified in option spec. Lemon also suggested that option specs should clearly articulate what it means when a client and a server sends the option. Issue: What about DDNS-DHCP interaction? Solution: Apply current specs to DHCPv6 as well; not required for base spec Outstanding issues: Is the current spec adequate; what options are needed? WG discussion: Mark Stapp will be asked to extend current DDNS-DHCP interaction docs for DHCPv6. Issue: Is merging DHCPDECLINE function from DHCPv4 into Release message a good idea? Solution: No; define new Decline message Issue: Does a DHCPv6 server need to differentiate between Request messages sent by client when initializing, confirming and extending address lifetimes? Solution: Yes; define different messages for each situation Issue: What if there is more than one relay agent on a link and the client receives multiple responses? Solution: Make sure DHCPv4 operation is carried forward Issue: Through what mechanism should an application communicate with the server? Solution: TBD WG discussion: There was an inquiry about whether the base spec should mention and API; no action for now Issue: What authentication mechanisms need to be defined in base protocol spec? Solution: Define authentication framework like DHCPv4; define one mandatory authentication protocol (e.g., DHCPv4 HMAC/shared-secret unless we can come up with something better) WG discussion: In an IETF security briefing (previous day) Jeff Schiller said HMAC/shared-secret is good enough; check with security experts for something better. WG discussion after review of -16 rev issues: * Milestones/timeline TBD to get to last call before next WG meeting (Minneapolis); see below for final schedule * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. * Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution. * IA identification in draft is based on tuple (UUID, binding-id). WG must develop rules for generating guaranteed unique UUID and whether server should also include link prefix with IA identifier. Lemon summarized his thoughts on generating UUID and will write a draft. Lemon will also write up requirements for UUID. Narten said UUIDs are in use elsewhere and we should research those other UUIDs. Discussion on IA identification will continue on WG mailing list. New schedule: Continue discussion of outstanding issues now Rev -17 of spec 1/31/2001 Teleconference 2/12/2001 Rev -18 of spec (if necessary) or last call 2/28/2001 WG review or last call Minneapolis 3/xx/2001 From owner-dhcp-v4@bucknell.edu Fri Jan 5 08:56:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA12620 for ; Fri, 5 Jan 2001 08:56:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f05Do2907704; Fri, 5 Jan 2001 08:50:02 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f05Dnw905312; Fri, 5 Jan 2001 08:49:58 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA20508; Fri, 5 Jan 2001 08:49:42 -0500 (EST) Message-Id: <4.3.1.2.20010105083715.00b0b9a0@localhost> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 05 Jan 2001 08:49:54 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Minutes from DHC WG meetings in San Diego (REMINDER!!) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN (Note that there is a small change to the notes about the "Addition of Device Class to Agent Options" I-D; see change bars. - RD) Included below is a draft of the minutes from the San Diego meetings. Please get back to me by the end of next week (1/5) if you have any additions, corrections or other questions. - Ralph ===== The DHC WG met twice in San Diego. The WG discussed DHCPv4 issues in the first meeting: Ralph Droms (chair) opened the meeting with a summary of recent WG activities and document publications: New RFCs: * Procedure for Defining New DHCP Options and Message Types (RFC2939) * The Name Service Search Option for DHCP (RFC2937) * The User Class Option for DHCP (RFC3004) * The Subnet Selection Option for DHCP (RFC3011) * DHCP Relay Agent Information Option (Accepted for Proposed Standard) I-D Actions and Status: * Authentication for DHCP Messages: republished; requires minor edits before submission for Proposed Standard * Dynamic host configuration : DHCP reconfigure extension: ready for submission for Proposed Standard; awaiting authentication draft * Several new drafts to be considered for WG action DHCPv6 Activities: * Teleconference 8/31 List of issues generated Solutions added to spec I-D Discussion on mailing list * -16 rev of I-D published * Teleconference 12/5 Issues in -16 rev Some solutions defined Some issues to be discussed in WG meeting * WG meeting on DHCPv6 12/12 DHCP Option for PacketCable VoIP Client Configuration Burcak Beser In packet cable equipment, there may be multiple personalities within a single device such as a VoIP device. Each personality may need a separate IP address and obtain that address through a different DHCP server. Beser's draft, draft-ietf-dhc-packetcable-01.txt, proposes a new option that would support the PacketCable standard for configuring a DHCP server in a packet cable device. The WG asked if it is necessary for packet cable devices to have an architecture with multiple personalities that is configured with a special option. Kim Kinnear clarified that this option will support the standard of another standards body (PacketCable) without mandating its use by all DHCp clients. There was another question about the use of unicast versus multicast, which was clarified by pointing out the the initially configured packet cable device can act as a relay agent for the second device and unicast messages directly to the second level DHCP server. Action item: Beser will redraft to clarify format of options. Droms will review use of option specific to packet cable devices with PacketCable standard. DHCP Lease Query Kim Kinnear Issues with current draft, draft-ietf-dhc-leasequery-00.txt: Security - Kinnear suggested configuration of server with list of acceptable queriers would be an acceptable solution. Bulk, subnet-basis query - Kinnear has investigated bulk queries, but s of the opinion that the extra complexity does not justify the efficiency gain. What has Cisco implemented - In response to query from Ted Lemon, Kinnear will post summary of current Cisco implementation to DHC WG mailing list. Lease query and failover - Bernie Volz suggested draft should discuss use of lease query with failover partners; Kinnear agreed to add text to the draft about failover. Reservation - Kinnear will add bit to message to explicitly identify reservations. Different message types - Lemon suggested new message types rather than ACK/NAK. Kinnear agreed to this change. Action items: Kinnear will revise draft according to changes discussed during WG meeting. WG will review new draft at next meeting (Minneapolis) and then draft will go to last call. DHCP failover protocol Kim Kinnear Kinnear discussed what changed in most recent draft, draft-ietf-dhc-failover-08.txt. Lemon suggested we do interoperability testing between two independent implementations. Richard Jones said he would have an implementation by late January. Action item: Draft to go to last call prior to Minneapolis (either -08 or -09 draft at authors' discretion). Addition of Device Class to Agent Options Rich Woundy Woundy describes a new relay agent suboption in draft-ietf-dhc-agentoptions-device-class-00.txt. The new suboption allows the relay agent to identify the device class to the DHCP server. Lemon pointed out that suboption code 3 should not be used | and new options should be assigned suboption code 4. Current draft | specifies suboption code 4 but will be revised to TBD. Action item: Author will resubmit and WG will review new draft. Dynamic Host Configuration Protocol (DHCP) Server MIB Glenn Waters Waters announced that the DHCP server MIB in draft-ietf-dhc-server-mib-05.txt will be reviewed by the MIB doctors and then will be ready for last call. Action item: Authors to submit draft to MIB doctors and then draft (revised if necessary) will got to last call. DHC Load Balancing Algorithm Bernie Volz Now at IESG for last call. The Classless Static Route Option for DHCP Ted Lemon Action items: Lemon to clarify draft. Revised draft then ready for last call. DHCP Domain Search Option Bernard Aboba Issue of DNS compression as "evil" was raised. In this option, because compression reference point is well-known (beginning of option), compression is not a problem. Action items: Lemon to write draft describing concatenation of DHCP options. Aboba to revise draft to reference Lemon doc. Domain Search Option draft then ready for last call. DHCP Authentication Via Kerberos V Ted Lemon Lemon opined that this draft is the Kerberos-based authentication scheme that is the most likely to be deployed. Droms suggested that a quick summary of the differences between this scheme and the Lalwaney-Smedvinsky scheme would be useful; Lalwaney-Smedvinsky draft has such a comparison. See notes on Lalwaney-Smedvinsky draft (below) for more information. Triggering AAA from DHCP Relay Agents George Tsirtsis This draft describes a mechanism in which relay agents use AAA to validate DHCP request. Draft triggered discussion about whether this issue is within DHC WG charter. WG consensus is that it *should* be. Action items: Author to revise and WG will consider draft. Droms to add AAA/DHCP interaction to WG charter. Kerberos V Authentication Mode for Uninitialized Clients Sasha Medvinsky The Lalwaney-Medvinsky scheme for Kerberos-based DHCP authentication involves the use of "Kerberos Proxy' that assists a Kerberos exchange before the DHCP message exchange. Action item: Authors of two Kerberos authentication drafts will meet to devise single scheme to bring to WG. The WG discussed DHCPv6 issues in the second meeting: * Recent protocol spec activities: - 8/31 teleconference - Publication of draft-ietf-dhc-dhcpv6-16.txt based on issues resolved in 8/31 teleconference - 12/5 teleconference The following people participated in the 8/31 teleconference: Ralph Droms, Mark Stapp, Rich Woundy, Michael Carney, Jim Bound, Bernie Volz, Richard Jones, Thomas Narten, Ted Lemon, Barr Hibbs, Bernard Aboba, Richard Johnson, Josh Littlefield, Subir Das, Tony McAuley, Franics DuPont The group identified the following changes to be made in DHCPv6 spec; Droms presented this list to the WG and the WG accepted the changes except where noted: Issue: Understanding spec requires reading two documents Solution: Combine protocol spec and definitions for options that are part of base protocol operation into single document Issue: Releasable resources defined in DHCPv6; only real example is IPv6 addresses Solution: Discard all references to releasable resources and refer only to IPv6 addresses WG discussion: What about IPv4 addresses? Should IPvn addresses be carried on;y in DHCPvn; i.e., a dual-stack client uses both DHCPv4 and DHCPv6? Issue: Address model needed to allow for multiple addresses on an interface, multiple interface, roaming client identification Solution: define "Identity Association" to be a labeled collection of addresses Outstanding issues: - How to label? - Semantics of address management WG discussion: Additional discussion reserved for end of WG meeting Issue: Client behavior for address lifetime extension undefined Solution: Added description of address lifetime extension through IAs, controlled by parameters T1 and T2 Issue: Cleaner and simpler message formats Solution: Redefined message headers; all messages share same header format Related: Servers no longer advertise prefixes WG discussion: What about prefix advertisements if not in a routed environment? Consensus in WG was that prefixes not needed in this case. Issue: What were called "options" in DHCPv4 are called "extensions" in DHCPv6 Solution: Rename "extensions" to be "options" Issue: Where appropriate, coordinate DHCPv4 and DHCPv6 options (e.g., option codes, data formats, specifications) Solution: TBD Issue: Reduce number of ways to release addresses Solution: Release message is only way to release addresses Issue: Simplify reconfiguration Solution: Use DHCPv4-style reconfiguration; include multicast reconfiguration with no reliability guarantees WG discussion: When using multicast reconfigure, should reconfigure message be multicast once or more than once. If the server has a list of the clients it is trying to reconfigure, the server can manage retransmission for reliability. However, if the clients are not using DHCP for address assignment (i.e., using DHCPINFORM-like function), server may not have a list of clients. In any event, clients must be able to detect duplicates and respond (or not respond) appropriately. To mitigate "multicast implosion" due to synchronized responses to multicast reconfigure messages, Erik Nordmark suggested including delay parameters in the reconfigure message. This new parameter would specify a random delay to be used by clients to spread out the responses sent to the server. Issue: Authentication Solution: Use DHCPv4-style authentication framework Issue: Relay agents function (carried forward from BOOTP) is cumbersome Solution: Use encapsulation, in which client message is carried as payload in relay agent message Issue: Clients unicast some messages and multicast others (on local link) Solution: Clients multicast Solicit and Request messages; are not required to explicitly learn of relay agents WG discussion: Consider control from server to require client to multicast all messages, which would enable relay agents to examine all client messages. Draft will be left as is; if all-multicast mode is desired, text will be drafted and added to the spec before last call Issue: Avoid stateful server operation so that correct server operation does not depend on XID Solution: Redefined message exchanges so that server always returns same reply to retransmitted client message Details of -16 Rev of Spec I-D * Implemented solutions from 8/32 teleconference * Published just before I-D cutoff * Lots of typos; report them off-line to rdroms@cisco.com There was another teleconference of 12/5 to discuss the 16 rev of the protocol spec. The following people participated in the 12/5 teleconference: Michael Carney, Jim Bound, Bernie Volz, Thomas Narten, Ted Lemon, Ralph Droms, Mark Stapp, Kim Kinnear, Matt Williamson, Mike Dooley, Vijaya Bhaskar Here is a list of issues and resolutions from the 12/5 teleconference; again with any WG discussion or outstanding issues: Issue: Definition of label for IA Solution: Define UUID - "Universally Unique IDentifier" for each client; client assigns label to each IA: (UUID, binding-id) Outstanding issues: How is UUID defined? How does server use UUID to identify an IA? Volz suggested the identifier should be called DUID - "DHCP Unique IDentifier". More discussion deferred to end of WG meeting. Issue: Should Advertise message include addresses and configuration parameters from server? Solution: Yes WG discussion: Jim Bound asked if DHCPv4 semantics, in which server must mark offered address for later assignment to the client, must be adhered to. Droms believes this is an implementation issue not specified in the DHCPv4 spec. Kinnear suggested that if the client explicitly wants the addresses from the Advertise message, there should be an option through which it can request those addresses. Issue: What additional options should be included in base protocol spec or in separate doc? Solution: - Base spec: Status code, DHCP operational parameters (timeouts, etc.) - Separate doc: DNS name, DNS search order, DNS servers, client class, vendor class, TFTP server, boot file name, static routes Outstanding issues: Base spec or separate doc? Others options? WG discussion: Kinnear suggested that the base spec doc should include a definition of standard data types for use in future options. Droms said he would put framework and data types for option definitions in base spec. Kinnear suggested relay agent option numbers should come from the same number space as client option numbers. There was some discussion about this suggestion but no consensus about a resolution. Issue: Should client be allowed to include requested or preferred option values in Solicit message? Solution: Yes. WG discussion: Lemon wants to allow clients to request specific options but not values for those options. Richard Jones suggested placing general prohibition on requesting specific values but allowing exceptions for individual options, to be specified in option spec. Lemon also suggested that option specs should clearly articulate what it means when a client and a server sends the option. Issue: What about DDNS-DHCP interaction? Solution: Apply current specs to DHCPv6 as well; not required for base spec Outstanding issues: Is the current spec adequate; what options are needed? WG discussion: Mark Stapp will be asked to extend current DDNS-DHCP interaction docs for DHCPv6. Issue: Is merging DHCPDECLINE function from DHCPv4 into Release message a good idea? Solution: No; define new Decline message Issue: Does a DHCPv6 server need to differentiate between Request messages sent by client when initializing, confirming and extending address lifetimes? Solution: Yes; define different messages for each situation Issue: What if there is more than one relay agent on a link and the client receives multiple responses? Solution: Make sure DHCPv4 operation is carried forward Issue: Through what mechanism should an application communicate with the server? Solution: TBD WG discussion: There was an inquiry about whether the base spec should mention and API; no action for now Issue: What authentication mechanisms need to be defined in base protocol spec? Solution: Define authentication framework like DHCPv4; define one mandatory authentication protocol (e.g., DHCPv4 HMAC/shared-secret unless we can come up with something better) WG discussion: In an IETF security briefing (previous day) Jeff Schiller said HMAC/shared-secret is good enough; check with security experts for something better. WG discussion after review of -16 rev issues: * Milestones/timeline TBD to get to last call before next WG meeting (Minneapolis); see below for final schedule * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. * Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution. * IA identification in draft is based on tuple (UUID, binding-id). WG must develop rules for generating guaranteed unique UUID and whether server should also include link prefix with IA identifier. Lemon summarized his thoughts on generating UUID and will write a draft. Lemon will also write up requirements for UUID. Narten said UUIDs are in use elsewhere and we should research those other UUIDs. Discussion on IA identification will continue on WG mailing list. New schedule: Continue discussion of outstanding issues now Rev -17 of spec 1/31/2001 Teleconference 2/12/2001 Rev -18 of spec (if necessary) or last call 2/28/2001 WG review or last call Minneapolis 3/xx/2001 From owner-dhcp-v6@bucknell.edu Fri Jan 5 16:33:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23302; Fri, 5 Jan 2001 16:33:26 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f05LUh918527; Fri, 5 Jan 2001 16:30:43 -0500 (EST) Received: from DF-INET-1.dogfoodinternet.com (df-inet1.exchange.microsoft.com [131.107.8.8]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f05LUc920792 for ; Fri, 5 Jan 2001 16:30:38 -0500 (EST) Received: from df-virus2.platinum.corp.microsoft.com ([172.30.236.33]) by DF-INET-1.dogfoodinternet.com with Microsoft SMTPSVC(5.0.2195.1600); Fri, 5 Jan 2001 11:58:50 -0800 Received: from 172.30.236.11 by df-virus2.platinum.corp.microsoft.com (InterScan E-Mail VirusWall NT); Fri, 05 Jan 2001 11:59:33 -0800 (Pacific Standard Time) Received: from DF-SPIKE.platinum.corp.microsoft.com ([172.30.236.82]) by yuri.dns.microsoft.com with Microsoft SMTPSVC(5.0.2195.2532); Fri, 5 Jan 2001 11:59:33 -0800 content-class: urn:content-classes:message Subject: RE: Minutes from DHC WG meetings in San Diego (REMINDER!!) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 5 Jan 2001 11:59:34 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.0.4604.0 Message-ID: <78B1387745A15C46A7A727F2670D4A681B655D@DF-MILO.platinum.corp.microsoft.com> Thread-Topic: Minutes from DHC WG meetings in San Diego (REMINDER!!) Thread-Index: AcB3Htfr7G8mdp1uSvyDUnjHh/L6aAAMnZpg From: "Thirumalesh Bhat" To: DHCPv6 discussion list Cc: "Matthew Williamson" , "Stephen Bensley" X-OriginalArrivalTime: 05 Jan 2001 19:59:33.0694 (UTC) FILETIME=[05EEE5E0:01C07752] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f05LUc906029 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Ralph, thanks for compiling the minutes and sending them to the dhcpv4 mailing list. I have a comment on the DHCPv6 drafr. Would it make sense to combine multicast address allocation with generic IPv6 address allocation? In the IPv4 world, we have different protocols ( MADCAP - RFC 2730 )for multicast address allocation. Since in IPv6, multicast is going to be more critical than in IPv4, a unified protocol would serve a better purpose. thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, January 05, 2001 5:50 AM To: DHCPv4 discussion list Subject: Minutes from DHC WG meetings in San Diego (REMINDER!!) (Note that there is a small change to the notes about the "Addition of Device Class to Agent Options" I-D; see change bars. - RD) Included below is a draft of the minutes from the San Diego meetings. Please get back to me by the end of next week (1/5) if you have any additions, corrections or other questions. - Ralph ===== The DHC WG met twice in San Diego. The WG discussed DHCPv4 issues in the first meeting: Ralph Droms (chair) opened the meeting with a summary of recent WG activities and document publications: New RFCs: * Procedure for Defining New DHCP Options and Message Types (RFC2939) * The Name Service Search Option for DHCP (RFC2937) * The User Class Option for DHCP (RFC3004) * The Subnet Selection Option for DHCP (RFC3011) * DHCP Relay Agent Information Option (Accepted for Proposed Standard) I-D Actions and Status: * Authentication for DHCP Messages: republished; requires minor edits before submission for Proposed Standard * Dynamic host configuration : DHCP reconfigure extension: ready for submission for Proposed Standard; awaiting authentication draft * Several new drafts to be considered for WG action DHCPv6 Activities: * Teleconference 8/31 List of issues generated Solutions added to spec I-D Discussion on mailing list * -16 rev of I-D published * Teleconference 12/5 Issues in -16 rev Some solutions defined Some issues to be discussed in WG meeting * WG meeting on DHCPv6 12/12 DHCP Option for PacketCable VoIP Client Configuration Burcak Beser In packet cable equipment, there may be multiple personalities within a single device such as a VoIP device. Each personality may need a separate IP address and obtain that address through a different DHCP server. Beser's draft, draft-ietf-dhc-packetcable-01.txt, proposes a new option that would support the PacketCable standard for configuring a DHCP server in a packet cable device. The WG asked if it is necessary for packet cable devices to have an architecture with multiple personalities that is configured with a special option. Kim Kinnear clarified that this option will support the standard of another standards body (PacketCable) without mandating its use by all DHCp clients. There was another question about the use of unicast versus multicast, which was clarified by pointing out the the initially configured packet cable device can act as a relay agent for the second device and unicast messages directly to the second level DHCP server. Action item: Beser will redraft to clarify format of options. Droms will review use of option specific to packet cable devices with PacketCable standard. DHCP Lease Query Kim Kinnear Issues with current draft, draft-ietf-dhc-leasequery-00.txt: Security - Kinnear suggested configuration of server with list of acceptable queriers would be an acceptable solution. Bulk, subnet-basis query - Kinnear has investigated bulk queries, but s of the opinion that the extra complexity does not justify the efficiency gain. What has Cisco implemented - In response to query from Ted Lemon, Kinnear will post summary of current Cisco implementation to DHC WG mailing list. Lease query and failover - Bernie Volz suggested draft should discuss use of lease query with failover partners; Kinnear agreed to add text to the draft about failover. Reservation - Kinnear will add bit to message to explicitly identify reservations. Different message types - Lemon suggested new message types rather than ACK/NAK. Kinnear agreed to this change. Action items: Kinnear will revise draft according to changes discussed during WG meeting. WG will review new draft at next meeting (Minneapolis) and then draft will go to last call. DHCP failover protocol Kim Kinnear Kinnear discussed what changed in most recent draft, draft-ietf-dhc-failover-08.txt. Lemon suggested we do interoperability testing between two independent implementations. Richard Jones said he would have an implementation by late January. Action item: Draft to go to last call prior to Minneapolis (either -08 or -09 draft at authors' discretion). Addition of Device Class to Agent Options Rich Woundy Woundy describes a new relay agent suboption in draft-ietf-dhc-agentoptions-device-class-00.txt. The new suboption allows the relay agent to identify the device class to the DHCP server. Lemon pointed out that suboption code 3 should not be used | and new options should be assigned suboption code 4. Current draft | specifies suboption code 4 but will be revised to TBD. Action item: Author will resubmit and WG will review new draft. Dynamic Host Configuration Protocol (DHCP) Server MIB Glenn Waters Waters announced that the DHCP server MIB in draft-ietf-dhc-server-mib-05.txt will be reviewed by the MIB doctors and then will be ready for last call. Action item: Authors to submit draft to MIB doctors and then draft (revised if necessary) will got to last call. DHC Load Balancing Algorithm Bernie Volz Now at IESG for last call. The Classless Static Route Option for DHCP Ted Lemon Action items: Lemon to clarify draft. Revised draft then ready for last call. DHCP Domain Search Option Bernard Aboba Issue of DNS compression as "evil" was raised. In this option, because compression reference point is well-known (beginning of option), compression is not a problem. Action items: Lemon to write draft describing concatenation of DHCP options. Aboba to revise draft to reference Lemon doc. Domain Search Option draft then ready for last call. DHCP Authentication Via Kerberos V Ted Lemon Lemon opined that this draft is the Kerberos-based authentication scheme that is the most likely to be deployed. Droms suggested that a quick summary of the differences between this scheme and the Lalwaney-Smedvinsky scheme would be useful; Lalwaney-Smedvinsky draft has such a comparison. See notes on Lalwaney-Smedvinsky draft (below) for more information. Triggering AAA from DHCP Relay Agents George Tsirtsis This draft describes a mechanism in which relay agents use AAA to validate DHCP request. Draft triggered discussion about whether this issue is within DHC WG charter. WG consensus is that it *should* be. Action items: Author to revise and WG will consider draft. Droms to add AAA/DHCP interaction to WG charter. Kerberos V Authentication Mode for Uninitialized Clients Sasha Medvinsky The Lalwaney-Medvinsky scheme for Kerberos-based DHCP authentication involves the use of "Kerberos Proxy' that assists a Kerberos exchange before the DHCP message exchange. Action item: Authors of two Kerberos authentication drafts will meet to devise single scheme to bring to WG. The WG discussed DHCPv6 issues in the second meeting: * Recent protocol spec activities: - 8/31 teleconference - Publication of draft-ietf-dhc-dhcpv6-16.txt based on issues resolved in 8/31 teleconference - 12/5 teleconference The following people participated in the 8/31 teleconference: Ralph Droms, Mark Stapp, Rich Woundy, Michael Carney, Jim Bound, Bernie Volz, Richard Jones, Thomas Narten, Ted Lemon, Barr Hibbs, Bernard Aboba, Richard Johnson, Josh Littlefield, Subir Das, Tony McAuley, Franics DuPont The group identified the following changes to be made in DHCPv6 spec; Droms presented this list to the WG and the WG accepted the changes except where noted: Issue: Understanding spec requires reading two documents Solution: Combine protocol spec and definitions for options that are part of base protocol operation into single document Issue: Releasable resources defined in DHCPv6; only real example is IPv6 addresses Solution: Discard all references to releasable resources and refer only to IPv6 addresses WG discussion: What about IPv4 addresses? Should IPvn addresses be carried on;y in DHCPvn; i.e., a dual-stack client uses both DHCPv4 and DHCPv6? Issue: Address model needed to allow for multiple addresses on an interface, multiple interface, roaming client identification Solution: define "Identity Association" to be a labeled collection of addresses Outstanding issues: - How to label? - Semantics of address management WG discussion: Additional discussion reserved for end of WG meeting Issue: Client behavior for address lifetime extension undefined Solution: Added description of address lifetime extension through IAs, controlled by parameters T1 and T2 Issue: Cleaner and simpler message formats Solution: Redefined message headers; all messages share same header format Related: Servers no longer advertise prefixes WG discussion: What about prefix advertisements if not in a routed environment? Consensus in WG was that prefixes not needed in this case. Issue: What were called "options" in DHCPv4 are called "extensions" in DHCPv6 Solution: Rename "extensions" to be "options" Issue: Where appropriate, coordinate DHCPv4 and DHCPv6 options (e.g., option codes, data formats, specifications) Solution: TBD Issue: Reduce number of ways to release addresses Solution: Release message is only way to release addresses Issue: Simplify reconfiguration Solution: Use DHCPv4-style reconfiguration; include multicast reconfiguration with no reliability guarantees WG discussion: When using multicast reconfigure, should reconfigure message be multicast once or more than once. If the server has a list of the clients it is trying to reconfigure, the server can manage retransmission for reliability. However, if the clients are not using DHCP for address assignment (i.e., using DHCPINFORM-like function), server may not have a list of clients. In any event, clients must be able to detect duplicates and respond (or not respond) appropriately. To mitigate "multicast implosion" due to synchronized responses to multicast reconfigure messages, Erik Nordmark suggested including delay parameters in the reconfigure message. This new parameter would specify a random delay to be used by clients to spread out the responses sent to the server. Issue: Authentication Solution: Use DHCPv4-style authentication framework Issue: Relay agents function (carried forward from BOOTP) is cumbersome Solution: Use encapsulation, in which client message is carried as payload in relay agent message Issue: Clients unicast some messages and multicast others (on local link) Solution: Clients multicast Solicit and Request messages; are not required to explicitly learn of relay agents WG discussion: Consider control from server to require client to multicast all messages, which would enable relay agents to examine all client messages. Draft will be left as is; if all-multicast mode is desired, text will be drafted and added to the spec before last call Issue: Avoid stateful server operation so that correct server operation does not depend on XID Solution: Redefined message exchanges so that server always returns same reply to retransmitted client message Details of -16 Rev of Spec I-D * Implemented solutions from 8/32 teleconference * Published just before I-D cutoff * Lots of typos; report them off-line to rdroms@cisco.com There was another teleconference of 12/5 to discuss the 16 rev of the protocol spec. The following people participated in the 12/5 teleconference: Michael Carney, Jim Bound, Bernie Volz, Thomas Narten, Ted Lemon, Ralph Droms, Mark Stapp, Kim Kinnear, Matt Williamson, Mike Dooley, Vijaya Bhaskar Here is a list of issues and resolutions from the 12/5 teleconference; again with any WG discussion or outstanding issues: Issue: Definition of label for IA Solution: Define UUID - "Universally Unique IDentifier" for each client; client assigns label to each IA: (UUID, binding-id) Outstanding issues: How is UUID defined? How does server use UUID to identify an IA? Volz suggested the identifier should be called DUID - "DHCP Unique IDentifier". More discussion deferred to end of WG meeting. Issue: Should Advertise message include addresses and configuration parameters from server? Solution: Yes WG discussion: Jim Bound asked if DHCPv4 semantics, in which server must mark offered address for later assignment to the client, must be adhered to. Droms believes this is an implementation issue not specified in the DHCPv4 spec. Kinnear suggested that if the client explicitly wants the addresses from the Advertise message, there should be an option through which it can request those addresses. Issue: What additional options should be included in base protocol spec or in separate doc? Solution: - Base spec: Status code, DHCP operational parameters (timeouts, etc.) - Separate doc: DNS name, DNS search order, DNS servers, client class, vendor class, TFTP server, boot file name, static routes Outstanding issues: Base spec or separate doc? Others options? WG discussion: Kinnear suggested that the base spec doc should include a definition of standard data types for use in future options. Droms said he would put framework and data types for option definitions in base spec. Kinnear suggested relay agent option numbers should come from the same number space as client option numbers. There was some discussion about this suggestion but no consensus about a resolution. Issue: Should client be allowed to include requested or preferred option values in Solicit message? Solution: Yes. WG discussion: Lemon wants to allow clients to request specific options but not values for those options. Richard Jones suggested placing general prohibition on requesting specific values but allowing exceptions for individual options, to be specified in option spec. Lemon also suggested that option specs should clearly articulate what it means when a client and a server sends the option. Issue: What about DDNS-DHCP interaction? Solution: Apply current specs to DHCPv6 as well; not required for base spec Outstanding issues: Is the current spec adequate; what options are needed? WG discussion: Mark Stapp will be asked to extend current DDNS-DHCP interaction docs for DHCPv6. Issue: Is merging DHCPDECLINE function from DHCPv4 into Release message a good idea? Solution: No; define new Decline message Issue: Does a DHCPv6 server need to differentiate between Request messages sent by client when initializing, confirming and extending address lifetimes? Solution: Yes; define different messages for each situation Issue: What if there is more than one relay agent on a link and the client receives multiple responses? Solution: Make sure DHCPv4 operation is carried forward Issue: Through what mechanism should an application communicate with the server? Solution: TBD WG discussion: There was an inquiry about whether the base spec should mention and API; no action for now Issue: What authentication mechanisms need to be defined in base protocol spec? Solution: Define authentication framework like DHCPv4; define one mandatory authentication protocol (e.g., DHCPv4 HMAC/shared-secret unless we can come up with something better) WG discussion: In an IETF security briefing (previous day) Jeff Schiller said HMAC/shared-secret is good enough; check with security experts for something better. WG discussion after review of -16 rev issues: * Milestones/timeline TBD to get to last call before next WG meeting (Minneapolis); see below for final schedule * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. * Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution. * IA identification in draft is based on tuple (UUID, binding-id). WG must develop rules for generating guaranteed unique UUID and whether server should also include link prefix with IA identifier. Lemon summarized his thoughts on generating UUID and will write a draft. Lemon will also write up requirements for UUID. Narten said UUIDs are in use elsewhere and we should research those other UUIDs. Discussion on IA identification will continue on WG mailing list. New schedule: Continue discussion of outstanding issues now Rev -17 of spec 1/31/2001 Teleconference 2/12/2001 Rev -18 of spec (if necessary) or last call 2/28/2001 WG review or last call Minneapolis 3/xx/2001 From owner-dhcp-v6@bucknell.edu Sat Jan 6 20:53:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19359; Sat, 6 Jan 2001 20:53:38 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f071nu910170; Sat, 6 Jan 2001 20:49:56 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f071nh918271 for ; Sat, 6 Jan 2001 20:49:44 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Sat, 6 Jan 2001 20:49:28 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE860360758C@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Cc: Matthew Williamson , Stephen Bensley Subject: RE: Minutes from DHC WG meetings in San Diego (REMINDER!!) Date: Sat, 6 Jan 2001 20:49:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I do think that this has some merit. Though I myself haven't looked at the MADCAP protocol. I think the best way to proceed is let us 'finish' DHCPv6 for address allocation (since we'd like to do this by about the Spring '01 IETF meeting). Please do look at the current work and make comments to the list if you see things that would prevent it working for multicast allocations. Once the base work is complete, additional options can be defined to support multicast allocations. - Bernie Volz -----Original Message----- From: Thirumalesh Bhat [mailto:thirub@exchange.microsoft.com] Sent: Friday, January 05, 2001 3:00 PM To: DHCPv6 discussion list Cc: Matthew Williamson; Stephen Bensley Subject: RE: Minutes from DHC WG meetings in San Diego (REMINDER!!) Ralph, thanks for compiling the minutes and sending them to the dhcpv4 mailing list. I have a comment on the DHCPv6 drafr. Would it make sense to combine multicast address allocation with generic IPv6 address allocation? In the IPv4 world, we have different protocols ( MADCAP - RFC 2730 )for multicast address allocation. Since in IPv6, multicast is going to be more critical than in IPv4, a unified protocol would serve a better purpose. thx -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, January 05, 2001 5:50 AM To: DHCPv4 discussion list Subject: Minutes from DHC WG meetings in San Diego (REMINDER!!) (Note that there is a small change to the notes about the "Addition of Device Class to Agent Options" I-D; see change bars. - RD) Included below is a draft of the minutes from the San Diego meetings. Please get back to me by the end of next week (1/5) if you have any additions, corrections or other questions. - Ralph ===== The DHC WG met twice in San Diego. The WG discussed DHCPv4 issues in the first meeting: Ralph Droms (chair) opened the meeting with a summary of recent WG activities and document publications: New RFCs: * Procedure for Defining New DHCP Options and Message Types (RFC2939) * The Name Service Search Option for DHCP (RFC2937) * The User Class Option for DHCP (RFC3004) * The Subnet Selection Option for DHCP (RFC3011) * DHCP Relay Agent Information Option (Accepted for Proposed Standard) I-D Actions and Status: * Authentication for DHCP Messages: republished; requires minor edits before submission for Proposed Standard * Dynamic host configuration : DHCP reconfigure extension: ready for submission for Proposed Standard; awaiting authentication draft * Several new drafts to be considered for WG action DHCPv6 Activities: * Teleconference 8/31 List of issues generated Solutions added to spec I-D Discussion on mailing list * -16 rev of I-D published * Teleconference 12/5 Issues in -16 rev Some solutions defined Some issues to be discussed in WG meeting * WG meeting on DHCPv6 12/12 DHCP Option for PacketCable VoIP Client Configuration Burcak Beser In packet cable equipment, there may be multiple personalities within a single device such as a VoIP device. Each personality may need a separate IP address and obtain that address through a different DHCP server. Beser's draft, draft-ietf-dhc-packetcable-01.txt, proposes a new option that would support the PacketCable standard for configuring a DHCP server in a packet cable device. The WG asked if it is necessary for packet cable devices to have an architecture with multiple personalities that is configured with a special option. Kim Kinnear clarified that this option will support the standard of another standards body (PacketCable) without mandating its use by all DHCp clients. There was another question about the use of unicast versus multicast, which was clarified by pointing out the the initially configured packet cable device can act as a relay agent for the second device and unicast messages directly to the second level DHCP server. Action item: Beser will redraft to clarify format of options. Droms will review use of option specific to packet cable devices with PacketCable standard. DHCP Lease Query Kim Kinnear Issues with current draft, draft-ietf-dhc-leasequery-00.txt: Security - Kinnear suggested configuration of server with list of acceptable queriers would be an acceptable solution. Bulk, subnet-basis query - Kinnear has investigated bulk queries, but s of the opinion that the extra complexity does not justify the efficiency gain. What has Cisco implemented - In response to query from Ted Lemon, Kinnear will post summary of current Cisco implementation to DHC WG mailing list. Lease query and failover - Bernie Volz suggested draft should discuss use of lease query with failover partners; Kinnear agreed to add text to the draft about failover. Reservation - Kinnear will add bit to message to explicitly identify reservations. Different message types - Lemon suggested new message types rather than ACK/NAK. Kinnear agreed to this change. Action items: Kinnear will revise draft according to changes discussed during WG meeting. WG will review new draft at next meeting (Minneapolis) and then draft will go to last call. DHCP failover protocol Kim Kinnear Kinnear discussed what changed in most recent draft, draft-ietf-dhc-failover-08.txt. Lemon suggested we do interoperability testing between two independent implementations. Richard Jones said he would have an implementation by late January. Action item: Draft to go to last call prior to Minneapolis (either -08 or -09 draft at authors' discretion). Addition of Device Class to Agent Options Rich Woundy Woundy describes a new relay agent suboption in draft-ietf-dhc-agentoptions-device-class-00.txt. The new suboption allows the relay agent to identify the device class to the DHCP server. Lemon pointed out that suboption code 3 should not be used | and new options should be assigned suboption code 4. Current draft | specifies suboption code 4 but will be revised to TBD. Action item: Author will resubmit and WG will review new draft. Dynamic Host Configuration Protocol (DHCP) Server MIB Glenn Waters Waters announced that the DHCP server MIB in draft-ietf-dhc-server-mib-05.txt will be reviewed by the MIB doctors and then will be ready for last call. Action item: Authors to submit draft to MIB doctors and then draft (revised if necessary) will got to last call. DHC Load Balancing Algorithm Bernie Volz Now at IESG for last call. The Classless Static Route Option for DHCP Ted Lemon Action items: Lemon to clarify draft. Revised draft then ready for last call. DHCP Domain Search Option Bernard Aboba Issue of DNS compression as "evil" was raised. In this option, because compression reference point is well-known (beginning of option), compression is not a problem. Action items: Lemon to write draft describing concatenation of DHCP options. Aboba to revise draft to reference Lemon doc. Domain Search Option draft then ready for last call. DHCP Authentication Via Kerberos V Ted Lemon Lemon opined that this draft is the Kerberos-based authentication scheme that is the most likely to be deployed. Droms suggested that a quick summary of the differences between this scheme and the Lalwaney-Smedvinsky scheme would be useful; Lalwaney-Smedvinsky draft has such a comparison. See notes on Lalwaney-Smedvinsky draft (below) for more information. Triggering AAA from DHCP Relay Agents George Tsirtsis This draft describes a mechanism in which relay agents use AAA to validate DHCP request. Draft triggered discussion about whether this issue is within DHC WG charter. WG consensus is that it *should* be. Action items: Author to revise and WG will consider draft. Droms to add AAA/DHCP interaction to WG charter. Kerberos V Authentication Mode for Uninitialized Clients Sasha Medvinsky The Lalwaney-Medvinsky scheme for Kerberos-based DHCP authentication involves the use of "Kerberos Proxy' that assists a Kerberos exchange before the DHCP message exchange. Action item: Authors of two Kerberos authentication drafts will meet to devise single scheme to bring to WG. The WG discussed DHCPv6 issues in the second meeting: * Recent protocol spec activities: - 8/31 teleconference - Publication of draft-ietf-dhc-dhcpv6-16.txt based on issues resolved in 8/31 teleconference - 12/5 teleconference The following people participated in the 8/31 teleconference: Ralph Droms, Mark Stapp, Rich Woundy, Michael Carney, Jim Bound, Bernie Volz, Richard Jones, Thomas Narten, Ted Lemon, Barr Hibbs, Bernard Aboba, Richard Johnson, Josh Littlefield, Subir Das, Tony McAuley, Franics DuPont The group identified the following changes to be made in DHCPv6 spec; Droms presented this list to the WG and the WG accepted the changes except where noted: Issue: Understanding spec requires reading two documents Solution: Combine protocol spec and definitions for options that are part of base protocol operation into single document Issue: Releasable resources defined in DHCPv6; only real example is IPv6 addresses Solution: Discard all references to releasable resources and refer only to IPv6 addresses WG discussion: What about IPv4 addresses? Should IPvn addresses be carried on;y in DHCPvn; i.e., a dual-stack client uses both DHCPv4 and DHCPv6? Issue: Address model needed to allow for multiple addresses on an interface, multiple interface, roaming client identification Solution: define "Identity Association" to be a labeled collection of addresses Outstanding issues: - How to label? - Semantics of address management WG discussion: Additional discussion reserved for end of WG meeting Issue: Client behavior for address lifetime extension undefined Solution: Added description of address lifetime extension through IAs, controlled by parameters T1 and T2 Issue: Cleaner and simpler message formats Solution: Redefined message headers; all messages share same header format Related: Servers no longer advertise prefixes WG discussion: What about prefix advertisements if not in a routed environment? Consensus in WG was that prefixes not needed in this case. Issue: What were called "options" in DHCPv4 are called "extensions" in DHCPv6 Solution: Rename "extensions" to be "options" Issue: Where appropriate, coordinate DHCPv4 and DHCPv6 options (e.g., option codes, data formats, specifications) Solution: TBD Issue: Reduce number of ways to release addresses Solution: Release message is only way to release addresses Issue: Simplify reconfiguration Solution: Use DHCPv4-style reconfiguration; include multicast reconfiguration with no reliability guarantees WG discussion: When using multicast reconfigure, should reconfigure message be multicast once or more than once. If the server has a list of the clients it is trying to reconfigure, the server can manage retransmission for reliability. However, if the clients are not using DHCP for address assignment (i.e., using DHCPINFORM-like function), server may not have a list of clients. In any event, clients must be able to detect duplicates and respond (or not respond) appropriately. To mitigate "multicast implosion" due to synchronized responses to multicast reconfigure messages, Erik Nordmark suggested including delay parameters in the reconfigure message. This new parameter would specify a random delay to be used by clients to spread out the responses sent to the server. Issue: Authentication Solution: Use DHCPv4-style authentication framework Issue: Relay agents function (carried forward from BOOTP) is cumbersome Solution: Use encapsulation, in which client message is carried as payload in relay agent message Issue: Clients unicast some messages and multicast others (on local link) Solution: Clients multicast Solicit and Request messages; are not required to explicitly learn of relay agents WG discussion: Consider control from server to require client to multicast all messages, which would enable relay agents to examine all client messages. Draft will be left as is; if all-multicast mode is desired, text will be drafted and added to the spec before last call Issue: Avoid stateful server operation so that correct server operation does not depend on XID Solution: Redefined message exchanges so that server always returns same reply to retransmitted client message Details of -16 Rev of Spec I-D * Implemented solutions from 8/32 teleconference * Published just before I-D cutoff * Lots of typos; report them off-line to rdroms@cisco.com There was another teleconference of 12/5 to discuss the 16 rev of the protocol spec. The following people participated in the 12/5 teleconference: Michael Carney, Jim Bound, Bernie Volz, Thomas Narten, Ted Lemon, Ralph Droms, Mark Stapp, Kim Kinnear, Matt Williamson, Mike Dooley, Vijaya Bhaskar Here is a list of issues and resolutions from the 12/5 teleconference; again with any WG discussion or outstanding issues: Issue: Definition of label for IA Solution: Define UUID - "Universally Unique IDentifier" for each client; client assigns label to each IA: (UUID, binding-id) Outstanding issues: How is UUID defined? How does server use UUID to identify an IA? Volz suggested the identifier should be called DUID - "DHCP Unique IDentifier". More discussion deferred to end of WG meeting. Issue: Should Advertise message include addresses and configuration parameters from server? Solution: Yes WG discussion: Jim Bound asked if DHCPv4 semantics, in which server must mark offered address for later assignment to the client, must be adhered to. Droms believes this is an implementation issue not specified in the DHCPv4 spec. Kinnear suggested that if the client explicitly wants the addresses from the Advertise message, there should be an option through which it can request those addresses. Issue: What additional options should be included in base protocol spec or in separate doc? Solution: - Base spec: Status code, DHCP operational parameters (timeouts, etc.) - Separate doc: DNS name, DNS search order, DNS servers, client class, vendor class, TFTP server, boot file name, static routes Outstanding issues: Base spec or separate doc? Others options? WG discussion: Kinnear suggested that the base spec doc should include a definition of standard data types for use in future options. Droms said he would put framework and data types for option definitions in base spec. Kinnear suggested relay agent option numbers should come from the same number space as client option numbers. There was some discussion about this suggestion but no consensus about a resolution. Issue: Should client be allowed to include requested or preferred option values in Solicit message? Solution: Yes. WG discussion: Lemon wants to allow clients to request specific options but not values for those options. Richard Jones suggested placing general prohibition on requesting specific values but allowing exceptions for individual options, to be specified in option spec. Lemon also suggested that option specs should clearly articulate what it means when a client and a server sends the option. Issue: What about DDNS-DHCP interaction? Solution: Apply current specs to DHCPv6 as well; not required for base spec Outstanding issues: Is the current spec adequate; what options are needed? WG discussion: Mark Stapp will be asked to extend current DDNS-DHCP interaction docs for DHCPv6. Issue: Is merging DHCPDECLINE function from DHCPv4 into Release message a good idea? Solution: No; define new Decline message Issue: Does a DHCPv6 server need to differentiate between Request messages sent by client when initializing, confirming and extending address lifetimes? Solution: Yes; define different messages for each situation Issue: What if there is more than one relay agent on a link and the client receives multiple responses? Solution: Make sure DHCPv4 operation is carried forward Issue: Through what mechanism should an application communicate with the server? Solution: TBD WG discussion: There was an inquiry about whether the base spec should mention and API; no action for now Issue: What authentication mechanisms need to be defined in base protocol spec? Solution: Define authentication framework like DHCPv4; define one mandatory authentication protocol (e.g., DHCPv4 HMAC/shared-secret unless we can come up with something better) WG discussion: In an IETF security briefing (previous day) Jeff Schiller said HMAC/shared-secret is good enough; check with security experts for something better. WG discussion after review of -16 rev issues: * Milestones/timeline TBD to get to last call before next WG meeting (Minneapolis); see below for final schedule * Thomas Narten raised issue of server control of DHCP operational parameters (retransmit times, delays, etc.). These parameters are likely to be stale when a client moves to a new link, before the client receives an update from the local server. How should client react - revert to defaults on a new link? If so, how are these parameters useful, especially in highly mobile environments. More discussion required on mailing list. * Narten also raised issue of interaction between DHCP and temporary addresses. DHCP server can provide temporary addresses by assigning addresses with short lifetimes. However, there will be an API through which an application can request a temporary address. How can the DHCP server indicate to the client which addresses are to be "temporary" and which are "permanent"? Narten thinks IESG will bounce anything that doesn't deal with temporary addresses. He will develop requirements doc so WG can develop solution. * IA identification in draft is based on tuple (UUID, binding-id). WG must develop rules for generating guaranteed unique UUID and whether server should also include link prefix with IA identifier. Lemon summarized his thoughts on generating UUID and will write a draft. Lemon will also write up requirements for UUID. Narten said UUIDs are in use elsewhere and we should research those other UUIDs. Discussion on IA identification will continue on WG mailing list. New schedule: Continue discussion of outstanding issues now Rev -17 of spec 1/31/2001 Teleconference 2/12/2001 Rev -18 of spec (if necessary) or last call 2/28/2001 WG review or last call Minneapolis 3/xx/2001 From owner-dhcp-v6@bucknell.edu Sun Jan 7 21:41:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA11998; Sun, 7 Jan 2001 21:41:35 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f082cM902339; Sun, 7 Jan 2001 21:38:22 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f082c9914719 for ; Sun, 7 Jan 2001 21:38:09 -0500 (EST) Received: from rdroms-nt.cisco.com (rtp-dial-2-244.cisco.com [10.83.96.244]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA01011; Sun, 7 Jan 2001 21:37:39 -0500 (EST) Message-Id: <4.3.1.2.20010107121831.00bd3c40@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Sun, 07 Jan 2001 12:23:48 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Minutes from DHC WG meetings in San Diego (REMINDER!!) Cc: "Matthew Williamson" , "Stephen Bensley" , DHCPv6 discussion list In-Reply-To: <78B1387745A15C46A7A727F2670D4A681B655D@DF-MILO.platinum.co rp.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 11:59 AM 1/5/01 -0800, Thirumalesh Bhat wrote: >Would it make sense to >combine multicast address allocation with generic IPv6 address >allocation? The WG chose not to include multicast address allocation in DHCPv4 because it seemed different enough from unicast allocation to warrant an independent protocol. We can certainly review multicast address allocation in DHCPv6 - a good place to start would be a mailing list discussion... - Ralph From owner-dhcp-v4@bucknell.edu Tue Jan 9 14:10:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA19820 for ; Tue, 9 Jan 2001 14:10:50 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f09J40911863; Tue, 9 Jan 2001 14:04:01 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f09J3p929181 for ; Tue, 9 Jan 2001 14:03:51 -0500 (EST) Received: from kkinnear-nt ([10.83.81.172]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA15319; Tue, 9 Jan 2001 14:03:33 -0500 (EST) Message-Id: <4.2.0.58.20010109135519.031f0e20@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 09 Jan 2001 14:03:21 -0500 To: DHCPv4 discussion list From: Kim Kinnear Subject: Cisco's current version of leasequery message Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: kkinnear@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Folks, One of the action items I took away with me from San Deigo IETF concerned the LEASEQUERY message/draft. We (Cisco) have implemented something essentially similar to the current leasequery draft in shipping hardware and software -- but the correspondence to the latest leasequery draft is growing less and less as the draft itself evolves. Ultimately we will bring our implementation back into conformance with the draft/RFC, but we will wait until the rate of change lessens. Ted Lemon asked me in the DHC WG meeting if I would circulate information as to what the Cisco hardware and software currently in the field does concerning leasequery. I said yes, so here it is. The following URL is a link to an appendix of a Cisco manual where the current approach we use is explained with moderate (though not extreme) clarity: http://www.cisco.com /univercd/cc/td/doc/product/rtrmgmt/ciscoasu/nr/nr50/cliref/clie.htm Cheers - Kim From owner-dhcp-v6@bucknell.edu Thu Jan 11 10:31:19 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03907; Thu, 11 Jan 2001 10:31:19 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0BFOI927112; Thu, 11 Jan 2001 10:24:18 -0500 (EST) Received: from mgw-x1.nokia.com (mgw-x1.nokia.com [131.228.20.21]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0BFO7929158 for ; Thu, 11 Jan 2001 10:24:07 -0500 (EST) Received: from esvir03nok.nokia.com (esvir03nokt.ntc.nokia.com [172.21.143.35]) by mgw-x1.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0BFNs301876 for ; Thu, 11 Jan 2001 17:23:54 +0200 (EET) Received: from esebh12nok.ntc.nokia.com (unverified) by esvir03nok.nokia.com (Content Technologies SMTPRS 4.1.2) with ESMTP id for ; Thu, 11 Jan 2001 17:24:05 +0200 Received: by esebh12nok with Internet Mail Service (5.5.2652.78) id ; Thu, 11 Jan 2001 17:23:02 +0200 Message-ID: From: patrik.flykt@nokia.com To: DHCPv6 discussion list Subject: RE: -16 rev of DHCPv6 spec Date: Thu, 11 Jan 2001 17:22:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hello all, In 9.9 and 9.10 of the -16 draft the DHCPv6 relay message headers and the option headers align on a 16 bit boundary. Could two octets be inserted between the prefix-length field and the relay address field in order to align the relay address field and the options on 4 octet (32 bit) boundaries? I'm thinking of making the implementation easier by casting the DHCPv6 message forwarded by the relay to something like: struct relay_fwd_msg { char msg-type; char prefix_len; struct in6_addr; int *opts; } - Patrik Flykt From owner-dhcp-v4@bucknell.edu Thu Jan 11 12:26:57 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09466 for ; Thu, 11 Jan 2001 12:26:57 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0BHK8926353; Thu, 11 Jan 2001 12:20:08 -0500 (EST) Received: from zcamail03.zca.compaq.com (zcamail03.zca.compaq.com [161.114.32.103]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0BHJv917733 for ; Thu, 11 Jan 2001 12:19:57 -0500 (EST) Received: by zcamail03.zca.compaq.com (Postfix, from userid 12345) id 20FFDE89; Thu, 11 Jan 2001 09:19:40 -0800 (PST) Received: from exccup-gh01.mis.tandem.com (exccup-gh01.mis.tandem.com [130.252.226.241]) by zcamail03.zca.compaq.com (Postfix) with ESMTP id 1A8FEE29 for ; Thu, 11 Jan 2001 09:19:40 -0800 (PST) Received: by exccup-gh01.mis.tandem.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 09:19:41 -0800 Message-ID: <2BAEE918EF6CD1118FA800805F57F12E0A54E990@excaus-11601.txn.cpqcorp.net> From: "Manpuria, Aditya" To: DHCPv4 discussion list Subject: DHCPprotocol conformance Date: Thu, 11 Jan 2001 09:19:40 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Aditya.Manpuria@compaq.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi, Do we have any test suites available for testing protocol compliance of DHCP clients/servers. Any pointers ??? Thanks and regards, Aditya. From owner-dhcp-v4@bucknell.edu Thu Jan 11 13:25:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11774 for ; Thu, 11 Jan 2001 13:25:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0BIJw914128; Thu, 11 Jan 2001 13:19:58 -0500 (EST) Received: from blaze.hcltech.com (IDENT:root@[203.199.199.225]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0BIJf928137 for ; Thu, 11 Jan 2001 13:19:42 -0500 (EST) Received: from nahar.netlab.hcltech.com (nahar [192.168.201.35]) by blaze.hcltech.com (8.9.3/8.8.7) with ESMTP id XAA27555 for ; Thu, 11 Jan 2001 23:25:36 +0530 Message-Id: <5.0.2.1.0.20010111231607.00a085d0@192.168.201.1> X-Sender: vknahar@192.168.201.1 X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Thu, 11 Jan 2001 23:17:38 +0530 To: DHCPv4 discussion list From: Virendra K Nahar Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_195862838==_.ALT" Reply-To: vknahar@netlab.hcltech.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --=====================_195862838==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed hi can any one send me some good docs on direct data link access for my client implementation i need some thing on linux packet filters or BPF pls reply asap. Virendra Nahar Member Technical Staff HCL Technologies Ltd Networking Systems Lab 51-JN Road Chennai -97 Ph-2334181 email:vknahar@netlab.hcltech.com --=====================_195862838==_.ALT Content-Type: text/html; charset="us-ascii" hi
can any one send me some good docs on direct data link access for my client implementation
i need some thing on linux packet filters or BPF pls reply asap.

Virendra Nahar
Member Technical Staff
HCL Technologies Ltd
Networking Systems Lab
51-JN Road
Chennai -97
Ph-2334181
email:vknahar@netlab.hcltech.com --=====================_195862838==_.ALT-- From owner-dhcp-v6@bucknell.edu Thu Jan 11 15:25:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13929; Thu, 11 Jan 2001 15:25:32 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0BKMF901807; Thu, 11 Jan 2001 15:22:15 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0BKMA913732; Thu, 11 Jan 2001 15:22:10 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07007; Thu, 11 Jan 2001 12:21:57 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA27792; Thu, 11 Jan 2001 12:21:53 -0800 (PST) Message-Id: <4.3.1.2.20010111090731.00bed7e0@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 11 Jan 2001 15:22:00 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Meetings during 50th IETF in Minneapolis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm about to submit a request for meeting slots for the DHC WG in Minneapolis. I expect we will meet twice - once for DHCPv4 and once for DHCPv6. If you have any specific conflicts with other WGs that you would like to avoid, please let me know. - Ralph From owner-dhcp-v4@bucknell.edu Thu Jan 11 15:28:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13996 for ; Thu, 11 Jan 2001 15:28:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0BKMF919040; Thu, 11 Jan 2001 15:22:15 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0BKMA913732; Thu, 11 Jan 2001 15:22:10 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA07007; Thu, 11 Jan 2001 12:21:57 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id MAA27792; Thu, 11 Jan 2001 12:21:53 -0800 (PST) Message-Id: <4.3.1.2.20010111090731.00bed7e0@funnel.cisco.com> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Thu, 11 Jan 2001 15:22:00 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Meetings during 50th IETF in Minneapolis Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm about to submit a request for meeting slots for the DHC WG in Minneapolis. I expect we will meet twice - once for DHCPv4 and once for DHCPv6. If you have any specific conflicts with other WGs that you would like to avoid, please let me know. - Ralph From owner-dhcp-v6@bucknell.edu Thu Jan 11 20:26:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA17225; Thu, 11 Jan 2001 20:26:52 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0C1O8900310; Thu, 11 Jan 2001 20:24:08 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0C1O0901360 for ; Thu, 11 Jan 2001 20:24:01 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 11 Jan 2001 20:23:45 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE86036075D6@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: Meetings during 50th IETF in Minneapolis Date: Thu, 11 Jan 2001 20:23:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ralph: Considering that we're trying to close on DHCPv6 about the time of this meeting, might it be worth while considering two sessions for DHCPv6 to assure we have sufficient time to discuss issues? I guess at worst we can always cancel the 2nd meeting if not needed (though it might waste a valuable time slot). - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, January 11, 2001 3:22 PM To: DHCPv6 discussion list Subject: Meetings during 50th IETF in Minneapolis I'm about to submit a request for meeting slots for the DHC WG in Minneapolis. I expect we will meet twice - once for DHCPv4 and once for DHCPv6. If you have any specific conflicts with other WGs that you would like to avoid, please let me know. - Ralph From owner-dhcp-v6@bucknell.edu Thu Jan 11 22:12:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA18926; Thu, 11 Jan 2001 22:12:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0C397905169; Thu, 11 Jan 2001 22:09:07 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0C391903505 for ; Thu, 11 Jan 2001 22:09:01 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f0C37cu01296 for ; Thu, 11 Jan 2001 22:07:38 -0500 Message-Id: <200101120307.f0C37cu01296@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: Meetings during 50th IETF in Minneapolis In-Reply-To: Message from Bernie Volz of "Thu, 11 Jan 2001 20:23:34 EST." <63D30D6E10CFD11190A90000F805FE86036075D6@lespaul.process.com> Date: Thu, 11 Jan 2001 22:07:38 -0500 From: Thomas Narten Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Considering that we're trying to close on DHCPv6 about the time of this > meeting, might it be worth while considering two sessions for DHCPv6 to > assure we have sufficient time to discuss issues? I guess at worst we can > always cancel the 2nd meeting if not needed (though it might waste a > valuable time slot). At the SD IETF, all slots were used and some requests for meeting slots were turned away. I don't expect the situation to get better anytime soon. :-( Getting 3 slots for DHCP just won't happen. Thomas From owner-dhcp-v6@bucknell.edu Thu Jan 11 23:37:20 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA21785; Thu, 11 Jan 2001 23:37:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0C4YY911125; Thu, 11 Jan 2001 23:34:34 -0500 (EST) Received: from mail.users.bit-net.com (www.bit-net.com [208.146.132.4]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0C4YX916368 for ; Thu, 11 Jan 2001 23:34:33 -0500 (EST) Received: from localhost by mail.users.bit-net.com; (5.65v3.2/1.1.8.2/30Jul96-0143PM) id AB08480; Thu, 11 Jan 2001 23:34:32 -0500 Date: Thu, 11 Jan 2001 23:34:32 -0500 (EST) From: Jim Bound To: DHCPv6 discussion list Subject: Re: Meetings during 50th IETF in Minneapolis In-Reply-To: <200101120307.f0C37cu01296@hygro.adsl.duke.edu> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Another option is to try to find a night when nothing is happening. There are lots of non-formal meetings going on. I used these for BIND V9 stuff a few years ago at meetings and it worked. I think Bernie has a good point if we can figure it out. /jim On Thu, 11 Jan 2001, Thomas Narten wrote: > > Considering that we're trying to close on DHCPv6 about the time of this > > meeting, might it be worth while considering two sessions for DHCPv6 to > > assure we have sufficient time to discuss issues? I guess at worst we can > > always cancel the 2nd meeting if not needed (though it might waste a > > valuable time slot). > > At the SD IETF, all slots were used and some requests for meeting > slots were turned away. I don't expect the situation to get better > anytime soon. :-( > > Getting 3 slots for DHCP just won't happen. > > Thomas > From owner-dhcp-v6@bucknell.edu Fri Jan 12 07:07:55 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07129; Fri, 12 Jan 2001 07:07:55 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0CC4q900774; Fri, 12 Jan 2001 07:04:52 -0500 (EST) Received: from hygro.adsl.duke.edu (IDENT:root@cichlid.adsl.duke.edu [152.16.64.203]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0CC4l923534 for ; Fri, 12 Jan 2001 07:04:47 -0500 (EST) Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.0/8.9.3) with ESMTP id f0CC3MA03042 for ; Fri, 12 Jan 2001 07:03:22 -0500 Message-Id: <200101121203.f0CC3MA03042@hygro.adsl.duke.edu> To: DHCPv6 discussion list Subject: Re: Meetings during 50th IETF in Minneapolis In-Reply-To: Message from Jim Bound of "Thu, 11 Jan 2001 23:34:32 EST." Date: Fri, 12 Jan 2001 07:03:22 -0500 From: Thomas Narten Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Another option is to try to find a night when nothing is happening. Good luck. :-) Actually, meeting informally during the week of course can be done. But I'm also wondering why more than 2 hours of face-to-face time is needed *in Minneapolis*. I've been assuming that with all the recent progress that more stuff would be worked out before Minneapolis, with even fewer open items still in place then. I'd rather see more emphasis on working more out sooner. Thomas From owner-dhcp-v6@bucknell.edu Fri Jan 12 07:21:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07388; Fri, 12 Jan 2001 07:21:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0CCKA903709; Fri, 12 Jan 2001 07:20:11 -0500 (EST) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0CCK0921067 for ; Fri, 12 Jan 2001 07:20:00 -0500 (EST) Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id EAA16286 for ; Fri, 12 Jan 2001 04:19:46 -0800 (PST) Received: from rdroms-nt.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id EAA07023 for ; Fri, 12 Jan 2001 04:19:43 -0800 (PST) Message-Id: <4.3.1.2.20010112071540.00b1c100@mail.bucknell.edu> X-Sender: rdroms@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 12 Jan 2001 07:19:54 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Meetings during 50th IETF in Minneapolis In-Reply-To: <200101121203.f0CC3MA03042@hygro.adsl.duke.edu> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Speaking as draft editor and WG chair, I expect the Minneapolis DHCPv6 meeting to go much like the San Diego meeting - we will be confirming WG consensus on changes to the draft since the San Diego meeting. My expectation is to have come to resolution of remaining issues - through the mailing list and one or two design team teleconferences - prior to meeting in Minneapolis. - Ralph At 07:03 AM 1/12/01 -0500, you wrote: >Actually, meeting informally during the week of course can be >done. But I'm also wondering why more than 2 hours of face-to-face >time is needed *in Minneapolis*. From owner-dhcp-v4@bucknell.edu Fri Jan 19 17:49:43 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07537 for ; Fri, 19 Jan 2001 17:49:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0JMhO917891; Fri, 19 Jan 2001 17:43:24 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0JMhD903201 for ; Fri, 19 Jan 2001 17:43:13 -0500 (EST) Received: from rdroms-nt.cisco.com (ch2-dhcp133-188.cisco.com [161.44.133.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21867 for ; Fri, 19 Jan 2001 17:42:56 -0500 (EST) Message-Id: <4.3.1.2.20010119173316.00c33510@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Fri, 19 Jan 2001 17:43:08 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: draft-ietf-sip-dhcp-02.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The SIP WG has asked the DHC WG for input on "DHCP Option for SIP Servers", . Please review this draft (it's less than four pages!) and post any comments to this mailing list before 1/24 (next Wednesday). Thanks... - Ralph From owner-dhcp-v6@bucknell.edu Sat Jan 20 02:52:05 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26058; Sat, 20 Jan 2001 02:52:05 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0K7nD915263; Sat, 20 Jan 2001 02:49:14 -0500 (EST) Received: from atlrel1.hp.com (atlrel1.hp.com [156.153.255.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0K7n0915010 for ; Sat, 20 Jan 2001 02:49:00 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by atlrel1.hp.com (Postfix) with ESMTP id B7FD82AD for ; Sat, 20 Jan 2001 02:48:58 -0500 (EST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id NAA04612 for dhcp-v6@bucknell.edu; Sat, 20 Jan 2001 13:20:50 +0530 (IST) From: Vijaya Bhaskar A K Message-Id: <200101200750.NAA04612@dce.india.hp.com> Subject: question on sending request to multiple servers To: DHCPv6 discussion list Date: Sat, 20 Jan 2001 13:20:50 +0530 (IST) X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit It is mentioned in the draft that at the expiration of T2, the client initiates the request/reply message exchange. This request message will be sent to a multicast address. i have few questions on this. 1) Is this the request for assignment of a new ip-address to an IA? (OR) 2) renewal of the a particular ip-address assigned to an IA? case 1) Since this is a multicast message, more than server can assign an IP-address. This means for a single reqeust, the client gets many IP-address. case 2) assume the server A which has assigned the particular ip-address to the client is down. then, how can a server B renew the lease for the ip-address assigned by server A? So, what is the actual use of sending the request message to mutiple servers after the expiration of T2. Regards, Vijay From owner-dhcp-v4@bucknell.edu Sat Jan 20 12:48:11 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28695 for ; Sat, 20 Jan 2001 12:48:11 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0KHgu916547; Sat, 20 Jan 2001 12:42:56 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0KHgs907966 for ; Sat, 20 Jan 2001 12:42:54 -0500 (EST) Received: from grosse.bisbee.fugue.com (205-140-116-227.ip.theriver.com [205.140.116.227]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f0KHfUJ04969; Sat, 20 Jan 2001 09:41:30 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f0KHgoj01389; Sat, 20 Jan 2001 10:42:50 -0700 (MST) Message-Id: <200101201742.f0KHgoj01389@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-sip-dhcp-02.txt In-Reply-To: Message from Ralph Droms of "Fri, 19 Jan 2001 17:43:08 EST." <4.3.1.2.20010119173316.00c33510@funnel.cisco.com> Date: Sat, 20 Jan 2001 10:42:50 -0700 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN My only comment on the draft is that given the frequency with which some implementors misread drafts, it would be good to really stress that the option is in DNS encoding, not a text string (if that is the intent). This option specifies the DNS [6] string that is passed to the client. This string SHOULD be the domain name of the SIP server (rather than a textual representation of the network address). The code for this option is TBD. The length of the DNS name string is specified in `Len'. The maximum length of this string is 255 octets and minimum length is 1 octet. For example, a value may be Hm. Actually, now that I think about it, it doesn't say what I thought it said. So this is unclear - if it's supposed to be a text string, it should say so explicitly, maybe like this: The domain name SHOULD be encoded as a printable representation of a fully-qualified domain name, as described in [6]. The name MUST NOT include a NUL termination byte at the end of the string. BTW, I would actually suggest encoding the string in DNS wire format rather than in presentation format (a text string), because this is more flexible - it may be difficult to losslessly represent internationalized domain names as plain ASCII strings. This is the approach that Bernard Aboba took with the new domain name search list option, so new clients will have to be prepared to decode this format anyway. _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Jan 21 20:27:37 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA12356; Sun, 21 Jan 2001 20:27:36 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0M1L7902903; Sun, 21 Jan 2001 20:21:07 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0M1L5919959 for ; Sun, 21 Jan 2001 20:21:05 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Sun, 21 Jan 2001 20:20:49 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE860360762E@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: RE: question on sending request to multiple servers Date: Sun, 21 Jan 2001 20:20:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I believe these problems will be solved by using a different message type (number) for a renewal vs a new address request. Thus, if the packet is multicast, all of the servers will see that it is a renewal request and can respond correctly. Please note that the draft that is out today doesn't have a unique message type for initial requests, vs renewals, vs checks on boot, etc. Please see the DHC WG notes from the San Diego IETF for more details. - Bernie -----Original Message----- From: Vijaya Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Saturday, January 20, 2001 2:51 AM To: DHCPv6 discussion list Subject: question on sending request to multiple servers It is mentioned in the draft that at the expiration of T2, the client initiates the request/reply message exchange. This request message will be sent to a multicast address. i have few questions on this. 1) Is this the request for assignment of a new ip-address to an IA? (OR) 2) renewal of the a particular ip-address assigned to an IA? case 1) Since this is a multicast message, more than server can assign an IP-address. This means for a single reqeust, the client gets many IP-address. case 2) assume the server A which has assigned the particular ip-address to the client is down. then, how can a server B renew the lease for the ip-address assigned by server A? So, what is the actual use of sending the request message to mutiple servers after the expiration of T2. Regards, Vijay From owner-dhcp-v4@bucknell.edu Mon Jan 22 11:31:44 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08053 for ; Mon, 22 Jan 2001 11:31:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0MGO7929271; Mon, 22 Jan 2001 11:24:07 -0500 (EST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0MGNw905344 for ; Mon, 22 Jan 2001 11:23:58 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id LAA18926; Mon, 22 Jan 2001 11:23:38 -0500 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id LAA27238; Mon, 22 Jan 2001 11:23:40 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id LAA19433; Mon, 22 Jan 2001 11:18:45 -0500 Message-Id: <200101221618.LAA19433@rotala.raleigh.ibm.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-sip-dhcp-02.txt In-Reply-To: Message from Ted Lemon of "Sat, 20 Jan 2001 10:42:50 MST." <200101201742.f0KHgoj01389@grosse.bisbee.fugue.com> Date: Mon, 22 Jan 2001 11:18:45 -0500 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Ted, > My only comment on the draft is that given the frequency with which > some implementors misread drafts, it would be good to really stress > that the option is in DNS encoding, not a text string (if that is the > intent). What are the encodings of other DNS "strings" in other DHCP options? Seems like one would want to start there, for compatability with deployed servers. Are any of the existing options using DNS "on-the-wire" encoding, for example? Thomas From owner-dhcp-v4@bucknell.edu Mon Jan 22 11:47:44 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08383 for ; Mon, 22 Jan 2001 11:47:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0MGkO918621; Mon, 22 Jan 2001 11:46:24 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0MGkH921602 for ; Mon, 22 Jan 2001 11:46:17 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA27414 for ; Mon, 22 Jan 2001 11:46:16 -0500 (EST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3A6C63D8.459402FF@cs.columbia.edu> Date: Mon, 22 Jan 2001 11:46:16 -0500 From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: draft-ietf-sip-dhcp-02.txt Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: hgs@cs.columbia.edu X-Sender: hgs@cs.columbia.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I've tried to clarify this encoding point in -03, which is in the I-D editor queue and at http://www.cs.columbia.edu/~hgs/sip/drafts/draft-ietf-sip-dhcp-03.txt This uses the standard FQDN representation as proposed a while ago for option 89. As long as the string is treated as UTF-8 rather than ASCII, would there be issues? (I'm mainly concerned about server configuration. I doubt that any existing server can handle DNS strings without going into tedious binary mode.) Please let me know if that increases or decreases the confusion factor... -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs From owner-dhcp-v4@bucknell.edu Mon Jan 22 12:14:52 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09225 for ; Mon, 22 Jan 2001 12:14:51 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0MH8R927816; Mon, 22 Jan 2001 12:08:27 -0500 (EST) Received: from firewall.ma.virata.com (agranat.com [198.113.147.2]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0MH8O917270 for ; Mon, 22 Jan 2001 12:08:24 -0500 (EST) Received: from agranat.com (alice.agranat.com [10.21.0.130]) by firewall.ma.virata.com (8.9.0/8.9.0) with ESMTP id MAA30460 for ; Mon, 22 Jan 2001 12:08:07 -0500 Received: (from worley@localhost) by agranat.com (8.8.5/8.8.5) id MAA10171; Mon, 22 Jan 2001 12:08:06 -0500 Date: Mon, 22 Jan 2001 12:08:06 -0500 Message-Id: <200101221708.MAA10171@agranat.com> X-Authentication-Warning: alice.ma.virata.com: worley set sender to worley@alice.ma.virata.com using -f From: Dale Worley To: DHCPv4 discussion list In-reply-to: <200101201742.f0KHgoj01389@grosse.bisbee.fugue.com> (message from Ted Lemon on Sat, 20 Jan 2001 10:42:50 -0700) Subject: Re: draft-ietf-sip-dhcp-02.txt References: <200101201742.f0KHgoj01389@grosse.bisbee.fugue.com> Reply-To: worley@agranat.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN From: Ted Lemon BTW, I would actually suggest encoding the string in DNS wire format rather than in presentation format (a text string), because this is more flexible - it may be difficult to losslessly represent internationalized domain names as plain ASCII strings. You *know* that the DNS wire format is future-proof, and it will always be able to represent any valid domain name, no matter in what direction DNS evolves. If you try to represent in ASCII, or any other text format, you will have to adjust the spec every time the space of domain names changes. Dale -- Dale R. WORLEY Project Manager - UPnP Virata Corp. Applications Infrastructure http://emweb.com From owner-dhcp-v6@bucknell.edu Mon Jan 22 13:52:56 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA11708; Mon, 22 Jan 2001 13:52:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0MIjU928124; Mon, 22 Jan 2001 13:45:30 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0MIjK905373 for ; Mon, 22 Jan 2001 13:45:20 -0500 (EST) Received: from rdroms-nt.bucknell.edu (sjck-dial-gw5-63.cisco.com [10.19.238.64]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA15439; Mon, 22 Jan 2001 13:45:01 -0500 (EST) Message-Id: <4.3.1.2.20010122111301.00c3f9b0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Mon, 22 Jan 2001 11:15:44 -0500 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: question on sending request to multiple servers In-Reply-To: <200101200750.NAA04612@dce.india.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 01:20 PM 1/20/01 +0530, Vijaya Bhaskar A K wrote: >1) Is this the request for assignment of a new ip-address to an IA? >(OR) >2) renewal of the a particular ip-address assigned to an IA? The request at time T2 will be case 2. So, it's OK if multiple servers respond (ignoring the problem of different lifetimes from different servers). Other requests - e.g, the request at T1 - will be case 1. - Ralph From owner-dhcp-v4@bucknell.edu Mon Jan 22 20:51:35 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18916 for ; Mon, 22 Jan 2001 20:51:34 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0N1iH909345; Mon, 22 Jan 2001 20:44:17 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0N1iA908685 for ; Mon, 22 Jan 2001 20:44:11 -0500 (EST) Received: from grosse.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.0/8.6.11) with ESMTP id f0N1ggJ10194; Mon, 22 Jan 2001 17:42:43 -0800 (PST) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.0/8.6.11) with ESMTP id f0MLhh300384; Mon, 22 Jan 2001 14:43:43 -0700 (MST) Message-Id: <200101222143.f0MLhh300384@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-sip-dhcp-02.txt In-Reply-To: Message from Thomas Narten of "Mon, 22 Jan 2001 11:18:45 EST." <200101221618.LAA19433@rotala.raleigh.ibm.com> Date: Mon, 22 Jan 2001 15:43:43 -0600 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > What are the encodings of other DNS "strings" in other DHCP options? > Seems like one would want to start there, for compatability with > deployed servers. Are any of the existing options using DNS > "on-the-wire" encoding, for example? The fqdn option does. The proposed domain name search list option does. I don't see that "compatibility" in this case is particularly valuable - what makes you say that it is? _MelloN_ From owner-dhcp-v4@bucknell.edu Tue Jan 23 10:49:16 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15631 for ; Tue, 23 Jan 2001 10:49:15 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0NFhX923608; Tue, 23 Jan 2001 10:43:33 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0NFhL919287 for ; Tue, 23 Jan 2001 10:43:21 -0500 (EST) Received: from rdroms-nt.cisco.com (sjck-dial-gw5-54.cisco.com [10.19.238.55]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA16247 for ; Tue, 23 Jan 2001 10:42:58 -0500 (EST) Message-Id: <4.3.1.2.20010123104051.00c537d0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 23 Jan 2001 10:42:52 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Fwd: I-D ACTION:draft-ietf-sip-dhcp-03.txt Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN FYI - a new version of the "DHCP option for SIP Servers" draft has been published. If you have comments, please post them to the mailing list by 5PM EST, 1/24. - Ralph >To: IETF-Announce:; >Cc: sip@lists.bell-labs.com >From: Internet-Drafts@ietf.org >Reply-to: Internet-Drafts@ietf.org >Subject: I-D ACTION:draft-ietf-sip-dhcp-03.txt >Date: Tue, 23 Jan 2001 07:34:38 -0500 >Sender: nsyracus@cnri.reston.va.us > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the Session Initiation Protocol Working Group >of the IETF. > > Title : DHCP Option for SIP Servers > Author(s) : G. Nair, H. Schulzrinne > Filename : draft-ietf-sip-dhcp-03.txt > Pages : 4 > Date : 22-Jan-01 > >This document defines a DHCP option that contains a single name that >can be mapped to one or more SIP outbound proxy servers. This is one >of the many methods that a SIP client can use to obtain the addresses >of such a local SIP server. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-sip-dhcp-03.txt > >Internet-Drafts are also available by anonymous FTP. Login with the username >"anonymous" and a password of your e-mail address. After logging in, >type "cd internet-drafts" and then > "get draft-ietf-sip-dhcp-03.txt". > >A list of Internet-Drafts directories can be found in >http://www.ietf.org/shadow.html >or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > >Internet-Drafts can also be obtained by e-mail. > >Send a message to: > mailserv@ietf.org. >In the body type: > "FILE /internet-drafts/draft-ietf-sip-dhcp-03.txt". > >NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. >Content-Type: text/plain >Content-ID: <20010122143536.I-D@ietf.org> > >ENCODING mime >FILE /internet-drafts/draft-ietf-sip-dhcp-03.txt > > From owner-dhcp-v4@bucknell.edu Tue Jan 23 12:14:40 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18174 for ; Tue, 23 Jan 2001 12:14:40 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0NH6M929883; Tue, 23 Jan 2001 12:06:22 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0NH68920867 for ; Tue, 23 Jan 2001 12:06:08 -0500 (EST) Received: from rdroms-nt.cisco.com (sjck-dial-gw5-191.cisco.com [10.19.238.192]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA28494; Tue, 23 Jan 2001 12:05:47 -0500 (EST) Message-Id: <4.3.1.2.20010123113319.00c5ac00@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.1 Date: Tue, 23 Jan 2001 12:05:58 -0500 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Fwd: I-D ACTION:draft-ietf-sip-dhcp-03.txt Cc: "Henning G. Schulzrinne" , =?iso-8859-1?Q?=22Patrik_F=E4ltstr=F6m=22?= , Allison Mankin , gnair@ober.cs.columbia.edu, dwillis@dynamicsoft.com, brosen@eng.fore.com, sob@harvard.edu In-Reply-To: <4.3.1.2.20010123104051.00c537d0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >3 SIP server DHCP options > > The SIP client obtains a DNS [6] full-qualified domain name (FQDN) > via a DHCP option. This FQDN is then used by the mechanism described > in [3] to locate the outbound proxy server. In summary, the domain > name encoded in the string is used first in a DNS SRV lookup and, if > that fails because of a lack of matching DNS SRV records, in an > address record lookup. Normative details are contained in [3]. The encoding technique needs to be more explicitly defined. Is it a string of 7-bit ASCII characters, is it null-terminated, is it RFC1035 encoded? The specifications for some earlier DHCP options have not been entirely explicit, which has led to interoperability problems. Later options have been more carefully specified; e.g., in RFC2241: >3. NDS Tree Name Option > > This option specifies the name of the NDS tree the client will be > contacting. NDS tree names are 16-bit Unicode strings. For > transmission in the NDS Tree Name Option, an NDS tree name is > transformed into octets using UTF-8. The string should NOT be zero > terminated. The only (standard status) options that use domain names are 15 (domain name) and 12 (host name). Both of these options are carried over to DHCP from BOOTP (RFC1497). Bernard Aboba's "DHCP Domain Search Option" specifies RFC1035 encoding of domain names. I would recommend using RFC1035 encoding. > It is possible, but NOT RECOMMENDED that the string is the textual > representation of a network address, e.g., a "dotted quad" for IPv4 > and the hexadecimal representation of RFC 2373 [7]. I would recommend against simply overloading text representation of IP addresses because of potential confusion. If you really want to allow use of IP addresses, how about names from the inverse DNS domains? >4 Security Consideration > > There are no security considerations beyond those described in RFC > 2132, RFC 2543 [2] and RFC XXX [3]. The DHCP security considerations are in RFC2131. - Ralph From owner-dhcp-v4@bucknell.edu Tue Jan 23 13:17:13 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20032 for ; Tue, 23 Jan 2001 13:17:13 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0NI83905127; Tue, 23 Jan 2001 13:08:03 -0500 (EST) Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0NI7Y931454 for ; Tue, 23 Jan 2001 13:07:34 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA12628; Tue, 23 Jan 2001 13:07:26 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA14846; Tue, 23 Jan 2001 13:07:23 -0500 (EST) Message-ID: <3A6DF382.83146843@cs.columbia.edu> Date: Tue, 23 Jan 2001 13:11:30 -0800 From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list , "Patrik =?iso-8859-1?Q?F=E4ltstr=F6m?=" , Allison Mankin , gnair@ober.cs.columbia.edu, dwillis@dynamicsoft.com, brosen@eng.fore.com, sob@harvard.edu Subject: Re: Fwd: I-D ACTION:draft-ietf-sip-dhcp-03.txt References: <4.3.1.2.20010123113319.00c5ac00@mail.bucknell.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: hgs@cs.columbia.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Ralph Droms wrote: > > The encoding technique needs to be more explicitly defined. Is it a string > of 7-bit ASCII characters, is it null-terminated, is it RFC1035 > encoded? The specifications for some earlier DHCP options have not been > entirely explicit, which has led to interoperability problems. Later > options have been more carefully specified; e.g., in RFC2241: > > >3. NDS Tree Name Option > > > > This option specifies the name of the NDS tree the client will be > > contacting. NDS tree names are 16-bit Unicode strings. For > > transmission in the NDS Tree Name Option, an NDS tree name is > > transformed into octets using UTF-8. The string should NOT be zero > > terminated. > > The only (standard status) options that use domain names are 15 (domain > name) and 12 (host name). Both of these options are carried over to DHCP > from BOOTP (RFC1497). Bernard Aboba's "DHCP Domain Search Option" > specifies RFC1035 encoding of domain > names. I would recommend using RFC1035 encoding. > I'm still not sure why RFC1035, compared to UTF-8. Even with RFC1035, you need to specify what the bytes mean, since RFC 1035 doesn't say: For all parts of the DNS that are part of the official protocol, all comparisons between character strings (e.g., labels, domain names, etc.) are done in a case-insensitive manner. At present, this rule is in force throughout the domain system without exception. However, future additions beyond current usage may need to use the full binary octet capabilities in names, so attempts to store domain names in 7-bit ASCII or use of special bytes to terminate labels, etc., should be avoided. Thus, I'm not sure why label\Llabel\L (where \L is the length) is any better than label.label. Assuming that 'label' is binary/UTF-8. All I know is that none of the current DHCP servers will work with RFC 1035 encoding without using hex encoding, which is awful. > > It is possible, but NOT RECOMMENDED that the string is the textual > > representation of a network address, e.g., a "dotted quad" for IPv4 > > and the hexadecimal representation of RFC 2373 [7]. > > I would recommend against simply overloading text representation of IP > addresses because of potential confusion. If you really want to allow use > of IP addresses, how about names from the inverse DNS domains? I'm open to suggestions, but using in-addr.arpa for this seems a bit odd. We definitely need this, though. > > >4 Security Consideration > > > > There are no security considerations beyond those described in RFC > > 2132, RFC 2543 [2] and RFC XXX [3]. > > The DHCP security considerations are in RFC2131. Fixed. > > - Ralph From owner-dhcp-v6@bucknell.edu Thu Jan 25 21:45:10 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14566; Thu, 25 Jan 2001 21:45:08 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0Q2f6916810; Thu, 25 Jan 2001 21:41:06 -0500 (EST) Received: from lespaul.process.com (lespaul.process.com [192.42.95.27]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0Q2es900846 for ; Thu, 25 Jan 2001 21:40:54 -0500 (EST) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Thu, 25 Jan 2001 21:40:38 -0500 Message-ID: <63D30D6E10CFD11190A90000F805FE8603607697@lespaul.process.com> From: Bernie Volz To: DHCPv6 discussion list Subject: DHCPv6 and DSTM (Dual Stack Transition Mechanism) Date: Thu, 25 Jan 2001 21:40:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Jim Bound, et al, Jim ... have you considered the impact of the DHCPv6 changes to draft-ietf-ngtrans-dstm-03.txt? Are there capabilities we need to include or modify with the revised DHCPv6 specification to accommodate DSTM needs? I haven't studied the DSTM specification carefully, but did notice it used and modified DHCPv6 somewhat. It doesn't appear that the capabilities required would be that difficult to include. Of course, you'll have to revise the DSTM draft. I'm also wondering if there are other drafts out there that add to or modify DHCPv6 behavoir that should be reviewed. We might either want to pull the functionality into the DHCPv6 specification directly (though at this time more work is likely not desireable) or at least alert the authors of those drafts that DHCPv6 is changing and they'll need to revise their drafts (hopefully they are monitoring the work and providing input). - Bernie Volz Ericsson From owner-dhcp-v6@bucknell.edu Thu Jan 25 21:53:08 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA14659; Thu, 25 Jan 2001 21:53:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0Q2q6924784; Thu, 25 Jan 2001 21:52:06 -0500 (EST) Received: from mgw-dax1.ext.nokia.com (mgw-dax1.ext.nokia.com [63.78.179.216]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0Q2q0929213 for ; Thu, 25 Jan 2001 21:52:01 -0500 (EST) Received: from davir03nok.americas.nokia.com (davir03nok.americas.nokia.com [172.18.242.86]) by mgw-dax1.ext.nokia.com (Switch-2.1.0/Switch-2.1.0) with ESMTP id f0Q2q1R27353 for ; Thu, 25 Jan 2001 20:52:01 -0600 (CST) Received: from daebh01nok.americas.nokia.com (unverified) by davir03nok.americas.nokia.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 25 Jan 2001 20:51:59 -0600 Received: by daebh01nok with Internet Mail Service (5.5.2652.78) id ; Thu, 25 Jan 2001 20:46:58 -0600 Message-ID: From: Jim.Bound@nokia.com To: DHCPv6 discussion list Subject: RE: DHCPv6 and DSTM (Dual Stack Transition Mechanism) Date: Thu, 25 Jan 2001 20:42:24 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.78) Content-Type: text/plain; charset="iso-8859-1" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi Bernie, Yes the draft has been completely modified to support our new model (the dhcpv6 option part. We want to put it in the base its just an option we need. I will posting a new DSTM draft to the IETF this weekend. Ralph and Mike have it and have thenew option. I don't want to send the draft now as edits and authors are just tiding it up. The NGTRANS group needs an IANA op-type for this option as this draft will go to PS in NGTRANS and is referenced by other transition mechanisms. regards, /jim > -----Original Message----- > From: ext Bernie Volz [mailto:Volz@ipworks.com] > Sent: Thursday, January 25, 2001 9:41 PM > To: DHCPv6 discussion list > Subject: DHCPv6 and DSTM (Dual Stack Transition Mechanism) > > > Jim Bound, et al, > > Jim ... have you considered the impact of the DHCPv6 changes to > draft-ietf-ngtrans-dstm-03.txt? Are there capabilities we > need to include or > modify with the revised DHCPv6 specification to accommodate > DSTM needs? > > I haven't studied the DSTM specification carefully, but did > notice it used > and modified DHCPv6 somewhat. It doesn't appear that the capabilities > required would be that difficult to include. Of course, you'll have to > revise the DSTM draft. > > I'm also wondering if there are other drafts out there that > add to or modify > DHCPv6 behavoir that should be reviewed. We might either want > to pull the > functionality into the DHCPv6 specification directly (though > at this time > more work is likely not desireable) or at least alert the > authors of those > drafts that DHCPv6 is changing and they'll need to revise their drafts > (hopefully they are monitoring the work and providing input). > > - Bernie Volz > Ericsson > From owner-dhcp-v4@bucknell.edu Fri Jan 26 06:51:28 2001 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA04416 for ; Fri, 26 Jan 2001 06:51:28 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0QBi2903394; Fri, 26 Jan 2001 06:44:02 -0500 (EST) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0QBht925092 for ; Fri, 26 Jan 2001 06:43:55 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04084; Fri, 26 Jan 2001 06:43:54 -0500 (EST) Message-Id: <200101261143.GAA04084@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-dhc-aaa-ra-00.txt Date: Fri, 26 Jan 2001 06:43:54 -0500 Sender: owner-dhcp-v4@bucknell.edu X-Sender: nsyracus@cnri.reston.va.us X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Triggering AAA from DHCP Relay Agents Author(s) : G. Tsirtsis, J. Privat Filename : draft-ietf-dhc-aaa-ra-00.txt Pages : 7 Date : 25-Jan-01 Recently there has been interest in using DHCP for configuring clients accessing the Internet through some form of high-speed access technology such as cable or ADSL [DHC-AGENT]. In addition, although DHCP was initially designed for configuring fixed hosts, proposals are being made to enhance DHCP to support roaming/mobile clients [DHC-ENHANCE]. These two trends have put in evidence the need for a coupling between AAA and DHCP. Some initial requirements for DHCP/AAA have been proposed in [DHC-AAA]. This document proposes a different model in which AAA procedures are invoked not from a DHCP server but from a DHCP relay agent to make sure that ALL the Internet Access features supported by the PPP model can be replicated in a DHCP based Internet Access environment. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-aaa-ra-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-aaa-ra-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-aaa-ra-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010125101826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-aaa-ra-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-aaa-ra-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010125101826.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Fri Jan 26 13:39:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17538 for ; Fri, 26 Jan 2001 13:39:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0QIUu919198; Fri, 26 Jan 2001 13:30:56 -0500 (EST) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0QIUc905584 for ; Fri, 26 Jan 2001 13:30:39 -0500 (EST) Received: from jschnizl1-pc (jschnizl-isdn1.cisco.com [171.68.12.74]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id KAA02393; Fri, 26 Jan 2001 10:30:17 -0800 (PST) Message-Id: <4.1.20010126132448.00ca8e00@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 26 Jan 2001 13:29:36 -0500 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: I-D ACTION:draft-ietf-dhc-aaa-ra-00.txt Cc: G.Tsirtsis@Flarion.com, jerome.privat@northstream.se In-Reply-To: <200101261143.GAA04084@ietf.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I could not find the reference for DHC-AAA at the archive. Is it on the way or under some other name? At 06:43 AM 01/26/2001 -0500, Internet-Drafts@ietf.org wrote: > > Title : Triggering AAA from DHCP Relay Agents > Author(s) : G. Tsirtsis, J. Privat > Filename : draft-ietf-dhc-aaa-ra-00.txt > Pages : 7 > Date : 25-Jan-01 > >... Some initial requirements for DHCP/AAA have been proposed in >[DHC-AAA]... >7. References > > [DHC-AAA] draft-ietf-dhc-aaa-requirements-00.txt From owner-dhcp-v4@bucknell.edu Fri Jan 26 13:56:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA18108 for ; Fri, 26 Jan 2001 13:56:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0QItF913068; Fri, 26 Jan 2001 13:55:15 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0QIsx925737 for ; Fri, 26 Jan 2001 13:55:00 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0QIoVR14534 for ; Fri, 26 Jan 2001 10:50:31 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Subject: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Fri, 26 Jan 2001 10:55:10 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Overall, I have substantial concerns about this draft. Before launching into a proposed architecture, I would like to first see a definition of the problem to be solved and a set of requirements for the solution. Reading between the lines, it appears that the problem involves access-control for inter-domain mobility. For example, the draft refers to "DHCP-based Internet access". Implicitly, it is assumed that authenticated DHCP can be used as an access control mechanism. However, this is not one of the threats discussed in the authenticated DHCP draft, so I wonder whether this is an appropriate use of DHCP. Since clients can just allocate static addresses, DHCP by itself cannot keep a host from accessing the network. Implicitly it is assumed that AAA mechanism is appropriate for integration with DHCP. However, the mechanisms discussed in the authenticated DHCP draft do not lend themselves well to integration with AAA, because the signing the DHCP authentication option requires access to the DHCP packet, which in turn may require the AAA server to understand DHCP. Defining a challenge/response authentication option within DHCP may not be a good idea because then the DHCP messages wouldn't be integrity protected. This prevents implementation of a secure boot process, which was one of the original objectives of authenticated DHCP. Furthermore the coupling of DHCP and AAA will result in a multi-hop architecture that will result in substantial latency. So after reading the draft, I am left with the feeling that we need to step back and define the problem. Some questions to think about: 1. Why is it that existing access control mechanisms (e.g. mobile ip) are inadequate for the task at hand? 2. Is it valid to think of DHCP an access control mechanism? 3. Do we want to change the threat model described in the authenticated DHCP draft to incorporate the goals described in this draft? 4. What are the requirements for a DHCP authentication extension that could satisfy the goals, assuming that we think they are valid? From owner-dhcp-v4@bucknell.edu Fri Jan 26 17:48:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA23956 for ; Fri, 26 Jan 2001 17:48:58 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0QMgW905182; Fri, 26 Jan 2001 17:42:32 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0QMgM904910 for ; Fri, 26 Jan 2001 17:42:22 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Fri, 26 Jan 2001 17:42:09 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Fri, 26 Jan 2001 17:42:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernard, Thanks for this excellent analysis. Lets see if all this makes sense. See comment below. -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Friday, January 26, 2001 6:55 PM To: DHCPv4 discussion list Subject: Comments on draft-ietf-dhc-aaa-ra-00.txt Overall, I have substantial concerns about this draft. Before launching into a proposed architecture, I would like to first see a definition of the problem to be solved and a set of requirements for the solution. Reading between the lines, it appears that the problem involves access-control for inter-domain mobility. For example, the draft refers to "DHCP-based Internet access". GT> Mobility was not the main focus of the draft, although I guess it could be considered. The idea of the draft was born after working with xDSL networks. We were trying to figure out how to build an initially xDSL, but then generic always-on, access network without the use of PPP. Main reason was that always on networks are... "always-on" => no dial-up and thus no much reason for PPP. On the other hand providing the corporate network environment to home network users (dhcp plug and play) has some appeal. Then again, public access networks need access controls and the draft is what we came up with. Implicitly, it is assumed that authenticated DHCP can be used as an access control mechanism. However, this is not one of the threats discussed in the authenticated DHCP draft, so I wonder whether this is an appropriate use of DHCP. Since clients can just allocate static addresses, DHCP by itself cannot keep a host from accessing the network. GT> Indeed, only the Access router can do that...hence the point of this draft. Implicitly it is assumed that AAA mechanism is appropriate for integration with DHCP. However, the mechanisms discussed in the authenticated DHCP draft do not lend themselves well to integration with AAA, because the signing the DHCP authentication option requires access to the DHCP packet, which in turn may require the AAA server to understand DHCP. GT> Agreed but does this still apply when AAA is triggered at RA? I think it depends how we do this exactly so I will leave it for now. Defining a challenge/response authentication option within DHCP may not be a good idea because then the DHCP messages wouldn't be integrity protected. This prevents implementation of a secure boot process, which was one of the original objectives of authenticated DHCP. GT> Again, not so sure, nothing prevents you from using Authenticated DHCP in its current form in combination with the new proposal but again depends how we do it. Furthermore the coupling of DHCP and AAA will result in a multi-hop architecture that will result in substantial latency. GT> I guess that is a fair point. So after reading the draft, I am left with the feeling that we need to step back and define the problem. Some questions to think about: 1. Why is it that existing access control mechanisms (e.g. mobile ip) are inadequate for the task at hand? GT> I would argue that the main competing access control mechanisms is PPP rather than Mobile IP but I think this is a good discussion to have. Lets do this in a separate thread. 2. Is it valid to think of DHCP an access control mechanism? 3. Do we want to change the threat model described in the authenticated DHCP draft to incorporate the goals described in this draft? 4. What are the requirements for a DHCP authentication extension that could satisfy the goals, assuming that we think they are valid? GT> I think (1) is the most important one. If we find that existing mechanisms are not adequate then we can continue with the others. Regards George From owner-dhcp-v4@bucknell.edu Sat Jan 27 01:03:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA00762 for ; Sat, 27 Jan 2001 01:03:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0R5vo919485; Sat, 27 Jan 2001 00:57:50 -0500 (EST) Received: from gate.internaut.com ([64.38.134.108]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0R5vb929759 for ; Sat, 27 Jan 2001 00:57:38 -0500 (EST) Received: from e1kj2 (kidneybean [64.38.134.109]) by gate.internaut.com (8.10.2/8.10.2) with SMTP id f0R5r0R18377; Fri, 26 Jan 2001 21:53:00 -0800 From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Fri, 26 Jan 2001 21:57:42 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-Mimeole: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >We were trying to figure out how to build an initially xDSL, but >then generic always-on, access network without the use of PPP. Main reason >was that always on networks are... "always-on" => no dial-up and thus no >much reason for PPP. On the other hand providing the corporate network >environment to home network users (dhcp plug and play) has some appeal. Then >again, public access networks need access controls and the draft is what we >came up with. I've also often wondered why it is that we need PPP in xDSL. The Ethernet in the Last Mile (ELM) study group in IEEE is looking at DSL-based Ethernet PHYs, so that you could use Ethernet as the link layer instead. For this, IEEE 802.1X Network Port Authentication would be used for access control. See: http://www.drizzle.com/~aboba/IEEE/8021x-d10.pdf.gz Another approach is to do the authentication at the IP layer. A while back B. Patil proposed an IP-layer authentication protocol (BURP), which he envisaged could be used for authentication and access control in multiple access methods. In both the above approaches, authentication and access control occurs separate from, and prior to, DHCP. GT> Indeed, only the Access router can do that...hence the point of this draft. Well, the question is whether the authentication/access control is intertwined with DHCP, or kept separate, and the number of messages and state required in the upstream router as a result. For example, are we talking about per-address state, or per-port state. The difference turns out to be important for larger deployments. GT> Agreed but does this still apply when AAA is triggered at RA? I think it depends how we do this exactly so I will leave it for now. The thing to think about is what information would be included in a AAA request and response. For the DHCP authentication draft, I think that the DHCPDISCOVER/DHCPREQUEST (including the auth option) would need to go in the response, and a DHCPOFFER/ACK/NAK would need to be sent in the response. This effectively requires an integrated AAA/DHCP server, which is a complex beast to build. GT> Again, not so sure, nothing prevents you from using Authenticated DHCP in its current form in combination with the new proposal but again depends how we do it. The issue with Challenge/Response is that it typically doesn't include calculation of a MIC a la the authenticated DHCP draft, in order to avoid the problem described above. By not including a MIC, the DHCP packet is no longer integrity protected. This allows an attack to change the TFTP server, for example. With diskless boot making something of a resurgence, that is worrisome. From owner-dhcp-v4@bucknell.edu Mon Jan 29 03:51:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28236 for ; Mon, 29 Jan 2001 03:51:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0T8i2918590; Mon, 29 Jan 2001 03:44:02 -0500 (EST) Received: from mail.northstream.se ([62.20.120.194]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0T8hi905272 for ; Mon, 29 Jan 2001 03:43:48 -0500 (EST) Received: from exchange.northstream.se by mail.northstream.se via smtpd (for marge.bucknell.edu [134.82.9.1]) with SMTP; 29 Jan 2001 08:43:42 UT Received: by exchange.northstream.se with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 09:42:54 +0100 Message-ID: <93E299DA8B7DD411904300D0B7D483433EF992@exchange.northstream.se> From: Jerome Privat To: DHCPv4 discussion list Cc: urp@research.telcordia.com Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 29 Jan 2001 09:42:52 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: jerome.privat@northstream.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Another approach is to do the authentication at the IP layer. A while back B. Patil proposed an IP-layer authentication protocol (BURP), which he envisaged could be used for authentication and access control in multiple access methods. In both the above approaches, authentication and access control occurs separate from, and prior to, DHCP. [JP] I am not sure which draft you are refering to. But in BURP_requirements_00.txt (B. Patil is one of the co-authors; draft posted by S. Das on the BURP list CCd here), BURP happens after the DHCP_ACK. So authentication and access control occurs post DHCP. Are you refering to another draft/proposal? I think that the question of the relative timing of DHCP (configuration) and Access Control is important. Indeed if access control means opening a "gate" on an access router, the IP address assigned to the client needs to be known for the access to be permitted (gate opened). In addition in the BURP draft they use DHCP to configure the client with the address of the BURP server (although they mention this could also be done by BURP's own discovery protocol). Jerome From owner-dhcp-v4@bucknell.edu Mon Jan 29 03:54:14 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28252 for ; Mon, 29 Jan 2001 03:54:14 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0T8qR906042; Mon, 29 Jan 2001 03:52:27 -0500 (EST) Received: from mail.northstream.se ([62.20.120.194]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0T8nQ911722 for ; Mon, 29 Jan 2001 03:49:28 -0500 (EST) Received: from exchange.northstream.se by mail.northstream.se via smtpd (for marge.bucknell.edu [134.82.9.1]) with SMTP; 29 Jan 2001 08:49:24 UT Received: by exchange.northstream.se with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 09:48:44 +0100 Message-ID: <93E299DA8B7DD411904300D0B7D483433EF993@exchange.northstream.se> From: Jerome Privat To: DHCPv4 discussion list Subject: RE: I-D ACTION:draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 29 Jan 2001 09:48:43 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: jerome.privat@northstream.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This draft has expired. It was written by people in Telcordia/Toshiba. This work seems now to be discussed on the BURP mailing list (see the requirements draft recently posted to the BURP list). Jerome -----Original Message----- From: John Schnizlein [mailto:jschnizl@cisco.com] Sent: Friday, January 26, 2001 7:30 PM To: DHCPv4 discussion list Cc: G.Tsirtsis@Flarion.com; jerome.privat@northstream.se Subject: Re: I-D ACTION:draft-ietf-dhc-aaa-ra-00.txt I could not find the reference for DHC-AAA at the archive. Is it on the way or under some other name? At 06:43 AM 01/26/2001 -0500, Internet-Drafts@ietf.org wrote: > > Title : Triggering AAA from DHCP Relay Agents > Author(s) : G. Tsirtsis, J. Privat > Filename : draft-ietf-dhc-aaa-ra-00.txt > Pages : 7 > Date : 25-Jan-01 > >... Some initial requirements for DHCP/AAA have been proposed in >[DHC-AAA]... >7. References > > [DHC-AAA] draft-ietf-dhc-aaa-requirements-00.txt From owner-dhcp-v4@bucknell.edu Mon Jan 29 06:15:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA28957 for ; Mon, 29 Jan 2001 06:15:54 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0TBAL901019; Mon, 29 Jan 2001 06:10:21 -0500 (EST) Received: from RRMAIL01.RADIOROUTER_NT ([63.103.94.23]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0TBA6919448 for ; Mon, 29 Jan 2001 06:10:06 -0500 (EST) Received: by rrmail01.lab.flarion.com with Internet Mail Service (5.5.2650.21) id ; Mon, 29 Jan 2001 06:09:49 -0500 Message-ID: From: George Tsirtsis To: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt Date: Mon, 29 Jan 2001 06:09:48 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: G.Tsirtsis@flarion.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernard, New comments are indicated with GT>> -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Saturday, January 27, 2001 5:58 AM To: George Tsirtsis; DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt >We were trying to figure out how to build an initially xDSL, but >then generic always-on, access network without the use of PPP. Main reason >was that always on networks are... "always-on" => no dial-up and thus no >much reason for PPP. On the other hand providing the corporate network >environment to home network users (dhcp plug and play) has some appeal. Then >again, public access networks need access controls and the draft is what we >came up with. I've also often wondered why it is that we need PPP in xDSL. The Ethernet in the Last Mile (ELM) study group in IEEE is looking at DSL-based Ethernet PHYs, so that you could use Ethernet as the link layer instead. For this, IEEE 802.1X Network Port Authentication would be used for access control. See: http://www.drizzle.com/~aboba/IEEE/8021x-d10.pdf.gz GT>> That is great, I will have a look, but as always an IP solution to this is preferable in terms of doing the same thing regardless of Link Layer...and anyway this does not solve exactly the same problem...see below. Another approach is to do the authentication at the IP layer. A while back B. Patil proposed an IP-layer authentication protocol (BURP), which he envisaged could be used for authentication and access control in multiple access methods. In both the above approaches, authentication and access control occurs separate from, and prior to, DHCP. GT>> Jerome replied to this...we notified the BURP BOF mailing list about this draft so we can get their point of view too. GT> Indeed, only the Access router can do that...hence the point of this draft. Well, the question is whether the authentication/access control is intertwined with DHCP, or kept separate, and the number of messages and state required in the upstream router as a result. For example, are we talking about per-address state, or per-port state. The difference turns out to be important for larger deployments. GT>> This is a good point. In always-on and fixed systems per-port authentication can be viewed as implicit! The provider sets-up a xDSL line with a customer in a controlled way => i.e.: per-port authentication may not be the main (or only) issue here. What is now needed is some control over users at the end of this line...and this is not only for refusal of service but maybe for enabling controlled roaming between customer's networks...etc GT> Agreed but does this still apply when AAA is triggered at RA? I think it depends how we do this exactly so I will leave it for now. The thing to think about is what information would be included in a AAA request and response. For the DHCP authentication draft, I think that the DHCPDISCOVER/DHCPREQUEST (including the auth option) would need to go in the response, and a DHCPOFFER/ACK/NAK would need to be sent in the response. This effectively requires an integrated AAA/DHCP server, which is a complex beast to build. GT>> In the lab we tried something different, which would require upgrade in the capabilities of the DHCP RA to be fully functional. Build a combined AAA/DHCP client (AAA-client + DHCP RA) and let the servers be separate. The end nodes does DHCP + Auth options. The DHCP RA triggers AAA client with the auth options received from the end node. If, and Only if, the AAA server confirms the identity of the end user the DHCP RA relays the DHCP message to the DHCP server...As I said this may require some modification to the RA but I think it is worth investigating as an alternative approach. GT> Again, not so sure, nothing prevents you from using Authenticated DHCP in its current form in combination with the new proposal but again depends how we do it. The issue with Challenge/Response is that it typically doesn't include calculation of a MIC a la the authenticated DHCP draft, in order to avoid the problem described above. By not including a MIC, the DHCP packet is no longer integrity protected. This allows an attack to change the TFTP server, for example. With diskless boot making something of a resurgence, that is worrisome. GT>> Here is were my ignorance becomes apparent :-) ...what is MIC? Thanks George From owner-dhcp-v4@bucknell.edu Mon Jan 29 12:26:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06250 for ; Mon, 29 Jan 2001 12:26:07 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0THJH913328; Mon, 29 Jan 2001 12:19:17 -0500 (EST) Received: from fwns2.raleigh.ibm.com (fwns2d.raleigh.ibm.com [204.146.167.236]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0THJF929448 for ; Mon, 29 Jan 2001 12:19:15 -0500 (EST) Received: from rtpmail01.raleigh.ibm.com (rtpmail01.raleigh.ibm.com [9.37.172.24]) by fwns2.raleigh.ibm.com (8.9.0/8.9.0/RTP-FW-1.2) with ESMTP id MAA07858; Mon, 29 Jan 2001 12:18:51 -0500 Received: from rotala.raleigh.ibm.com (root@rotala.raleigh.ibm.com [9.37.60.3]) by rtpmail01.raleigh.ibm.com (8.8.5/8.8.5/RTP-ral-1.1) with ESMTP id MAA31146; Mon, 29 Jan 2001 12:18:51 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.9.3/8.7/RTP-ral-1.0) with ESMTP id MAA10314; Mon, 29 Jan 2001 12:15:32 -0500 Message-Id: <200101291715.MAA10314@rotala.raleigh.ibm.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: draft-ietf-sip-dhcp-02.txt In-Reply-To: Message from Ted Lemon of "Mon, 22 Jan 2001 15:43:43 CST." <200101222143.f0MLhh300384@grosse.bisbee.fugue.com> Date: Mon, 29 Jan 2001 12:15:31 -0500 From: Thomas Narten Reply-To: narten@raleigh.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > What are the encodings of other DNS "strings" in other DHCP options? > > Seems like one would want to start there, for compatability with > > deployed servers. Are any of the existing options using DNS > > "on-the-wire" encoding, for example? > The fqdn option does. The proposed domain name search list option > does. I don't see that "compatibility" in this case is particularly > valuable - what makes you say that it is? If I was wearing a "sip srv" hat, my assumption would be that I would want this new option useable by existing deployed DHCP servers with little or no hassle. I.e., if I encoded the option in a way that required deployment of new servers, that would be a fairly big negative. Immediate deployability has been a factor in deciding the exact format of other options discussed in the last couple of years. Wearing a "good for dhcp" hat, I'd want the format to be be as future proof as possible (e.g., perhaps same as the DNS on-the-wire format). I'd also want to be sure that the description of the actual bytes in the option are clearly enough defined that there won't be any interoperability problems once it gets implemented/deployed. Right now, IMO the option isn't specified clearly enough to avoid interoperability problems. I think the WG could really help here by saying what it thinks should be done. BTW, this option has been in the works for some time, and this is the last remaining issue. So if the WG could come to closure quickly and make a recommendation, this (and its companion document draft-ietf-sip-srv-01.txt) could be approved and sent to the RFC editor. Thanks, Thomas From owner-dhcp-v4@bucknell.edu Mon Jan 29 13:26:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07142 for ; Mon, 29 Jan 2001 13:26:42 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0TIKG900334; Mon, 29 Jan 2001 13:20:16 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0TIK7920251 for ; Mon, 29 Jan 2001 13:20:07 -0500 (EST) Received: from marvel.research.telcordia.com (marvel [192.4.16.140]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f0TIJpO23830 for ; Mon, 29 Jan 2001 13:19:51 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by marvel.research.telcordia.com (8.8.8/8.8.8) with ESMTP id NAA14144 for ; Mon, 29 Jan 2001 13:19:50 -0500 (EST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3A75B446.39CCB3B6@research.telcordia.com> Date: Mon, 29 Jan 2001 13:19:50 -0500 From: Subir Das X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: A new BOF Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: subir@research.telcordia.com X-Sender: subir@research.telcordia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit A BOF on Basic User Registration Protocol (BURP) Charter: The vision of pervasive computing also includes constantly being connected and the ability to access the Internet or the enterprise over the Internet. Mobile computing solutions based on protocols such as Mobile IP offer seamless and continuous connectivity for users. However a lot of roadwarriors and other types of users access the network from places like airports, hotels, malls and sports complexes. These environments may offer access to the network over wireless LANs or via Ethernet LAN ports or other mediums. In such scenarios, DHCP can provide configuration information (e.g., giving a valid address etc.), but there is no standard way for service providers to obtain user information to perform AAA functions. For users who do not have Mobile IP clients on their devices but would like to access the network, they need to register and be authenticated by the local network service provider before being authorized to use the resources. The intent of this proposal is to develop an application layer registration protocol that allows a user to register in the local network by providing identity and authentication information to the local network which then uses a AAA infrastructure to validate the user, charge him and, authorize use of resources. We would like to request a BOF on a "Basic User Registration Protocol (BURP)" for the March 2001 meeting of the IETF in Minneapolis. The objective of the BOF will be to -- Detail the scope of the proposal and applicable scenarios -- Chart a course and an action plan (including milestones and deliverables) for BURP. -- Investigate the impact on existing AAA protocols and make it flexible to support various authentication schemes. The goal will be to define a standard UNI for environments in which neither PPP nor Mobile IP is required but AAA interaction is essential. The basic principle will include: -- The solution being a client-server application layer protocol -- Is applicable to both IPv4 and IPv6. -- User interacts only with a local Registration Agent (RA), which may reside on any node in the Network Domain. -- It should work with any configuration protocol, such as DHCP, IPv6 stateless autoconfiguration, and manual configuration. -- Protects RA from replay attacks. -- Provide information on and control of network usage. -- Interacts with routers/policers to limit packets forwarding based on a user's Service Level Specification (may be optional or may interwork with standard policy protocols). -- Defines an RA-to-AAA interface ----------------------------------------------------------------------- To subscribe to the mailing list for discussion on this topic, please follow these instructions: To subscribe, send mail to urp-request@research.telcordia.com, and use "subscribe" for the subject line. To unsubscribe, send mail to urp-request@research.telcordia.com, and use "unsubscribe" for the subject line. To contribute to the list, send mail to urp@research.telcordia.com. For additional help, send mail to urp-request@research.telcordia.com and use "help" for the subject line. From owner-dhcp-v4@bucknell.edu Mon Jan 29 14:58:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08934 for ; Mon, 29 Jan 2001 14:58:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0TJpW901955; Mon, 29 Jan 2001 14:51:32 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0TJpM921094 for ; Mon, 29 Jan 2001 14:51:22 -0500 (EST) Received: from earth.research.telcordia.com (extranet-207.cc.telcordia.com [192.4.246.207]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f0TJovO29067; Mon, 29 Jan 2001 14:50:58 -0500 (EST) Message-ID: <3A75C9CF.16F98FF7@earth.research.telcordia.com> Date: Mon, 29 Jan 2001 14:51:43 -0500 From: mcauley X-Mailer: Mozilla 4.51 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: dhcp-v4@bucknell.edu, urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt References: <93E299DA8B7DD411904300D0B7D483433EF992@exchange.northstream.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: mcauley@earth.research.telcordia.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit George, Jerome, I liked your draft and think that it reflect the same goals as BURP: i.e. getting the AAA features supported by the PPP model while using DHCP based configuration. Also you do it technology independently rather than at the link layer (as is done in 802.1X). The one key difference between the apporaches, which it would be good to discuss, is whether to integrate it with DHCP. We believe non-integration gives better: 1. Modularity: DHCP is fundamentally for terminal configuration and should have nothing to do with the user (not sure whether the DHCP experts would agree...). 2. Reusuability: Such as using BURP with IPv6 Stateless,... 3. Scalabiltiy: No node on each link to deal with AAA (as long as DHCP provides its address, no BURP server (or relay) need be on the access link). We believe these benefits outweigh speed/efficeincy gains from integration. The only other trade, which you point out in your draft, is in security. Certainly, simpler security is possible with your suggestion, which I like, of doing the AAA from the DHCP relay agents (rather than the DHCP server as we had ealier suggested). DHCP then gives no addresses (or other configuration info) to those that have not been authorized. However, I can always manually configure my terminal, so separate policing must still be done. Integration, with DHCP clients and servers authenticating each other, also helps prevent Denial of Service (DoS) attacks. Again, however, we believe there are alternative policing mechanisms. BURP itself does not do policing (again for reasons of modularity). However, the Local Security Association established by BURP could be used (by a policing protocol) to achieve access control and guard against DoS attacks. Appreciate your thoughts, or other in the DHC WG, on the integration non-integration issues. Thanks Tony Jerome Privat wrote: > Another approach is to do the authentication at the IP layer. A while > back B. Patil proposed an IP-layer authentication protocol (BURP), which > he envisaged could be used for authentication and access control in > multiple access methods. > > In both the above approaches, authentication and access control occurs > separate from, and prior to, DHCP. > > [JP] > I am not sure which draft you are refering to. But in > BURP_requirements_00.txt (B. Patil is one of the co-authors; draft posted by > S. Das on the BURP list CCd here), BURP happens after the DHCP_ACK. So > authentication and access control occurs post DHCP. Are you refering to > another draft/proposal? > > I think that the question of the relative timing of DHCP (configuration) and > Access Control is important. > Indeed if access control means opening a "gate" on an access router, the IP > address assigned to the client needs to be known for the access to be > permitted (gate opened). > > In addition in the BURP draft they use DHCP to configure the client with the > address of the BURP server (although they mention this could also be done by > BURP's own discovery protocol). > > Jerome From owner-dhcp-v4@bucknell.edu Mon Jan 29 21:40:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA15047 for ; Mon, 29 Jan 2001 21:39:59 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0U2X0902564; Mon, 29 Jan 2001 21:33:00 -0500 (EST) Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0U2Wj924995 for ; Mon, 29 Jan 2001 21:32:47 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id SAA06558; Mon, 29 Jan 2001 18:32:39 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA01256; Mon, 29 Jan 01 19:09:06 -0800 Date: Mon, 29 Jan 2001 19:09:05 -0800 (GMT-0800) From: "Bernard D. Aboba" To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: RE: Comments on draft-ietf-dhc-aaa-ra-00.txt In-Reply-To: Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: aboba@internaut.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Out of curiousity, how does IP-layer auth work in a multi-protocol situation? For example, if I'm running dual stack (IPv4, IPv6), do I now need two authentications, one for each protocol? What if one auth succeeds and another fails? In effect, the interface is down for one protocol and up for another. How does this work? I think that while it's easy to advocate "doing it at the IP layer" it's a lot harder to describe how this would work (and why this solution would be better than a linklayer one). From owner-dhcp-v4@bucknell.edu Tue Jan 30 13:52:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15370 for ; Tue, 30 Jan 2001 13:52:49 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0UIj0924484; Tue, 30 Jan 2001 13:45:00 -0500 (EST) Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0UIiq927252 for ; Tue, 30 Jan 2001 13:44:52 -0500 (EST) Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.117.200.22]) by e4.ny.us.ibm.com (8.9.3/8.9.3) with ESMTP id NAA331064 for ; Tue, 30 Jan 2001 13:43:49 -0500 Received: from d27ml105.rchland.ibm.com (d27ml105.rchland.ibm.com [9.5.39.22]) by northrelay02.pok.ibm.com (8.8.8m3/NCO v4.95) with ESMTP id NAA40156 for ; Tue, 30 Jan 2001 13:41:32 -0500 Importance: Normal Subject: Clarification on draft-ietf-dhc-fqdn-option-00.txt To: DHCPv4 discussion list X-Mailer: Lotus Notes Release 5.0.4a July 24, 2000 Message-ID: From: "John Corcoran" Date: Tue, 30 Jan 2001 13:46:26 -0500 X-MIMETrack: Serialize by Router on d27ml105/27/M/IBM(Release 5.0.5 |September 22, 2000) at 01/30/2001 12:46:28 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Reply-To: jjcorc@us.ibm.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm looking for some clarification regarding how a DHCP client and server should handle Option 81. The draft states " When a DHCP server sends the Client FQDN option to a client in the DHCPACK message, the DHCP server SHOULD send its notion of the complete FQDN for the client in the Domain Name field." By "complete FQDN" is it intended that the server's response end with a "."? The draft also states "The server MAY simply copy the Domain Name field from the Client FQDN option that the client sent to the server in the DHCPREQUEST message." In some testing, we've observed that a certain, very popular client, will derive it's FQDN from it's locally configured host name and the domain name (option 15) when it received from the server in a DHCPOffer message. The client then sends, in it's DHCPRequest , option 81. However, the FQDN from the client does not end with a "." unless the option 15 data configured in the server ends in a "." If a server simply echo's this data back to the client, the client is unable to resolve to the correct DNS. Also per the draft "The DHCP server MAY be configured to complete or modify the domain name which a client sent, or it MAY be configured to substitute a different name." So, really I have the same question, in this case is it also incumbent upon the DHCP server to add a terminating "."? And finally, is it a legitimate use of the option to return option 81 with just the FLAGS and RCODE fields set assuming that the server intends to use the client's notion of the FQDN? Or must the server include the Domain Name field when sending option 81? Thanks for any clarification that can be provided. Jack Corcoran From owner-dhcp-v4@bucknell.edu Tue Jan 30 15:15:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA16978 for ; Tue, 30 Jan 2001 15:15:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id f0UK95a06786; Tue, 30 Jan 2001 15:09:05 -0500 (EST) Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id f0UK8pa30884 for ; Tue, 30 Jan 2001 15:08:51 -0500 (EST) Received: from marvel.research.telcordia.com (marvel [192.4.16.140]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id f0UK7HO12173; Tue, 30 Jan 2001 15:07:17 -0500 (EST) Received: from research.telcordia.com (localhost [127.0.0.1]) by marvel.research.telcordia.com (8.8.8/8.8.8) with ESMTP id PAA16827; Tue, 30 Jan 2001 15:07:16 -0500 (EST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3A771EF4.DCFF8C02@research.telcordia.com> Date: Tue, 30 Jan 2001 15:07:16 -0500 From: Subir Das X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list , urp@research.telcordia.com Subject: Re: Comments on draft-ietf-dhc-aaa-ra-00.txt References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: subir@research.telcordia.com X-Sender: subir@research.telcordia.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Bernard, Here is an attempt to answer your question: 1. Authentication above layer-2 works for any link technology (e.g., home, cable, cellular, office). 2. Authentication at the application layer (as is proposed for BURP, for example), independent of IP address, eliminates the need to do separate authentication for a dual stack(IPv4, IPv6). Appreciate your comments. Regards, Subir "Bernard D. Aboba" wrote: > Out of curiousity, how does IP-layer auth work in a multi-protocol > situation? > > For example, if I'm running dual stack (IPv4, IPv6), do I now need two > authentications, one for each protocol? What if one auth succeeds and > another fails? In effect, the interface is down for one protocol and up > for another. How does this work? > > I think that while it's easy to advocate "doing it at the IP layer" it's > a lot harder to describe how this would work (and why this solution would > be better than a linklayer one). -- ******************************************************************************** Subir Das Ofc: MCC 1D-210R Telcordia Technologies Tel: 973 829 4959 (Formerly Bellcore) Fax: 973 829 5888 445, South Street E-mail: subir@research.telcordia.com Morristown, NJ 07960-6438 ********************************************************************************