From owner-dhcp-v4@bucknell.edu Mon May 1 11:32:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28398 for ; Mon, 1 May 2000 11:32:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA07126; Mon, 1 May 2000 11:27:52 -0400 (EDT) Received: from atlas.centergate.com (atlas.centergate.com [204.74.78.20]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA26780 for ; Mon, 1 May 2000 11:27:40 -0400 (EDT) Received: from ULTRADNS6PMNFK (natpool0.186.vantas.net [12.22.21.65] (may be forged)) by atlas.centergate.com (8.10.0/8.9.11) with SMTP id e41FRTl11085 for ; Mon, 1 May 2000 08:27:29 -0700 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Relayed lease extension Date: Mon, 1 May 2000 08:33:36 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <009E94C3.BDA22C64.15@process.com> Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit This set-up might be used in other instances where the end-client never gets an address via DHCP itself (if I recall, PPP sends it in the inital negotiation to the client and thus the client isn't running DHCP at all). If the BigBox gets the lease on the address for a shorter time than the client is connected, it will need to renew the lease and hence the situation Wim is looking at. ...Bernie, did you really mean to say that? It seems to me that in the case you describe, BigBox (and NOT its downstream client) is the host known to a DHCP server as the DHCP client. If you are suggesting a different interpretation, such as BigBox acting as proxy for its client, then the protocol may not adequately cover all implementation cases. I do think this is a reasonable problem to solve and should be included on the list of issues for revisions to the DHCP RFC. The simply policy of sending the reply to the giaddr might be best and it is consistent with what's done on the initial lease. ...I agree that we should consider this case. Note: In the above case, I'm not sure I'd call the "DHCP thing" on the "BigBox" a DHCP Relay. It really is more of a DHCP Client on behalf of the actual client. If it is a classic relay, then as Bernard says, the client is doing DHCP and thus there is no need for the relay to become involved in the renewals. ...sounds suspiciously like a proxy to me when expressed in these terms.... --Barr From owner-dhcp-v4@bucknell.edu Mon May 1 11:47:21 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28726 for ; Mon, 1 May 2000 11:47:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA01736; Mon, 1 May 2000 11:46:05 -0400 (EDT) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA28488 for ; Mon, 1 May 2000 11:45:58 -0400 (EDT) Received: by process.com (MX V5.1-X A2w8g) id 162; Mon, 1 May 2000 11:45:30 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Mon, 1 May 2000 11:45:29 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E96EB.369A41D0.162@process.com> Subject: RE: Relayed lease extension Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Barr: >This set-up might be used in other instances where the end-client never >gets an address via DHCP itself (if I recall, PPP sends it in the inital >negotiation to the client and thus the client isn't running DHCP at >all). If the BigBox gets the lease on the address for a shorter time >than the client is connected, it will need to renew the lease and hence >the situation Wim is looking at. > >...Bernie, did you really mean to say that? It seems to me that in the case >you describe, BigBox (and NOT its downstream client) is the host known to a >DHCP server as the DHCP client. If you are suggesting a different >interpretation, such as BigBox acting as proxy for its client, then the >protocol may not adequately cover all implementation cases. For renewals, how are they handled? The renewl is sent by BigBox with the client's IP address. If the response is send back to the cleint's IP address, then either: a) BigBox must take steps to prevent it from going to the client and intercept it. b) The renewal will go directly to the client and in the case of PPP where the client isn't running DHCP, it will not have the desired effect. Since the original lease was done by BigBox on behalf of the client, the renewal must also be done by BigBox on behalf of the client. - Bernie From owner-dhcp-v4@bucknell.edu Mon May 1 12:37:38 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29791 for ; Mon, 1 May 2000 12:37:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA21013; Mon, 1 May 2000 12:34:04 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA31123 for ; Mon, 1 May 2000 12:33:43 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id JAA86033; Mon, 1 May 2000 09:18:34 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Relayed lease extension Date: Mon, 1 May 2000 09:34:56 -0700 Message-ID: <002c01bfb38b$2fe13e60$428939cc@ntdev.microsoft.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <009E96EB.369A41D0.162@process.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >For renewals, how are they handled? The renewal is sent by BigBox with >the client's IP address. If the response is send back to the cleint's >IP address, then either: >a) BigBox must take steps to prevent it from going to the client and >intercept it. >b) The renewal will go directly to the client and in the case of PPP >where the client isn't running DHCP, it will not have the desired >effect. >Since the original lease was done by BigBox on behalf of the client, the >renewal must also be done by BigBox on behalf of the client. I think that this does make an argument for updating the RFC. I also think that it also indicates that having a different address assignment mechanism for PPP was a mistake. That's one reason why we're trying to leverage DHCP in the VPN case, so that we don't make the same mistake there. From owner-dhcp-v4@bucknell.edu Mon May 1 13:01:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00338 for ; Mon, 1 May 2000 13:01:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA14968; Mon, 1 May 2000 13:00:32 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA24974 for ; Mon, 1 May 2000 13:00:22 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac34.dialup.mindspring.com [207.69.48.100]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA08150; Sun, 30 Apr 2000 18:20:58 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id IAA03275; Mon, 1 May 2000 08:54:28 -0700 (MST) Message-Id: <200005011554.IAA03275@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Options in dhcpd.conf In-Reply-To: Message from Medi Montaseri of "Fri, 28 Apr 2000 15:17:38 PDT." <390A0E02.E798A4F0@sanlight.com> Date: Mon, 01 May 2000 11:54:28 -0400 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Question is "how do I specify Vendor Extensions Option in my > dhcpd.conf(4)" I've > read the man page on dhcp-2.0-3 (from RedHat 6.1 distribution) and > I didn't see > any references to Vendor extensions. Switch to 3.0b1pl13. The one that comes with the Redhat 6.1 distribution is several years old, and does not support vendor extensions. :'} _MelloN_ From owner-dhcp-v4@bucknell.edu Mon May 1 13:03:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00390 for ; Mon, 1 May 2000 13:03:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA31739; Mon, 1 May 2000 13:02:10 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA12074 for ; Mon, 1 May 2000 13:00:33 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac34.dialup.mindspring.com [207.69.48.100]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA08163; Sun, 30 Apr 2000 18:21:13 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id IAA03154; Mon, 1 May 2000 08:44:42 -0700 (MST) Message-Id: <200005011544.IAA03154@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Relayed lease extension In-Reply-To: Message from Wim Janssen of "Fri, 28 Apr 2000 17:03:09 -0000." <3909C44D.2D317FB2@assuredaccess.com> Date: Mon, 01 May 2000 11:44:42 -0400 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN If the client acts like it's in the REBINDING state, the DHCP server *must* honor giaddr. The only time that the server's expected behaviour is not defined for giaddr is when the client is acting like it's in the RENEWING state. So if you want consistent behaviour, you shouldn't have the client fill in giaddr when it's acting like it's in the RENEWING state. I will freely admit that this isn't entirely optimal - it would be nice if the standard said that the server MUST honor giaddr in favor of ciaddr, but it doesn't, so you're stuck. :'} _MelloN_ From owner-dhcp-v4@bucknell.edu Mon May 1 13:10:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00512 for ; Mon, 1 May 2000 13:10:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA20764; Mon, 1 May 2000 13:07:58 -0400 (EDT) Received: from atlas.centergate.com (atlas.centergate.com [204.74.78.20]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA22341 for ; Mon, 1 May 2000 13:07:50 -0400 (EDT) Received: from ULTRADNS6PMNFK (natpool0.186.vantas.net [12.22.21.65] (may be forged)) by atlas.centergate.com (8.10.0/8.9.11) with SMTP id e41H7ml13868 for ; Mon, 1 May 2000 10:07:48 -0700 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Relayed lease extension Date: Mon, 1 May 2000 10:13:55 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <009E96EB.369A41D0.162@process.com> Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit If the response is send back to the cleint's IP address, then either: a) BigBox must take steps to prevent it from going to the client and intercept it. b) The renewal will go directly to the client and in the case of PPP where the client isn't running DHCP, it will not have the desired effect. Since the original lease was done by BigBox on behalf of the client, the renewal must also be done by BigBox on behalf of the client. ...I'm in agreement with what you said above. --Barr From owner-dhcp-v4@bucknell.edu Mon May 1 13:12:58 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00552 for ; Mon, 1 May 2000 13:12:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA15673; Mon, 1 May 2000 13:09:18 -0400 (EDT) Received: from atlas.centergate.com (atlas.centergate.com [204.74.78.20]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA17334 for ; Mon, 1 May 2000 13:07:50 -0400 (EDT) Received: from ULTRADNS6PMNFK (natpool0.186.vantas.net [12.22.21.65] (may be forged)) by atlas.centergate.com (8.10.0/8.9.11) with SMTP id e41H7nl13871 for ; Mon, 1 May 2000 10:07:49 -0700 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Relayed lease extension Date: Mon, 1 May 2000 10:13:56 -0700 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) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <002c01bfb38b$2fe13e60$428939cc@ntdev.microsoft.com> Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit [Bernard] I think that this does make an argument for updating the RFC. I also think that it also indicates that having a different address assignment mechanism for PPP was a mistake. That's one reason why we're trying to leverage DHCP in the VPN case, so that we don't make the same mistake there. ...for about a year there has been a growing list of items needing clarification and amplification: Ted volunteered [or maybe got suckered into doing so???] to coordinate these items at the WG meeting in Washington, DC. Ted, I'm not trying to put you on the spot, especially since I haven't finished a couple of my work items either, but it does look as if the list has started growing again. I'll volunteer to assist you in accumulating and codifying the work items list for discussion [hopefully] at the summer WG meeting. Ralph, we're not stepping on anybody else's work by doing this, are we? --Barr From owner-dhcp-v4@bucknell.edu Mon May 1 13:25:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00761 for ; Mon, 1 May 2000 13:25:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA19173; Mon, 1 May 2000 13:24:31 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA08349 for ; Mon, 1 May 2000 13:24:26 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac34.dialup.mindspring.com [207.69.48.100]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA08319; Sun, 30 Apr 2000 18:45:05 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id KAA04895; Mon, 1 May 2000 10:24:40 -0700 (MST) Message-Id: <200005011724.KAA04895@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Relayed lease extension In-Reply-To: Message from "Barr Hibbs" of "Mon, 01 May 2000 10:13:56 PDT." Date: Mon, 01 May 2000 13:24:40 -0400 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I will point out to those of you who are favoring an update of the spec that while I agree that this is worth doing, updating the spec doesn't actually solve the problem. The only thing that would solve the problem would be if the spec had taken this into account when the servers with which this new client is intended to interoperate were implemented. Changing the spec now doesn't change old implementations. So from a pragmatic standpoint, the right thing to tell him is how he can reliably get the behaviour he wants given the *current* spec. _MelloN_ From owner-dhcp-v4@bucknell.edu Mon May 1 14:37:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02155 for ; Mon, 1 May 2000 14:37:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA09228; Mon, 1 May 2000 14:32:50 -0400 (EDT) Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA05524 for ; Mon, 1 May 2000 14:32:21 -0400 (EDT) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id LAA14682 for ; Mon, 1 May 2000 11:32:20 -0700 (MST)] Received: [from noah.dma.isg.mot.com (noah.dma.isg.mot.com [150.21.2.29]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id LAA25802 for ; Mon, 1 May 2000 11:32:20 -0700 (MST)] Received: from dma.isg.mot.com (cabs1.dma.isg.mot.com [150.21.2.34]) by noah.dma.isg.mot.com (8.8.8+Sun/8.8.8) with ESMTP id OAA00440; Mon, 1 May 2000 14:13:21 -0400 (EDT) Message-Id: <200005011813.OAA00440@noah.dma.isg.mot.com> To: DHCPv4 discussion list cc: mpatrick@dma.isg.mot.com Subject: Relay Agent Options draft "9A" Date: Mon, 01 May 2000 14:13:19 -0400 From: "Michael W. Patrick" Reply-To: mpatrick@dma.isg.mot.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN DHCP V4 group, As Eric Michelson reported on 3/20, he and I reached agreement on wording changes to the Relay Agent option draft that he felt were absolutely required by the DSL community. The idea is that a bridging DSL modem or the DSLAM should be permitted to act as a "trusted network element" and add its own DHCP Relay agent option, *without* setting giaddr. The wording of section 2.1 had stated that a subsequey DHCP Relay Agent receiving such a packet with zero giaddr and a DHCP agent option already MUST reject it. The new wording permits this kind of packet, as long as the source of the packet (i.e. the previous network element forwarding it), was "trusted". The other change he wanted was to not preclude adding agent options to BOOTP packets. I'm attaching a draft "9A" with my proposed wording changes to address these issues. All wording changes are in section 2.1. If there's no objection by 5/8, I'll submit this as draft -10 of the relay agent options spec. Thanx, -mike INTERNET DRAFT DHC Working Grop Michael Patrick Motorola ING May 1, 2000 DHCP Relay Agent Information Option Status of this Memo This document is an Internet Draft and is in full conformance of section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shado Directories can be accessed at http://ww.ietf.org/shadow.html The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. Abstract Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such "public" DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. Expires November 2000 [Page 1] May 1, 2000 The new option is called the Relay Agent Information option and is inserted by the DHCP relay agent when forwarding client-originated DHCP packets to a DHCP server. Servers recognizing the Relay Agent Information option may use the information to implement IP address or other parameter assignment policies. The DHCP Server echoes the option back verbatim to the relay agent in server-to-client replies, and the relay agent strips the option before forwarding the reply to the client. The "Relay Agent Information" option is organized as a single DHCP option that contains one or more "sub-options" that convey information known by the relay agent. The initial sub-options are defined for a relay agent that is co-located in a public circuit access unit. These include a "circuit ID" for the incoming circuit, and a "remote ID" which provides a trusted identifier for the remote high-speed modem. Table of Contents 1 Introduction........................................... 3 1.1 High-Speed Circuit Switched Data Networks.............. 3 1.2 DHCP Relay Agent in the Circuit Access Equipment....... 5 2.0 Relay Agent Information Option......................... 6 2.1 Agent Operation........................................ 7 2.1.1 Reforwarded DHCP requests............................ 8 2.2 Server Operation....................................... 8 3.0 Relay Agent Information Suboptions..................... 9 3.1 Agent Circuit ID....................................... 9 3.2 Agent Remote ID........................................ 10 4.0 Issues Resolved........................................ 11 5.0 Security Considerations................................ 12 6.0 IANA Considerations.................................... 12 7.0 Intellectual Property Notice........................... 13 8.0 References............................................. 13 9.0 Glossary............................................... 14 10.0 Author's Address...................................... 14 Expires November 2000 [Page 2] May 1, 2000 Revision History Rev Date Description --- -------- ----------- -9A 5/1/2000 Relay agent operation (section 2.1): Define operation for both BOOTP and DHCP. Allow an existing Relay Agent option added by a trusted network element between the client and Relay Agent. -09 3/2/2000 Remove Subnet Mask suboption. It will be considered as a separate draft. -08 1/3/2000 Require that agents MUST NOT modify DHCP packets that use IPSEC. -07 8/24/99 Updated "Status of this memo" to conform to current I-D requirements. Revision -06 added section 7 Intellectual Property Notices. 1 Introduction 1.1 High-Speed Circuit Switched Data Networks Public Access to the Internet is usually via a circuit switched data network. Today, this is primarily implemented with dial-up modems connecting to a Remote Access Server. But higher speed circuit access networks also include ISDN, ATM, Frame Relay, and Cable Data Networks. All of these networks can be characterized as a "star" topology where multiple users connect to a "circuit access unit" via switched or permanent circuits. With dial-up modems, only a single host PC attempts to connect to the central point. The PPP protocol is widely used to assign IP addresses to be used by the single host PC. The newer high-speed circuit technologies, however, frequently provide a LAN interface (especially Ethernet) to one or more host PCs. It is desirable to support centralized assignment of the IP addresses of host computers connecting on such circuits via DHCP. The DHCP server can be, but usually is not, co-implemented with the centralized circuit concentration access device. The DHCP server is often connected as a separate server on the "Central LAN" to which the central access device (or devices) attach. Expires November 2000 [Page 3] May 1, 2000 A common physical model for high-speed Internet circuit access is shown in Figure 1, below. +---------------+ | Central | Circuit |-- ckt 1--- Modem1-- Host-|- Host A LAN | | Access | Lan |- Host B | | Unit 1 | |- Host C |-----| |-- | | |(relay agent) |... +---------+ | +---------------+ | DHCP |--| | Server | | +---------+ | | | +---------------+ +---------+ | | Circuit |-- ckt 1--- Modem2-- Host--- Host D | Other | | | Access | Lan | Servers |--|-----| Unit 2 | | (Web, | | | |-- ckt 2--- Modem3-- Host--- Host E | DNS) | | |(relay agent) |... Lan | | +---------------+ +---------+ Figure 1: DHCP High Speed Circuit Access Model Note that in this model, the "modem" connects to a LAN at the user site, rather than to a single host. Multiple hosts are implemented at this site. Although it is certainly possible to implement a full IP router at the user site, this requires a relatively expensive piece of equipment (compared to typical modem costs). Furthermore, a router requires an IP address not only for every host, but for the router itself. Finally, a user-side router requires a dedicated Logical IP Subnet (LIS) for each user. While this model is appropriate for relatively small corporate networking environments, it is not appropriate for large, public accessed networks. In this scenario, it is advantageous to implement an IP networking model that does not allocate an IP address for the modem (or other networking equipment device at the user site), and especially not an entire LIS for the user side LAN. Note that using this method to obtain IP addresses means that IP addresses can only be obtained while communication to the central site is available. Some host lan installations may use a local DHCP server or other methods to obtain IP addresses for in-house use. Expires November 2000 [Page 4] May 1, 2000 1.2 DHCP Relay Agent in the Circuit Access Unit It is desirable to use DHCP to assign the IP addresses for public high-speed circuit access. A number of circuit access units (e.g. RAS's, cable modem termination systems, ADSL access units, etc) connect to a LAN (or local internet) to which is attached a DHCP server. For scaling and security reasons, it is advantageous to implement a "router hop" at the circuit access unit, much like high-capacity RAS's do today. The circuit access equipment acts as both a router to the circuits and as the DHCP relay agent. The advantages of co-locating the DHCP relay agent with the circuit access equipment are: DHCP broadcast replies can be routed to only the proper circuit, avoiding, say, the replication of the DCHP reply broadcast onto thousands of access circuits; The same mechanism used to identify the remote connection of the circuit (e.g. a user ID requested by a Remote Access Server acting as the circuit access equipment) may be used as a host identifier by DHCP, and used for parameter assignment. This includes centralized assignment of IP addresses to hosts. This provides a secure remote ID from a trusted source -- the relay agent. A number of issues arise when forwarding DHCP requests from hosts connecting publicly accessed high-speed circuits with LAN connections at the host. Many of these are security issues arising from DHCP client requests from untrusted sources. How does the relay agent know to which circuit to forward replies? How does the system prevent DHCP IP exhaustion attacks? This is when an attacker requests all available IP addresses from a DHCP server by sending requests with fabricated client MAC addresses. How can an IP address or LIS be permanently assigned to a particular user or modem? How does one prevent "spoofing" of client identifer fields used to assign IP addresses? How does one prevent denial of service by "spoofing" other client's MAC addresses? All of these issues may be addressed by having the circuit access equipment, which is a trusted component, add information to DHCP client requests that it forwards to the DHCP server. Expires November 2000 [Page 5] May 1, 2000 2.0 Relay Agent Information Option This document defines a new DHCP Option called the Relay Agent Information Option. It is a "container" option for specific agent- supplied sub-options. The format of the Relay Agent Information option is: Code Len Agent Information Field +------+------+------+------+------+------+--...-+------+ | 82 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ The length N gives the total number of octets in the Agent Information Field. The Agent Information field consists of a sequence of SubOpt/Length/Value tuples for each sub-option, encoded in the following manner: SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 1 | N | s1 | s2 | s3 | s4 | | sN | +------+------+------+------+------+------+--...-+------+ SubOpt Len Sub-option Value +------+------+------+------+------+------+--...-+------+ | 2 | N | i1 | i2 | i3 | i4 | | iN | +------+------+------+------+------+------+--...-+------+ No "pad" sub-option is defined, and the Information field shall NOT be terminated with a 255 sub-option. The length N of the DHCP Agent Information Option shall include all bytes of the sub-option code/length/value tuples. Since at least one sub-option must be defined, the minimum Relay Agent Information length is two (2). The length N of the sub-options shall be the number of octets in only that sub-option's value field. A sub-option length may be zero. The sub-options need not appear in sub-option code order. The initial assignment of DHCP Relay Agent Sub-options is as follows: DHCP Agent Sub-Option Descrption Sub-option Code --------------- ---------------------- 1 Agent Circuit ID Sub-option 2 Agent Remote ID Sub-option Expires November 2000 [Page 6] May 1, 2000 New sub-option codes MUST be assigned by IANA according to the policy described in the "IANA Considerations" section of this document. 2.1 Agent Operation Overall adding of the DHCP relay agent option SHOULD be configurable, and SHOULD be disabled by default. Relay agents SHOULD have separate configurables for each sub-option to control whether it is added to client-to-server packets. A DHCP relay agent adding a Relay Agent Information field SHALL add it as the last DHCP agent option in the DHCP options field of any recognized BOOTP or DHCP packet forwarded from a client to a server. Relay agents receiving a DHCP packet from an untrusted source with giaddr set to zero (indicating that they are the first-hop router) but with a Relay Agent Information option already present in the packet SHALL discard the packet and increment an error count. A trusted network element (e.g. a bridge) between the relay agent and the client MAY add a relay agent option but not set the giaddr field. In this case, the relay agent does NOT add a "second" relay agent option, but forwards the DHCP packet per normal DHCP relay agent operations. Relay agents MAY have a configurable for the maximum size of the DHCP packet to be created after appending the Agent Information option. Packets which, after appending the Relay Agent Information option, would exceed this configured maximum size shall be forwarded WITHOUT adding the Agent Information option. An error counter SHOULD be incremented in this case. In the absence of this configurable, the agent SHALL NOT increase a forwarded DHCP packet size to exceed the MTU of the interface on which it is forwarded. The Relay Agent Information option echoed by a server MUST be removed by the agent when forwarding a server-to-client response back to the client. The agent SHALL NOT add an "Option Overload" option to the packet or use the "file" or "sname" fields for adding Relay Agent Information option. It SHALL NOT parse or remove Relay Agent Information options that may appear in the sname or file fields of a server-to-client packet forwarded through the agent. The operation of relay agents for specific sub-options is specified with that sub-option. Relay agents are NOT required to monitor or modify client-originated DHCP packets addressed to a server unicast address. This includes Expires November 2000 [Page 7] May 1, 2000 the DHCP-REQUEST sent when entering the RENEWING state. Relay agents MUST NOT modify DHCP packets that use the IPSEC Authentication Header or IPSEC Encapsulating Security Payload [6]. 2.1.1 Reforwarded DHCP requests A DHCP relay agent may receive a client DHCP packet forwarded from a BOOTP/DHCP relay agent closer to the client. Such a packet will have giaddr as non-zero, and may or may not already have a DHCP Relay Agent option in it. Relay agents configured to add a Relay Agent option which receive a client DHCP packet with a nonzero giaddr SHALL discard the packet if the giaddr spoofs a giaddr address implemented by the local agent itself. Otherwise, the relay agent SHALL forward any received DHCP packet with a valid non-zero giaddr WITHOUT adding any relay agent options. Per RFC 2131, it shall also NOT modify the giaddr value. 2.2 Server Operation DHCP servers unaware of the Relay Agent Information option will ignore the option upon receive and will not echo it back on responses. This is the specified server behavior for unknown options. DHCP servers claiming to support the Relay Agent Information option SHALL echo the entire contents of the Relay Agent Information option in all replies. Servers SHOULD copy the Relay Agent Information option as the last DHCP option in the response. Servers SHALL NOT place the echoed Relay Agent Information option in the overloaded sname or file fields. If a server is unable to copy a full Relay Agent Information field into a response, it SHALL send the response without the Relay Information Field, and SHOULD increment an error counter for the situation. The operation of DHCP servers for specific sub-options is specified with that sub-option. Note that DHCP relay agents are not required to monitor unicast DHCP messages sent directly between the client and server (i.e, those that aren't sent via a relay agent). However, some relay agents MAY chose to do such monitoring and add relay agent options. Consequently, servers SHOULD be prepared to handle relay agent options in unicast messages, but MUST NOT expect them to always be there. Expires November 2000 [Page 8] May 1, 2000 3.0 Relay Agent Information Sub-options 3.1 Agent Circuit ID Sub-option This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits. It encodes an agent-local identifier of the circuit from which a DHCP client-to-server packet was received. It is intended for use by agents in relaying DHCP responses back to the proper circuit. Possible uses of this field include - Router interface number - Switching Hub port number - Remote Access Server port number - Frame Relay DLCI - ATM virtual circuit number - Cable Data virtual circuit number Servers MAY use the Circuit ID for IP and other parameter assignment policies. The Circuit ID SHOULD be considered an opaque value, with policies based on exact string match only; that is, the Circuit ID SHOULD NOT be internally parsed by the server. The DHCP server SHOULD report the Agent Circuit ID value of current leases in statistical reports (including its MIB) and in logs. Since the Circuit ID is local only to a particular relay agent, a circuit ID should be qualified with the giaddr value that identifies the relay agent. SubOpt Len Circuit ID +------+------+------+------+------+------+------+------+-- | 1 | n | c1 | c2 | c3 | c4 | c5 | c6 | ... +------+------+------+------+------+------+------+------+-- Expires November 2000 [Page 9] May 1, 2000 3.2 Agent Remote ID Sub-option This sub-option MAY be added by DHCP relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. The Remote ID field may be used to encode, for instance: -- a "caller ID" telephone number for dial-up connection -- a "user name" prompted for by a Remote Access Server -- a remote caller ATM address -- a "modem ID" of a cable data modem -- the remote IP address of a point-to-point link -- a remote X.25 address for X.25 connections The remote ID MUST be globally unique. DHCP servers MAY use this option to select parameters specific to particular users, hosts, or subscriber modems. The option SHOULD be considered an opaque value, with policies based on exact string match only; that is, the option SHOULD NOT be internally parsed by the server. The relay agent MAY use this field in addition to or instead of the Agent Circuit ID field to select the circuit on which to forward the DHCP reply (e.g. Offer, Ack, or Nak). DHCP servers SHOULD report this value in any reports or MIBs associated with a particular client. SubOpt Len Agent Remote ID +------+------+------+------+------+------+------+------+-- | 2 | n | r1 | r2 | r3 | r4 | r5 | r6 | ... +------+------+------+------+------+------+------+------+-- Expires November 2000 [Page 10] May 1, 2000 4.0 Issues Resolved Broadcast Forwarding The circuit access equipment forwards the normally broadcasted DHCP response only on the circuit indicated in the Agent Circuit ID. DHCP Address Exhaustion In general, the DHCP server may be extended to maintain a database with the "triplet" of (client IP address, client MAC address, client remote ID) The DHCP server SHOULD implement policies that restrict the number of IP addresses to be assigned to a single remote ID. Static Assignment The DHCP server may use the remote ID to select the IP address to be assigned. It may permit static assignment of IP addresses to particular remote IDs, and disallow an address request from an unauthorized remote ID. IP Spoofing The circuit access device may associate the IP address assigned by a DHCP server in a forwarded DHCP Ack packet with the circuit to which it was forwarded. The circuit access device MAY prevent forwarding of IP packets with source IP addresses -other than- those it has associated with the receiving circuit. This prevents simple IP spoofing attacks on the Central LAN, and IP spoofing of other hosts. Client Identifer Spoofing By using the agent-supplied Agent Remote ID option, the untrusted and as-yet unstandardized client identifer field need not be used by the DHCP server. Expires November 2000 [Page 11] May 1, 2000 MAC Address Spoofing By associating a MAC address with an Agent Remote ID, the DHCP server can prevent offering an IP address to an attacker spoofing the same MAC address on a different remote ID. 5.0 Security Considerations DHCP as currently defined provides no authentication or security mechanisms. Potential exposures to attack are discussed in section 7 of the DHCP protocol specification in RFC 2131 [1]. This document introduces mechanisms to address several security attacks on the operation of IP address assignment, including IP spoofing, Client ID spoofing, MAC address spoofing, and DHCP server address exhaustion. It relies on an implied trusted relationship between the DHCP Relay Agent and the DHCP server, with an assumed untrusted DHCP client. It introduces a new identifer, the "Remote ID", that is also assumed to be trusted. The Remote ID is provided by the access network or modem and not by client premise equipment. Cryptographic or other techniques to authenticate the remote ID are certainly possible and encouraged, but are beyond the scope of this document. Note that any future mechanisms for authenticating DHCP client to server communications must take care to omit the DHCP Relay Agent option from server authentication calculations. This was the principal reason for organizing the DHCP Relay Agent Option as a single option with sub-options, and for requiring the relay agent to remove the option before forwarding to the client. While it is beyond the scope of this document to specify the general forwarding algorithm of public data circuit access units, note that automatic reforwarding of IP or ARP broadcast packets back downstream exposes serious IP security risks. For example, if an upstream broadcast DHCP-DISCOVER or DHCP-REQUEST were re-broadcast back downstream, any public host may easily spoof the desired DHCP server. 6.0 IANA Considerations IANA is required to maintain a new number space of "DHCP Relay Agent Sub-options", with the initial sub-options as described in this document. IANA MUST assign future DHCP Relay Agent Sub-options with a "IETF Consensus" policy as described in RFC 2434 [3]. Future proposed sub-options MUST be referenced symbolically in the internet-drafts that describe them, and shall be assigned numeric codes by IANA when Expires November 2000 [Page 12] May 1, 2000 and if the draft is approved by IESG for Proposed Standard RFC status. 7.0 Intellectual Property Notices This section contains two notices as required by [5] for standards track documents. Per [5], section 10.4(A): The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. Per [5] section 10.4(D): The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. 8.0 References Expires November 2000 [Page 13] May 1, 2000 [1] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131, Bucknell University, March 1997. [2] Alexander,S. and Droms, R., "DHCP Options and BOOTP Vendor Extension" RFC 2132. [3] Narten,T. and Alvestrand, H. "Guidelines for Writing an IANA Considerations Section in RFCs", RFC 2434. [4] Bradner, S. "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119. [5] Bradner, S. "The Internet Standards Process -- Revision 3", RFC 2026. [6] Kent, S. and Atkinson, R. "Security Architecture for the Internet Protocol", RFS 2401. 9.0 Glossary IANA Internet Assigned Numbers Authority LIS Logical IP Subnet MAC Message Authentication Code RAS Remote Access Server 10.0 Author's Address Michael Patrick Motorola Broadband Communications Sector 20 Cabot Blvd., MS M4-30 Mansfield, MA 02048 Phone: (508) 261-5707 Email: mpatrick@dma.isg.mot.com Expires November 2000 [Page 14] From owner-dhcp-v4@bucknell.edu Mon May 1 15:17:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03546 for ; Mon, 1 May 2000 15:17:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA25804; Mon, 1 May 2000 15:14:10 -0400 (EDT) Received: from beach.sctc.com (beach.sctc.com [192.55.214.50]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA27904 for ; Mon, 1 May 2000 15:14:07 -0400 (EDT) Received: from beach.sctc.com (root@localhost) by beach.sctc.com with ESMTP id OAA10803; Mon, 1 May 2000 14:07:48 -0500 (CDT) Received: from sphinx.sctc.com (sphinx.sctc.com [172.17.192.3]) by beach.sctc.com with ESMTP id OAA10799; Mon, 1 May 2000 14:07:48 -0500 (CDT) Received: from stpsowk45 (stpsowk45.sctc.com [172.17.192.169]) by sphinx.sctc.com (8.8.8+Sun/8.7.3) with ESMTP id OAA02077; Mon, 1 May 2000 14:14:13 -0500 (CDT) Received: from localhost (allison@localhost) by stpsowk45 (8.9.3+Sun/) with ESMTP id OAA11790; Mon, 1 May 2000 14:12:13 -0500 (CDT) Date: Mon, 1 May 2000 14:12:13 -0500 (CDT) From: Tylor Allison X-Sender: allison@stpsowk45.sctc.com To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Relayed lease extension In-Reply-To: <200005011544.IAA03154@grosse.manhattan.fugue.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: allison@securecomputing.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN On Mon, 1 May 2000, Ted Lemon wrote: > If the client acts like it's in the REBINDING state, the DHCP server > *must* honor giaddr. The only time that the server's expected > behaviour is not defined for giaddr is when the client is acting like > it's in the RENEWING state. So if you want consistent behaviour, you > shouldn't have the client fill in giaddr when it's acting like it's in > the RENEWING state. > > I will freely admit that this isn't entirely optimal - it would be > nice if the standard said that the server MUST honor giaddr in favor > of ciaddr, but it doesn't, so you're stuck. :'} > > _MelloN_ Even using the giaddr field does not solve all implementation scenarios. The scenario I've been wrestling with is having a DHCP client (similar to the BixBox described previously) hosted on the same machine as a DHCP server. In this scenario the client cannot use the giaddr field (to act as a DHCP relay agent) because the DHCP server port is already bound to the local DHCP server. Any ideas on how this can be accomplished using the current DHCP standards? Does it make sense to support this scenario at all? --- Tylor Allison tylor_allison@securecomputing.com Secure Computing Corporation From owner-dhcp-v4@bucknell.edu Mon May 1 15:30:34 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03848 for ; Mon, 1 May 2000 15:30:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA30199; Mon, 1 May 2000 15:29:16 -0400 (EDT) Received: from mailgate2.austin.ibm.com (mg02.austin.ibm.com [192.35.232.12]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA12619 for ; Mon, 1 May 2000 15:29:05 -0400 (EDT) Received: from netmail2.austin.ibm.com (netmail2.austin.ibm.com [9.53.250.97]) by mailgate2.austin.ibm.com (AIX4.3/8.9.3/8.9.3) with ESMTP id OAA21966 for ; Mon, 1 May 2000 14:30:11 -0500 Received: from yeast.austin.ibm.com (yeast.austin.ibm.com [9.53.150.239]) by netmail2.austin.ibm.com (8.8.5/8.8.5) with ESMTP id OAA26534; Mon, 1 May 2000 14:29:04 -0500 Received: from austin.ibm.com (yeast.austin.ibm.com [9.53.150.239]) by yeast.austin.ibm.com (AIX4.3/8.9.3/8.7-client1.01) with ESMTP id OAA20656; Mon, 1 May 2000 14:29:03 -0500 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <390DDAFF.D8BBFB3D@austin.ibm.com> Date: Mon, 01 May 2000 14:29:03 -0500 From: David Babbitt X-Mailer: Mozilla 4.7 [en] (X11; U; AIX 4.3) X-Accept-Language: en-US, en, es MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: Relayed lease extension References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dbabbitt@austin.ibm.com X-Sender: dbabbitt@austin.ibm.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > Any ideas on how this can be accomplished using the current DHCP > standards? Does it make sense to support this scenario at all? > It's a hack, but you could make the client use REBIND instead of RENEW, and you may have to always set the broadcast bit (depends on how your server learns of your hwaddr.) Like the rest of the discussion in this thread, this might also depend on how lenient the server is. The second question is probably more philosophical :) I guess it makes sense if you want to use DHCP as a client for some interfaces on which the server won't receive requests from clients, but I'd have to lean to the "no" answer for anything else. Dave -- David Babbitt AIX TCP/IP Development IBM Austin From owner-dhcp-v4@bucknell.edu Mon May 1 15:33:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03974 for ; Mon, 1 May 2000 15:33:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA11114; Mon, 1 May 2000 15:32:16 -0400 (EDT) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA01693 for ; Mon, 1 May 2000 15:32:07 -0400 (EDT) Received: by process.com (MX V5.1-X A2w8g) id 61; Mon, 1 May 2000 15:31:32 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Mon, 1 May 2000 15:31:31 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E970A.CA109CE7.61@process.com> Subject: Re: Relayed lease extension Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN >Even using the giaddr field does not solve all implementation >scenarios. The scenario I've been wrestling with is having a DHCP >client (similar to the BixBox described previously) hosted on the same >machine as a DHCP server. In this scenario the client cannot use the >giaddr field (to act as a DHCP relay agent) because the DHCP server port >is already bound to the local DHCP server. > >Any ideas on how this can be accomplished using the current DHCP >standards? Does it make sense to support this scenario at all? I guess that is a good point if you want to act as a relay on the same system on which the server is running. This would, however, also cause problems with the INITIAL lease assignment and thus is not just with the renewal process. Depending on your TCP/IP stack on the "bigbox", you may be able to set up an alternate address and listen for packets on to that address on port 68. - Bernie From owner-dhcp-v4@bucknell.edu Mon May 1 17:02:36 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06368 for ; Mon, 1 May 2000 17:02:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA06159; Mon, 1 May 2000 16:58:34 -0400 (EDT) Received: from gateway.assuredaccess.com (gateway.assuredaccess.com [206.169.126.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA31867 for ; Mon, 1 May 2000 16:58:18 -0400 (EDT) Received: from assuredaccess.com ([10.193.101.165]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA212; Mon, 1 May 2000 14:00:08 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <390DF02F.56A10DD7@assuredaccess.com> Date: Mon, 01 May 2000 13:59:27 -0700 From: Wim Janssen Organization: Alcatel Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: Relayed lease extension References: <200005011544.IAA03154@grosse.manhattan.fugue.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Reply-To: wjanssen@assuredaccess.com X-Sender: janssenw X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > For renewals, how are they handled? The renewl is sent by BigBox with > the client's IP address. If the response is send back to the cleint's > IP address, then either: > a) BigBox must take steps to prevent it from going to the client and > intercept it. I'm not really in favor of snooping all DHCP packets, which would be the only solution if the DHCPACK is returned to the PPP user. AnyBox would loose a lot of its performance in doing so. > If the client acts like it's in the REBINDING state, the DHCP server > *must* honor giaddr. The only time that the server's expected > behaviour is not defined for giaddr is when the client is acting like > it's in the RENEWING state. So if you want consistent behaviour, you > shouldn't have the client fill in giaddr when it's acting like it's in > the RENEWING state. Would it be a valid scenario, if the client immediately went to REBINDING state (and doesn't fill in ciaddr), when T2 expires (and didn't do anything when T1 expires)? I suppose the server doesn't know that this client is skipping the RENEWING state. Of course, this would be a temporary solution, as long as there is no definite answer. > The scenario I've been wrestling with is having a DHCP >client (similar to the BixBox described previously) hosted on the same >machine as a DHCP server. In this scenario the client cannot use the >giaddr field (to act as a DHCP relay agent) because the DHCP server port >is already bound to the local DHCP server. That's a similar problem BigBox has, when it wants to relay *real* dhcp clients. If it can only listen for a single DHCP server port, it has to make its decisions based on its knowledge of client leases it owns, and decide whether it needs to relay the request to a real dhcp client or not. Wim From owner-dhcp-v4@bucknell.edu Mon May 1 19:05:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08045 for ; Mon, 1 May 2000 19:05:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA02818; Mon, 1 May 2000 19:01:30 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA08516 for ; Mon, 1 May 2000 19:01:19 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac3t.dialup.mindspring.com [207.69.48.125]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id AAA09118; Mon, 1 May 2000 00:21:58 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id QAA07635; Mon, 1 May 2000 16:01:33 -0700 (MST) Message-Id: <200005012301.QAA07635@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Relayed lease extension In-Reply-To: Message from Tylor Allison of "Mon, 01 May 2000 14:12:13 CDT." Date: Mon, 01 May 2000 19:01:33 -0400 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Any ideas on how this can be accomplished using the current DHCP > standards? Does it make sense to support this scenario at all? Criminy, man! I think the answer in this case is currently that you're SOL. Sorry about that. I do a lot of DHCP development on my laptop, and the only way I've found to work around this issue is to assign more than one IP address to the DHCP client/server machine and bind to specific addresses. In combination with BPF, this gives me the behaviour I want, but I wouldn't want to have to tell a customer how to do it! _MelloN_ From owner-dhcp-v4@bucknell.edu Mon May 1 19:40:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA08359 for ; Mon, 1 May 2000 19:40:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA27293; Mon, 1 May 2000 19:36:06 -0400 (EDT) Received: from mail.sanlight.com (IDENT:root@mail.sanlight.com [208.184.100.76]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA25809 for ; Mon, 1 May 2000 19:36:00 -0400 (EDT) Received: from sanlight.com (IDENT:medi@medi.sanlight.com [208.184.100.70]) by mail.sanlight.com (8.9.3/8.9.3) with ESMTP id QAA07741 for ; Mon, 1 May 2000 16:34:24 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <390E14BD.70BD735D@sanlight.com> Date: Mon, 01 May 2000 16:35:25 -0700 From: Medi Montaseri X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: fixed-address statement Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: medi@sanlight.com X-Sender: medi@sanlight.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit How do I use the fixed-addres statement, is the following correct subnet x.x.x.x netmask x.x.x.x { range x.x.x.x. y.y.y.y; option router x.x.x.x.; ..other options.... host xyz { fixed-address x.x.x.x } } The client is a DHCP client not a BootP client. -- ===================================================================== Medi Montaseri, Software Eng, medi@sanlight.com ===================================================================== From owner-dhcp-v4@bucknell.edu Mon May 1 20:03:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08581 for ; Mon, 1 May 2000 20:03:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id UAA07325; Mon, 1 May 2000 20:02:38 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id UAA15143 for ; Mon, 1 May 2000 20:02:24 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac3t.dialup.mindspring.com [207.69.48.125]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id BAA09372; Mon, 1 May 2000 01:23:03 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id RAA08051; Mon, 1 May 2000 17:02:38 -0700 (MST) Message-Id: <200005020002.RAA08051@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: fixed-address statement In-Reply-To: Message from Medi Montaseri of "Mon, 01 May 2000 16:35:25 PDT." <390E14BD.70BD735D@sanlight.com> Date: Mon, 01 May 2000 20:02:38 -0400 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > How do I use the fixed-addres statement, is the following correct Please take questions about the ISC DHCP server to the ISC DHCP server mailing list. I won't answer this question here - sorry. You can find out about the ISC DHCP server mailing list at www.isc.org. Sorry to be a pain, but making a habit of answering ISC-specific questions here is a disservice to the non-ISC WG members, who are a majority. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue May 2 01:21:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15398 for ; Tue, 2 May 2000 01:21:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id BAA00735; Tue, 2 May 2000 01:17:50 -0400 (EDT) Received: from gateway.assuredaccess.com (gateway.assuredaccess.com [206.169.126.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id BAA15981 for ; Tue, 2 May 2000 01:17:36 -0400 (EDT) Received: from assuredaccess.com ([10.193.101.165]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA268; Mon, 1 May 2000 22:19:03 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <390E651F.57AED08C@assuredaccess.com> Date: Mon, 01 May 2000 22:18:23 -0700 From: Wim Janssen Organization: Alcatel Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: Relayed lease extension References: <200005011544.IAA03154@grosse.manhattan.fugue.com> <390DF02F.56A10DD7@assuredaccess.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: wjanssen@assuredaccess.com X-Sender: janssenw X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > Would it be a valid scenario, if the client immediately went to > REBINDING state (and doesn't fill in ciaddr), when T2 expires > (and didn't do anything when T1 expires)? I myself can answer this ;-) Apparently not: 'ciaddr' is supposed to be filled in all the time, even when REBINDING. The reason behind the idea was that it still didn't work when I went to REBINDING state, and 'ciaddr' & 'giaddr' were filled in. Is this then a problem in the server? Wim From owner-dhcp-v4@bucknell.edu Tue May 2 02:39:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25316 for ; Tue, 2 May 2000 02:39:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id CAA12273; Tue, 2 May 2000 02:36:09 -0400 (EDT) Received: from ns4.sony.co.jp (ns4.Sony.CO.JP [202.238.80.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id CAA05890 for ; Tue, 2 May 2000 02:35:55 -0400 (EDT) Received: from mail2.sony.co.jp (gatekeeper7.Sony.CO.JP [202.238.80.21]) by ns4.sony.co.jp (04/18/00) with ESMTP id PAA16359; Tue, 2 May 2000 15:35:52 +0900 (JST) Received: from artisan.sm.sony.co.jp ([43.11.135.217]) by mail2.sony.co.jp (3.7W99040614b) with ESMTP id PAA04861; Tue, 2 May 2000 15:35:51 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by artisan.sm.sony.co.jp (8.8.8/3.4Wbeta3) with ESMTP id PAA00781; Tue, 2 May 2000 15:33:33 +0900 (JST) To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu From: tomy@sfc.wide.ad.jp Subject: RE: Relayed lease extension In-Reply-To: <009E96EB.369A41D0.162@process.com> References: <009E96EB.369A41D0.162@process.com> X-Mailer: Mew version 1.95b3 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) X-PGP-Fingerprint: B6 18 6F BE B7 7B 5C 01 0B 92 DE 9A 29 00 9C 2B Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000502153333J.atomy@sm.sony.co.jp> Date: Tue, 02 May 2000 15:33:33 +0900 Sender: owner-dhcp-v4@bucknell.edu X-Dispatcher: imput version 991025(IM133) Lines: 13 Reply-To: tomy@sfc.wide.ad.jp X-Sender: Akihiro Tominaga X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > Since the original lease was done by BigBox on behalf of the client, the > renewal must also be done by BigBox on behalf of the client. I agree. It may be acceptable to make the DHCP server to see giaddr field in DHCPREQUEST from RENEWING client. Although, IMHO, it is semantically correct that BigBox send RENEWING request. -- Akihiro TOMINAGA, Ph.D WIDE Project. Akihiro Tominaga (tomy@sfc.wide.ad.jp) From owner-dhcp-v4@bucknell.edu Tue May 2 14:22:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06627 for ; Tue, 2 May 2000 14:22:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA17828; Tue, 2 May 2000 14:18:09 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA32227 for ; Tue, 2 May 2000 14:18:05 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kacsj.dialup.mindspring.com [207.69.51.147]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA13170; Mon, 1 May 2000 19:38:42 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA13923; Tue, 2 May 2000 11:18:19 -0700 (MST) Message-Id: <200005021818.LAA13923@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Relayed lease extension In-Reply-To: Message from Wim Janssen of "Mon, 01 May 2000 22:18:23 PDT." <390E651F.57AED08C@assuredaccess.com> Date: Tue, 02 May 2000 14:18:19 -0400 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here's the table from the standard: --------------------------------------------------------------------- | |INIT-REBOOT |SELECTING |RENEWING |REBINDING | --------------------------------------------------------------------- |broad/unicast |broadcast |broadcast |unicast |broadcast | |server-ip |MUST NOT |MUST |MUST NOT |MUST NOT | |requested-ip |MUST |MUST |MUST NOT |MUST NOT | |ciaddr |zero |zero |IP address |IP address| --------------------------------------------------------------------- It looks like the DHCPREQUEST in RENEWING and REBINDING states is the same, so you don't get any benefit from mimicking the REBINDING state when you really want the RENEWING state - they should both look the same to the server. RFC2131 says, in section 4.1 (constructing and sending DHCP messages): If the 'giaddr' field in a DHCP message from a client is non-zero, the server sends any return messages to the 'DHCP server' port on the BOOTP relay agent whose address appears in 'giaddr'. If the 'giaddr' field is zero and the 'ciaddr' field is nonzero, then the server unicasts DHCPOFFER and DHCPACK messages to the address in 'ciaddr'. If 'giaddr' is zero and 'ciaddr' is zero, and the broadcast bit is set, then the server broadcasts DHCPOFFER and DHCPACK messages to 0xffffffff. If the broadcast bit is not set and 'giaddr' is zero and 'ciaddr' is zero, then the server unicasts DHCPOFFER and DHCPACK messages to the client's hardware address and 'yiaddr' address. In all cases, when 'giaddr' is zero, the server broadcasts any DHCPNAK messages to 0xffffffff. So if you set giaddr and the response comes back to ciaddr, the DHCP server is in violation of the protocol. I'm sorry for not having read the specification before responding earlier - in fact, the specification says what needs to be said quite clearly, and if you are experiencing different behaviour from a DHCP server, you should contact the server vendor and request an update. Sigh. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue May 2 19:33:14 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA10379 for ; Tue, 2 May 2000 19:33:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA02012; Tue, 2 May 2000 19:29:27 -0400 (EDT) Received: from gateway.assuredaccess.com (gateway.assuredaccess.com [206.169.126.4]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA20001 for ; Tue, 2 May 2000 19:29:17 -0400 (EDT) Received: from assuredaccess.com ([10.193.101.165]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA153; Tue, 2 May 2000 16:31:10 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <390F6517.DE7C6CD9@assuredaccess.com> Date: Tue, 02 May 2000 16:30:31 -0700 From: Wim Janssen Organization: Alcatel Telecom X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list CC: DHCPv4 discussion list Subject: Re: Relayed lease extension References: <200005021818.LAA13923@grosse.manhattan.fugue.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Reply-To: wjanssen@assuredaccess.com X-Sender: janssenw X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Ted Lemon wrote: > > It looks like the DHCPREQUEST in RENEWING and REBINDING states is the > same, so you don't get any benefit from mimicking the REBINDING state > when you really want the RENEWING state - they should both look the > same to the server. RFC2131 says, in section 4.1 (constructing and > sending DHCP messages): With all due respect - & with apologies if I look too persistent - I must say the rfc actually assumes that a DHCPREQUEST won't contain 'giaddr' when generated during RENEWING state. On the other hand, it doesn't mention 'giaddr' when the client is in REBINDING state. Section 4.3.2 (DHCPREQUEST message): Clients send DHCPREQUEST messages as follows: o DHCPREQUEST generated during RENEWING state: 'server identifier' MUST NOT be filled in, 'requested IP address' option MUST NOT be filled in, 'ciaddr' MUST be filled in with client's IP address. In this situation, the client is completely configured, and is trying to extend its lease. This message will be unicast, so no relay agents will be involved in its transmission. Because 'giaddr' is therefore not filled in, the DHCP server will trust the value in 'ciaddr', and use it when replying to the client. So your initial remark, stating that 'giaddr' can be filled in & needs to be addressed when responding during REBINDING state is perfectly valid - which is what I will do (for now). > So if you set giaddr and the response comes back to ciaddr, the DHCP > server is in violation of the protocol. > > I'm sorry for not having read the specification before responding > earlier - in fact, the specification says what needs to be said quite > clearly, and if you are experiencing different behaviour from a DHCP > server, you should contact the server vendor and request an update. I just did. Wim From owner-dhcp-v4@bucknell.edu Wed May 3 01:37:12 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19135 for ; Wed, 3 May 2000 01:37:09 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id BAA08197; Wed, 3 May 2000 01:33:16 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id BAA08833 for ; Wed, 3 May 2000 01:33:06 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac01.dialup.mindspring.com [207.69.48.1]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id GAA16581; Tue, 2 May 2000 06:53:44 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id WAA21318; Tue, 2 May 2000 22:33:17 -0700 (MST) Message-Id: <200005030533.WAA21318@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Relayed lease extension In-Reply-To: Message from Wim Janssen of "Tue, 02 May 2000 16:30:31 PDT." <390F6517.DE7C6CD9@assuredaccess.com> Date: Wed, 03 May 2000 01:33:17 -0400 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > So your initial remark, stating that 'giaddr' can be filled in & needs > to be addressed when responding during REBINDING state is perfectly > valid - which is what I will do (for now). The section of the RFC that I quoted applies to _all_ DHCP messages originating from the DHCP server, not just to certain ones. If giaddr is set, the server is very clearly required to send the message to giaddr, *not* to the client. The state the client is in is irrelevant. The fact that the giaddr-specific behaviour is not reiterated in the section you quoted is immaterial. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed May 3 10:04:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02595 for ; Wed, 3 May 2000 10:04:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA06646; Wed, 3 May 2000 10:00:42 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA30450 for ; Wed, 3 May 2000 10:00:40 -0400 (EDT) From: jerome.privat@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Wed, 3 May 2000 14:57:02 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Wed, 3 May 2000 14:56:54 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2040874CC@mbtlipnt02.btlabs.bt.co.uk> To: DHCPv4 discussion list Subject: User Class draft Date: Wed, 3 May 2000 14:56:56 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN includes the last changes agreed on this list. It has been out for a couple of weeks now without further comments. Could we go to WG Last Call for this draft? Jerome Privat, BT From owner-dhcp-v4@bucknell.edu Wed May 3 10:32:37 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03244 for ; Wed, 3 May 2000 10:32:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA15760; Wed, 3 May 2000 10:30:42 -0400 (EDT) Received: from alcor.process.com (alcor.process.com [192.42.95.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA13027 for ; Wed, 3 May 2000 10:30:31 -0400 (EDT) Received: by process.com (MX V5.1-X A2w8g) id 138; Wed, 3 May 2000 10:30:08 -0400 Sender: owner-dhcp-v4@bucknell.edu Date: Wed, 3 May 2000 10:30:08 -0400 From: Bernie Volz To: DHCPv4 discussion list CC: DHCP-V4@bucknell.edu Message-ID: <009E9873.04504B2A.138@process.com> Subject: RE: User Class draft Reply-To: volz@process.com X-Sender: volz@process.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > includes the last changes agreed on this >list. It has been out for a couple of weeks now without further comments. > >Could we go to WG Last Call for this draft? Sorry about these late comments ... I have a nit with the draft as it stands. This change is recommended to clarify the definition of the option data. In section 4 it current says: >Each User Class value is indicated in an opaque field and is >preceded by a one-byte field giving its length. >The length of the option as specified in Len must be the sum >of the lengths of each of the class names, starting with Len1 >through to the length of the last class. > > > Code Len Len1 Len2 > +-----+-----+-----+----------+-----+--------------+---- > | TBD | N | L1 | class 1 | L2 | class 2 |... > +-----+-----+-----+----------+-----+--------------+---- I assume L1, L2, ... are the length of the class name (class 1, ...) PLUS the 1 byte for the length. The security section (5) is also a bit weak. It might be useful to point out that there is no explicit authentication of whether a particular client is allowed to use a user class or not - we "trust" the client to supply an appropriate class. And, perhaps it is worth pointing out that naming this "user class" is really not correct as there is NO true correlation to the user(s) of the client system. It is really a client class (however name is already taken). While I can understand reasons for wanting to keep the draft flexible and leave a lot of the policy issues to server implementations, I think that for this option to be useful, a warning that says something to the effect that "servers implementations are free to intreprete the meanings of multiple class specifications as they desire and thus the behavoir when multiple classes are specified by a client is not standardized." - Bernie Volz IPWorks, Inc. From owner-dhcp-v4@bucknell.edu Wed May 3 11:46:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04648 for ; Wed, 3 May 2000 11:46:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA29891; Wed, 3 May 2000 11:41:00 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA10694 for ; Wed, 3 May 2000 11:40:54 -0400 (EDT) Received: from kkinnear-nt (ch2-dhcp133-199.cisco.com [161.44.133.199]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA23837; Wed, 3 May 2000 11:40:24 -0400 (EDT) Message-Id: <4.2.0.58.20000503112241.019b4100@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 03 May 2000 11:41:20 -0400 To: DHCPv4 discussion list From: Kim Kinnear Subject: RE: User Class draft Cc: kkinnear@cisco.com, volz@process.com In-Reply-To: <009E9873.04504B2A.138@process.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 At 10:30 AM 5/3/00 -0400, Bernie Volz wrote: > > includes the last changes agreed on this > >list. It has been out for a couple of weeks now without further comments. > > > >Could we go to WG Last Call for this draft? > >Sorry about these late comments ... > >I have a nit with the draft as it stands. This change is recommended to >clarify the definition of the option data. > >In section 4 it current says: > > >Each User Class value is indicated in an opaque field and is > >preceded by a one-byte field giving its length. > >The length of the option as specified in Len must be the sum > >of the lengths of each of the class names, starting with Len1 > >through to the length of the last class. > > > > > > Code Len Len1 Len2 > > +-----+-----+-----+----------+-----+--------------+---- > > | TBD | N | L1 | class 1 | L2 | class 2 |... > > +-----+-----+-----+----------+-----+--------------+---- > >I assume L1, L2, ... are the length of the class name (class 1, ...) >PLUS the 1 byte for the length. I read the draft w/out looking at Bernie's comments and I had the same problem as Bernie. As described, the Len1, Len2 etc. would seem to be the length of class 1, class 2. If this is the case, i.e., if they don't also include themselves, then Len cannot equal Len1 + Len2 +...+ Lenn, because it would come up "n" short. But the draft says that Len is the sum of all of the Len1...Lenn. So, either Len1 must equal the length of Class 1 + 1, *or* Len should be defined as Len1 + Len2 + ... + Lenn + n. I don't care which, but one of these should be made clear. >The security section (5) is also a bit weak. It might be useful to point >out that there is no explicit authentication of whether a particular >client is allowed to use a user class or not - we "trust" the client to >supply an appropriate class. > >And, perhaps it is worth pointing out that naming this "user class" is >really not correct as there is NO true correlation to the user(s) of the >client system. It is really a client class (however name is already >taken). > >While I can understand reasons for wanting to keep the draft flexible >and leave a lot of the policy issues to server implementations, I think >that for this option to be useful, a warning that says something to the >effect that "servers implementations are free to intreprete the meanings >of multiple class specifications as they desire and thus the behavoir >when multiple classes are specified by a client is not standardized." At some level, what we are standardizing here isn't the behavior of the server when presented with a user class option, but rather the way to transmit that option from a client to the server in a standardized manner. I think that is appropriate, because the way that a server behaves when presented with a user class option will be driven totally by its configuration given by the network administrator configuring the server. That is just the way an option like this works. I think that while we could add the comment Bernie suggests above and it would be true, if we are going to add a comment, we might say something like "servers may interpret the meanings of multiple class specifications in an implementation dependent or configuration dependent manner, and so the use of multiple classes by a DHCP client should be based on the specific server implementation and configuration which will be used to process that user class option". Which is true anyway and for all user class options whether they are multiple or not because this is just the way that an option like this works. But it might make sense to stress this for multiple class specifications, since the number of different ways that a server could process it is greater than that of a single class. I could go either way, put it in or leave it out. Cheers -- Kim >- Bernie Volz > IPWorks, Inc. > From owner-dhcp-v4@bucknell.edu Wed May 3 16:39:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA10852 for ; Wed, 3 May 2000 16:39:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA00696; Wed, 3 May 2000 16:34:38 -0400 (EDT) Received: from atlas.centergate.com (atlas.centergate.com [204.74.78.20]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA08372 for ; Wed, 3 May 2000 16:34:35 -0400 (EDT) Received: from ULTRADNS6PMNFK (natpool0.186.vantas.net [12.22.21.65] (may be forged)) by atlas.centergate.com (8.10.0/8.9.11) with SMTP id e43KYOu29217 for ; Wed, 3 May 2000 13:34:25 -0700 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Static IP Date: Wed, 3 May 2000 13:40:47 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <391081B2.52E14C65@genie96.com> Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit But the part of DHCP I really want is the ability to change the config on PC's easily from one central location ( DNS/WINS/default gateway/etc) We are undergoing a network structure change ( new server, new gateway, new internet connection, etc ), and to do it in a controlled manner, I don't want to have to go to every PC every time I change the network configuration in such a way that all the PC's have to be changed. ...you will have to *touch* every single host, forcing them to release and renew their leases, to actually accomplish this... unless, of course, you use very short (say, 1 hour) leases. I really want to have PC's with meaningful names, and the only way I can see to do this is the way I am. PLEASE correct me if I am wrong. ...your users will resist you like crazy, and defeat the entire purpose by choosing their own names... I really don't care what IP address a PC gets, I just want to know that a PC sitting on Steve's desk is called "stevespc" when I want to get to it. Not "random_pc_99" or some such host. ...that means you MUST touch each machine... Windows in particular does not allow you to set the hostname, so all of your efforst may be for nought... From owner-dhcp-v4@bucknell.edu Wed May 3 17:31:06 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11655 for ; Wed, 3 May 2000 17:31:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA04211; Wed, 3 May 2000 17:27:43 -0400 (EDT) Received: from honts307.wal-mart.com (honts307.wal-mart.com [146.132.234.37]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA20394 for ; Wed, 3 May 2000 17:27:40 -0400 (EDT) Received: from honts305.homeoffice.wal-mart.com (fwnts002.wal-mart.com [146.132.235.8]) by honts307.wal-mart.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KCVTBV47; Wed, 3 May 2000 16:30:11 -0500 Received: by HONTS305.homeoffice.wal-mart.com with Internet Mail Service (5.5.2650.21) id ; Wed, 3 May 2000 16:27:25 -0500 Message-ID: From: Nathan Lane To: DHCPv4 discussion list Subject: RE: Static IP Date: Wed, 3 May 2000 16:27:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Reply-To: ndlane@wal-mart.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > But the part of DHCP I really want is the ability to change the config on > PC's easily from one central location ( DNS/WINS/default gateway/etc) > > > ...you will have to *touch* every single host, forcing them to release and > renew their leases, to actually accomplish this... unless, of course, > you > use very short (say, 1 hour) leases. > The lease time is not relevant post service pack 2. You may change the renewal interval and the parameters will change within the renewal interval without touching the lease time (after they've picked up the new renewal interval). > > ...that means you MUST touch each machine... Windows in particular does > not > allow you to set the hostname, so all of your efforst may be for nought... > Unfortunate, but true. Nathan Lane Wal-Mart Stores, Inc. (501) 277-5786 > From owner-dhcp-v4@bucknell.edu Wed May 3 18:22:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA12141 for ; Wed, 3 May 2000 18:22:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA11572; Wed, 3 May 2000 18:19:24 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA30529 for ; Wed, 3 May 2000 18:19:18 -0400 (EDT) Received: from grosse.manhattan.fugue.com (user-37kac2s.dialup.mindspring.com [207.69.48.92]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id XAA18367; Tue, 2 May 2000 23:39:36 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id PAA27402; Wed, 3 May 2000 15:19:11 -0700 (MST) Message-Id: <200005032219.PAA27402@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: User Class draft In-Reply-To: Message from Bernie Volz of "Wed, 03 May 2000 10:30:08 EDT." <009E9873.04504B2A.138@process.com> Date: Wed, 03 May 2000 18:19:11 -0400 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I assume L1, L2, ... are the length of the class name (class 1, ...) > PLUS the 1 byte for the length. I hope not, since this would be the only place in any DHCP-related protocol where the length included itself. _MelloN_ From owner-dhcp-v4@bucknell.edu Wed May 3 19:52:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA12939 for ; Wed, 3 May 2000 19:52:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA11264; Wed, 3 May 2000 19:47:51 -0400 (EDT) Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA16117 for ; Wed, 3 May 2000 19:47:41 -0400 (EDT) Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145]) by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id QAA26215 for ; Wed, 3 May 2000 16:17:09 -0700 Received: from metaip.checkpoint.com (sneakers.metainfo.com [204.29.28.213]) by cartman.metainfo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KC0737AM; Wed, 3 May 2000 16:45:10 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3910BA9C.6CE2B7BE@metaip.checkpoint.com> Date: Wed, 03 May 2000 16:47:40 -0700 From: Richard Jones Organization: Checkpoint Software Technologies X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: User Class draft References: <200005032219.PAA27402@grosse.manhattan.fugue.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: richardj@metaip.checkpoint.com X-Sender: richardj@postal.metaip.checkpoint.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Ted Lemon wrote: > > I assume L1, L2, ... are the length of the class name (class 1, ...) > > PLUS the 1 byte for the length. > > I hope not, since this would be the only place in any DHCP-related > protocol where the length included itself. > > _MelloN_ I understood the issue to be over the length byte that immediately follows the tag [TBD] byte, which describes the length of the whole option field. In the draft, it's not clear that the whole option length has to include the length byte for each userclass name as well as the length of the name itself, when multiple classnames are in the option space. Richard From owner-dhcp-v4@bucknell.edu Thu May 4 05:12:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01347 for ; Thu, 4 May 2000 05:12:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id FAA31735; Thu, 4 May 2000 05:07:04 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id FAA31695 for ; Thu, 4 May 2000 05:06:55 -0400 (EDT) From: jerome.privat@bt.com Received: from cbtlipnt02.btlabs.bt.co.uk by marvin (local) with ESMTP; Thu, 4 May 2000 09:59:56 +0100 Received: by cbtlipnt02.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Thu, 4 May 2000 09:59:51 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2040874D3@mbtlipnt02.btlabs.bt.co.uk> To: DHCPv4 discussion list Subject: RE: User Class draft Date: Thu, 4 May 2000 09:59:47 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="iso-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks all for your comments. See my answers below. 1- Length of the option I will modify the text to say: " Let n be the number of User Classes carried in the option. The length of the option as specified in Len must be the sum of the lengths of each of the class names plus n: Len= Len1 + Len2 + ...+ Lenn + n." 2- Multiple User classes I will add Kim's comment: "Servers may interpret the meanings of multiple class specifications in an implementation dependent or configuration dependent manner, and so the use of multiple classes by a DHCP client should be based on the specific server implementation and configuration which will be used to process that User class option". 3- Security section I will add to the end of the security section: "This lack of authentication mechanism means that a DHCP server cannot check if a given client or user is authorised to use a given User Class." 4- Name of the option I would prefer not to add anything here. The User Class option neither identifies a user or a client. Several clients can use the same User Class. For me the term "User" refers to the fact that a user should be able to configure this option. I will add all these modifications into version -07 of the draft if there are no further objections. Jerome Privat BT From owner-dhcp-v4@bucknell.edu Thu May 4 15:13:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14446 for ; Thu, 4 May 2000 15:13:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA19846; Thu, 4 May 2000 15:08:24 -0400 (EDT) Received: from web3201.mail.yahoo.com (web3201.mail.yahoo.com [204.71.202.198]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA32282 for ; Thu, 4 May 2000 15:08:21 -0400 (EDT) Message-ID: <20000504190804.9730.qmail@web3201.mail.yahoo.com> Received: from [136.182.2.222] by web3201.mail.yahoo.com; Thu, 04 May 2000 12:08:04 PDT Date: Thu, 4 May 2000 12:08:04 -0700 (PDT) From: Lucy Yang Subject: Re: Relayed lease extension To: DHCPv4 discussion list Cc: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Reply-To: lucy_kunming@yahoo.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN When DHCP client is moved to a nothet network segment, this client is in "re-start" mode when DHCPREQUEST may be sent out. Could someone let me know 1) if the server will detact the change and release DHCPNAK to the client and force client into INIT stage? 2) If client will be able to detact "timed out" and put it self into "INIT" stage Which would be a preferred mechanism to choose? Thanks for the help. Lucy Yang ===== Lucy Yang Sr. Software Engineer Motorola 847-435-0744 Email: lucy@bit.edu __________________________________________________ Do You Yahoo!? Send instant messages & get email alerts with Yahoo! Messenger. http://im.yahoo.com/ From owner-dhcp-v4@bucknell.edu Thu May 4 15:23:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14565 for ; Thu, 4 May 2000 15:23:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id PAA15721; Thu, 4 May 2000 15:22:26 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id PAA15477 for ; Thu, 4 May 2000 15:22:24 -0400 (EDT) Received: from agrabilnt ([198.200.138.254]) by quadntweb.quadritek.com (Post.Office MTA Undefined release Undefined ID# 0-59484U200L100S0V35) with SMTP id com; Thu, 4 May 2000 15:18:48 -0400 From: agrabil@quadritek.com (Greg Rabil) To: DHCPv4 discussion list Subject: RE: Relayed lease extension Date: Thu, 4 May 2000 15:21:41 -0400 Message-ID: <008a01bfb5fd$fa3f50b0$fe8ac8c6@quadritek.com> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20000504190804.9730.qmail@web3201.mail.yahoo.com> Reply-To: agrabil@quadritek.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit When the client appears on the new subnet. The DHCP server should send a DHCPNAK to force the client back to INIT state. Regards, Greg A. Gregory Rabil Team Leader - Network Services Development IP Services Product Group Lucent Technologies, InterNetworking Systems grabil@lucent.com agrabil@quadritek.com > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Lucy Yang > Sent: Thursday, May 04, 2000 3:08 PM > To: DHCPv4 discussion list > Cc: DHCPv4 discussion list > Subject: Re: Relayed lease extension > > > When DHCP client is moved to a nothet network segment, > this client is in "re-start" mode when DHCPREQUEST may > be sent out. > Could someone let me know > 1) if the server will detact the change and release > DHCPNAK to the client and force client into INIT > stage? > 2) If client will be able to detact "timed out" and > put it self into "INIT" stage > > Which would be a preferred mechanism to choose? > > Thanks for the help. > Lucy Yang > > > ===== > Lucy Yang > Sr. Software Engineer > Motorola > 847-435-0744 > Email: lucy@bit.edu > > __________________________________________________ > Do You Yahoo!? > Send instant messages & get email alerts with Yahoo! Messenger. > http://im.yahoo.com/ > > From owner-dhcp-v4@bucknell.edu Thu May 4 17:55:01 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA19235 for ; Thu, 4 May 2000 17:55:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA23726; Thu, 4 May 2000 17:48:30 -0400 (EDT) Received: from uplink.net (marcie.uplink.net [209.173.80.3]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA27846 for ; Thu, 4 May 2000 17:48:17 -0400 (EDT) Received: from droms-mac (pm3mi3-26.uplink.net [209.173.86.123]) by uplink.net (8.9.3/8.9.3) with ESMTP id RAA27800 for ; Thu, 4 May 2000 17:48:17 -0400 (EDT) Message-Id: <4.2.2.20000504174406.00a61810@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 04 May 2000 17:48:07 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Fwd: linklocal + DHCP servers Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Jay Goldschmidt posted the question below to the zeroconf mailing list; the discussion morphed into the broader question about whether DHCP servers should ever hand out link-local (169.254/16) addresses. Seemed like a good question to ask on the DHCP mailing list, too... There's a related question - after taking on a link-local address, should the DHCP client use that link-local address or 0.0.0.0 as the source address in subsequent broadcast DHCPDISCOVER messages? - Ralph >From: Jason Goldschmidt >To: zeroconf@merit.edu >Subject: linklocal + DHCP servers > >When a DHCP server comes up on a zeroconf network, are link-local >configured devices considered as configured devices to the DHCP server? > >Or in other words: There is a zeroconf device that has configured itself >w/ a link-local address. Can that device, send a DHCPREQUEST for its >link-local address? And if so, what should the DHCP server do with that >address request? > >A server might want to allow the zeroconf device to keep the address and >then respond w/ additional configuration information in the subsequent >DHCPACK. Though, doing so would still bring up the problems that Bernard >just mentioned about NATing for link-local addresses. > >Thanks, > >-Jason > > >*************************************) >Jason Goldschmidt jgoldsch@acm.org *) >http://coral.bucknell.edu/~jgoldsch *) >"My Reality Check Bounced" *) > -Scott Adams *) >*************************************) > > > > > From owner-dhcp-v4@bucknell.edu Thu May 4 19:17:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20772 for ; Thu, 4 May 2000 19:17:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA04204; Thu, 4 May 2000 19:13:19 -0400 (EDT) Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA20640 for ; Thu, 4 May 2000 19:13:14 -0400 (EDT) Received: from cartman.metainfo.com (cartman.metainfo.com [204.29.28.145]) by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id PAA31016 for ; Thu, 4 May 2000 15:42:25 -0700 Received: from metaip.checkpoint.com (sneakers.metainfo.com [204.29.28.213]) by cartman.metainfo.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id KJ1KVW2B; Thu, 4 May 2000 16:10:38 -0700 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3911F6B8.C4040C2E@metaip.checkpoint.com> Date: Thu, 04 May 2000 15:16:24 -0700 From: Richard Jones Organization: Checkpoint Software Technologies X-Mailer: Mozilla 4.61 [en] (X11; U; Linux 2.2.12-20 i686) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: Re: Fwd: linklocal + DHCP servers References: <4.2.2.20000504174406.00a61810@mail.bucknell.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: richardj@metaip.checkpoint.com X-Sender: richardj@postal.metaip.checkpoint.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit It's an excellent question. I can't imagine an admin wanting to configure a network to run from a pool of link-local addresses, but it seems to me that having the protocol start to carve up pieces of the address space and call them off limits (or special cases) would be a bad precedent, at the least. It sounds like the idea is to have clients come up with their own link-local addresses and have the DHCP server 'approve' them, optionally adding configuration info. Sounds like a different protocol. As far as the source address goes, (doesn't that refer to 'ciaddr'?), it looks to me like 2131 is clear about it being zero during a DHCPDISCOVER (not that I'm comfortable quoting that RFC to you, Ralph ;-). It would seem like an implementation issue if someone wanted to support clients that do otherwise, unless we want to change the protocol. Ralph Droms wrote: > Jay Goldschmidt posted the question below to the zeroconf mailing list; the > discussion morphed into the broader question about whether DHCP servers > should ever hand out link-local (169.254/16) addresses. Seemed like a good > question to ask on the DHCP mailing list, too... > > There's a related question - after taking on a link-local address, should > the DHCP client use that link-local address or 0.0.0.0 as the source > address in subsequent broadcast DHCPDISCOVER messages? > > - Ralph > > >From: Jason Goldschmidt > >To: zeroconf@merit.edu > >Subject: linklocal + DHCP servers > > > >When a DHCP server comes up on a zeroconf network, are link-local > >configured devices considered as configured devices to the DHCP server? > > > >Or in other words: There is a zeroconf device that has configured itself > >w/ a link-local address. Can that device, send a DHCPREQUEST for its > >link-local address? And if so, what should the DHCP server do with that > >address request? > > > >A server might want to allow the zeroconf device to keep the address and > >then respond w/ additional configuration information in the subsequent > >DHCPACK. Though, doing so would still bring up the problems that Bernard > >just mentioned about NATing for link-local addresses. > > > >Thanks, > > > >-Jason > > > > > >*************************************) > >Jason Goldschmidt jgoldsch@acm.org *) > >http://coral.bucknell.edu/~jgoldsch *) > >"My Reality Check Bounced" *) > > -Scott Adams *) > >*************************************) > > > > > > > > > > From owner-dhcp-v4@bucknell.edu Fri May 5 09:20:22 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18006 for ; Fri, 5 May 2000 09:20:22 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA24029; Fri, 5 May 2000 09:14:07 -0400 (EDT) Received: from monitor.internaut.com (mg-206253200-16.ricochet.net [206.253.200.16]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA00349; Fri, 5 May 2000 09:13:50 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id FAA91083; Fri, 5 May 2000 05:58:35 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: linklocal + DHCP servers Date: Fri, 5 May 2000 06:16:01 -0700 Message-ID: <004e01bfb694$101e9d00$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.2.2.20000504174406.00a61810@mail.bucknell.edu> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit draft-ietf-dhc-ipv4-autoconfig-04.txt states: [Section 4] When the client originally sent out it's request, there may have been a network problem stopping the DHCP Server from responding. To make sure this is not the case, a host with an auto-configured IP address MUST keep checking for an active DHCP Server. To do this, the host MUST attempt to fetch an IP address as described in section 1 of this document. [Section 1] This is done by sending out a DHCPDISCOVER message, with various tags set indicating what options the DHCP Client would like to receive information for [DHCPOPT]. The DHCP Client SHOULD also send the DHCP AutoConfigure option described in [DHCPAC]. So the client is supposed to send a DHCPDISCOVER, not a DHCPREQUEST. One of the arguments for *not* allowing DHCP to allocate 169.254/16 is the issue of conflict avoidance. If the DHCP server is directly attached to the 169.254/16 segment, it is possible for the DHCP server to do the same checks that the client would, namely ARP'ing for the address before allocating it. However, if the DHCP server is not directly attached, such a check would not be possible and since addresses within the 169.254/16 prefix are not supposed to be routable, it is not clear how the DHCP server could ping the address or otherwise accomplish the check. -----Original Message----- From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On Behalf Of Ralph Droms Sent: Thursday, May 04, 2000 2:48 PM To: DHCPv4 discussion list Subject: Fwd: linklocal + DHCP servers Jay Goldschmidt posted the question below to the zeroconf mailing list; the discussion morphed into the broader question about whether DHCP servers should ever hand out link-local (169.254/16) addresses. Seemed like a good question to ask on the DHCP mailing list, too... There's a related question - after taking on a link-local address, should the DHCP client use that link-local address or 0.0.0.0 as the source address in subsequent broadcast DHCPDISCOVER messages? - Ralph >From: Jason Goldschmidt >To: zeroconf@merit.edu >Subject: linklocal + DHCP servers > >When a DHCP server comes up on a zeroconf network, are link-local >configured devices considered as configured devices to the DHCP server? > >Or in other words: There is a zeroconf device that has configured itself >w/ a link-local address. Can that device, send a DHCPREQUEST for its >link-local address? And if so, what should the DHCP server do with that >address request? > >A server might want to allow the zeroconf device to keep the address and >then respond w/ additional configuration information in the subsequent >DHCPACK. Though, doing so would still bring up the problems that Bernard >just mentioned about NATing for link-local addresses. > >Thanks, > >-Jason > > >*************************************) >Jason Goldschmidt jgoldsch@acm.org *) >http://coral.bucknell.edu/~jgoldsch *) >"My Reality Check Bounced" *) > -Scott Adams *) >*************************************) > > > > > From owner-dhcp-v6@bucknell.edu Sat May 6 04:49:26 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19244 for ; Sat, 6 May 2000 04:49:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id EAA25907; Sat, 6 May 2000 04:45:02 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id EAA07304 for ; Sat, 6 May 2000 04:43:52 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA18488 for ; Sat, 6 May 2000 01:43:51 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id BAA08674 for ; Sat, 6 May 2000 01:43:51 -0700 (PDT) Received: from eng.sun.com (hobo231.Eng.Sun.COM [129.146.31.231]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with ESMTP id e468hZh574129 for ; Sat, 6 May 2000 01:43:36 -0700 (PDT) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3913DB4A.4CE44631@eng.sun.com> Date: Sat, 06 May 2000 01:43:54 -0700 From: "Michael W. Carney" Organization: SNT Internet Engineering X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Version #12 of the DHCPv6 extensions draft Content-Type: multipart/mixed; boundary="------------156CF9832665A8A27425E726" Reply-To: dhcp-v6@bucknell.edu X-Sender: Michael.Carney@eng.sun.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. --------------156CF9832665A8A27425E726 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi folks, Comments welcome! --------------156CF9832665A8A27425E726 Content-Type: text/plain; charset=us-ascii; name="dhcpv6ext.tty" Content-Disposition: inline; filename="dhcpv6ext.tty" Content-Transfer-Encoding: 7bit Internet Engineering Task Force J. Bound INTERNET DRAFT Compaq Computer Corp. DHC Working Group M. Carney Obsoletes: draft-ietf-dhc-dhcpv6exts-11.txt Sun Microsystems, Inc C. Perkins Nokia Research Center 5 May 2000 Extensions for the Dynamic Host Configuration Protocol for IPv6 draft-ietf-dhc-v6exts-12.txt Status of This Memo This document is a submission by the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the dhcp-v6@bucknell.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract The Dynamic Host Configuration Protocol for IPv6 [4] (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in typed data items that are stored in the ``extensions'' field of the DHCP message. The data items themselves are also called ``extensions.'' This document specifies the initial set of DHCP extensions, which will be periodically updated as new extensions are defined until this document reaches proposed standard. Bound, Carney, Perkins Expires 5 November 2000 [Page i] Internet Draft DHCP Extensions for IPv6 5 May 2000 After that time, individual extensions will be defined in separate documents, to be reviewed by the DHCP WG (if it still exists) and the IESG. Contents Status of This Memo i Abstract i 1. Introduction 1 2. DHCP Extension Field Format 2 3. DHCP Relay Considerations 4 4. Releasable Resource Extensions 4 4.1. IP Address Extension . . . . . . . . . . . . . . . . . . 4 4.1.1. IP Address Lifetimes . . . . . . . . . . . . . . 8 4.1.2. Client Considerations . . . . . . . . . . . . . . 9 4.1.3. Server Considerations . . . . . . . . . . . . . . 11 5. General Extensions 14 5.1. IEEE 1003.1 POSIX Timezone Extension . . . . . . . . . . 14 5.1.1. IEEE 1003.1 POSIX Timezone specifier . . . . . . 15 5.1.2. An Example: . . . . . . . . . . . . . . . . . . . 16 5.2. Domain Name Server Extension . . . . . . . . . . . . . . 17 5.3. Domain Name Suffix Extension . . . . . . . . . . . . . . 17 5.4. Service Location Protocol Directory Agent Extension . . . 17 5.5. Service Location Protocol Service Scope Extension . . . . 19 5.6. Network Time Protocol Servers Extension . . . . . . . . . 22 5.7. Network Information Service (NIS) Domain Name Extension . 22 5.8. Network Information Service (NIS) Servers Extension . . . 23 5.9. Network Information Service V2 (NIS+) Domain Extension . 23 5.10. Network Information Service V2 (NIS+) Servers Extension . 23 5.11. TCP-specific Extensions . . . . . . . . . . . . . . . . . 24 5.11.1. TCP Keepalive Interval Extension . . . . . . . . 24 6. DHCP-specific Extensions 24 6.1. Maximum DHCP Message Size Extension . . . . . . . . . . . 25 6.2. DHCP Retransmission and Configuration Parameter Extension 25 6.3. Extension Request Extension (ERE) . . . . . . . . . . . . 26 6.3.1. Client Considerations . . . . . . . . . . . . . . 26 6.3.2. Server Considerations . . . . . . . . . . . . . . 26 6.4. Subnet Prefix Extension . . . . . . . . . . . . . . . . . 26 6.4.1. Client Considerations . . . . . . . . . . . . . . 27 6.4.2. Server Considerations . . . . . . . . . . . . . . 27 6.5. Platform Specific Information Extension . . . . . . . . . 27 Bound, Carney, Perkins Expires 5 November 2000 [Page ii] Internet Draft DHCP Extensions for IPv6 5 May 2000 6.6. Platform Class Identifier Extension . . . . . . . . . . . 28 6.6.1. Client Considerations . . . . . . . . . . . . . . 29 6.6.2. Server Considerations . . . . . . . . . . . . . . 29 6.7. User Class Identifier Extension . . . . . . . . . . . . . 29 6.7.1. Client Considerations . . . . . . . . . . . . . . 30 6.7.2. Server Considerations . . . . . . . . . . . . . . 30 6.8. Reconfigure Multicast Address Extension . . . . . . . . . 30 6.9. Renumber DHCP Server Address Extension . . . . . . . . . 31 6.10. Client-Server Authentication Extension . . . . . . . . . 31 6.11. Client Key Selection Extension . . . . . . . . . . . . . 32 7. Security Considerations 33 7.1. Replay Protection . . . . . . . . . . . . . . . . . . . . 33 7.2. Default Authentication Algorithm . . . . . . . . . . . . 33 8. IANA Considerations 34 9. Acknowledgements 35 10. Full Copyright Statement 35 Chair's Address 39 Authors' Addresses 39 1. Introduction This document specifies extensions for use with the Dynamic Host Configuration Protocol for IP version 6 (DHCP). The DHCP message formats are described in the DHCP protocol document [4]. In this document, several words are used to signify the requirements of the specification, in accordance with RFC 2119 [5]. These words (MUST, SHOULD, MAY, MUST NOT, etc) are often capitalized. This document defines the overall format of information in the ``extensions'' field of DHCP messages. The extensions defined within this document specify a generalized way to distribute information useful to a wide class of devices, operating systems and configurations. Sites with a DHCP server that is shared among heterogeneous clients may choose to define other, site-specific formats for the use of the ``extensions'' field. Section 2 of this memo describes the formats of DHCP extensions. Information on registering new extensions is contained in section 8. The other sections organize the format descriptions of various extensions according to their general type, as follows: o Releasable Resource Extensions (section 4) Bound, Carney, Perkins Expires 5 November 2000 [Page 1] Internet Draft DHCP Extensions for IPv6 5 May 2000 o General Extensions (section 5) * TCP-specific Extensions o DHCP-specific Extensions (section 6) Future applications will make extensive use of an ever-increasing number and variety of network services. It is expected that client requirements for locating these network services will be satisfied by the Service Location Protocol [20], and not the DHCP. The DHCP is expected to be used for the kinds of configuration that enable clients to become fully functional as self-contained network entities. 2. DHCP Extension Field Format Extensions may be fixed length or variable length. All extensions begin with a ``Type'' field, which is a an two octet unsigned network-order integer that uniquely identifies the extension. Every extension has a two octet unsigned network-order integer ``Length'' field following the ``Type'' field. The ``Length'' field contains the number of octets of extension data that follow the ``Length'' field. Thus, the ``Length'' field value does not include the number of octets needed to carry the ``Type'' and ``Length'' fields. For some extensions, the ``Length'' field is always the same number, but it MUST still be specified. There is no requirement for alignment of data fields within existing DHCP extensions. Any extensions defined subsequent to this document MUST contain a two-octet ``Length'' field even if the value it would contain would always be fixed or zero. Unrecognized extensions MUST be silently ignored by skipping over the number of octets specified in the ``Length'' field, and processing continued for subsequent extensions. Unless and until specified otherwise by use of the ``Maximum DHCP message size'' extension (section 6.1), DHCP implementations MUST assume that that the maximum DHCP message size including extensions is limited to 1280 octets. All multi-octet quantities are in network-order. Extension Type 0 (zero) is reserved. There can be 65535 different extensions, which are divided up into the following ranges: Releasable Resource Range (1--8192) Extensions carrying data which identifies a resource which is leased by the server to a client for a finite period of time Bound, Carney, Perkins Expires 5 November 2000 [Page 2] Internet Draft DHCP Extensions for IPv6 5 May 2000 known as a ``lease''. The client agrees to stop using the resource when the lease expires, and the server guarantees that it will not allocate the resource to another client until the lease expires or the client signals that it is done using the resource. A server MUST NOT return a releasable resource to a client unless the client explicitly requests an instance of that resource from the server. This requirement ensures that only clients capable of managing a releasable resource receive them. A client MUST remember which server allocated the client a releasable resource, in order to contact that server to extend the lease on the resource or release the resource back to the server when it is finished with it. As of this writing, the only example of a type of releasable resource is an IP address, carried in the ``IP Address Extension'' (section 4.1). See the ``DHCP for IPv6'' companion document ([4]) for more details. General Range (8193-49152) Extensions in this range are informational in nature, and may point to resources which may be shared by any number of nodes. General extension proposals are reviewed by the DHC WG and IESG for general usefulness to the IETF community at large. Servers MAY return any general range extension to clients if administrative policy requires it; however, a server SHOULD only return general extensions if the client requests them using the ``Extension Request Extension'' (ERE) (section 6.3). Examples of general extensions include Domain Name Service parameters, Network Time Protocol (NTP, [14]) parameters, those carrying information pertaining to the DHCP, such as the ``Maximum DHCP Message Size'' (section 6.1), ``DHCP Retransmission and Configuration Parameter'' (section 6.2, and ``Platform Specific Information'' (section 6.5) Extensions. Site-specific Range (49153--65535) Extensions in this range are reserved for use by Site managers (administrators of the DHCP domain). Their type and content is entirely up to the administrator. DHCP implementations SHOULD permit the definition of site-specific extensions, including such information as data type and format. Note that both client and server implementations MAY need to be configured in order to properly exchange site extensions. Bound, Carney, Perkins Expires 5 November 2000 [Page 3] Internet Draft DHCP Extensions for IPv6 5 May 2000 A server SHOULD only return site-specific extensions to the client if it explicitly requests them using the ``Extension Request Extension'' (ERE) (section 6.3). All of the extensions described in this document MUST also have their default values specified, if any. Whenever an extension is received as part of a DHCP message, any reserved fields of the message MUST be ignored, and processing continued as if the reserved fields were zero. Typically, the value of the ``Type'' field is shown directly in the format illustration, and for some fixed-length extensions the value of the ``Length'' field is also shown in the format illustration for the extension. 3. DHCP Relay Considerations The DHCP Relay MUST NOT change any information in any DHCP Extension fields. All Extension information flows between DHCP Server and DHCP Client without modification by any Relay. 4. Releasable Resource Extensions Releasable resource extensions contain data identifying a specific resource leased by the server to the client for a specific period of time known as a ``lease''. Because the allocation of such extensions requires extension-specific management of the lease by both the client and the server, these extensions MUST only be returned to the client if they have been explicitly requested by the client. How the resource and its lease is managed is resource-specific (extension-specific). A client MUST remember in non-volatile storage which server allocated which releasable resource, in order to appropriately manage the lease associated with that resource. As of this writing, the only example of a releasable resource is an IP address, which is carried in the ``IP Address Extension'', discussed below. 4.1. IP Address Extension The IP address extension is used by clients and servers to refer to a particular IP address and related information such as the status of the host name associated with the IP address. All information relevant to a particular IP address allocation has been collected together within the ``IP address'' extension. Bound, Carney, Perkins Expires 5 November 2000 [Page 4] Internet Draft DHCP Extensions for IPv6 5 May 2000 The ``lease'' feature of the ``IP address'' extension is implemented by the ``Preferred lifetime'' and ``Valid lifetime'' fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | status |C|I|L|Q|A|P| reserved |scope| prefix-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) | | IP address (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) preferred lifetime (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) valid lifetime (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) DNS name (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 Length (unsigned integer, variable) The length of the Extension in octets. status The receiver's result of its attempt to honor the sender's request. C If the ``C'' bit is set, the field containing the IP address is present in the extension. I If the ``I'' bit is set, the client is informing the server that the IP address listed *was not* received from DHCP (e.g. received from Stateless Autoconfiguration, or manually configured). The ``I'' bit MUST NOT be set if the ``C'' bit is not set (IP address field MUST be present). The ``L'' bit MUST NOT be set if the ``I'' bit is set. L If the ``L'' bit is set, the preferred and valid lifetimes are present in the extension. Q If the ``Q'' bit is set, the fields included by the client are required, and must be made available by the server or else the extension must be rejected. Bound, Carney, Perkins Expires 5 November 2000 [Page 5] Internet Draft DHCP Extensions for IPv6 5 May 2000 A If the ``A'' bit is set, the client requests that the server updates DNS with a new AAAA/A6 record, as specified by the client's FQDN. P If the ``P'' bit is set, the client requests that the server updates DNS with a new PTR record, as specified by the client's FQDN. reserved MUST be zero. scope This 3-bit field is used by the client to request an IP address of a certain scope. The 3 bits form a number (0--7) which can have the following settings: 0 Don't Care 1 Globally-scoped address 2 Site local-scoped address 3 reserved 4 reserved 5 reserved 6 reserved 7 reserved prefix-len If the IP address field is present (the ``C'' bit is set), a non-zero prefix-len is the number of left-most bits of the IP address which make up the subnet prefix. Otherwise, if the ``C'' bit is not set, prefix-len MUST be zero. The prefix-len field is 7-bits in length. IP address The IP address to be conveyed to the receiver from the sender. (16 octets long). preferred lifetime The preferred lifetime of the IP address in seconds. valid lifetime The valid lifetime of the IP address in seconds. Bound, Carney, Perkins Expires 5 November 2000 [Page 6] Internet Draft DHCP Extensions for IPv6 5 May 2000 DNS name The DNS name (a string of NVT-ASCII octets) associated with the IP address. The following values for the status field are defined within this document: 0 request granted, no errors 1 IP address is already in use by a different node 2 Extension settings (bit combinations) illegal 3 IP address scope requested is not available 4 IP address requested by client is not available 18 Security parameters failed for this client 20 Resource AAAA/A6 Record Parameter Problem 21 Resource PTR Record Parameter Problem 23 DNS name string error 24 dynDNS Not Implemented 25 Authoritative DNS Server could not be found 33 The name server was unable to interpret the request due to a format error. 34 dynDNS unavailable at this time (SERVFAIL) 35 Some name that ought to exist, does not exist (NXDOMAIN) 36 The name server does not support the specified Opcode (NOTIMP) 37 The name server refuses to perform the specified operation for policy or security reasons (REFUSED) 38 Some name that ought not to exist, does exist (YXDOMAIN) 39 Some RRset that ought not to exist, does exist (YXRRSET) 40 Some RRset that ought to exist, does not exist (NXRRSET) 41 The server is not authoritative for the zone named in the Zone Section (NOTAUTH) 42 A name used in the Prerequisite or Update Section is not within the zone denoted by the Zone Section (NOTZONE) Bound, Carney, Perkins Expires 5 November 2000 [Page 7] Internet Draft DHCP Extensions for IPv6 5 May 2000 Status values 33 through 42 are described more fully within Dynamic Updates to DNS (RFC 2136 [21]). Up-to-date values for the values of the status field are specified in the most recent ``Assigned Numbers'' document [17]. The DNS name can be a host name, which does not contain the ``.'' ASCII character as a separator between DNS hierarchy components. Any name containing the ``.'' is treated as a Fully Qualified Domain Name (FQDN). The length of the DNS name may be determined by subtracting, from the Length, the length of those fixed length fields which are present. If the ``Q'' bit is set, the values or actions requested by the C, I, L, A, P bits and the scope field are required, and MUST be provided, or the extension MUST be rejected with the appropriate ``status'' field value, indicating the reason why the server was unable to fulfill the required extension attributes. The ``Q'' bit is NEVER used by the server in ``IP address'' extensions it generates. A DHCP client can include an IP address in its IP Address extension and set the ``I'' bit and the ``A'' bit and/or ``P'' bit to ask the DHCP Server to use the information contained in the extension to update the DNS on the client's behalf. This would be done for IP addresses obtained by a method other than the DHCP, such as Stateless Address Autoconfiguration, RFC 2462 [19]. If the client wishes to have its FQDN associated with one of several existing IP addresses which it has received from the DHCP Server, the client MUST supply that IP address in the IP address extension along with the FQDN. By default, the client SHOULD update the AAAA/A6 (See [7] for information about the A6 record type) record, and the server SHOULD update the PTR record. The IP Address extension permit clients and servers to use a different behavior than the default through the use of the 'Q' and 'A' bits and associated fields. 4.1.1. IP Address Lifetimes The lifetime value contained in the ``preferred'' and ``valid'' fields is a value relative to when the sender sent the message containing the ``IP address'' extension. The receiver adds these times to the current clock time in order to determine the absolute times for the ``preferred'' and ``valid'' lifetimes. Bound, Carney, Perkins Expires 5 November 2000 [Page 8] Internet Draft DHCP Extensions for IPv6 5 May 2000 4.1.2. Client Considerations Sent in a DHCP Request Message In a DHCP Request message (for each IP address extension), a client MUST initialize the ``status'' field value to zero. A client may include multiple IP Address extensions in a single DHCP Request, in order to request as many IP addresses of varying scopes or subnet prefixes as it requires. In a DHCP Request (for each address extension), a client MAY: o Request that any IP address of a specific scope be returned. The client does this by setting the scope value to the desired value. The ``C'' bit and prefix-len fields MUST NOT be set, as the client is not requesting a particular IP address. o Request the lease of some IP address on a specific network (subnet prefix) or a specific IP address (interface ID specified). The client does this by setting the ``C'' bit and including the desired information in the ``IP address'' and ``prefix-len'' fields in the extension. Note that the client MUST set the prefix-len field to the number of left-most bits representing the subnet prefix, even if it is requesting a specific IP address. o Ask that the IP address returned have the ``preferred'' and ``valid'' lifetimes suggested by the client. The client does this by setting the ``L'' bit and including the desired lifetime values in the ``preferred'' and ``valid'' lifetime fields. The client MUST use the lifetimes returned by the DHCP server. o Request that the DHCP server perform a DNS AAAA/A6 record update (``A'' bit is set) and/or DNS PTR record update (``P'' bit is set) for either an IP address the server will assign (``I'' bit not set) or the IP address the client has provided (``I'' bit set) which it acquired through a means other than DHCP, for the host name or Fully Qualified Domain Name (FQDN) the client has provided. o Specify that the attributes of the request carried by the ``IP address'' extension are required by the client by setting the ``Q'' bit. Bound, Carney, Perkins Expires 5 November 2000 [Page 9] Internet Draft DHCP Extensions for IPv6 5 May 2000 Received in a DHCP Reply Message in response to a DHCP Request When the client receives an IP address extension within a DHCP Reply message, it first validates that the bits / fields set in the extension are valid. If they aren't, the client generates a DHCP Release message including the ill-formed IP address extension, and sets the ``status'' field to 2, and sends it to the server. If the extension is valid, the client inspects the ``status'' field value to see whether the client's request has been granted. If the status is nonzero, the client should log the error, and display the error condition for action by the user and/or the network administrator. Non-zero status almost always indicates that the client will be need to modify its request before it could be satisfied by the replying DHCP server, or alternatively that the replying DHCP server will need to be given updated configuration information for the client. Upon reception of a new IP address, the client MUST perform Duplicate Address Detection (DAD) as specified in RFC 2462 [19]. If the IP address has already been allocated to the client and the client is merely requesting a renewal of the lifetime of the IP address, the client MUST NOT perform DAD, as it is using this IP address. If the client finds that the new IP address is in use by another node, the client forms a DHCP Release message including the IP address extension containing the in-use IP address, and sets the ``status'' field value to 1, and sends the Release to the DHCP server. If the client receives an IP address with zero valid lifetime and: - The DHCP Reply message has been authenticated, the client MUST immediately discontinue using that IP address. - The DHCP Reply message has no authentication, the client sets the valid lifetime for the address to 2 hours. When the preferred lifetime of an IP address leased from the DHCP server is 80% exhausted, the client SHOULD begin sending DHCP requests to the server requesting a renewal of the lease on that IP address. If the client is unsuccessful at its attempts and the valid lifetime expires, the client MUST immediately stop using that IP address. Sent in a DHCP Release Message A client sends IP address extension(s) in a DHCP Release message when: Bound, Carney, Perkins Expires 5 November 2000 [Page 10] Internet Draft DHCP Extensions for IPv6 5 May 2000 o It is releasing an IP address back to the server because it is finished using it. o It has discovered through DAD that the IP address assigned by the DHCP server is already being used by a different node. o The IP address extension received from the DHCP server has an illegal combination of bit/fields settings. o The client wishes to delete the DNS records associated with the IP address/hostname it will present to the server. 4.1.3. Server Considerations This section contains information specifying the handling of the ``IP Address'' extension by DHCP servers. Note that a server implementation MUST scan its client bindings from time to time to locate bindings whose lifetimes have expired. Those bindings SHOULD be deleted, and any DNS operations performed which are recorded in those bindings MUST be reversed. The DHCP Advertise Message and the ``IP address'' Extension The ``IP address'' extension is not used in the DHCP Advertise message. Received in a DHCP Request Message When a server processes an ``IP address'' extension within a DHCP Request, the server first validates the combination of bits / fields contained within the extension. If these bits / fields are set incorrectly, the server generates a DHCP Reply message, which includes the incorrect IP address extension from the client's request, with the ``status'' field set to 2, thereby notifying the client of the error. If the IP address extension is correct, the server processes the extension as follows: o If no IP address field is present, then the client is requesting that the server allocate an IP address of the scope identified by the ``scope'' field value. If the IP address field is present and the ``I'' bit is not set, then the client is requesting the assignment of: * A specific IP address (interface ID present) Bound, Carney, Perkins Expires 5 November 2000 [Page 11] Internet Draft DHCP Extensions for IPv6 5 May 2000 * Any IP address in the specified network (interface ID is zero) The prefix-len field specifies the length of the subnet prefix in either case. The server consults its allocation tables and attempts to select an IP address meeting the client's request which is appropriate for the link to which the client is attached. The link can be determined by the contents of the relay-agent address and prefix-len fields of the DHCP Request message. If these fields are set, then the client is off-link, otherwise the client is attached to one of the same links as the server. o If the client is requesting that the server update the DNS on its behalf (either for the IP address the server will assign or the one it provided which was acquired through some other means (not the DHCP)), the server makes the appropriate DNS dynamic update requests and records the status of the update within the ``status'' field of the IP address extension it will include in the DHCP Reply message sent to the client. If the ``Q'' bit is set, then the server will ensure that the DNS operation has completed successfully before responding to the client. If the ``Q'' bit is not set, then the server SHOULD register the update request with the DNS, and MAY immediately return its DHCP Reply without waiting for the result of the DNS operation. If the client has requested that the server perform DNS updates as part of the IP address allocation and configuration, the server MUST maintain this fact as part of the client's binding. Then, if the client eventually releases the IP address by sending a DHCP Release message or the lifetimes associated with the IP address expire because the client has not renewed them, the server MUST perform the reverse service by updating DNS again to remove the changes it has made on the client's behalf. o If the client has set the ``Q'' bit, then all fields within the IP address extension which represent attributes of interest to the client are requirements, and must be met, otherwise a DHCP Reply message is generated with the ``status'' field set identifying the portion of the request the server could not fulfill. Note that if more than one attribute of the request could not be provided, the server can only identify one of the problems in the ``status'' field. Bound, Carney, Perkins Expires 5 November 2000 [Page 12] Internet Draft DHCP Extensions for IPv6 5 May 2000 Sent in a DHCP Reply Message in response to a DHCP Request If the server is assigning an IP address (or extending the lifetimes of an existing IP address binding the client holds), the server MUST include an IP address extension for the IP address with the following settings: - the preferred lifetime - the valid lifetime If the DHCP Reply is a response to a DHCP Release, the lifetimes MUST both be zero. If the server has performed DNS operations on behalf of the client, it sets the ``A'' and ``P'' bits if the AAAA/A6 record and PTR record respectively have been updated by the DNS. The ``status'' field of the extension MUST be set by the server indicating the result of the server's attempt to honor the client's IP address-related request. If the server receives a DHCP Request from one of its clients whose address it wishes to invalidate, it can cause the client to discontinue use of the old address by including valid and preferred lifetimes with a value of zero. To perform renumbering, the server will include two IP address extensions, one to reduce the preferred and valid lifetimes for the old address, and another to give the client its new address. Received in a DHCP Release Message When a server processes an ``IP address'' extension within a DHCP Release, the server first validates the combination of bits / fields contained within the extension. If these bits / fields are set incorrectly, the server generates a DHCP Reply message, which includes the incorrect IP address extension from the client's request, with the ``status'' field set to 2, thereby notifying the client of the error. If the IP address extension is correct, the server continues to processes the extension. The client generates a DHCP Release for the following reasons: o Client is finished with the IP address. In this case, the client has determined it no longer needs the IP address, and is returning it to the server for use by other clients. Bound, Carney, Perkins Expires 5 November 2000 [Page 13] Internet Draft DHCP Extensions for IPv6 5 May 2000 The server removes the IP address from the client's binding, returning it to the general pool of IP addresses. If the server has performed DNS operations on behalf of the client regarding this IP address, the server contacts the DNS service and deletes the changes it has made regarding the FQDN/IP address. The server generates a DHCP Reply including the client's IP address extension, with the ``status'' field set to indicate the results of the release operation. o Client has discovered through DAD that the IP address is already in use by another node. The server MUST mark the errant IP address as unavailable for assignment, and SHOULD generate a log message indicating the problem to the administrator. The server then generates a DHCP Reply message containing the client's IP address extension, with the ``status'' field set to 0 to indicate that it has received the client's release. o The client has requested that the DHCP server serve as a DNS update proxy for a name associated with an IP address that it acquired outside of the DHCP. The server will undo the DNS operations it performed on behalf of this client, deletes its knowledge of those operations, and generates a DHCP Reply message including the client's IP address extension with the ``status'' field set to indicate the result of the release operation. The ``IP Address'' Extension and the DHCP Reconfigure-init Messages A server MUST NOT include an ``IP address'' extension in DHCP Reconfigure or DHCP Reconfigure-init messages. IP addresses may be changed during the DHCP Request/Reply exchange set in motion by DHCP Reconfigure-init message(s). 5. General Extensions General extensions (in the range 8193-49152) are important for many DHCP clients, and are not specific to any upper-level protocol. 5.1. IEEE 1003.1 POSIX Timezone Extension This extension allows delivery of timezone information in the form of a IEEE 1003.1 POSIX Timezone specifier, as detailed in section 5.1.1. Bound, Carney, Perkins Expires 5 November 2000 [Page 14] Internet Draft DHCP Extensions for IPv6 5 May 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8193 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IEEE 1003.1 POSIX Timezone string (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If a DHCP client finds that the POSIX Timezone extension value is misformatted, it SHOULD notify the the user of the problem and MUST discard the entire extension value. 5.1.1. IEEE 1003.1 POSIX Timezone specifier The format of the IEEE 1003.1 POSIX timezone string is specified as StdOffset[Dst[Offset],[Start[/Time],End[/Time]]] where '[' and ']' enclose optional fields, '|' indicates choice of exactly one of the alternatives, ',' and '/' represent literal characters present in the string, and: Std three or more octets for the standard timezone (Std). Any characters (or case) except a leading colon, digits, comma, minus or plus sign are allowed. Offset Indicates the value one must add to local time to arrive at UTC, of the form: [+|-]hh[:mm[:ss]]. Offset following Std is required. Digits are always interpreted as decimal number. If preceded by a '-', the timezone is east of the Prime Meridian, otherwise it is west ('+' is optional) The permissible values for hh[:mm[:ss]] are as follows: hh 0 <= hh <= 23 mm 0 <= mm <= 60 ss 0 <= ss <= 60 Offset has no default value. Dst three or more octets for the daylight savings timezone. If Dst is missing, then daylight savings time does not Bound, Carney, Perkins Expires 5 November 2000 [Page 15] Internet Draft DHCP Extensions for IPv6 5 May 2000 apply in this locale. If no Offset follows Dst, then Dst is assumed to be one hour ahead of standard time. Any characters (or case) except a leading colon, digits, comma, minus or plus sign are allowed. Start Indicates the day of the year, in one of the formats indicated below, when to change to daylight savings time. The ``Time'' field (which follows immediately after a ``/'' character, if present) indicates when the change is made, in local time. End Indicate the day of the year, in one of the formats indicated below, when to change back from daylight savings time. The ``Time'' field (which follows immediately after a ``/'' character, if present) indicates when the change is made, in local time. Time Time has the same format as Offset, except that no leading ``-'' or ``+'' is permitted. The default is 02:00:00. The day of the year can be given in one of the following formats: Jn The julian day n, (1 <= n <= 365). Leap days are not counted. n Zero-based julian day, (0 <= n <= 365). Leap days are counted so it is possible to refer to Feb 29. Mm.n.d The ``d''th day, (0 <= d <= 6) of week ``n'' of month ``m'' of the year (1 <= n <= 5, 1 <= m <= 12, where week 5 means last ``d'' day in month ``m'' which may occur in either the fourth or the fifth week. Week ``1'' is the first week in which the ``d'' day occurs. 5.1.2. An Example: For Eastern USA time zone, 1986, the Posix timezone string is as follows: EST5EDT4,116/02:00:00,298/02:00:00 Here, ``5'' is the Offset for Std, and ``4'' is the Offset for Dst. Start is the 116th day at 2am, and End is 298th day at 2am. Bound, Carney, Perkins Expires 5 November 2000 [Page 16] Internet Draft DHCP Extensions for IPv6 5 May 2000 5.2. Domain Name Server Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8194 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain Name System server addresses | | (16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Domain Name Server extension specifies a list of Domain Name System (STD13 [16]) name servers available to the client. Servers SHOULD be listed in order of preference. The minimum Length for this extension is 16 octets, and MUST always be a multiple of 16. 5.3. Domain Name Suffix Extension This extension specifies the default domain name suffix that client should use when resolving hostnames via the Domain Name System. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8195 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Domain Name Suffix (variable length) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The minimum length for this extension is 1. The domain name is a NVT-ASCII string, ``Length'' octets in size. If the Domain Name Suffix extension is not specified, and the IP Address extension received by a client contains a FQDN, then the client MAY take the part of the FQDN after the first ``.'' octet as the Domain Name Suffix. 5.4. Service Location Protocol Directory Agent Extension Entities using the Service Location Protocol (SLP) [20] need to find out the address of one or more Directory Agents in order to transact messages, and possibly the correct scope to be used in conjunction with the service attributes which are exchanged using the Service Location Protocol. Bound, Carney, Perkins Expires 5 November 2000 [Page 17] Internet Draft DHCP Extensions for IPv6 5 May 2000 The Directory Agent extension requests or specifies a Directory Agent (DA), along with zero or more scopes supported by that DA. Note that this extension MAY be included multiple times in the same DHCP Request or DHCP Reply. If so, then the extensions SHOULD be included in order of decreasing preference. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8196 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |D|F|M|T| reserved | DA length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Directory Agent (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (if present) Typed-Scope-List (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length (unsigned integer, variable) The length of the Extension in octets. D If the ``D'' bit is set, the Directory Agent field and the DA Length fields are present. F If the ``F'' bit is set, the Directory Agent is indicated by including its variable length host name or Fully Qualified Domain Name (FQDN) instead of its IP address. M If the ``M'' bit is set, the Directory Agent address MUST be present, and multicast methods for discovering Directory Agents MUST NOT be used. T If the ``T'' bit is set, the Typed-Scope-List is present. rsv reserved; ignored upon reception; MUST be sent as zero DA Length The length (in octets) of the Directory Agent field. Directory Agent The FQDN, host name, or IP address of the Directory Agent. Typed-Scope-List The string denoting the typed-scope-list formatted as explained in the description of the service scope extension (section 5.5). Bound, Carney, Perkins Expires 5 November 2000 [Page 18] Internet Draft DHCP Extensions for IPv6 5 May 2000 In order to simplify administration of the configuration of DAs for clients using SLP, the DA can be indicated by presenting its host name or FQDN instead of its IP address. This allows renumbering to proceed more smoothly as outlined in RFC1900 [6]. When the FQDN or host name is used, the server sets the ``F'' bit. The host name can be distinguished from the FQDN by the presence of a ``.'' character. In any case, the DA length field is set to be the length of the Directory Agent field. When the ``F'' bit is not set, the DA Length MUST be 16. Note that more than one Directory Agent extension may be present in a DHCP message. Each such extension may have the same or different typed-scope-list. The client may request any Directory Agent with a particular scope, by including the Directory Agent extension in a DHCP Request message with no Directory Agent address included (the ``D'' bit set to zero), and a nonempty typed-scope-list. The length of the Typed-Scope-List is only indicated implicitly by the overall length of the extension. The format of the Typed-Scope-List field is described in the service scope extension (section 5.5). The ``M'' bit MUST NOT be set when the extension is used as part of a DHCP Request message. Extension type 8196 MUST include one or more scopes if a DA address is returned. Using extension type 8196, it is not possible for different service types on the same node to be configured with different directory agents. In other words, all service agents of the same service type on the same node will be configured with the same directory agent. 5.5. Service Location Protocol Service Scope Extension This extension indicates a scope that should be used by a Service Agent (SA) as described in RFC 2165 [20], when responding to Service Request messages as specified by the Service Location Protocol (SLP). This extension MAY be included multiple times in the same DHCP Request or DHCP Reply. Bound, Carney, Perkins Expires 5 November 2000 [Page 19] Internet Draft DHCP Extensions for IPv6 5 May 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8197 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Typed-Scope-List ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length (unsigned integer, variable) The length of the Extension in octets. Typed-Scope-List In Service Location Protocol (SLP) [20], multiple service types can be hosted on the same network node. It is possible that different service types on the same computer would be administered from different scopes. Thus, extension types 8196 and 8197 have additional syntax to allow this more detailed style of service configuration. In particular, the list of scopes contained in the extensions is syntactically separated into lists pertaining to each service type. Grammatically, a typed-scope-list extension in a DHCP Reply is structured as follows: typed-scope-list = one or more maybe-typed-scope-items, separated by commas maybe-typed-scope-item = typed-scope-item, or scope-list typed-scope-item = '(' service-type '=' scope-list ')' scope-list = one or more scope-items, comma-separated A typed-scope-list extension in a DHCP Request is structured as follows: typed-scope-list = one or more maybe-typed-scope-items, separated by commas Bound, Carney, Perkins Expires 5 November 2000 [Page 20] Internet Draft DHCP Extensions for IPv6 5 May 2000 maybe-typed-scope-item = typed-scope-item, or maybe-empty-scope-list typed-scope-item = '(' service-type '=' maybe-empty-scope-list ')' maybe-empty-scope-list = zero or more scope-items, comma-separated A service type has the format defined in RFC 2609 ([9]), and a scope-item has the format defined in RFC 2608 ([10]) for ``strval''. Basically, a scope-item is a character string that has alphanumeric characters not including control characters or `(',`)',`,', \',`!',`<',`=',`>', or `"' Service schemes are special cases of schemes as defined for general URLs in RFC 1738 ([3]). The typed-scope-list MAY contain both untyped-scope-lists and typed-scope-lists. Each scope-item in each untyped-scope-list applies to every service type on the node. The string containing the typed-scope-list is NOT null-terminated. The typed-scope-list string must be UTF-8 character encoded. As an example, the scope-list ``A,B,C'' denotes scopes A, B and C for all service types on the client. In a DHCP Request, this scope string would indicate that the client wishes a directory agent which supports ANY of these three scopes. In a DHCP Reply, the scope indicates that the directory agent supports ALL of the three scopes. Suppose instead that service types ``netman'' and ``proxystuff'' are residing on a DHCP client. Then, the typed-scope-list in a DHCP Reply could be: (netman=mgmt),(proxystuff=math-dept,labs) Assuming the DHCP client with two service types ``netman'' and ``proxystuff'' did not make any scope restriction, a corresponding typed-scope-list in a DHCP Request could be: (netman=),(proxystuff=) asking for scopes for those service types. Bound, Carney, Perkins Expires 5 November 2000 [Page 21] Internet Draft DHCP Extensions for IPv6 5 May 2000 The Typed-Scope-List is described in section 5.5. The DHCP client (i.e., user agent or service agent) which receives this extension will use the indicated scope for in all SLP requests and registrations. DHCP clients MAY use extension 8197 to request scopes for one or more particular service types. Note that more than one Service Scope extension may be present in a DHCP message. The length of the typed-scope-list is only indicated implicitly by the overall length of the extension. 5.6. Network Time Protocol Servers Extension This extension specifies a list of IP addresses indicating NTP [13] servers available to the client. Servers SHOULD be listed in order of preference. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8198 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NTP server addresses | | (16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The minimum Length for this extension is 16, and the Length MUST be a multiple of 16. 5.7. Network Information Service (NIS) Domain Name Extension This extension specifies the name of the client's NIS domain. The domain is formatted as a character string consisting of characters from the NVT-ASCII character set. The minimum length for this extension is 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8199 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NIS Domain Name (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bound, Carney, Perkins Expires 5 November 2000 [Page 22] Internet Draft DHCP Extensions for IPv6 5 May 2000 5.8. Network Information Service (NIS) Servers Extension This extension specifies a list of IP addresses indicating NIS servers available to the client. Servers SHOULD be listed in order of preference. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8200 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NIS server addresses | | (16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The minimum Length for this extension is 16, and the length MUST be a multiple of 16. 5.9. Network Information Service V2 (NIS+) Domain Extension This extension specifies the name of the client's NIS+ domain. The domain is formatted as a character string consisting of characters from the NVT-ASCII character set. The minimum Length for this extension is 1. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8201 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NIS+ Client Domain Name (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.10. Network Information Service V2 (NIS+) Servers Extension This extension specifies a list of IP addresses indicating NIS+ servers available to the client. Servers SHOULD be listed in order of preference. Bound, Carney, Perkins Expires 5 November 2000 [Page 23] Internet Draft DHCP Extensions for IPv6 5 May 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8202 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NIS+ server addresses | | (16 octets each) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The minimum Length for this extension is 16, and the length MUST be a multiple of 16. 5.11. TCP-specific Extensions This section lists the extensions that affect the operation of the TCP layer on a per-interface basis. 5.11.1. TCP Keepalive Interval Extension 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8203 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Keepalive Time Interval | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This extension specifies the interval (in seconds) that the client TCP should wait before sending a keepalive message on a TCP connection. The time is specified as a 32-bit unsigned integer. A value of zero indicates that the client should not generate keepalive messages on connections unless specifically requested by an application. The length for this extension is 4. 6. DHCP-specific Extensions This section details the extensions that are used by the DHCP. Bound, Carney, Perkins Expires 5 November 2000 [Page 24] Internet Draft DHCP Extensions for IPv6 5 May 2000 6.1. Maximum DHCP Message Size Extension This extension specifies the maximum size in octets of any DHCP message that the sender of the extension is willing to accept. The size is specified as an unsigned 32-bit integer. A client may use the maximum DHCP message size extension in DHCP Request messages, but MUST NOT use the extension in other DHCP messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8204 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max DHCP Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length for this extension is 4. The minimum permissible value is 1280, as specified in RFC 2460 [8]. 6.2. DHCP Retransmission and Configuration Parameter Extension This extension allows configuration of values for DHCP retransmission and configuration variables, as specified for use when sending or receiving DHCP messages. These variables are discussed in detail in the section on ``Configuration Variables'' in the ``DHCP for IPv6'' companion document [4]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8205 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Configuration Variable Identifier (2 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New Variable Value (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The length for this extension is 10 octets. The ``Configuration Variable Identifier'' field carries an unsigned 16-bit network-order integer representing the configuration variable. The ``New Variable Value'' field carries a 64-bit network-order integer representing the value of the configuration variable. If a client uses this extension in a DHCP Request message, then the ``New Variable Value'' field MUST be 0 (zero). If a client does not receive a setting for the ``Configuration Variable Identifier'' it has requested, it MUST use Bound, Carney, Perkins Expires 5 November 2000 [Page 25] Internet Draft DHCP Extensions for IPv6 5 May 2000 the default values defined in the ``Configuration Variables'' section of the ``DHCP for IPv6'' document [4]. 6.3. Extension Request Extension (ERE) The ``Extension Request Extension'' (ERE) MAY be used by DHCP implementations to indicate which DHCP extensions they are interested in (client), or what DHCP information (e.g. extensions) are available (server). 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8206 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | B | C | D | E | ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The extension contains a list of extension ``Type'' values indicating the extension of interest. Since an extension ``Type'' field is an unsigned two-octet network-order integer, each extension is identified by two-octets. Thus, the Length field MUST always be an even number. Extension types listed in the ERE are listed in priority order, with the extensions of highest priority listed before those of lower priority. One and only one ERE extension is permitted within a DHCP message. 6.3.1. Client Considerations If the client implementation supports it, the client SHOULD generate a Extensions Request Extension identifying which extensions it is interested in and include it in its DHCP Request messages. 6.3.2. Server Considerations If a server receives a DHCP request with an ERE extension present, the server SHOULD attempt to provide valid values for all the information requested. 6.4. Subnet Prefix Extension The ``Subnet Prefix'' extension is a DHCP server-only extension used to advertise what networks are available on the client's link. Each extension carries a single subnet prefix. Bound, Carney, Perkins Expires 5 November 2000 [Page 26] Internet Draft DHCP Extensions for IPv6 5 May 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8207 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix Len (number of left-most bits) (1 octet) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Subnet Prefix Octets (variable number of octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A subnet prefix is specified by the ``Subnet Prefix Octets'' field and the ``Prefix-Len'' field. The ``Subnet Prefix Octets'' field is large enough to contain all the bits of the subnet prefix. Any unused bits in the last octet of this field MUST be set to off (zero). The length of this extension is variable. 6.4.1. Client Considerations Clients MAY use the ``Subnet Prefix'' extension value to request one or more IP addresses on that network. A client does this by forming an ``IP address'' extension with the value of the ``Subnet Prefix Octets'' field copied into the high-order portion of the ``IP address'' field (``C'' bit set) and the ``Prefix-len'' value copied into the ``prefix-len'' field of the ``IP address'' extension for each IP address desired on the advertised network. 6.4.2. Server Considerations In response to a client's DHCP Solicit message (``P'' bit set), a server SHOULD return one ``Prefix'' extension for each of the networks it is configured to manage that exist on the client's link in the resultant DHCP Advertise message. A server SHOULD NOT include ``Prefix'' extensions in its Advertise messages if the client has not requested them (``P'' bit NOT set). If a server receives a DHCP Request message with ``Prefix'' extension(s), that DHCP Request message MUST be dropped. 6.5. Platform Specific Information Extension A platform is defined as the combination of hardware and operating system (OS). Bound, Carney, Perkins Expires 5 November 2000 [Page 27] Internet Draft DHCP Extensions for IPv6 5 May 2000 This extension is used by clients and servers to exchange client-platform-specific information. The information is an opaque collection of data, presumably interpreted by platform-specific code on the clients. The definition of this information is platform specific. Clients identify their platform through the use of the Platform Class identifier extension (see Section 6.6). Clients which do not receive platform specific information SHOULD make an attempt to operate without it, although they may do so (and announce that they are doing so) in a degraded mode. If a platform vendor encodes more than one item of information in this extension, then the vendor MUST encode the extension using ``Encapsulated platform-specific extensions'' as described below. The ``Encapsulated platform-specific extensions'' field MUST be encoded as a sequence of type/length/value fields of identical syntax to the form defined for DHCP extensions (see section 2), encapsulated within the ``Platform Specific Information Extension''. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8208 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Platform-specific extension information ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The minimum length for this extension is 4. DHCP servers which support the configuration of ``Platform Specific Information'' extensions, and which have been configured with configuration information specific to some number of ``Platform Class Identifiers'' MUST select and return only those platform-specific extensions which match the ``Platform Class Identifier'' provided by the DHCP client. 6.6. Platform Class Identifier Extension This extension is used by a DHCP client to identify the hardware type and operating system platform it is hosted on. The extension value itself is an opaque value to a DHCP server, and is only used by the DHCP server to "lookup" Platform Specific Extensions associated with clients of a certain platform class. DHCP servers SHOULD also allow the association of other extensions (Releasable, General, etc) with clients of a certain platform class. Note that unlike the ``User Class Identifier'' (see section 6.7, the ``Platform Class Identifier'' does not need to be echoed back to the Bound, Carney, Perkins Expires 5 November 2000 [Page 28] Internet Draft DHCP Extensions for IPv6 5 May 2000 DHCP client because there can be one and only one ``Platform Class Identifier'' for a client. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8209 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Platform Class Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The minimum length for this extension is 4. The ``Platform Class Identifier'' is a string of UTF-8 characters of Length octets. The ``Platform Class Identifier'' represents the hardware and operating system class of which the client is a member. In order to prevent collisions in the ``Platform Class Identifier'' namespace, DHCP client vendors MUST prefix their ``Platform Class Identifiers'' with their stock symbol or some other globally recognized organizational identifier. For example, ``Platform Class Identifiers'' for Sun Microsystems Inc platforms would be prefaced by ``SUNW'', the NASDAQ stock symbol for Sun. Those associated with Microsoft platforms would be prefaced by ``MSFT''. 6.6.1. Client Considerations If the client wishes platform-specific data, it includes a platform class identifier extension identifying its platform type. 6.6.2. Server Considerations Servers not equipped to interpret the platform class identifier specified by a client MUST ignore it (although it may be reported to the DHCP administrator). Otherwise, servers SHOULD respond with the set of extensions corresponding to the platform class identifier specified by the client. 6.7. User Class Identifier Extension This extension is used by a DHCP client to optionally identify the type or category of user or applications it represents. Network administrators may define specific user class identifiers to convey information about a client's software configuration or about Bound, Carney, Perkins Expires 5 November 2000 [Page 29] Internet Draft DHCP Extensions for IPv6 5 May 2000 its user's preferences. For example, an identifier may specify that a particular machine hosting a DHCP client is a member of the class ``accounting auditors'', which have special service needs such as a particular database server or printer. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8210 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User Class Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The minimum length for this extension is 4. The user class identifier is a UTF-8 string of Length octets. The value of the ``User Class Identifier'' is selected by the administrator of the DHCP domain containing the all members of this class. Thus, a ``User Class Identifier'' need only be unique within the DHCP domain, although the administrator MAY choose to prefix the ``User Class Identifier'' with the department name in order to reduce the possibility of ``User Class Identifier'' name space collisions. 6.7.1. Client Considerations If the client is configured to request user class-specific data, it includes a User Class identifier extension for each user class it is configured with. 6.7.2. Server Considerations Servers not equipped to interpret the user class identifier specified by a client MUST ignore it (although it may be reported to the network administrator). Otherwise, servers SHOULD respond with the set of extensions corresponding to the user class identifier specified by the client. Further, if the server responds with the set of extensions corresponding to the given user class identifier, it MUST echo the client's user class identifier extension back to the client. 6.8. Reconfigure Multicast Address Extension A DHCP server can instruct its clients to join one or more multicast groups for the purposes of receiving DHCP Reconfigure or DHCP Reconfigure-init messages. The DHCP server accomplishes this by Bound, Carney, Perkins Expires 5 November 2000 [Page 30] Internet Draft DHCP Extensions for IPv6 5 May 2000 returning a ``Reconfigure Multicast Address Extension'' for each multicast address associated with the group. See the ``DHCP for IPv6'' document [4] for more details on the use of this extension. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8211 | Length = 16 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reconfigure Multicast Address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length for this extension is 16. 6.9. Renumber DHCP Server Address Extension A DHCP server can instruct its clients to change their internal records to reflect the server's newly renumbered IP address, by using the ``Renumber DHCP Server Address Extension''. This extension SHOULD be sent in the DHCP Reconfigure message. The server includes both its previous IP address and its new IP address. Providing the previous IP address allows clients to update only those resource associations owned by this server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8212 | Length = 32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Previous DHCP Server Address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | New DHCP Server Address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length for this extension is 32. 6.10. Client-Server Authentication Extension Exactly one ``Client-Server Authentication Extension'' MAY be present in any DHCP message transmitted between a client and server (or vice-versa). If present, it MUST be the last extension. Bound, Carney, Perkins Expires 5 November 2000 [Page 31] Internet Draft DHCP Extensions for IPv6 5 May 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8213 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Replay Protection | | (8 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authenticator (variable length) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length (unsigned integer, variable) 4 for the SPI, plus 8 for the replay protection, plus the number of octets in the Authenticator. SPI A Security Parameters Index (SPI) [2] identifying a security context from among those available between the DHCP client and server. Replay Protection A 64-bit timestamp (in Network Time Protocol (NTP) [15] format) (see section 7.1). Authenticator (variable length) (See Section 7.2.) This authentication extension remedies the inability of IPsec (RFC 2402 [11]) to provide for non end-to-end authentication, since authentication is needed even when the client has no IPv6 address with enough scope to reach the DHCP server. The extension can be originated by either the client or server to authenticate the rest of the data in the DHCP message. The default authentication algorithm, which MUST be supported by all clients and servers, is defined in section 7.2. SPI values 0 through 255 are reserved and, if used, MUST conform to the security context defined by that value in the most recent Assigned Numbers RFC (e.g., STD1 [17]). 6.11. Client Key Selection Extension A DHCP server may wish to indicate to a prospective client which SPI it must use to authenticate subsequent messages, using the ``Client-Server Authentication Extension''. In such cases, the Bound, Carney, Perkins Expires 5 November 2000 [Page 32] Internet Draft DHCP Extensions for IPv6 5 May 2000 server includes the ``Client Key Selection Extension'' in its DHCP Advertise message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 8214 | Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Security Parameters Index (SPI) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Security Parameters Index (SPI) [2] identifies a security context between a pair of nodes among the contexts available in the security association defined between the DHCP client and server. SPI values 0 through 255 are reserved and, if used, MUST conform to the security context defined by that value as defined in the most recent Assigned Numbers RFC (e.g.,STD1 [17]). 7. Security Considerations A security protocol is urgently needed for use with DHCP, since otherwise malicious parties could create numerous denial-of-service style attacks based on depleting available server resources or providing corrupted or infected data to unsuspecting clients. The following sections discuss aspects of security relevant for users of the Client-Server Authentication extension 6.10. See also the Security Considerations in the companion specification [4]. 7.1. Replay Protection A 64-bit timestamp, in Network Time Protocol [15](NTP) format, is used to protect against replay of previous authenticated messages by malicious agents. The NTP timestamp value used in the extension MUST be chosen, and verified, to be larger than values used by the originator in previous Client-Server Authentication extensions. On the other hand, the timestamp value MUST also be chosen (and verified) to be no greater than one year more than the last known value (if any) used by the originator. 7.2. Default Authentication Algorithm The default authentication algorithm is HMAC [12], using keyed-MD5 [18]. Given a secret key K, and "data" the information to be authenticated, HMAC_result is computed as follows: Bound, Carney, Perkins Expires 5 November 2000 [Page 33] Internet Draft DHCP Extensions for IPv6 5 May 2000 1. opad := 0x36363636363636363636363636363636 (128 bits) 2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits) 3. zero_extended_key := K extended by zeroes to be 128 bits long 4. opadded_key := zero_extended_key XOR opad 5. ipadded_key := zero_extended_key XOR ipad 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) The key K is the shared secret defined by the security association between the client and server and by the SPI value specified in the Authentication Extension. The "data" is the stream of octets in all previous fields in the DHCP message and extensions. The authenticator is the 128-bit value HMAC_result. 8. IANA Considerations This document MAY be superseded by new documents for DHCP extensions, which will then include the entire current list of valid extensions. This section details the method for specifying new extensions. Implementation specific use of undefined extensions (all those in the range 86-32767 inclusive) may conflict with other implementations, and registration is required. The following steps MUST be followed by the author of any new DHCP extension, in order to obtain acceptance of the extension as a part of the DHCP Internet Standard: 1. The author documents the new extension as an Internet Draft. 2. The author submits the Internet Draft for review through the IETF standards process as defined in "Internet Official Protocol Standards" [17]. The new extension will be submitted for eventual acceptance as an Internet Standard. 3. The author requests a number for the new extension from IANA by contacting: Internet Assigned Numbers Authority (IANA) USC/Information Sciences Institute 4676 Admiralty Way Bound, Carney, Perkins Expires 5 November 2000 [Page 34] Internet Draft DHCP Extensions for IPv6 5 May 2000 Marina del Rey, California 90292-6695 or by email as: iana@isi.edu 4. The new extension progresses through the IETF standards process; the new extension will be reviewed by the Dynamic Host Configuration Working Group (if that group still exists), or as an Internet Draft not submitted by an IETF working group. 5. If the new extension fails to gain acceptance as an Internet Standard, the assigned extension number will be returned to IANA for reassignment. This procedure for defining new extensions will ensure that: * allocation of new extension numbers is coordinated from a single authority, * new extensions are reviewed for technical correctness and appropriateness, and * documentation for new extensions is complete and published. 9. Acknowledgements The original form of this internet draft was copied directly from RFC1533 [1], written by Steve Alexander and Ralph Droms. Thanks to Mike Carney for his many helpful comments, as well as contributing the design of the Platform Specific Information and Platform Class Identifier. Thanks to Erik Guttman for his helpful suggestions for the Service Location extensions. Thanks to Ralph Droms, Matt Crawford, Thomas Narten, and Erik Nordmark for their careful review as part of the Last Call process. 10. Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures Bound, Carney, Perkins Expires 5 November 2000 [Page 35] Internet Draft DHCP Extensions for IPv6 5 May 2000 for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Bound, Carney, Perkins Expires 5 November 2000 [Page 36] Internet Draft DHCP Extensions for IPv6 5 May 2000 References [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Request for Comments (Proposed Standard) 1533, Internet Engineering Task Force, October 1993. [2] R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 1826, Internet Engineering Task Force, August 1995. [3] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource Locators (URL). Request for Comments (Proposed Standard) 1738, Internet Engineering Task Force, December 1994. [4] J. Bound, M. Carney, and C. Perkins. DHCP for IPv6. draft-ietf-dhc-dhcpv6-15.txt, May 2000. (work in progress). [5] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [6] B. Carpenter and Y. Rekhter. Renumbering Needs Work. Request for Comments (Informational) 1900, Internet Engineering Task Force, February 1996. [7] M. Crawford, C. Huitema, and S. Thomson. DNS Extensions to Support IPv6 Address Aggregation and Renumbering. draft-ietf-ipngwg-dns-lookups-07.txt, 2000. (work in progress). [8] S. Deering and R. Hinden. Internet Protocol, Version 6 (ipv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [9] E. Guttman, C. Perkins, and J. Kempf. Service Templates and Service: Schemes. Request for Comments (Proposed Standard) 2609, Internet Engineering Task Force, June 1999. [10] E. Guttman, C. Perkins, J. Veizades, and M. Day. Service Location Protocol, Version 2. Request for Comments (Proposed Standard) 2608, Internet Engineering Task Force, June 1999. [11] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [12] H. Krawczyk, M. Bellare, and R. Canetti. HMAC: Keyed-Hashing for Message Authentication. Request for Comments (Informational) 2104, Internet Engineering Task Force, February 1997. Bound, Carney, Perkins Expires 5 November 2000 [Page 37] Internet Draft DHCP Extensions for IPv6 5 May 2000 [13] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI. Request for Comments (Informational) 2030, Internet Engineering Task Force, October 1996. [14] D. L. Mills. Internet time synchronization: The Network Time Protocol. Request for Comments 1129, Internet Engineering Task Force, October 1989. [15] David L. Mills. Network Time Protocol (version 3) Specification, Implementation. Request for Comments (Draft Standard) 1305, Internet Engineering Task Force, March 1992. [16] P. V. Mockapetris. Domain names - concepts and facilities. Request for comments (standard), Internet Engineering Task Force, November 1987. [17] J. Reynolds and R. Braden. Internet Official Protocol Sandards. Request for comments (proposed standard), Internet Engineering Task Force, March 2000. [18] R. Rivest. The MD5 Message-Digest Algorithm. Request for Comments (Informational) 1321, Internet Engineering Task Force, April 1992. [19] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [20] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service Location Protocol. Request for Comments (Proposed Standard) 2165, Internet Engineering Task Force, June 1997. [21] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System (DNS UPDATE). Request for Comments (Proposed Standard) 2136, Internet Engineering Task Force, April 1997. Bound, Carney, Perkins Expires 5 November 2000 [Page 38] Internet Draft DHCP Extensions for IPv6 5 May 2000 Chair's Addresses The working group can be contacted via the current chair: Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (717) 524-1145 EMail: droms@bucknell.edu Authors' Addresses Questions about this memo can be directed to: Jim Bound Compaq Computer Corporation Mail Stop: ZK03-3/U14 110 Spitbrook Road Nashua, NH 03062 USA Phone: +1-603-884-0400 Email: bound@zk3.dec.com Mike Carney Sun Microsystems, Inc Mail Stop: UMPK17-202 901 San Antonio Road Palo Alto, CA 94303-4900 USA Phone: +1-650-786-4171 Email: mwc@eng.sun.com Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Bound, Carney, Perkins Expires 5 November 2000 [Page 39] --------------156CF9832665A8A27425E726-- From owner-dhcp-v6@bucknell.edu Sat May 6 04:50:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19262 for ; Sat, 6 May 2000 04:49:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id EAA22702; Sat, 6 May 2000 04:42:28 -0400 (EDT) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id EAA04711 for ; Sat, 6 May 2000 04:42:26 -0400 (EDT) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id BAA18438 for ; Sat, 6 May 2000 01:42:24 -0700 (PDT) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.85.31]) by sunmail1.Sun.COM (8.9.1b+Sun/8.9.1/ENSMAIL,v1.6.1-sunmail1) with ESMTP id BAA08590 for ; Sat, 6 May 2000 01:42:24 -0700 (PDT) Received: from eng.sun.com (hobo231.Eng.Sun.COM [129.146.31.231]) by jurassic.eng.sun.com (8.10.1+Sun/8.10.1) with ESMTP id e468g1h574073 for ; Sat, 6 May 2000 01:42:02 -0700 (PDT) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3913DAE9.94167D72@eng.sun.com> Date: Sat, 06 May 2000 01:42:17 -0700 From: "Michael W. Carney" Organization: SNT Internet Engineering X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.5-22 i586) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Version #15 of the DHCPv6 protocol Draft Content-Type: multipart/mixed; boundary="------------D85E2B5E82FC81B2301608FB" Reply-To: dhcp-v6@bucknell.edu X-Sender: Michael.Carney@eng.sun.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. --------------D85E2B5E82FC81B2301608FB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi folks, Here it is. Comments welcome! --------------D85E2B5E82FC81B2301608FB Content-Type: text/plain; charset=us-ascii; name="dhcpv6.tty" Content-Disposition: inline; filename="dhcpv6.tty" Content-Transfer-Encoding: 7bit Internet Engineering Task Force J. Bound INTERNET DRAFT Compaq Computer Corp. DHC Working Group M. Carney Obsoletes: draft-ietf-dhc-dhcpv6-14.txt Sun Microsystems, Inc C. Perkins Nokia Research Center 5 May 2000 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) draft-ietf-dhc-dhcpv6-15.txt Status of This Memo This document is a submission by the Dynamic Host Configuration Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the dhcp-v6@bucknell.edu mailing list. Distribution of this memo is unlimited. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at: http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at: http://www.ietf.org/shadow.html. Abstract The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters using extensions to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to ``IPv6 Stateless Address Autoconfiguration'' [15], and can be used separately or concurrently with the latter to obtain configuration parameters. Bound, Carney, Perkins Expires 1 November 2000 [Page i] Internet Draft DHCP for IPv6 5 May 2000 Contents Status of This Memo i Abstract i 1. Introduction 1 2. Terminology 2 2.1. IPv6 Terminology . . . . . . . . . . . . . . . . . . . . 2 2.2. DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3 3. DHCP Constants 5 3.1. Multicast Addresses . . . . . . . . . . . . . . . . . . . 5 3.2. UDP ports . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. DHCP message types . . . . . . . . . . . . . . . . . . . 6 3.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. Generic Error Values . . . . . . . . . . . . . . 8 3.4.2. Server-specific Error Values . . . . . . . . . . 8 3.5. Configuration Variables . . . . . . . . . . . . . . . . . 8 4. Requirements 9 5. Background 9 6. Design Goals 11 7. Non-Goals 11 8. Overview 12 8.1. How does a node know to use DHCP? . . . . . . . . . . . . 12 8.2. How does a client find out about DHCP agents? . . . . . . 12 8.3. What if the client and server(s) are on different links? 12 8.4. How does a client request configuration parameters from servers? . . . . . . . . . . . . . . . . . . . . . . . 13 8.5. What are releasable resources, and when are they used? . 13 8.6. Can a client release its releasable resources before the lease expires? . . . . . . . . . . . . . . . . . . . . . . . 14 8.7. What if the client determines its releasable resource is already being used by another client? . . . . . . . . 14 8.8. How are clients notified of server configuration changes? 14 9. Message Formats 15 9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 15 9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 16 9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 18 Bound, Carney, Perkins Expires 1 November 2000 [Page ii] Internet Draft DHCP for IPv6 5 May 2000 9.4. DHCP Reply Message Format . . . . . . . . . . . . . . . . 19 9.5. DHCP Release Message Format . . . . . . . . . . . . . . . 20 9.6. DHCP Reconfigure Message Format . . . . . . . . . . . . . 22 9.7. DHCP Reconfigure-reply Message Format . . . . . . . . . . 23 9.8. DHCP Reconfigure-init Message Format . . . . . . . . . . 24 10. DHCP Server Solicitation and Subnet Prefix Discovery 25 10.1. Solicit Message Validation . . . . . . . . . . . . . . . 25 10.2. Advertise Message Validation . . . . . . . . . . . . . . 25 10.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 26 10.3.1. Creation and sending of the Solicit message . . . 26 10.3.2. Time out and retransmission of Solicit Messages . 27 10.3.3. Receipt of Advertise messages . . . . . . . . . . 27 10.4. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 28 10.4.1. Relaying of Solicit messages . . . . . . . . . . 28 10.4.2. Relaying of Advertise messages . . . . . . . . . 28 10.5. Server Behavior . . . . . . . . . . . . . . . . . . . . . 28 10.5.1. Receipt of Solicit messages . . . . . . . . . . . 28 10.5.2. Creation and sending of Advertise messages . . . 29 11. DHCP Client-Initiated Configuration Exchange 29 11.1. Request Message Validation . . . . . . . . . . . . . . . 29 11.2. Reply Message Validation . . . . . . . . . . . . . . . . 30 11.3. Release Message Validation . . . . . . . . . . . . . . . 31 11.4. Client Behavior . . . . . . . . . . . . . . . . . . . . . 31 11.4.1. Creation and sending of Request messages . . . . 32 11.4.2. Time out and retransmission of Request Messages . 33 11.4.3. Receipt of Reply message in response to a Request 33 11.4.4. Creation and sending of Release messages . . . . 33 11.4.5. Time out and retransmission of Release Messages . 34 11.4.6. Receipt of Reply message in response to a Release 35 11.5. Relay Behavior . . . . . . . . . . . . . . . . . . . . . 35 11.5.1. Relaying of Request or Release messages . . . . . 35 11.6. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35 11.6.1. Receipt of Request messages . . . . . . . . . . . 35 11.6.2. Receipt of Release messages . . . . . . . . . . . 36 11.6.3. Creation and sending of Reply messages . . . . . 36 12. DHCP Server-Initiated Configuration Exchange 37 12.1. Reconfigure Message Validation . . . . . . . . . . . . . 37 12.2. Reconfigure-reply Message Validation . . . . . . . . . . 38 12.3. Reconfigure-init Message Validation . . . . . . . . . . . 38 12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 38 12.4.1. Creation and sending of Reconfigure messages . . 39 12.4.2. Time out and retransmission of Reconfigure messages . . . . . . . . . . . . . . . . . 40 12.4.3. Receipt of Reconfigure-reply messages . . . . . . 40 12.4.4. Creation and sending of Reconfigure-init messages 40 Bound, Carney, Perkins Expires 1 November 2000 [Page iii] Internet Draft DHCP for IPv6 5 May 2000 12.4.5. Time out and retransmission of Reconfigure-init messages . . . . . . . . . . . . . . . . . 41 12.4.6. Receipt of Request messages . . . . . . . . . . . 41 12.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 41 12.5.1. Receipt of Reconfigure messages . . . . . . . . . 42 12.5.2. Creation and sending of Reconfigure-reply messages 42 12.5.3. Receipt of Reconfigure-init messages . . . . . . 43 12.5.4. Creation and sending of Request messages . . . . 43 12.5.5. Time out and retransmission of Request messages . 43 12.5.6. Receipt of Reply messages . . . . . . . . . . . . 43 13. Using DHCP for network renumbering 43 13.1. Passive Renumbering . . . . . . . . . . . . . . . . . . . 44 13.2. Active Renumbering . . . . . . . . . . . . . . . . . . . 44 14. DHCP Client Implementator Notes 44 14.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45 14.2. Advertise Message and Configuration Parameter Caching . . 45 14.3. Time out and retransmission variables . . . . . . . . . . 45 14.4. Server Preference . . . . . . . . . . . . . . . . . . . . 45 15. DHCP Server Implementator Notes 46 15.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46 15.2. Reconfigure Considerations . . . . . . . . . . . . . . . 46 15.3. Server Preference . . . . . . . . . . . . . . . . . . . . 46 15.4. Request Message Transaction-ID Cache . . . . . . . . . . 47 16. DHCP Relay Implementator Notes 47 17. Open Issues for Working Group Discussion 47 17.1. Trade-offs: Optional fields in DHCP messages . . . . . . 47 17.2. Use DHCPv4 authentication or the current DHCPv6 method? . 48 17.3. The Reconfigure Message and Subnet Prefix Extensions . . 48 17.4. ``R'' bit in Request message not needed? . . . . . . . . 48 18. Security Considerations 48 19. Year 2000 considerations 49 20. IANA Considerations 49 21. Acknowledgements 50 A. Comparison between DHCPv4 and DHCPv6 50 B. Full Copyright Statement 52 Chair's Address 55 Bound, Carney, Perkins Expires 1 November 2000 [Page iv] Internet Draft DHCP for IPv6 5 May 2000 Author's Address 55 Bound, Carney, Perkins Expires 1 November 2000 [Page v] Internet Draft DHCP for IPv6 5 May 2000 1. Introduction This document describes DHCP for IPv6 (DHCP), a UDP [14] client / server protocol designed to reduce the cost of management of IPv6 nodes in environments where network managers require more control over the allocation of network resources more varied than that offered by ``IPv6 Stateless Autoconfiguration'' [15]. The DHCP is a stateful counterpart to stateless autoconfiguration. Note that both stateful and stateless autoconfiguration can be used concurrently in the same environment, leveraging the strengths of both mechanisms in order to reduce the cost of ownership and management of network nodes. The DHCP reduces the cost of ownership by centralizing the management of network resources such as IP addresses, routing information, OS installation information, directory service information, and other such information on a few DHCP servers, rather than distributing such information in local configuration files among each network node. The DHCP is designed to be easily extended to carry new configuration parameters through the addition of new DHCP ``extensions'' defined to carry this information. See this document's companion specification, ``Extensions for the Dynamic Host Configuration Protocol for IPv6'' [2] for specifications of existing extensions as well as information on the process by which an interested party might specify new extensions. Those readers familiar with DHCP for IPv4 [7] will find DHCP for IPv6 provides a superset of features, and benefits from the additional features of IPv6 and freedom from BOOTP [5]-backward compatibility constraints. For more information about the differences between DHCP for IPv6 and DHCP for IPv4, see Appendix A. This document is organized as follows. Section 2 defines terminology used throughout this document. Section 3 defines constant values used by DHCP. Section 4 briefly discusses requirement levels. Section 5 points the reader to helpful background specifications covering related IPv6 protocols. Section 6 discusses the design goals that influenced DHCP. Section 7 identifies some of the non-goals of this specification. Section 8 gives a high level overview of DHCP, its message types, and identifies DHCP functional entities (client, relay, server). Section 9 describes in detail the format of each DHCP message type. Section 10 discusses DHCP server solicitation and subnet prefix discovery. Section 11 discusses DHCP client-initiated configuration information exchange. Section 12 discusses DHCP server-initiated configuration information exchange. Section 13 describes how DHCP can be used to renumber networks. Section 14 presents helpful notes for DHCP client implementators. Section 15 presents helpful notes for DHCP server implementors. Bound, Carney, Perkins Expires 1 November 2000 [Page 1] Internet Draft DHCP for IPv6 5 May 2000 Section 16 presents helpful notes for DHCP relay implementors. Section 18 discusses security considerations for DHCP. 2. Terminology 2.1. IPv6 Terminology IPv6 terminology relevant to this specification from the IPv6 Protocol [6], IPv6 Addressing Architecture [8], and IPv6 Stateless Address Autoconfiguration [15] is included below. address An IP layer identifier for an interface or a set of interfaces. unicast address An identifier for a single interface. A packet sent to a unicast address is delivered to the interface identified by that address. multicast address An identifier for a set of interfaces (typically belonging to different nodes). A packet sent to a multicast address is delivered to all interfaces identified by that address. host Any node that is not a router. IP Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6 are used only in contexts where it is necessary to avoid ambiguity. interface A node's attachment to a link. link A communication facility or medium over which nodes can communicate at the link layer, i.e., the layer immediately below IP. Examples are Ethernet (simple or bridged); Token Ring; PPP links, X.25, Frame Relay, or ATM networks; and Internet (or higher) layer "tunnels", such as tunnels over IPv4 or IPv6 itself. link-layer identifier a link-layer identifier for an interface. Examples include IEEE 802 addresses for Ethernet or Token Ring network interfaces, and E.164 addresses for ISDN links. link-local address An IP address having link-only scope, indicated by Bound, Carney, Perkins Expires 1 November 2000 [Page 2] Internet Draft DHCP for IPv6 5 May 2000 having the subnet prefix (FE80::0000/64), that can be used to reach neighboring nodes attached to the same link. Every interface has a link-local address. message A unit of data carried in a packet, exchanged between DHCP agents and clients. neighbor A node attached to the same link. node A device that implements IP. packet An IP header plus payload. prefix A bit string that consists of some number of initial bits of an address. router A node that forwards IP packets not explicitly addressed to itself. 2.2. DHCP Terminology Terminology specific to DHCP can be found below. abort status A status value returned to the application that has invoked a DHCP client operation, indicating anything other than success. agent address The address of a neighboring DHCP Agent on the same link as the DHCP client. binding A binding (or, client binding) is a group of server data records indexed by containing the releasable resource data which a DHCP server has assigned to a client. Note that the transaction-ID from the Request message that produced the assignment of the releasable resource is also stored in the server data record including the releasable resource identifier. DHCP Dynamic Host Configuration Protocol for IPv6. The terms DHCPv4 and DHCPv6 are used only in contexts where it is necessary to avoid ambiguity. Bound, Carney, Perkins Expires 1 November 2000 [Page 3] Internet Draft DHCP for IPv6 5 May 2000 configuration parameter An element of the configuration information set on the server and delivered to the client using DHCP. Such parameters may be used to carry information to be used by a node to configure its network subsystem and enable communication on a link or internetwork, for example. DHCP client (or client) A node that initiates requests on a link to obtain configuration parameters from one or more DHCP servers. DHCP domain A chunk of network topology managed by DHCP and operated by a single administrative entity. DHCP server (or server) A server is a node that responds to requests from clients, and may or may not be on the same link as the client(s). DHCP relay (or relay) A node that acts as an intermediary to deliver DHCP messages between clients and servers, and is on the same link as a client. DHCP agent (or agent) Either a DHCP server on the same link as a client, or a DHCP relay. Releasable resource Any configuration resource allocated by a server for a finite period of time. As of this writing, the only example of such a resource is the IP address. Releasable resources are carried in extensions allocated out of the 1--8192 range. solicit-ID An unsigned integer generated by the client and inserted into its DHCP Solicit messages, and echoed back to the client by the server in its resultant DHCP Advertise message(s). The client uses the solicit-ID to match received Advertise messages to Solicit messages it has generated. transaction-ID An unsigned integer to match responses with replies initiated either by a client or server. Servers Bound, Carney, Perkins Expires 1 November 2000 [Page 4] Internet Draft DHCP for IPv6 5 May 2000 allocate their transaction-IDs from the range of 0--1023, and clients allocate their transaction-IDs from the range of 1024--65535. Limiting clients and servers to different ranges prevents transaction-ID collisions (e.g. client and server happen to use the same transaction-ID for unrelated transactions (e.g. client Request, server Reconfigure-init). 3. DHCP Constants This section describes various program and networking constants used by DHCP. 3.1. Multicast Addresses The DHCP makes use of the following multicast addresses: All DHCP Agents address: FF02::1:2 This link-local multicast address is used by clients to communicate with the on-link agent(s) when they do not know those agents' link-local address(es). All agents (servers and relays) are members of this multicast group. All DHCP Servers address: FF05::1:3 This site-local multicast address is used by clients or relays to communicate with server(s), either because they want to send messages to all servers or because they do not know the server(s) unicast address(es). Note that in order for a client to use this address, it must have an address of sufficient scope to be reachable by the server(s). All servers within the site are members of this multicast group. 3.2. UDP ports The DHCP uses the following destination UDP [14] port numbers. While source ports MAY be arbitrary, client implementations SHOULD permit their specification through a local configuration parameter to facilitate the use of DHCP through firewalls. 546 Client port. Used by agents to send messages to clients. Also used by servers to send messages to relays. Bound, Carney, Perkins Expires 1 November 2000 [Page 5] Internet Draft DHCP for IPv6 5 May 2000 547 Agent port. Used by clients to send messages to agents. Also used by relays to send messages to servers. 3.3. DHCP message types The DHCP defines the following message types. More detail on these message types can be found in Section 9. Message types 0 and 9--255 are reserved and MUST be silently ignored. 01 DHCP Solicit The DHCP Solicit (or Solicit) message is used by clients to locate servers and (optionally) learn about the subnet prefixes on the client's link for networks that are managed by DHCP. This message is multicast using the All-DHCP-Agents address. Relay(s) forward Solicits as necessary to off-link servers. Section 9.1 contains more details about the Solicit message. 02 DHCP Advertise The DHCP Advertise (or Advertise) message is used by servers responding to Solicits. This message is unicast to the client's link-local address (if the server and client are on the same link) or unicast to the relay through which the Solicit was sent for final delivery to the client. Section 9.2 contains more details about the Advertise message. 03 DHCP Request The DHCP Request (or Request) message is used by clients to request configuration parameters from servers. This message is unicast to the server if the client has an address with sufficient scope to be reachable by the server, otherwise it is unicast to the on-link relay through which the Advertise message was relayed. Section 9.3 contains more details about the Request message. 04 DHCP Reply The DHCP Reply (or Reply) message is used by servers responding to Request and Release messages. In the case of responding to a Request message, the Reply contains configuration parameters destined for the client. This message is unicast to the client if the client has an address of sufficient scope that is Bound, Carney, Perkins Expires 1 November 2000 [Page 6] Internet Draft DHCP for IPv6 5 May 2000 reachable by the server. Otherwise, it is unicast to the relay through which the Request or Release message was sent for final delivery to the client. Section 9.4 contains more details about the Reply message. 05 DHCP Release The DHCP Release (or Release) message is used by clients to return one or more instances of releasable resources (e.g. IP addresses) to servers. This message is unicast to the server if the client will have an address of sufficient scope after the Release operation to receive a Reply message. Otherwise, the Release message is sent through the relay. The server will acknowledge the receipt of the Release message by sending the client a Reply message. Section 9.5 contains more details about the Release message. 06 DHCP Reconfigure The DHCP Reconfigure (or Reconfigure) message is sent by servers to client(s). It contains new or updated configuration parameters for use by the client(s). This message may be unicast or multicast to the client(s). Section 9.6 contains more details about the Reconfigure message. 07 DHCP Reconfigure-reply The DHCP Reconfigure-reply (or Reconfigure-reply) message is unicast by client(s) to the server to acknowledge the receipt of a Reconfigure message. Section 9.7 contains more details about the Reconfigure-reply message. 08 DHCP Reconfigure-init The DHCP Reconfigure-init (or Reconfigure-init) message is set by server(s) to inform client(s) that the server(s) has new or updated configuration parameters, and that the client(s) are to initiate a Request/Reply transaction with the server(s) in order to receive the updated information. Section 9.8 contains more details about the Reconfigure-init message. Bound, Carney, Perkins Expires 1 November 2000 [Page 7] Internet Draft DHCP for IPv6 5 May 2000 3.4. Error Values This section describes error values exchanged between DHCP implementations. 3.4.1. Generic Error Values The following symbolic names are used between client and server implementations to convey error conditions. The following table contains the actual numeric values for each name. Note that the numeric values do not start at 1, nor are they consecutive. The errors are organized in logical groups. _______________________________________________________________ |_Error_Name___|Error_ID_|Description__________________________| |_Success______|00_______|Success______________________________| |_UnspecFail___|16_______|Failure,_reason_unspecified__________| |_AuthFailed___|17_______|Authentication_failed_or_nonexistent_| |_PoorlyFormed_|18_______|Poorly_formed_message________________| |_Unavail______|19_______|Resources_unavailable________________| 3.4.2. Server-specific Error Values The following symbolic names are used by server implementations to convey error conditions to clients. The following table contains the actual numeric values for each name. _______________________________________________________________ |_Error_Name____|Error_ID_|Description_________________________| |_NoBinding_____|20_______|Client_record_(binding)_unavailable_| |_InvalidSource_|21_______|Invalid_Client_IP_address___________| |_NoServer______|23_______|Relay_cannot_find_Server_Address____| |_ICMPError_____|64_______|Server_unreachable_(ICMP_error)_____| 3.5. Configuration Variables This section presents a table of client and server configuration variables and the default or initial values for these variables. The client-specific variables MAY be configured on the server and MAY be delivered to the client through the ``DHCP Retransmission Parameter Extension''carried in a Reply message. This extension is documented in the ``extensions document'' [2]. Bound, Carney, Perkins Expires 1 November 2000 [Page 8] Internet Draft DHCP for IPv6 5 May 2000 ______________________________________________________________ |_Parameter__________|Default_|Description____________________| |_MIN_SOL_DELAY______|1_______|MIN_(secs)_to_delay_1st_mesg___| |_MAX_SOL_DELAY______|5_______|MAX_(secs)_to_delay_1st_mesg___| |_ADV_MSG_TIMEOUT____|500_____|SOL_Retrans_timer_(msecs)______| |_ADV_MSG_MAX________|30______|MAX_timer_value_(secs)_________| |_SOL_MAX_ATTEMPTS___|-1______|MAX_attempts_(-1_=_infinite)___| |_REP_MSG_TIMEOUT____|250_____|REQ_Retrans_timer_(msecs)______| |_REQ_MSG_ATTEMPTS___|10______|MAX_Request_attempts___________| |_REL_MSG_ATTEMPTS___|5_______|MAX_Release_attempts___________| |_RECREP_MSG_TIMEOUT_|2000____|Retrans_timer_(msecs)__________| |_REC_MSG_ATTEMPTS___|10______|Reconfigure_attempts___________| |_REC_REP_MIN________|5_______|Minimum_pause_interval_(secs)__| |_REC_REP_MAX________|7200____|Maximum_pause_interval_(secs)__| |_REC_THRESHOLD______|100_____|%_of_required_clients__________| |_SRVR_PREF_WAIT_____|2_______|Advertise_Collect_timer_(secs)_| 4. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [3]. This document also makes use of internal conceptual variables to describe protocol behavior and external variables that an implementation must allow system administrators to change. The specific variable names, how their values change, and how their settings influence protocol behavior are provided to demostrate protocol behavior. An implementation is not required to have them in the exact form described here, so long as its external behavior is consistent with that described in this document. 5. Background Related work in IPv6 that would best serve an implementor to study is the IPv6 Specification [6], the IPv6 Addressing Architecture [8], IPv6 Stateless Address Autoconfiguration [15], IPv6 Neighbor Discovery Processing [12], and Dynamic Updates to DNS [17]. These specifications enable DHCP to build upon the IPv6 work to provide both robust stateful autoconfiguration and autoregistration of DNS Host Names. The IPv6 Specification provides the base architecture and design of IPv6. A key point for DHCP implementors to understand is that IPv6 requires that every link in the Internet have an MTU of 1280 octets or greater (in IPv4 the requirement is 68 octets). This means that a UDP packet of 536 octets will always pass through an internetwork Bound, Carney, Perkins Expires 1 November 2000 [Page 9] Internet Draft DHCP for IPv6 5 May 2000 (less 40 octets for the IPv6 header), as long as there are no IP options prior to the UDP header in the packet. But, IPv6 does not support fragmentation at routers, so that fragmentation takes place end-to-end between hosts. If a DHCP implementation needs to send a packet greater than 1500 octets it can either fragment the UDP packet into fragments of 1500 octets or less, or use Path MTU Discovery [10] to determine the size of the packet that will traverse a network path. DHCP clients use Path MTU discovery when they have an address of sufficient scope to reach the DHCP server. If a DHCP client does not have such an address, that client MUST fragment its packets if the resultant message size is greater than the minimum 1280 octets. Path MTU Discovery for IPv6 is supported for both UDP and TCP and can cause end-to-end fragmentation when the PMTU changes for a destination. The IPv6 Addressing Architecture specification [8] defines the address scope that can be used in an IPv6 implementation, and the various configuration architecture guidelines for network designers of the IPv6 address space. Two advantages of IPv6 are that support for multicast is required, and nodes can create link-local addresses during initialization. This means that a client can immediately use its link-local address and a well-known multicast address to begin communications to discover neighbors on the link. For instance, a client can send a Solicit message and locate a server or relay. IPv6 Stateless Address Autoconfiguration [15] (Addrconf) specifies procedures by which a node may autoconfigure addresses based on router advertisements [12], and the use of a valid lifetime to support renumbering of addresses on the Internet. In addition the protocol interaction by which a node begins stateless or stateful autoconfiguration is specified. The DHCP is one vehicle to perform stateful autoconfiguration. Compatibility with addrconf is a design requirement of DHCP (see Section 6). IPv6 Neighbor Discovery [12] is the node discovery protocol in IPv6 which replaces and enhances functions of ARP [13]. To understand IPv6 and Addrconf it is strongly recommended that implementors understand IPv6 Neighbor Discovery. Dynamic Updates to DNS [17] is a specification that supports the dynamic update of DNS records for both IPv4 and IPv6. DHCP can use the dynamic updates to DNS to integrate addresses and name space to not only support autoconfiguration, but also autoregistration in IPv6. The security model to be used with DHCPv6 should conform as closely as possible to the authentication model outlined in RFC2402 [9]. Bound, Carney, Perkins Expires 1 November 2000 [Page 10] Internet Draft DHCP for IPv6 5 May 2000 6. Design Goals - DHCP is a mechanism rather than a policy. Network administrators set their administrative policies through the configuration parameters they place upon the DHCP servers in the DHCP domain they're managing. DHCP is simply used to deliver parameters according to that policy to each of the DHCP clients within the domain. - DHCP is compatible with IPv6 stateless autoconf [15]. - DHCP does not require manual configuration of network parameters on DHCP clients, except in cases where such configuration is needed for security reasons. A node configuring itself using DHCP should require no user intervention. - DHCP does not require a server on each link. To allow for scale and economy, DHCP must work across DHCP relays. - DHCP coexists with statically configured, non-participating nodes and with existing network protocol implementations. - DHCP clients can operate on a link without IPv6 routers present. - DHCP will provide the ability to renumber network(s) when required by network administrators [4]. - A DHCP client can make multiple, different requests for configuration parameters when necessary from one or more DHCP servers at any time. DHCP will provide enough information to enable a DHCP server to keep track of a DHCP client's configuration state. - DHCP will contain the appropriate time out and retransmission mechanisms to efficiently operate in environments with high latency and low bandwidth characteristics. 7. Non-Goals This specification explicitly does not cover the following: - Specification of a DHCP server to server protocol. - How a DHCP server stores its DHCP data. - How to manage a DHCP domain or DHCP server. Bound, Carney, Perkins Expires 1 November 2000 [Page 11] Internet Draft DHCP for IPv6 5 May 2000 - How a DHCP relay is configured or what sort of information it may log. 8. Overview This section provides a general overview of the interaction between the functional entities of DHCP. The overview is organized as a series of questions and answers. Details of DHCP such as message formats and retransmissions are left to sections 9, 10, 11, 12, 14, 15, and 16. 8.1. How does a node know to use DHCP? An unconfigured node determines that it is to use DHCP for configuration of an interface by detecting the presence (or absence) of routers on the link. If router(s) are present, the node examines router advertisements to determine if DHCP should be used to configure the interface. If there are no routers present, then the node MUST use DHCP to configure the interface. Detail on this process can be found in neighbor discovery [12] and stateless autoconfiguration [15]. 8.2. How does a client find out about DHCP agents? The client forms a Solicit message, and multicasts it to the FF02::1:2(All DHCP Agents) address. Server(s) receiving the Solicit respond with Advertise message(s). If requested in the client's Solicit message, the Advertise message(s) can include one or more subnet prefix extensions [2], informing the client of subnet prefixes for the networks(s) managed by the server(s) on the client's link. Now that the client knows the IP address(es) of agents(s) on the link, it can request configuration parameters from servers. 8.3. What if the client and server(s) are on different links? Use of DHCP in such environments requires one or more DHCP relays be set up on the client's link, because a client may only have a link-local address. Relays pick up the Solicit and Request messages from the client and forward them to some set of servers within the DHCP domain. A relay will include one of its own addresses (of sufficient scope) of the interface on the same link as the client. The relay also includes the subnet prefix length of that address in the client's messages. Servers receiving the forwarded traffic use this information to aid in selecting configuration parameters appropriate to the client's link. The servers also use the relay's Bound, Carney, Perkins Expires 1 November 2000 [Page 12] Internet Draft DHCP for IPv6 5 May 2000 address as the destination to forward client-destined messages for final delivery by the relay. Relays forward client messages to servers using some combination of the FF05::1:3(All Servers) site-local multicast address, some other (perhaps a combination) of site-local multicast addresses set up within the DHCP domain to include the servers in that domain, or a list of unicast addresses for servers. The network administrator makes relay configuration decisions based upon the topological requirements (scope) of the DHCP domain they are managing. Note that if the DHCP domain spans more than the site-local scope, then the relays MUST be configured with global addresses for the client's link so as to be reachable by servers outside the relays' site-local environment. 8.4. How does a client request configuration parameters from servers? To request configuration parameters, the client forms a Request message, and sends it to the server either directly (client has an address of sufficient scope) or indirectly (through the on-link relay). The client MAY include a Extension Request Extension [2] along with other extensions to request specific information from the server. Note that the client MAY form multiple Request messages and send each of them to different servers to request potentially different information (perhaps based upon what was advertised) in order to satisfy its needs. As a client's needs may change over time (perhaps based upon an application's requirements), the client may form additional Request messages to request additional information as it is needed. The server(s) respond with Reply messages containing the requested configuration parameters, which can include status information regarding the information requested by the client. The Reply MAY also include additional information, such as a reconfiguration event multicast group for the client to join to monitor reconfiguration events, as described in section 8.8. The receipt of a Reply from a server concludes the basic request/reply transaction of the protocol. 8.5. What are releasable resources, and when are they used? A releasable resource is configuration information leased to a client by a server for some finite period of time. When negotiating for a releasable resource, the client and server agree upon a finite period of time the client may use the resource. The client MAY request a renewal of the lease on the resource at any time. The length of time of the lease (and whether it is renewable) are server-based policy tunables. The client MUST stop using the resource when the lease on Bound, Carney, Perkins Expires 1 November 2000 [Page 13] Internet Draft DHCP for IPv6 5 May 2000 the resource expires. The server MUST NOT reallocate an assigned resource before either its lease expires or the client releases the resource. See the ``extensions document'' [2] for more information about releasable resources. 8.6. Can a client release its releasable resources before the lease expires? A client forms a Release message, including extensions carrying the resource(s) to be released. The client sends the Release to the server which leased the resource(s) to the client initially. If that server cannot be reached after a certain number of attempts (see section 3.5), the client can abandon the Release attempt. In this case, the resource(s) will be reclaimed by the server(s) when the client's lease(s) expire. 8.7. What if the client determines its releasable resource is already being used by another client? If the client determines through a releasable resource-specific manner that the resource it was assigned by the server is already in use by another client, the client will form a Release message, including the extension carrying the in-use resource. The extension's status field MUST be set to the extension-specific value reflecting the ``in use'' status of the resource. For example, if the releasable resource is an IP address, the client uses Duplicate Address Detection (DAD) to verify that the IP address is not in use. If the client determines that the IP address is already in use, it forms a Release message including the IP address extension containing the appropriate status value and sends it to the server. See the ``extensions document''for details on the IP address extension. [2]. 8.8. How are clients notified of server configuration changes? There are two possibilities. Either the clients discover the new information when they revisit the server(s) to request additional configuration information / renew the lease on a releasable resource, or through a server-initiated event known as a reconfigure event. The reconfiguration feature of DHCP offers network administrators the opportunity to update configuration information on DHCP clients whenever necessary. If the information to be updated is not Bound, Carney, Perkins Expires 1 November 2000 [Page 14] Internet Draft DHCP for IPv6 5 May 2000 client-specific, the server will form a Reconfigure message and add the new or changed configuration information to it. The Reconfigure may be unicast or multicast (to a preassigned multicast address for this purpose) to one or more client(s) to which the new or updated information needs to be directed. The client(s) will acknowledge the receipt of the Reconfigure message by forming a Reconfigure-reply message and unicasting it to the server. If the configuration information change is different for each client (e.g. a change in subnet prefix, perhaps, which would affect the IP address releasable resource(s)), the server will form a Reconfigure-init message and unicast / multicast as needed to the client(s). A Reconfigure-init is a trigger which will cause the client(s) to initiate a standard Request/Reply exchange with the server in order to acquire the new or updated resources. 9. Message Formats All reserved fields in a message MUST be transmitted as zeroes and ignored by the receiver of the message. 9.1. DHCP Solicit Message Format A client multicasts a DHCP Solicit message to the FF02::1:2(All DHCP agents) address over the interface to be configured to locate one or more servers which are configured to provide configuration parameters to nodes on the client's link. Unless otherwise noted, the value of all fields are set by the client. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 1 |C|P| reserved | prefix-len | solicit-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C If set, the client requests that all servers receiving the message deallocate the releasable resources (e.g. IP addresses) associated with the client's binding. Bound, Carney, Perkins Expires 1 November 2000 [Page 15] Internet Draft DHCP for IPv6 5 May 2000 P If set, the client requests that all servers receiving the message SHOULD return a list of subnet prefix extensions identifying the networks on the client's link that the server(s) are configured to manage. reserved 0 prefix-len An unsigned 7 bit number (0-127) non-zero prefix-len is the number of leftmost bits of the agent's IPv6 address which make up the subnet prefix. The prefix-len field is set by the relay if the relay receives the Solicit message and forwards it to one or more servers. solicit-ID An unsigned 9 bit number (0-511) generated by the client used to identify this Solicit message. client's link-local address The IP link-local address of the client interface through which the client will issue the Solicit message. relay-address Set by the client to be zero. If received by a relay, set by the relay to the site-local IP address of the interface on which the relay received the client's Solicit message. Note that if the DHCP domain crosses site boundaries, the relay MUST place a globally-scoped address in this field. A client MUST send the Solicit message to the All-DHCP-Agents multicast group (see section 3.1), setting the relay-address to zero. 9.2. DHCP Advertise Message Format A server sends an Advertise message in response to a client's Solicit message. The Advertise message notifies the client of the server's IP address. If the server is so configured by the network administrator and the client requests it through the ``P'' bit in its Solicit message, the server SHOULD add a list of subnet prefix extensions to the Advertise message to notify the client of the networks it manages on the client's link. When the client and server are on different links, the server sends the Advertise message back through the relay whence the corresponding Solicit came. The solicit-ID is copied from the client's Solicit Bound, Carney, Perkins Expires 1 November 2000 [Page 16] Internet Draft DHCP for IPv6 5 May 2000 Message. The value of all fields in the Advertise message are filled in by the server and not changed in any way by any intervening relay. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 2 | reserved | solicit-ID | preference | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved 0 solicit-ID An unsigned 9 bit number (0-511) used to identify this Advertise message. Copied from the client's Solicit message. preference An octet (unsigned) indicating a server's willingness to provide service to the client. client's link-local address The IP link-local address of the client interface from which the client issued the Solicit message. relay-address The IP address of the relay interface on the same link as the client. Copied from the client's Solicit. If the server is on the same link as the client, then this field MUST be zero. server-address The site-local IP address of the server. If the DHCP domain crosses site boundaries, then this address MUST be globally-scoped. extensions See the ``extensions document'' for details [2]. See Sections 14.4 and 15.3 for information about how clients and servers handle the preference field. Bound, Carney, Perkins Expires 1 November 2000 [Page 17] Internet Draft DHCP for IPv6 5 May 2000 9.3. DHCP Request Message Format A client sends a Request message to request configuration parameters from a server. It MAY append appropriate extensions [2]. When a client reboots, it often does not have a valid IP address of sufficient scope for the server to communicate with the client. In such cases, the client MUST NOT unicast the message to the server because the server could not return a response to the client. The client MUST send the message to the server indirectly, by using the on-link relay. The client MUST fill in the relay address field with the on-link relay's IP address. If the Request message is being formed in response to a Reconfigure-init message from the server, then the transaction ID used must be copied from the Reconfigure-init. All fields in the DHCP Request message are entered by the client. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 3 |C|R| reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ C If set, the client requests the server to remove all releasable resources associated with the client binding, except those releasable resources provided as extensions. R If set, the client has rebooted and requests that the server clear any transaction-ID cache entries for the client. reserved 0 Bound, Carney, Perkins Expires 1 November 2000 [Page 18] Internet Draft DHCP for IPv6 5 May 2000 transaction-ID An unsigned integer identifier used to identify this request. client's link-local address The link-local address of the client interface from which the client will issue the Request message. relay-address The IP address of a relay's interface, copied from an Advertise message. If the server is on the same link as the client, then this field MUST BE zero. server-address The IP address of the server to which the the client's Request message is directed, copied from an Advertise message. extensions See the ``extensions document'' [2]. A DHCP client selects the transaction-ID from the range of 1024--65535 used to identify its Request. In contrast, a transaction-ID from the range of 0--1023is selected by a DHCP server to identify a Reconfigure-init. In the latter case, the transaction ID from the Reconfigure-init is copied by the client into its Request message. When the client sets the `C' bit and adds extensions documenting the releasable resources the client wishes to keep, the server is expected to deallocate all other releasable resources not listed. The server SHOULD examine the included extensions to check whether the client is still authorized to use them. 9.4. DHCP Reply Message Format A server sends a Reply message in response to a client's Request message or Release message. If a Request message is received which contains a non-zero relay address field, then the client could not unicast the Request message to the server and thus had to use a on-link relay. In that case, the server unicasts the Reply message to the relay address found in the Request message. If a Release message is received which contains a non-zero relay address field, then the client will not have an IP address of sufficient scope after the Release to receive the Reply message. In Bound, Carney, Perkins Expires 1 November 2000 [Page 19] Internet Draft DHCP for IPv6 5 May 2000 this case, the server unicasts the Reply message to the relay address found in the Release message. All the fields in the DHCP Reply message are set by the DHCP server. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 4 |R| status | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | relay-address (if present) | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R If set, the ``relay-address'' field is present. status This 7-bit field contains one of the values in the errors table in section 3.4. transaction-ID Copied from the client's Request or Release. client's link-local address Copied from the client's Request or Release message. relay-address The IP address of a relay's interface, copied from the Request or Release message. If the server is on the same link as the client, then the ``R'' bit is not set and this field is not present. extensions See the ``extensions document'' [2]. 9.5. DHCP Release Message Format A client sends a Release message to a server when it wishes to return one or more releasable resources to the server which allocated them. This can occur either because the client no longer needs the resource(s) or the client has determined through a resource-specific manner that the resource(s) are already in use by different Bound, Carney, Perkins Expires 1 November 2000 [Page 20] Internet Draft DHCP for IPv6 5 May 2000 client(s). The client communicates the reason for the premature release of the resource in the status field of the resource's extension. See ``extensions document'' [2] for more details. When a client sends a Release message, it needs to have a valid IP address with sufficient scope to allow access by the target server. If such an address is not available, a relay is used. Only those releasable resources identified by extensions are released. If no extensions are included in the Release message, then all releasable resources associated with the client's binding are to be released. The values of all fields of the Release message are set by the client. The DHCP server acknowledges the Release message by sending a Reply message. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 5 |R| reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | X-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ R If set, the ``X-address'' field contains the address of relay. If not set, the ``X-address'' field contains a non-local scope client address. reserved 0 transaction-ID An unsigned integer identifier used to identify this Release message. client's link-local address The client's link-local address for the interface from which the client issued the Release message (and to which the releasable resources are bound at the server). Bound, Carney, Perkins Expires 1 November 2000 [Page 21] Internet Draft DHCP for IPv6 5 May 2000 server-address The IP address of the server which allocated the resource. X-address If the ``R'' bit is set, the ``X-address'' field contains the IP address of the relay interface on the same link as the client. If the ``R'' bit is not set, this field contains a non-link-local IP address of the client interface from which the the client issued the Release message. extensions See the ``extensions document'' [2]. A client selects the transaction-ID from the range of 1024--65535 used to identify the Release message. A client MUST NOT specify an IP address in the client-address field that it is releasing in the extensions field. 9.6. DHCP Reconfigure Message Format A server sends a Reconfigure message when it wishes to inform one or more clients of new or updated values for configuration parameters. The new configuration parameters are carried in the extensions portion of the Reconfigure message. Note that a Reconfigure message MUST NOT carry releasable resource extensions. Reconfigure messages can ONLY be sent to clients which have established an IP address of sufficient scope as to be directly reachable by the server. Clients acknowledge Reconfigure messages with Reconfigure-reply messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 6 | reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved 0 Bound, Carney, Perkins Expires 1 November 2000 [Page 22] Internet Draft DHCP for IPv6 5 May 2000 transaction-ID An unsigned integer identifier in the range of 0--1023 chosen by the server to identify this Reconfigure message. server-address The IP address of the DHCP server issuing the Reconfigure message. MUST be of sufficient scope to be reachable by all clients. extensions See the ``extensions document'' [2]. 9.7. DHCP Reconfigure-reply Message Format A client sends a Reconfigure-reply message to acknowledge receipt of a Reconfigure message from a server. A Reconfigure-reply message can only be sent if the client has an IP address of sufficient scope to contact the server. No interaction with a relay is possible. All fields in the DHCP Reconfigure-reply message are entered by the client. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 7 |r| status | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client's link-local address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ r reserved (0) status This 7-bit field contains one of the values from the errors table in section 3.4. transaction-ID An unsigned integer identifier copied from the server's Reconfigure message. Bound, Carney, Perkins Expires 1 November 2000 [Page 23] Internet Draft DHCP for IPv6 5 May 2000 client's link-local address The client's link-local address for the interface from which the client issued the Reconfigure-reply message. server-address Copied from the Reconfigure message. 9.8. DHCP Reconfigure-init Message Format A server sends a Reconfigure-init message when it wishes to notify one or more clients of new or updated values for configuration parameters available on the server. Reconfigure-init messages can ONLY be sent to clients which have established an IP address of sufficient scope as to be directly reachable by the server. A ``Reconfigure-init'' serves as a trigger which will cause the clients to initiate a Request/Reply exchange with the server in order to receive the new information. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | msg-type = 8 | reserved | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | server-address | | (16 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | extensions (variable number and length) .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ reserved 0 transaction-ID An unsigned integer identifier in the range of 0--1023 chosen by the server to identify this Reconfigure-init message. server-address The IP address of the DHCP server issuing the Reconfigure-init message. MUST be of sufficient scope to be reachable by all clients. extensions SHOULD only include an ERE and/or authentication extensions. No configuration information SHOULD be Bound, Carney, Perkins Expires 1 November 2000 [Page 24] Internet Draft DHCP for IPv6 5 May 2000 included. See the ``extensions document'' [2] for more information about extensions. 10. DHCP Server Solicitation and Subnet Prefix Discovery This section describes how a client locates agents (relays and servers) and how it can learn about the networks on its link that are managed by these servers. The behavior of client, server, and relay implementations is discussed, along with the messages they use. 10.1. Solicit Message Validation Clients MUST silently discard any received Solicit messages. Agents MUST discard any received Solicit messages if the ``client's link-local address'' field does not contain a valid link-local address. Servers MUST discard each received Solicit message which meet the following criteria: o The ``relay-address'' field does not contain an address of sufficient scope that is reachable by the server. o The ``relay-address'' field is non-zero, but prefix-len is zero. An error message MAY be logged by the agent. The logging of such messages SHOULD be controlled by an agent implementation configuration flag. 10.2. Advertise Message Validation Servers MUST silently discard any received Advertise messages. Clients MUST discard any Advertise messages that meet any of the following criteria: o The ``Solicit-ID'' field value does not match the value the client used in its Solicit message. o The ``client's link-local address'' field value does not match the link-local address of the interface upon which the client sent the Solicit message. Relays MUST discard any Advertise messages that meet any of the following criteria: Bound, Carney, Perkins Expires 1 November 2000 [Page 25] Internet Draft DHCP for IPv6 5 May 2000 o The ``relay-address'' field does not contain the relay's address on the same link as the client. o The ``client's link-local address'' field does not contain a valid link-local address. 10.3. Client Behavior Clients use the Solicit message primarily to discover DHCP servers configured to serve networks on the link containing the client. Optionally, the client MAY set the ``P'' bit which has the effect of requesting that the server return subnet prefix extensions identifying the networks on the client's link the server is configured to manage. 10.3.1. Creation and sending of the Solicit message When creating a Solicit message, the client SHOULD start out with a buffer initialized with zeroed octets. The client sets the ``msg-type'' field to 1, and places the link-local address of the interface it wishes to configure in the link-local address field. If the client is prepared to process multiple Advertise messages in response to its Solicit message, the client will set the Solicit-ID field to 1. Every time the client initiates a new server solicitation attempt (not a retransmission), the client increments the Solicit-ID by one. If the 9-bit field rolls over to 0, then the client sets the Solicit-ID to 1. A client which will only accept the first Advertise message it receives leaves the Solicit-ID field initialized to zero. The ``C'' bit of the Solicit message is set by the client when the client has no cached knowledge of previous DHCP configuration for the interface. Setting this bit requests that the server release any information assigned to the client for the networks on the client's link. If the client desires to learn of the networks managed by DHCP on the link its interface is attached to, it sets the ``P'' bit in the Solicit message. The client transmits the Solicit message to the FF02::1:2 (All DHCP Agents) multicast address, destination port 547. The source port selection can be arbitrary, although it SHOULD be possible using a client configuration facility to set a specific source port value. Bound, Carney, Perkins Expires 1 November 2000 [Page 26] Internet Draft DHCP for IPv6 5 May 2000 10.3.2. Time out and retransmission of Solicit Messages The client's first Solicit message on the interface MUST be delayed by a random amount of time between the interval of MIN_SOL_DELAY and MAX_SOL_DELAY. This random delay desynchronizes clients which start at the same time (e.g., after a power outage). The client waits ADV_MSG_TIMEOUT, collecting Advertise messages. If no Advertise messages are received, the client retransmits the Solicit, and doubles the ADV_MSG_TIMEOUT value. This process continues until either one or more Advertise messages are received or ADV_MSG_TIMEOUT reaches the ADV_MSG_MAX value. Thereafter, Solicits are retransmitted every ADV_MSG_MAX until SOL_MAX_ATTEMPTS have been made, at which time the client stops trying to DHCP configure the interface. An event external to DHCP is required to restart the DHCP configuration process. Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 3.5. 10.3.3. Receipt of Advertise messages Upon receipt of one or more validated Advertise messages, the client selects one or more Advertise messages based upon the following criteria. - Those Advertise messages with the highest server preference value (see section 14.4) are preferred over all other Advertise messages. - Within a group of Advertise messages with the same server preference value, a client MAY select those servers whose Advertise messages advertise information of interest to the client. For example, one server may be advertising the availability of IP addresses on networks which have an address scope of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as relay address and prefix length, server preference value, networks advertised, when the advertisement was received, and so on. Depending on the requirements of the client's invoking user, the client MAY initiate a configuration exchange with the server(s) immediately, or MAY defer this exchange until later. Bound, Carney, Perkins Expires 1 November 2000 [Page 27] Internet Draft DHCP for IPv6 5 May 2000 10.4. Relay Behavior For this discussion, the Relay is assumed to have been configured with some list of server destination addresses, which may be unicast, the FF05::1:3 (All DHCP Servers) multicast address, or some other multicast address selected by the network administrator. 10.4.1. Relaying of Solicit messages When a Relay receives a valid Solicit message, it places the IP address of the interface upon which it received the Solicit message in the ``relay-address'' field of the Solicit. The Relay also places the number of bits of that make up the subnet prefix for this address in the ``prefix-len'' field of the Solicit. The Relay then forwards this Solicit to the list of server destination addresses that it has been configured with. 10.4.2. Relaying of Advertise messages When a Relay receives a valid Advertise message, it unicasts the message to the link-local address found in the ``client's link-local address'' field by way of the appropriate network interface. 10.5. Server Behavior For this discussion, the Server is assumed to have been configured in an implementation specific manner. This configuration is assumed to contain all network topology information for the DHCP domain, as well as any necessary authentication information. 10.5.1. Receipt of Solicit messages Upon the receipt of a valid Solicit message, the server first identifies the client's location within the DHCP domain. If the ``relay-address'' and / or ``prefix-len'' fields of the Solicit are zeroed, then the client is attached to the same link as the server. If these fields are non-zero, then the client exists on the same link as the network identified by these two fields. If administrative policy permits the server to respond to a client on that link, the server will generate and send an Advertise message to the client. Bound, Carney, Perkins Expires 1 November 2000 [Page 28] Internet Draft DHCP for IPv6 5 May 2000 10.5.2. Creation and sending of Advertise messages When creating an Advertise message, the server SHOULD start out with a buffer initialized with zeroed octets. The server sets the ``msg-type'' field to 2 and copies the values of the following fields from the client's Solicit to the Advertise message: o solicit-ID o client's link-local address o relay-address The server places one of its IP addresses (determined through administrator setting) in the ``server-address'' field of the Advertise message. The server initializes the ``preference'' field from its configuration information. See section 15.3 for a description of server preference. If the client requests subnet prefix extensions (by setting the ``P'' bit in its Solicit) and the server implements and is configured to provide prefix extensions, the server will generate and insert a subnet prefix extension for each network on the client's link it is configured to manage. If the ``relay-address'' field of the Advertise message is zero, then the server unicasts the Advertise message directly to the client using the ``client's link-local address'' field value as destination address. If the ``relay-address'' field is non-zero, then the server unicasts the Advertise message directly to the relay using the ``relay-address'' field value as the destination address. 11. DHCP Client-Initiated Configuration Exchange A client initiates a configuration exchange with one or more servers it has found through DHCP server solicitation whenever requested to do so by the application layer in order to acquire configuration information of interest. 11.1. Request Message Validation Clients MUST silently discard any received Request messages. Agents MUST discard any Request messages in which the ``client's link-local address'' field does not contain a valid link-local address. Bound, Carney, Perkins Expires 1 November 2000 [Page 29] Internet Draft DHCP for IPv6 5 May 2000 Relays MUST discard any received Request messages in which the ``relay-address'' field value does not match any of the relay's addresses. Servers MUST discard any received Request message which meets any of the following criteria: o The ``server-address'' field value does not match any of the server's addresses. o If the ``relay-address'' field is set, and that field's value does not contain an address of sufficient scope as to be reachable by the server. o The ``extensions'' field contains an authentication extension, and the server cannot successfully authenticate the client. 11.2. Reply Message Validation Servers MUST silently discard any received Reply messages. Clients MUST discard any Reply message that meets any of the following criteria: o The ``transaction-ID'' field value does not match the value the client used in its Request or Release message. o The ``client's link-local address'' field value does not match the link-local address of the interface upon which the client sent in its Request or Release message. o The Reply message contains an authentication extension, and the client's attempt to authenticate the message fails. Relays MUST discard any Reply message that meets any of the following criteria: o The ``R'' bit isn't set. o The ``relay-address'' field value does not contain the relay's address on the same link as the client. o The ``client's link-local address'' field value does not contain a valid link-local address. Bound, Carney, Perkins Expires 1 November 2000 [Page 30] Internet Draft DHCP for IPv6 5 May 2000 11.3. Release Message Validation Clients MUST silently discard any received Release messages. Agents MUST discard any Release message that meets any of the following criteria: o The ``transaction-ID'' field contains a value not in the 1024--65535 range. o The ``client's link-local address'' field does not contain a valid link-local address. Relays MUST discard any received Release message that meets any of the following criteria: o The ``R'' bit is not set. o The ``X-address'' field value does not match any of the relay's addresses. Servers MUST discard any received Release message which meets any of the following criteria: o The ``X-address'' field does not contain an address of sufficient scope as to be reachable by the server. o The ``extensions'' field contains an authentication extension, and the server cannot successfully authenticate the client. 11.4. Client Behavior A client will generate one or more Request messages when prompted by the application layer in order to acquire configuration information. A client may initiate such an exchange automatically in order to acquire the necessary network parameters to communicate with nodes off-link. The client uses the server and relay address information from previous Advertise message(s) for use in delivering Request message(s). Note that a client may request configuration information from one or more servers at any time. A client uses the Release message in the management of releasable resources when: o The client has determined through a resource-specific manner that the resource assigned by the server is already in use by a different client. Bound, Carney, Perkins Expires 1 November 2000 [Page 31] Internet Draft DHCP for IPv6 5 May 2000 o The client has been instructed to release the resource prior to the lease expiration time since it is no longer needed. 11.4.1. Creation and sending of Request messages When creating a Request message, the client SHOULD start out with a buffer initialized with zeroed octets. The client sets the ``msg-type'' field to 3, and places the link-local address of the interface it wishes to associate with the configuration information with in the ``client's link-local address'' field. Unless the Request message is created in response to a Reconfigure-init message, the client generates a transaction ID in the range of 1024--65535 and inserts this value in the ``transaction-ID'' field. The client places the address of the destination server in the ``server-address'' field. If the client is not on the same link as the destination server, the client places the appropriate relay's address in the ``relay-address'' field. If the client is acquiring configuration information on the interface for the first time, the client SHOULD set the ``C'' bit in the header. How the client determines if this is the first configuration attempt on the interface is implementation-specific. A client may implement a cache of configuration information on a per-interface basis; if that cache does not exist, that client would set the ``C'' bit. Clients which do not implement caching of per-interface configuration information MUST always set the ``C'', and include any extensions carrying releasable resources received from earlier configuration exchanges in the extensions field of the Request. If the client has determined through an implementation-specific manner that the client implementation itself has restarted, it MUST set the ``R'' bit in the header. After the first successful exchange with the server, the client MUST NOT set the ``R'' bit in subsequent Request messages. Client considerations for extensions are now considered (see the ``extensions document'', [2] for more details). If the client already has an IP address of sufficient scope to directly reach the server, then the client SHOULD unicast the Request to the server. Otherwise, if the server is off-link, the client unicasts the Request message to the appropriate relay. Bound, Carney, Perkins Expires 1 November 2000 [Page 32] Internet Draft DHCP for IPv6 5 May 2000 11.4.2. Time out and retransmission of Request Messages The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply messages. If no Reply messages are received, the client retransmits the Request with the same transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits again. The client continues this process until a Reply is received or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at which time the client MUST abort the configuration attempt. The client SHOULD report the abort status to the application layer. Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS are documented in section 3.5. 11.4.3. Receipt of Reply message in response to a Request Upon the receipt of a valid Reply message, the client extracts the configuration information contained in the Reply. If the ``status'' field contains a non-zero value, the client reports the error status to the application layer. If the extensions field contains one or more ``Reconfigure Multicast Address'' extensions (see ``extensions document'', ``Reconfigure Multicast Address Extension'' section [2]), the client MUST join these multicast groups, and MUST monitor the UDP 546 port for Reconfigure or Reconfigure-init messages on the networks configured by DHCP. If the configuration information returned in the Reply contains releasable resources, then the client MUST take over lease management of the resource. A client MUST NOT request releasable resources unless it is prepared to appropriately manage the resource lease. 11.4.4. Creation and sending of Release messages When creating a Release message, the client SHOULD start out with a buffer initialized with zeroed octets. The client sets the ``msg-type'' field to 5, and places the link-local address of the interface the configuration information it wishes to release is associated with in the ``client's link-local address'' field. The client generates a transaction ID in the range of 1024--65535 and inserts this value in the ``transaction-ID'' field. The client includes extensions containing the releasable resources it is releasing in the ``extensions'' field. The appropriate ``status'' Bound, Carney, Perkins Expires 1 November 2000 [Page 33] Internet Draft DHCP for IPv6 5 May 2000 field in the extensions MUST be set to indicate the reason for the release. The client places the IP address of the server who allocated the resource(s) in the ``server-address'' field. If the client will have an appropriately scoped IP address after the release transaction is completed, the client clears the ``R'' bit and places this address in the ``X-address'' field. If the client will not have an appropriately scoped IP address after the release transaction is completed, the client sets the ``R'' bit and places the address of the appropriate relay in the ``X-address'' field. If the client is configured to use authentication, the client generates the appropriate authentication extension, and adds this extension to the ``extensions'' field. Note that the authentication extension MUST be the last extension in the ``extensions'' field. See the ``extension document'' for more details about the authentication extension [2]. If the ``R'' bit is set, then the client MUST unicast the Release to the relay indicated in the ``X-address'' field. Otherwise, the client unicasts the Release message directly to the server indicated in the ``server-address'' field. 11.4.5. Time out and retransmission of Release Messages The client waits REP_MSG_TIMEOUT milliseconds, collecting Reply messages. If no Reply messages are received, the client retransmits the Release, and doubles the REP_MSG_TIMEOUT value, and waits again. The client continues this process until a Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been made, at which time the client SHOULD abort the release attempt. The client SHOULD return the abort status to the application, if an application initiated the release. Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS are documented in section 3.5. Note that if the client fails to release the resource, the resource will be reclaimed by the server when the lease associated with it expires. Bound, Carney, Perkins Expires 1 November 2000 [Page 34] Internet Draft DHCP for IPv6 5 May 2000 11.4.6. Receipt of Reply message in response to a Release Upon receipt of a valid Reply message, the client can consider the Release event successful, and SHOULD return the successful status to the application layer, if an application initiated the release. 11.5. Relay Behavior 11.5.1. Relaying of Request or Release messages When a Relay receives a valid Request or Release message, it forwards it to the IP address found in the ``server-address'' field of the message. 11.6. Server Behavior For this discussion, the Server is assumed to have been configured in an implementation specific manner with configuration of interest to clients. Such configuration information MAY contain releasable resources such as IP addresses. 11.6.1. Receipt of Request messages Upon the receipt of a valid Request message from a client the server can respond to, (implementation-specific administrative policy satisfied) the server scans the extensions field. If the client has set the ``C'' bit, the server MUST release all releasable resources currently associated with the client's binding that do not appear in the ``extensions'' field. If the client has set the ``R'' bit, the server MUST delete any transaction-ID cache entries it is maintaining for this client, if the server implements such a cache. Server considerations for extensions are now evaluated (see the ``extensions document'', [2] for more details). If the configuration information to be returned to the client includes releasable resources, the server checks if a binding already exists for the client. If so, the server examines the data records within the binding to determine if the client's Request is a retransmission of an earlier Request or a new Request. Releasable resource identifiers are stored within the binding with the transaction-ID used by the client to request the resource's assignment. If the transaction-ID's match, this is a retransmission Bound, Carney, Perkins Expires 1 November 2000 [Page 35] Internet Draft DHCP for IPv6 5 May 2000 and the server simply return the contents of the client's binding which satisfy its request. If the transaction-ID's do not match, the server records the additional resources it is assigning in the existing binding with the new Request's transaction-ID. If the client does not have an existing binding, the server creates a binding for the client and records the resources it is assigning in this binding along with the transaction-ID from the client's Request. The server then constructs a Reply message and sends it to the client. 11.6.2. Receipt of Release messages Upon the receipt of a valid Release message, the server performs a lookup to find the client's binding. If the binding is found, the server examines the binding to see if the resource(s) identified by the client in the Release message's extensions field are in fact assigned to the client. If they are, the server deletes these resources from the client's binding, making them available to other clients. The server then generates a Reply message. If a binding was found and the resources presented to the server were deleted from the client's binding, the server sets the ``status'' field to ``Success''. If no binding is found, the server sets the ``status'' field to ``NoBinding''(section 3.4). 11.6.3. Creation and sending of Reply messages When creating a Reply message, the server SHOULD start out with a buffer initialized with zeroed octets. The server sets the ``msg-type'' field to 4 and copies the values of the following fields from the client's Request or Release to the Reply message: o transaction-ID o client's link-local address o If the client's message is a Request with a non-zero ``relay-address'' field value, the server sets the ``R'' bit in the Reply and copies the ``relay-address'' field value from the Request to the Reply. If the client's message is a Release with the ``R'' bit set, the server sets the ``R'' bit in the Reply and sets the ``relay-agent'' field to the contents of the Release's X-address field. Bound, Carney, Perkins Expires 1 November 2000 [Page 36] Internet Draft DHCP for IPv6 5 May 2000 The server sets the ``status'' field appropriately (see the table in section 3.4) based upon the results of processing the client's request. If configured to do so, a server will include ``Reconfigure Multicast Address'' extensions (see ``extensions document'', ``Reconfigure Multicast Address Extension'' [2]), in Reply messages sent in response to a Request, informing the client of one or more multicast groups it should join to facilitate the receipt of Reconfigure or Reconfigure-init messages. If the DHCP domain is using authentication, the server will generate an authentication extension with the appropriate settings and add that extension as the last extension in the ``extensions'' field of the Reply message. If the ``relay-address'' field of the Reply message is zero, then the server unicasts the Reply directly to the client using the ``client's link-local address'' field value as destination address. If the ``relay-address'' field is non-zero, then the server unicasts the Reply directly to the relay using the ``relay-address'' field value as the destination address. If the server implements a transaction-ID cache, the server would add an entry for the client to this cache. 12. DHCP Server-Initiated Configuration Exchange A server initiates a configuration exchange on behalf of the administrator of the DHCP domain. An administrator may initiate such an exchange when new networks are added to the domain or existing networks are to be renumbered. Other examples include changes in the location of directory servers, addition of new services such as printing, and availability of new software (system or application). 12.1. Reconfigure Message Validation Agents MUST silently discard any received Reconfigure messages. Clients MUST discard any Reconfigure message that meets any of the following criteria: o The ``transaction-ID'' field value is not within the 0--1023 range. o The Reconfigure message contains an authentication extension, and the client's attempt to authenticate the message fails. Bound, Carney, Perkins Expires 1 November 2000 [Page 37] Internet Draft DHCP for IPv6 5 May 2000 12.2. Reconfigure-reply Message Validation Clients and Relays MUST silently discard any received Reconfigure-reply messages. Servers MUST discard any Reconfigure-reply message that meets any of the following criteria: o The ``transaction-ID'' field value is not that same value the server used in its Reconfigure message. o The ``server-address'' field value does not match the value the server placed in its Reconfigure message. 12.3. Reconfigure-init Message Validation Agents MUST silently discard any received Reconfigure-init messages. Clients MUST discard any Reconfigure-init messages that meets any of the following criteria: o The ``transaction-ID'' field value is not within the 0--1023 range. o The Reconfigure-init message contains an authentication extension, and the client's attempt to authenticate the message fails. 12.4. Server Behavior For this discussion, the server is assumed to have a implementation-specific interface by which an administrator may initiate a reconfiguration event with some set of clients. There are two methods of initiating a reconfiguration event. Each has its advantages: Reconfigure with payload This method uses the Reconfigure message. Items to be changed are included as extensions in the ``extensions'' field. This method MUST NOT be used to reconfigure releasable resources. Examples of information which can be reconfigured using this method are DNS domain and servers, NTP servers, other name service parameters. The server generates and sends the Reconfigure message; clients respond with Reconfigure-reply messages. Bound, Carney, Perkins Expires 1 November 2000 [Page 38] Internet Draft DHCP for IPv6 5 May 2000 Reconfigure Trigger This method uses the Reconfigure-init message. When a client receives a Reconfigure-init message, it initiates a Request/Reply exchange with the server. Any kind of resource can be reconfigured using this method, including releasable resources. An example of an releasable resource is an IP address. A server can send Reconfigure and Reconfigure-init messages only to those clients who have an address of sufficient scope to be reachable by the server. Thus, those clients who have not requested an IP address and are off-link cannot be reconfigured by the server. Before initiating a reconfigure process, the server SHOULD be configured with a REC_THRESHOLD threshold value which represents the percentage of clients successfully reconfigured before the reconfigure process is considered a success. See section 3.5 for the default setting of REC_THRESHOLD. Note that the server MUST be able to determine the set of clients that should receive the reconfigure, in order to determine when the reconfigure process is complete. 12.4.1. Creation and sending of Reconfigure messages When creating a Reconfigure message, the server SHOULD start out with a buffer initialized with zeroed octets. The server sets the ``msg-type'' field to 6. The server generates a transaction-ID from the 0--1023 range and inserts it in the ``transaction-ID'' field. The server places its address (of appropriate scope) in the ``server-address'' field. The server then generates extensions for the non-releasable resources to be changed and places them in the ``extensions'' field. If the DHCP domain is using authentication, the server will generate an authentication extension with the appropriate settings and add that extension as the last extension in the ``extensions'' field of the Reconfigure message. The server multicasts the Reconfigure message to one or more Reconfigure Multicast Addresses previously sent as extensions to the clients. Note that a server MAY unicast Reconfigure message(s) to specific clients by walking its list of bindings to determine the unicast address(es) of the clients. Whether or not the Reconfigure is multicast or unicast is an implementation detail. A server waits for Reconfigure-reply messages from clients confirming that they have received the Reconfigure. Bound, Carney, Perkins Expires 1 November 2000 [Page 39] Internet Draft DHCP for IPv6 5 May 2000 12.4.2. Time out and retransmission of Reconfigure messages The server waits RECREP_MSG_TIMEOUT milliseconds, collecting Reconfigure-reply messages. If all the expected Reconfigure-reply messages are received, then the reconfigure process is successful. If some or all of the expected Reconfigure-reply messages are not received, then the server retransmits the Reconfigure, and doubles the RECREP_MSG_TIMEOUT value, and waits again. The server continues this process until all Reconfigure-reply messages are received or REC_MSG_ATTEMPTS unsuccessful attempts have been made, at which time the server SHOULD abort the reconfigure process. The server SHOULD log the result of the reconfigure process. Default and initial values for RECREP_MSG_TIMEOUT and REC_MSG_ATTEMPTS are documented in section 3.5. 12.4.3. Receipt of Reconfigure-reply messages Upon receipt of a valid Reconfigure-reply message, the server removes that client from the list of clients it is expecting a Reconfigure-reply message from. 12.4.4. Creation and sending of Reconfigure-init messages When creating a Reconfigure-init message, the server SHOULD start out with a buffer initialized with zeroed octets. The server sets the ``msg-type'' field to 8. The server generates a transaction-ID from the 0--1023 range and inserts it in the ``transaction-ID'' field. The server places its address (of appropriate scope) in the ``server-address'' field. The server MAY generate an ERE extension to inform the client of what information has been changed or new information that has been added. If the DHCP domain is using authentication, the server will generate an authentication extension with the appropriate settings and add that extension as the last extension in the ``extensions'' field of the Reconfigure-init message. Typically, the server will not provide more than an ERE and / or Authentication extension, since it will provide the new configuration information as part of the Request/Reply transaction triggered by the Reconfigure-init message. The server multicasts the Reconfigure-init message to one or more Reconfigure Multicast Addresses previously sent as extensions to the clients. Note that a server MAY unicast Reconfigure-init Bound, Carney, Perkins Expires 1 November 2000 [Page 40] Internet Draft DHCP for IPv6 5 May 2000 message(s) to specific clients by walking its list of bindings to determine the unicast address(es) of the clients. Whether or not the Reconfigure-init is multicast or unicast is an implementation detail. A server waits for a Request message from each client confirming that they have received the Reconfigure-init and are thus initiating a Request/Reply transaction with the server. The server can determine that a Request message is in response to a Reconfigure-init because the transaction-ID in the Request will be the same value as was used in the Reconfigure-init message. 12.4.5. Time out and retransmission of Reconfigure-init messages The server uses the same algorithm and configuration values for sending Reconfigure-init messages as it does with Reconfigure messages. See Section 12.4.2 for this algorithm. 12.4.6. Receipt of Request messages Upon receipt of a valid Request message with the same transaction-ID as the Reconfigure-init messages it sent, the server removes that client from the list of clients it is expecting to initiate a Request/Reply transaction. The server generates and sends Reply message(s) to the client as described in section 11.6.3, including in the ``extension'' field new values for configuration parameters. If the extensions include releasable resources, the server will include two extensions for each resource - one with the original values with the lease times set to zero, and another with new values and lease times. Note that the server can terminate the client's ability to use a resource simply by including only the first extension value. 12.5. Client Behavior A client MUST always monitor UDP port 546 for Reconfigure and Reconfigure-init messages on interfaces upon which it has acquired DHCP parameters. Since the results of a reconfiguration event may affect application layer programs, the client SHOULD log these events, and MAY notify these programs of the change through an implementation-specific interface. Bound, Carney, Perkins Expires 1 November 2000 [Page 41] Internet Draft DHCP for IPv6 5 May 2000 12.5.1. Receipt of Reconfigure messages Upon receipt of a valid Reconfigure message, the client extracts the configuration parameters contained in the ``extensions'' field, and notifies the application layer that new values for these parameters are available. The client then generates and sends a Reconfigure-reply message to the server. 12.5.2. Creation and sending of Reconfigure-reply messages When creating a Reconfigure-reply message, the client SHOULD start out with a buffer initialized with zeroed octets. The client sets the ``msg-type'' field to 7, and places the link-local address of the interface upon which it received the Reconfigure message in the ``client's link-local address'' field. The client copies the values of the following fields from the Reconfigure message to the Reconfigure-reply message: o transaction-ID o server-address The client sets the ``status'' field appropriately (see the table in section 3.4) based upon the results of processing the server's reconfigure-reply. The client places the address of the destination server in the ``server-address'' field. If the client is configured to use authentication, the client generates the appropriate authentication extension, and adds this extension to the ``extensions'' field. Note that the authentication extension MUST be the last extension in the ``extensions'' field. The client delays the sending of the Reconfigure-reply by some random value selected in the range of REC_REP_MIN and REC_REP_MAX seconds. This delay helps reduce the load on the server generated by processing large numbers of Reconfigure-reply messages. Default and initial values for REC_REP_MIN and REC_REP_MAX are documented in section 3.5. The client unicasts the Reconfigure-reply to the address identified in the ``server-address'' field. Sending the Reconfigure-reply completes the reconfiguration process for the client. Bound, Carney, Perkins Expires 1 November 2000 [Page 42] Internet Draft DHCP for IPv6 5 May 2000 12.5.3. Receipt of Reconfigure-init messages Upon receipt of a valid Reconfigure-init message, the client initiates a Request/Reply transaction with the server. 12.5.4. Creation and sending of Request messages When responding to a Reconfigure-init, the client creates and sends the Request message in exactly the same manner as outlined in section 11.4.1 with the following differences: transaction-ID The client copies the transaction-ID from the Reconfigure-init message into the Request message. Pause before sending Request The client pauses before sending the Request for a random value within the range REC_REP_MIN and REC_REP_MAX seconds, as outlined in section 12.5.2. 12.5.5. Time out and retransmission of Request messages The client uses the same variables and retransmission algorithm as it does with Request messages generated as part of a client-initiated configuration exchange. See section 11.4.2 for details. 12.5.6. Receipt of Reply messages Upon the receipt of a valid Reply message, the client extracts the contents of the ``extension'' field, and sets (or resets) configuration parameters appropriately. If the configuration parameters changed were requested by the application layer, the client notifies the application layer of the changes using an implementation-specific interface. If the resources changed are releasable, the client makes the appropriate adjustments to its management of the leases of these resources. 13. Using DHCP for network renumbering An administrator can use DHCP to renumber links within her DHCP domain through two techniques, passive renumbering and active renumbering. Bound, Carney, Perkins Expires 1 November 2000 [Page 43] Internet Draft DHCP for IPv6 5 May 2000 13.1. Passive Renumbering The administrator can configure her servers to return relatively short preferred and valid lifetimes for the IP addresses she makes available to clients. When she determines that she'd like to renumber a network, she configures her servers through an implementation-specific manner to disallow the extension of the IP address lifetimes on the original network, and adds the new network configuration data to the server's database. The clients on the original network will fail to acquire lifetime extensions on their IP addresses, and will request and acquire IP addresses from the new network when the valid lifetime of the original IP addresses approaches expiration. When the lifetimes for all of the IP addresses on the original network expire, the network can be considered renumbered. 13.2. Active Renumbering The administrator can force the renumbering of networks in her DHCP domain by using the reconfigure feature of DHCP. She instructs her servers of the network renumbering through an implementation-specific interface. The servers in the domain will generate Reconfigure-init messages, which will cause the clients to initiate a Request/Reply transaction with the server. The servers will include two IP address extensions for each IP address being changed. The first will contain the original IP address, with the preferred and valid lifetimes set to zero. The second will contain the new IP address, with non-zero preferred and valid lifetimes. A server implementation MAY permit the administrator to set the original IP address lifetimes to some small value greater than zero, to allow applications running on the client to orderly transfer to the new network over time. 14. DHCP Client Implementator Notes This section provides helpful information for the client implementor regarding their implementations. The text described here is not part of the protocol, but rather a discussion of implementation features we feel the implementor should consider during implementation. Bound, Carney, Perkins Expires 1 November 2000 [Page 44] Internet Draft DHCP for IPv6 5 May 2000 14.1. Primary Interface Since configuration parameters acquired through DHCP can be interface-specific or more general, the client implementor SHOULD provide a mechanism by which the client implementation can be configured to specify which interface is the primary interface. The client SHOULD always query the DHCP data associated with the primary interface for non-interface specific configuration parameters. An implementation MAY implement a list of interfaces which would be scanned in order to satisfy the general request. In either case, the first interface scanned is considered the primary interface. By allowing the specification of a primary interface, the client implementor identifies which interface is authoritative for non-interface specific parameters, which prevents configuration information ambiguity within the client implementation. 14.2. Advertise Message and Configuration Parameter Caching If the hardware the client is running on permits it, the implementor SHOULD provide a cache for Advertise messages and a cache of configuration parameters received through DHCP. Providing these caches prevents unnecessary DHCP traffic and the subsequent load this generates on the servers. The implementor SHOULD provide a configuration knob for setting the amount of time the cache(s) are valid. 14.3. Time out and retransmission variables Note that the client time out and retransmission variables outlined in section 3.5 can be configured on the server and sent to the client through the use of the ``DHCP Retransmission Parameter Extension'', which is documented in the ``extensions document'' [2]. A client implementation SHOULD be able to reset these variables using the values from this extension. 14.4. Server Preference A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message to collect Advertise messages and compare their preferences (see section 15.3), unless it receives an Advertise message with a preference of 255. If the client receives an Advertise message with a preference of 255, then the client MAY act immediately on that Advertise without waiting for any more additional Advertise messages. Bound, Carney, Perkins Expires 1 November 2000 [Page 45] Internet Draft DHCP for IPv6 5 May 2000 15. DHCP Server Implementator Notes This section provides helpful information for the server implementor. 15.1. Client Bindings A server implementation can use the client's link-local address and the subnet prefix specification from which the client sent its Request message(s) as an index for finding configuration parameters assigned to the client. While it isn't critical to keep track of which clients were given information (resources) that isn't releasable, it IS critical for the server to keep track of which client it has assigned releasable resources. The server MUST include the transaction-ID from the client's Request along with the releasable resource identifier(s) within the binding. This is done so that the server can detect whether a client Request is a retransmission of an earlier Request or an entirely new Request. The server should periodically scan its bindings for releasable resources whose leases have expired. When the server finds expired resource assignments, it MUST delete these assignments, thereby making these resources available to other clients. The client bindings MUST be stored in non-volatile storage. The server implementation should provide policy knobs to control whether or not the lease on a releasable resource is renewable, and by how long. 15.2. Reconfigure Considerations A server implementation MUST provide an interface to the administrator for initiating reconfigure events. A server implementation may provide a mechanism for allowing the specification of how many clients comprise a reconfigure multicast group. This enables the administrator to control the hit a server takes when a reconfigure event occurs. 15.3. Server Preference The server implementation SHOULD allow the setting of a server preference value by the administrator. The server preference variable is an unsigned single octet value (0--255), with the lowest preference being 0 and the highest 255. Clients will choose higher preference servers over those with lower preference values. If you Bound, Carney, Perkins Expires 1 November 2000 [Page 46] Internet Draft DHCP for IPv6 5 May 2000 don't choose to implement this feature in your server, you MUST set the server preference field to 0 in the Advertise messages generated by your server. 15.4. Request Message Transaction-ID Cache In order to improve performance, a server implementation MAY include an in memory transaction-ID cache. This cache is indexed by client binding and transaction-ID, and enables the server to quickly determine whether a Request is a retransmission or a new Request without the cost of a database lookup. If an implementor chooses to implement this cache, then they SHOULD provide a configuration knob to tune the lifetime of the cache entries. 16. DHCP Relay Implementator Notes A relay implementation SHOULD allow the specification of a list of destination addresses for Solicit messages. This list MAY contain any mixture of unicast addresses and multicast addresses. If a relay receives an ICMP message in response to a DHCP message it has forwarded, it SHOULD log this event. 17. Open Issues for Working Group Discussion This section contains some items for discussion by the working group. 17.1. Trade-offs: Optional fields in DHCP messages You'll notice that the message formats have changed. In particular, some of the optional fields are now required. This will increase the size of DHCP messages in some cases, consuming network bandwidth and memory on the DHCP client (an issue for small devices such as PDAs). The changes were made for the following reasons: o Fields that were used most of the time were made required. o Some fields that were optional were either made required or added to messages which previously didn't have them. This was done for robustness reasons (receivers can validate that the message is for them, and in the case of clients, know which interface the message is intended for). o Simplicity. Bound, Carney, Perkins Expires 1 November 2000 [Page 47] Internet Draft DHCP for IPv6 5 May 2000 Please look at the messages as they are now defined, and let us know your opinion. 17.2. Use DHCPv4 authentication or the current DHCPv6 method? Now that the DHCPv4 authentication draft is in last call, should we use the technique described in that document to provide authentication for DHCPv6, or should we continue with the authentication technique currently documented in the extensions draft? 17.3. The Reconfigure Message and Subnet Prefix Extensions The drafts currently specify that Releasable resources (such as an IP address) can only be reconfigured using the Reconfigure-init trigger message. This was done for simplicity (enables clients to perform DAD on the new address and return the appropriate result to the server) using the same mechanism as a standard Request/Reply/Release exchange. This method also makes no assumptions about the charactistics of the releasable resource. However, for IP addresses with interface IDs, one could send out two IP address extensions, one for the old prefix and one for the new, and cause clients to change the prefix and thus renumber over time. This scheme avoids the added DHCP Request traffic - clients acknowledge with a Reconfigure-reply message. 17.4. ``R'' bit in Request message not needed? Now that the transaction-ID is stored along with the releasable resource identifier in a client's binding, the transaction-ID cache becomes an optional feature of the DHCP server implementation, not a requirement of the protocol. Should we do away with the ``R'' bit? 18. Security Considerations Clients and servers often have to authenticate the messages they exchange. For instance, a server may wish to be certain that a Request originated from the client identified by the fields included within the Request message header. Conversely, it is quite often essential for a client to be certain that the configuration parameters and addresses it has received were sent to it by an authoritative server. Similarly, a server should only accept a Release message which seems to be from one of its clients, if it has some assurance that the client actually Bound, Carney, Perkins Expires 1 November 2000 [Page 48] Internet Draft DHCP for IPv6 5 May 2000 did transmit the Release message. Again, a client might wish to only accept Reconfigure or Reconfigure-init messages that are certain to have originated from a server with authority to issue them. The IPv6 Authentication Header can provide security for DHCPv6 messages when both endpoints have a suitable IP address. However, a client often has only a link-local address, and such an address is not sufficient for a server which is off-link. In those circumstances the relay is involved, so that the DHCP message MUST have the relay's address in the IP destination address field, even though the client aims to deliver the message to the server. The DHCP Client-Server Authentication Extension [2] is intended to be used in these circumstances. Note that, if a client receives a DHCP message which fails authentication, it should continue to wait for another message which might be correctly authenticated just as if the failed message had never arrived; however, receiving such failed messages SHOULD be logged. 19. Year 2000 considerations Since all times are relative to the current time of the transaction, there is no problem within the DHCPv6 protocol related to any hardcoded dates or two-digit representation of the current year. 20. IANA Considerations This document defines message types 1--8 to be received by UDP at port numbers 546 and 547. Additional message types may be defined in the future. Section 3.1 lists several multicast addresses used by DHCP. This document also defines several status codes that are to be returned with the Reply and Reconfigure-reply messages (see sections 9.4 and 9.7). The non-zero values for these status codes which are currently specified are shown in the table in section 3.4. There is a DHCPv6 extension [2] which allows clients and servers to exchange values for some of the timing and retransmission parameters defined in section 3.5. Adding new parameters in the future would require extending the values by which the parameters are indicated in the DHCP extension. Since there needs to be a list kept, the default values for each parameter should also be stored as part of the list. Bound, Carney, Perkins Expires 1 November 2000 [Page 49] Internet Draft DHCP for IPv6 5 May 2000 All of these protocol elements may be specified to assume new values at some point in the future. New values should be approved by the process of IETF Consensus [11]. 21. Acknowledgements Thanks to the DHC Working Group for their time and input into the specification. Ralph Droms and Thomas Narten have had a major role in shaping the continued improvement of the protocol by their careful reviews. Many thanks to Matt Crawford, Erik Nordmark, Gerald Maguire, and Mike Carney for their studied review as part of the Last Call process. Thanks also for the consistent input, ideas, and review by (in alphabetical order) Brian Carpenter, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson, and Phil Wells. Thanks to Steve Deering and Bob Hinden, who have consistently taken the time to discuss the more complex parts of the IPv6 specifications. A. Comparison between DHCPv4 and DHCPv6 This appendix is provided for readers who will find it useful to see a model and architecture comparison between DHCPv4 [7, 1] and DHCPv6. There are three key reasons for the differences: o IPv6 inherently supports a new model and architecture for communications and autoconfiguration of addresses. o DHCPv6 benefits from the new IPv6 features. o New features were added to support the expected evolution and the existence of more complicated Internet network service requirements. IPv6 Architecture/Model Changes: o The link-local address permits a node to have an address immediately when the node boots, which means all clients have a source IP address at all times to locate an on-link server or relay. o The need for BOOTP compatibility and the broadcast flag have been removed. o Multicast and address scoping in IPv6 permit the design of discovery packets that would inherently define their range by the multicast address for the function required. Bound, Carney, Perkins Expires 1 November 2000 [Page 50] Internet Draft DHCP for IPv6 5 May 2000 o Stateful autoconfiguration has to coexist and integrate with stateless autoconfiguration supporting Duplicate Address Detection and the two IPv6 lifetimes, to facilitate the dynamic renumbering of addresses and the management of those addresses. o Multiple addresses per interface are inherently supported in IPv6. o Some DHCPv4 options are unnecessary now because the configuration parameters are either obtained through IPv6 Neighbor Discovery or the Service Location protocol [16]. DHCPv6 Architecture/Model Changes: o The message type is the first byte in the packet. o IPv6 Address allocations are now handled in a message extension as opposed to the message header. o Client/Server bindings are now mandatory and take advantage of the client's link-local address to always permit communications either directly from an on-link server, or from a off-link server through an on-link relay. o Servers are discovered by a client Solicit, followed by a server Advertise message o The client will know if the server is on-link or off-link. o The on-link relay may locate off-link server addresses from system configuration or by the use of a site-wide multicast packet. o ACKs and NAKs are not used. o The server assumes the client receives its responses unless it receives a retransmission of the same client request. This permits recovery in the case where the network has faulted. o Clients can issue multiple, unrelated Request messages to the same or different servers. o The function of DHCPINFORM is inherent in the new packet design; a client can request configuration parameters other than IPv6 addresses in the optional extension headers. o Clients MUST listen to their UDP port for the new Reconfigure message from servers. Bound, Carney, Perkins Expires 1 November 2000 [Page 51] Internet Draft DHCP for IPv6 5 May 2000 o New extensions have been defined. With the changes just enumerated, we can support new user features, including o Configuration of Dynamic Updates to DNS o Address deprecation, for dynamic renumbering. o Relays can be preconfigured with server addresses, or use of multicast. o Authentication o Clients can ask for multiple IP addresses. o Addresses can be reclaimed using the Reconfigure-init message. o Integration between stateless and stateful address autoconfiguration. o Enabling relays to locate off-link servers. B. Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Bound, Carney, Perkins Expires 1 November 2000 [Page 52] Internet Draft DHCP for IPv6 5 May 2000 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. References [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor Extensions. Request for Comments (Draft Standard) 2132, Internet Engineering Task Force, March 1997. [2] J. Bound, M. Carney, and C. Perkins. Extensions for the Dynamic Host Configuration Protocol for IPv6. draft-ietf-dhc-dhcpv6ext-12.txt, May 2000. (work in progress). [3] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [4] S. Bradner and A. Mankin. The Recommendation for the IP Next Generation Protocol. Request for Comments (Proposed Standard) 1752, Internet Engineering Task Force, January 1995. [5] W. J. Croft and J. Gilmore. Bootstrap Protocol. Request for Comments 951, Internet Engineering Task Force, September 1985. [6] S. Deering and R. Hinden. Internet Protocol, Version 6 (IPv6) Specification. Request for Comments (Draft Standard) 2460, Internet Engineering Task Force, December 1998. [7] R. Droms. Dynamic Host Configuration Protocol. Request for Comments (Draft Standard) 2131, Internet Engineering Task Force, March 1997. [8] R. Hinden and S. Deering. IP Version 6 Addressing Architecture. Request for Comments (Proposed Standard) 2373, Internet Engineering Task Force, July 1998. [9] S. Kent and R. Atkinson. IP Authentication Header. Request for Comments (Proposed Standard) 2402, Internet Engineering Task Force, November 1998. [10] J. McCann, S. Deering, and J. Mogul. Path MTU Discovery for IP version 6. Request for Comments (Proposed Standard) 1981, Internet Engineering Task Force, August 1996. [11] T. Narten and H. Alvestrand. Guidelines for Writing an IANA Considerations Section in RFCs. Request for Comments (Best Current Practice) 2434, Internet Engineering Task Force, October 1998. Bound, Carney, Perkins Expires 1 November 2000 [Page 53] Internet Draft DHCP for IPv6 5 May 2000 [12] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [13] D. C. Plummer. Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware. Request for Comments (Standard) 826, Internet Engineering Task Force, November 1982. [14] J. Postel. User Datagram Protocol. Request for Comments (Standard) 768, Internet Engineering Task Force, August 1980. [15] S. Thomson and T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [16] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service Location Protocol. Request for Comments (Proposed Standard) 2165, Internet Engineering Task Force, June 1997. [17] P. Vixie, Ed., S. Thomson, Y. Rekhter, and J. Bound. Dynamic Updates in the Domain Name System (DNS UPDATE). Request for Comments (Proposed Standard) 2136, Internet Engineering Task Force, April 1997. Bound, Carney, Perkins Expires 1 November 2000 [Page 54] Internet Draft DHCP for IPv6 5 May 2000 Chair's Address The working group can be contacted via the current chair: Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: (570) 577-1145 E-mail: droms@bucknell.edu Author's Address Questions about this memo can be directed to: Jim Bound Compaq Computer Corporation Mail Stop: ZK03-3/U14 110 Spitbrook Road Nashua, NH 03062 USA Phone: +1-603-884-0400 Email: bound@zk3.dec.com Mike Carney Sun Microsystems, Inc Mail Stop: UMPK17-202 901 San Antonio Road Palo Alto, CA 94303-4900 USA Phone: +1-650-786-4171 Email: mwc@eng.sun.com Charles E. Perkins Communications Systems Lab Nokia Research Center 313 Fairchild Drive Mountain View, California 94043 USA Phone: +1-650 625-2986 EMail: charliep@iprg.nokia.com Fax: +1 650 625-2502 Bound, Carney, Perkins Expires 1 November 2000 [Page 55] --------------D85E2B5E82FC81B2301608FB-- From owner-dhcp-v4@bucknell.edu Tue May 9 06:41:34 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14072 for ; Tue, 9 May 2000 06:41:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA24213; Tue, 9 May 2000 06:35:36 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA17397 for ; Tue, 9 May 2000 06:35:28 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13808; Tue, 9 May 2000 06:35:27 -0400 (EDT) Message-Id: <200005091035.GAA13808@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-dhcpv6-15.txt Date: Tue, 09 May 2000 06:35:27 -0400 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 : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, M. Carney, C. Perkins Filename : draft-ietf-dhc-dhcpv6-15.txt Pages : 55 Date : 08-May-00 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters using extensions to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' [15], and can be used separately or concurrently with the latter to obtain configuration parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-15.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-dhcpv6-15.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-dhcpv6-15.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: <20000508103821.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-15.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-15.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000508103821.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue May 9 06:42:19 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14084 for ; Tue, 9 May 2000 06:42:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA19100; Tue, 9 May 2000 06:39:03 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA07641 for ; Tue, 9 May 2000 06:35:42 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13836; Tue, 9 May 2000 06:35:41 -0400 (EDT) Message-Id: <200005091035.GAA13836@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-userclass-07.txt Date: Tue, 09 May 2000 06:35:40 -0400 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 : The User Class Option for DHCP Author(s) : G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat Filename : draft-ietf-dhc-userclass-07.txt Pages : 5 Date : 08-May-00 This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-07.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-userclass-07.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-userclass-07.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: <20000508103857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-userclass-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000508103857.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue May 9 06:43:09 2000 Received: from mail.bucknell.edu ([134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14095 for ; Tue, 9 May 2000 06:43:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA13007; Tue, 9 May 2000 06:38:52 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA26279 for ; Tue, 9 May 2000 06:35:34 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13822; Tue, 9 May 2000 06:35:33 -0400 (EDT) Message-Id: <200005091035.GAA13822@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-dhcpv6exts-12.txt Date: Tue, 09 May 2000 06:35:32 -0400 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 : Extensions for the Dynamic Host Configuration Protocol for IPv6 Author(s) : J. Bound, M. Carney, C. Perkins Filename : draft-ietf-dhc-dhcpv6exts-12.txt Pages : 39 Date : 08-May-00 The Dynamic Host Configuration Protocol for IPv6 [4] (DHCP) provides a framework for passing configuration information to hosts on a TCP/IP network. Configuration parameters and other control information are carried in typed data items that are stored in the 'extensions' field of the DHCP message. The data items themselves are also called 'extensions.' This document specifies the initial set of DHCP extensions, which will be periodically updated as new extensions are defined until this document reaches proposed standard. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6exts-12.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-dhcpv6exts-12.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-dhcpv6exts-12.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: <20000508103844.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6exts-12.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6exts-12.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000508103844.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Tue May 9 07:34:56 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15317 for ; Tue, 9 May 2000 07:34:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA25203; Tue, 9 May 2000 07:31:29 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA06634 for ; Tue, 9 May 2000 07:31:14 -0400 (EDT) From: jerome.privat@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Tue, 9 May 2000 12:06:08 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Tue, 9 May 2000 12:06:01 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2040874FA@mbtlipnt02.btlabs.bt.co.uk> To: DHCPv4 discussion list Subject: FW: I-D ACTION:draft-ietf-dhc-userclass-07.txt Date: Tue, 9 May 2000 12:06:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01BFB9A6.937DD430" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN ------_=_NextPart_000_01BFB9A6.937DD430 Content-type: text/plain; charset="ISO-8859-1" This version of the User Class draft includes all the changes agreed on this list last week. Ralph, can we go to WG Last Call with this one? Jerome Privat, BT -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 09 May 2000 11:36 To: DHCPv4 discussion list Cc: dhcp-v4@bucknell.edu Subject: I-D ACTION:draft-ietf-dhc-userclass-07.txt 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 : The User Class Option for DHCP Author(s) : G. Stump, R. Droms, Y. Gu, R. Vyaghrapuri, A. Demirtjis, B. Beser, J. Privat Filename : draft-ietf-dhc-userclass-07.txt Pages : 5 Date : 08-May-00 This option is used by a DHCP client to optionally identify the type or category of user or applications it represents. The information contained in this option is an opaque field that represents the user class of which the client is a member. Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters. This option should be configurable by a user. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-userclass-07.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-userclass-07.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-userclass-07.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_000_01BFB9A6.937DD430 Content-type: message/rfc822 To: Subject: Date: Tue, 9 May 2000 12:06:01 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.88) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01BFB9A6.937DD430" ------_=_NextPart_002_01BFB9A6.937DD430 Content-type: text/plain; charset="us-ascii" ------_=_NextPart_002_01BFB9A6.937DD430 Content-type: application/octet-stream; name="ATT10021" Content-Disposition: attachment; filename="ATT10021" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000508103857.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-userclass-07.txt ------_=_NextPart_002_01BFB9A6.937DD430 Content-type: message/external-body; site="internet-drafts"; dir="draft-ietf-dhc-userclass-07.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01BFB9A6.937DD430-- ------_=_NextPart_000_01BFB9A6.937DD430-- From owner-dhcp-v4@bucknell.edu Tue May 9 19:23:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA02671 for ; Tue, 9 May 2000 19:23:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA27398; Tue, 9 May 2000 19:17:42 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA07241 for ; Tue, 9 May 2000 19:17:35 -0400 (EDT) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id QAA00347 for ; Tue, 9 May 2000 16:17:33 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id for ; Tue, 09 May 2000 16:17:22 -0700 Received: from [17.201.23.37] (chesh1.apple.com [17.201.23.37]) by scv2.apple.com (8.9.3/8.9.3) with SMTP id QAA08200 for ; Tue, 9 May 2000 16:17:18 -0700 (PDT) Message-Id: <200005092317.QAA08200@scv2.apple.com> Subject: draft-ietf-dhc-domsrch-03.txt Date: Tue, 9 May 2000 16:17:18 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: DHCPv4 discussion list MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Reply-To: cheshire@apple.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN What happened to draft-ietf-dhc-domsrch-03.txt? I'm all ready to implement this in the Mac OS client, but we can't ship it without an RFC. says: >This Internet-Draft has expired and is no longer available. > >Unrevised documents placed in the Internet-Drafts directories have a >maximum life of six months. After that time, they must be updated, or >they will be deleted. This document was deleted on March 20, 2000. Stuart Cheshire * Wizard Without Portfolio, Apple Computer From owner-dhcp-v4@bucknell.edu Wed May 10 19:07:12 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04795 for ; Wed, 10 May 2000 19:07:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA30745; Wed, 10 May 2000 19:01:47 -0400 (EDT) Received: from baucis.sc.intel.com (baucis.sc.intel.com [143.183.152.22]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA26122 for ; Wed, 10 May 2000 19:01:35 -0400 (EDT) Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.28 2000/05/06 00:07:11 dmccart Exp $) with SMTP id QAA06756; Wed, 10 May 2000 16:01:18 -0700 (PDT) Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 10 May 2000 23:01:18 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 10 May 2000 16:01:16 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F29A0@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: DHCPv4 discussion list Subject: RE: zeroconf and non-zeroconf scenarios Date: Wed, 10 May 2000 16:01:00 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Reply-To: myron.hattig@intel.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Sorry for the cross posting but ... > Although I said in my last message that a vendor COULD make a > NAT gateway > to work with self-configured link-local devices, that doesn't > necessarily > mean that I'm endorsing the idea. Bernard is right that if you're > building a NAT gateway, it makes more sense to put a simple > DHCP server > into it. Here's why I'm hesitating on assuming a home gateway will have a DHCP server: There is no such thing as a simple DHCP server. DHCP in home networks requires a server-to-server mechanism to choose which DHCP server is the "best". The current drafts on "mini-DHCP" and "server-to-sever" options are far too insufficient. Whatever options get defined may also require support on the DHCP client. For example, how will the client know to start using a new DHCP server unless it watches for the "server-to-server" option. Modifying the DHCP client makes one of the arguments for DHCP null-and-avoid, the argument is that using DHCP in home networks does not involve modifying DHCP clients. The alternative argument is that if you must modify clients, then just modify them to support a ZC autonet protocol. Here is the scenario to show why server-to-server negotiation is required: Someone hooks up two computers at home through shared internet access PC software such as Microsoft ICS, Intel Anypoint ISS, Winproxy. Two of these products include DHCP servers. One includes an install tool that configures link-local addresses (to be compatible with "autonet"ed addresses). Now someone purchases an xDSL gateway which also has a DHCP server but the person does know enough to uninstall the PC software. All the machines on the network continue to use the default route configured from DHCP server running on the PC, thus no traffic is ever routed through the xDSL gateway. Power-cycling the PCs ;-) may not even fix the problem. This will be a very common scenario that all gateway vendors (hardware and PC software) will have to address. An alternative is to only use link-local addresses on the LAN, then NAT them. At this point, I'm not strongly advocating one approach over another, (I'd like to see a clearly articulated home networking DHCP solution that also accounts for interaction between DNS server and DHCP server) but I think it is too soon to preclude NATing link-local addresses. I just want us to proceed cautiously. -myron From owner-dhcp-v4@bucknell.edu Wed May 10 19:19:12 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04874 for ; Wed, 10 May 2000 19:19:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA28623; Wed, 10 May 2000 19:16:15 -0400 (EDT) Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA29055 for ; Wed, 10 May 2000 19:16:02 -0400 (EDT) Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.28 2000/05/06 00:07:11 dmccart Exp $) with SMTP id QAA03852; Wed, 10 May 2000 16:16:00 -0700 (PDT) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 10 May 2000 23:15:59 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2448.0) id ; Wed, 10 May 2000 16:15:58 -0700 Message-ID: <4148FEAAD879D311AC5700A0C969E8904F29A1@orsmsx35.jf.intel.com> From: "Hattig, Myron" To: DHCPv4 discussion list Subject: RE: zeroconf and non-zeroconf scenarios Date: Wed, 10 May 2000 16:15:49 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="windows-1252" Reply-To: myron.hattig@intel.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Typo on last msg. The text was: > Now someone purchases an xDSL gateway which also has a DHCP server > but the person does know enough to uninstall the PC software. The text should be: "but the person does NOT know" -myron From owner-dhcp-v4@bucknell.edu Mon May 15 00:23:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA16529 for ; Mon, 15 May 2000 00:23:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA27803; Mon, 15 May 2000 00:19:59 -0400 (EDT) Received: from bucky.excite.com (bucky-rwcmex.excite.com [198.3.99.218]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id AAA06344 for ; Mon, 15 May 2000 00:19:51 -0400 (EDT) Received: from prickles ([199.172.153.88]) by bucky.excite.com (InterMail vM.4.01.02.39 201-229-119-122) with ESMTP id <20000515041935.KSPE9044.bucky.excite.com@prickles> for ; Sun, 14 May 2000 21:19:35 -0700 Message-ID: <20623647.958364375951.JavaMail.imail@prickles> Date: Sun, 14 May 2000 21:19:35 -0700 (PDT) From: Joe Chromcik To: DHCPv4 discussion list Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Excite Inbox X-Sender-Ip: 208.200.110.173 Reply-To: jchromcik@excite.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit I have Windows 98 machines on my LAN that will not renew their IP config from the DHCP server. I have removed all other protocols and services. Other machines running Windows 2000 and NT have no problems. Is this a client side or server side problem? Joe Chromcik _______________________________________________________ Get 100% FREE Internet Access powered by Excite Visit http://freelane.excite.com/freeisp From owner-dhcp-v4@bucknell.edu Mon May 15 10:42:39 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04927 for ; Mon, 15 May 2000 10:42:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA19516; Mon, 15 May 2000 10:38:22 -0400 (EDT) Received: from hotmail.com (law2-f131.hotmail.com [216.32.181.131]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA22319 for ; Mon, 15 May 2000 10:38:15 -0400 (EDT) Received: (qmail 55430 invoked by uid 0); 15 May 2000 14:37:59 -0000 Message-ID: <20000515143759.55429.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Mon, 15 May 2000 07:37:59 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: Printer HP 2000C fails. Date: Mon, 15 May 2000 16:37:59 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have a a Microsoft Domain network, with the PDC server (NT Server .0) and the workstations (Windows 95). All the clients are printing to a HP 2000C printer and have the same problem: when a document is printing, it doesn't continue printing, but when restarts to continue printing, it begins at page 1, not at the last printed page. For example, the document has 60 pages, the printing process stops at page 40, and when restart, reprint all the document, not from page 40 to end page. All the clients have the latest printer driver for Windows 95 installed locally. The NT Server has their last version installed on. Both NT and 95 driver version is 2.3. It happens with normal documents and transparences too. Apparently this hardware is supported by 95 and NT according to Microsoft Hardware Compatibility List. I've obtained a temporal solution activating the "optime quality" on printer properties, but then documents are printed slowly, and taht's not the solution. Any suggestion? Thanks in advanced. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Mon May 15 12:09:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06506 for ; Mon, 15 May 2000 12:09:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA13073; Mon, 15 May 2000 12:05:35 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA18731 for ; Mon, 15 May 2000 12:05:30 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA06440; Sun, 14 May 2000 17:26:00 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id JAA00539; Mon, 15 May 2000 09:05:29 -0700 (MST) Message-Id: <200005151605.JAA00539@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Printer HP 2000C fails. In-Reply-To: Message from "Marc" of "Mon, 15 May 2000 16:37:59 EST." <20000515143759.55429.qmail@hotmail.com> Date: Mon, 15 May 2000 09:05:29 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Any suggestion? Call HP for support? This is a mailing list for the Dynamic Host Configuration Protocol working group of the IETF, and while printers do sometimes do DHCP, this doesn't sound like a DHCP-related issue. I'd offer you suggestions anyway if I had some, but I don't. Best of luck, though! _MelloN_ From owner-dhcp-v4@bucknell.edu Mon May 15 12:28:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06722 for ; Mon, 15 May 2000 12:28:54 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA17477; Mon, 15 May 2000 12:26:28 -0400 (EDT) Received: from hotmail.com (law2-f262.hotmail.com [216.32.180.220]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA31894 for ; Mon, 15 May 2000 12:26:19 -0400 (EDT) Received: (qmail 78363 invoked by uid 0); 15 May 2000 16:26:03 -0000 Message-ID: <20000515162603.78362.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Mon, 15 May 2000 09:26:03 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: Re: Printer HP 2000C fails. Date: Mon, 15 May 2000 18:26:03 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Sorry, i'm on a mistake, i had two questions, one about the printer, but the other about DHCP, wich i supose i can post, isn't it? Here it is the problem: I have problems to start the DHCP Server Service on a Windows NT Server. When the service try to start, appears a messages like to: Cannot start DHCP Server Services. Looking for a solution to Microsoft Developer Network, i found some related articles, but without a real solution. The event viewer shows the next event ID's: 1004, 1008, 1014, 1018 and 7023 Any suggestion? Thanks in advance ----Original Message Follows---- From: Ted Lemon To: marc_jaumandreu@hotmail.com CC: DHCPv4 discussion list Subject: Re: Printer HP 2000C fails. Date: Mon, 15 May 2000 09:05:29 -0700 > Any suggestion? Call HP for support? This is a mailing list for the Dynamic Host Configuration Protocol working group of the IETF, and while printers do sometimes do DHCP, this doesn't sound like a DHCP-related issue. I'd offer you suggestions anyway if I had some, but I don't. Best of luck, though! _MelloN_ ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Mon May 15 12:48:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06965 for ; Mon, 15 May 2000 12:48:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA06632; Mon, 15 May 2000 12:45:39 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA10868 for ; Mon, 15 May 2000 12:45:25 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a17.pm3-32.theriver.com [206.102.192.81]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id SAA06556; Sun, 14 May 2000 18:04:09 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id JAA00649; Mon, 15 May 2000 09:43:26 -0700 (MST) Message-Id: <200005151643.JAA00649@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: mcse@mail.saluki.com, winnt-l@peach.ease.lsoft.com, dhcp-v4@bucknell.edu Subject: Re: Printer HP 2000C fails. In-Reply-To: Message from "Marc" of "Mon, 15 May 2000 18:26:03 EST." <20000515162603.78362.qmail@hotmail.com> Date: Mon, 15 May 2000 09:43:25 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Any suggestion? Contact Microsoft Support? Again, this is not a mailing list for supporting implementations of the DHCP protocol - it is a mailing list for discussing issues pertaining to the protocol itself. You can try the dhcp-interest@isc.org mailing list, but I can't promise that you'll find anything useful out there either. One thing I can suggest: make sure that you aren't running the DHCP client on your NT system as well as the DHCP server - NT won't let you run both. That about exhausts my NT DHCP expertise... :') _MelloN_ From owner-dhcp-v4@bucknell.edu Mon May 15 12:48:40 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06976 for ; Mon, 15 May 2000 12:48:39 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA01771; Mon, 15 May 2000 12:45:53 -0400 (EDT) Received: from hotmail.com (law2-f280.hotmail.com [216.32.180.134]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA04218 for ; Mon, 15 May 2000 12:45:26 -0400 (EDT) Received: (qmail 85540 invoked by uid 0); 15 May 2000 16:45:10 -0000 Message-ID: <20000515164510.85538.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Mon, 15 May 2000 09:45:10 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: DHCP Server Service cannot start. Date: Mon, 15 May 2000 18:45:10 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have a question about DHCP, wich i supose i can post, isn't it? Here it is the problem: I have problems to start the DHCP Server Service on a Windows NT Server. When the service try to start, appears a messages like to: Cannot start DHCP Server Services. Looking for a solution to Microsoft Developer Network, i found some related articles, but without a real solution. The event viewer shows the next event ID's: 1004, 1008, 1014, 1018 and 7023 Any suggestion? Thanks in advance ----Original Message Follows---- From: Ted Lemon To: marc_jaumandreu@hotmail.com CC: DHCPv4 discussion list Subject: Re: Printer HP 2000C fails. Date: Mon, 15 May 2000 09:05:29 -0700 > Any suggestion? Call HP for support? This is a mailing list for the Dynamic Host Configuration Protocol working group of the IETF, and while printers do sometimes do DHCP, this doesn't sound like a DHCP-related issue. I'd offer you suggestions anyway if I had some, but I don't. Best of luck, though! _MelloN_ ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Mon May 15 16:21:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09602 for ; Mon, 15 May 2000 16:21:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA08074; Mon, 15 May 2000 16:17:36 -0400 (EDT) Received: from hotmail.com (law-f98.hotmail.com [209.185.131.161]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA04027 for ; Mon, 15 May 2000 16:17:21 -0400 (EDT) Received: (qmail 55498 invoked by uid 0); 15 May 2000 20:17:05 -0000 Message-ID: <20000515201705.55497.qmail@hotmail.com> Received: from 192.11.226.101 by www.hotmail.com with HTTP; Mon, 15 May 2000 13:17:05 PDT X-Originating-IP: [192.11.226.101] From: "Ramkumar Perumanam" To: DHCPv4 discussion list Subject: TCP/IP stack initialization with DHCP client Date: Mon, 15 May 2000 16:17:05 EDT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: rperumanam@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Hi All, I have a fundamental question regarding the DHCP client initialization with TCP/IP protocol stack. If this is a oft repeated question please bear with me. Here is my question. DHCP is based on UDP and hence requires TCP/IP stack to be setup to be functional(to send broadcast messages). If that's the case assuming that there is no IP addr yet assigned to the client, is it possible to initialize the TCP/IP stack without an IP addr so that DHCP can be used to obtain the real IP addr from a DHCP server? Once the DHCP client obtains IP addr from the server does the TCP/IP stack need to be reinitialized with the new IP addr or how does the reinitialization of TCP/IP with IP addr does not cause a reboot of the client machine? This is a theoretical question. If you answer this question with a practical example(say wrt a commercial implementation) that's fine with me. I would like to know how the catch-16 situation between IP stack initialization and DHCP client behavior(if at all any) is resolved? I really appreciate if any knowledgeable folks could clarify my doubts. Thanks, Ram. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Mon May 15 16:32:24 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09788 for ; Mon, 15 May 2000 16:32:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA28182; Mon, 15 May 2000 16:30:42 -0400 (EDT) Received: from gidget.incognito.com (GIDGET.INCOGNITO.COM [207.102.214.80]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA17464 for ; Mon, 15 May 2000 16:30:39 -0400 (EDT) Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21) id ; Mon, 15 May 2000 13:32:39 -0700 Message-ID: <716D440F8C29D311991100A0C9204874509F92@GIDGET.INCOGNITO.COM> From: "Kostur, Andre" To: DHCPv4 discussion list Cc: "'rperumanam@hotmail.com'" Subject: RE: TCP/IP stack initialization with DHCP client Date: Mon, 15 May 2000 13:32:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Andre@incognito.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN See RFC2131, Section 2, Page 11 (for how can UDP work with a partially unconfigured IP stack) Basically it depends on the behaviour of the DHCP client's IP stack that it will accept packets destined to its MAC address, regardless of the destination IP. So what happens is the client starts off by broadcasting to the world, and using 255.255.255.255 (I recall seeing Microsoft's stack using this) as the source IP address. As part of the DHCP packet, the device's MAC address is included. The DHCP servers interested in responding either: 1) Broadcast their replys (which a lot of IP stacks seem to accept when unconfigured) 2) Unicast their replys back to the origination MAC address, with the offered IP address as the destination IP address. Now, as for individual IP stacks and how they behave, that's up to the implementor. -----Original Message----- From: Ramkumar Perumanam [mailto:rperumanam@hotmail.com] Sent: Monday, May 15, 2000 1:17 PM To: DHCPv4 discussion list Subject: TCP/IP stack initialization with DHCP client Hi All, I have a fundamental question regarding the DHCP client initialization with TCP/IP protocol stack. If this is a oft repeated question please bear with me. Here is my question. DHCP is based on UDP and hence requires TCP/IP stack to be setup to be functional(to send broadcast messages). If that's the case assuming that there is no IP addr yet assigned to the client, is it possible to initialize the TCP/IP stack without an IP addr so that DHCP can be used to obtain the real IP addr from a DHCP server? Once the DHCP client obtains IP addr from the server does the TCP/IP stack need to be reinitialized with the new IP addr or how does the reinitialization of TCP/IP with IP addr does not cause a reboot of the client machine? This is a theoretical question. If you answer this question with a practical example(say wrt a commercial implementation) that's fine with me. I would like to know how the catch-16 situation between IP stack initialization and DHCP client behavior(if at all any) is resolved? I really appreciate if any knowledgeable folks could clarify my doubts. Thanks, Ram. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Tue May 16 10:23:28 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05950 for ; Tue, 16 May 2000 10:23:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA08968; Tue, 16 May 2000 10:18:23 -0400 (EDT) Received: from monitor.internaut.com (mg136-128.ricochet.net [204.179.136.128]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA01204 for ; Tue, 16 May 2000 10:18:06 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id HAA16007; Tue, 16 May 2000 07:01:30 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: zeroconf and non-zeroconf scenarios Date: Tue, 16 May 2000 07:21:58 -0700 Message-ID: <018d01bfbf42$192b0620$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4148FEAAD879D311AC5700A0C969E8904F29A0@orsmsx35.jf.intel.com> X-Mimeole: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >DHCP in home networks requires a server-to-server mechanism to >choose which DHCP server is the "best". This is an issue only if there is more than one home gateway running a mini-DHCP server. In that case, it is worth remembering that DHCP was designed so that more than one server could handle a given segment. As long as both gateways allocate addresses from the same scope, there will not necessarily be a problem. >Whatever options get defined may also require support on the >DHCP client. The client can ignore the options because a server should not respond to a client DHCPDISCOVER without sending its own DHCPDISCOVER in order to figure out if there is another DHCP server present. Thus in normal operation the client will only receive one offer. >For example, how will the client know to start using >a new DHCP server unless it watches for the >"server-to-server" option. If home gateways are coming up and down it is conceivable that a new server could be in place, or even that the client could receive more than one offer. At worst, this could result in a client being allocated an IP address that is otherwise in use. However, if client and servers do the checks recommended in RFC 2131, then this should be detected. >One includes an install tool that configures link-local >addresses (to be compatible with "autonet"ed addresses). Given that in such a situation it is possible for clients to auto-allocate addresses, it seems that there are some of the same issues in running one mini-DHCP server as in running two of them in that duplicate detection is required. >All the machines on the network continue to use the default route >configured from DHCP server running on the PC, thus no traffic is >ever routed through the xDSL gateway. Power-cycling the PCs ;-) >may not even fix the problem. This problem is not caused by DHCP -- it's a routing problem. Turning off a mini-DHCP server *does not* result in the gateway being turned off. Fixing this is tricky because both gateways could respond to router solicitations; so it looks to me that something like the "silent RIP" feature is required to address this issue. >An alternative is to only use link-local addresses on the LAN, >then NAT them. Not sure this would help the scenario above. You'll still have two gateways, no? >I'd like to see a clearly articulated >home networking DHCP solution that also accounts for interaction >between DNS server and DHCP server Isn't this just draft-ietf-dhc-dhcp-dns-12.txt? From owner-dhcp-v4@bucknell.edu Wed May 17 07:00:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02260 for ; Wed, 17 May 2000 07:00:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id GAA24080; Wed, 17 May 2000 06:57:36 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id GAA24373 for ; Wed, 17 May 2000 06:57:21 -0400 (EDT) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA02172; Wed, 17 May 2000 06:57:15 -0400 (EDT) Message-Id: <200005171057.GAA02172@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-agent-options-10.txt Date: Wed, 17 May 2000 06:57:14 -0400 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 : DHCP Relay Agent Information Option Author(s) : M. Patrick Filename : draft-ietf-dhc-agent-options-10.txt Pages : 14 Date : 16-May-00 Newer high-speed public Internet access technologies call for a high-speed modem to have a LAN attachment to one or more customer premise hosts. It is advantageous to use the Dynamic Host Configuration Protocol as defined in RFC 2131 [1] to assign customer premise host IP addresses in this environment. However, a number of security and scaling problems arise with such 'public' DHCP use. This document describes a new DHCP option to address these issues. This option extends the set of DHCP options as defined in RFC 2132 [2]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-options-10.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-agent-options-10.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-agent-options-10.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: <20000516095053.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-options-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-options-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000516095053.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v4@bucknell.edu Wed May 17 07:13:13 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02450 for ; Wed, 17 May 2000 07:13:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA21772; Wed, 17 May 2000 07:12:16 -0400 (EDT) Received: from smtp.alpha-soft.com (pop3.alpha-soft.com [209.12.181.72]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA24909 for ; Wed, 17 May 2000 07:12:08 -0400 (EDT) Received: from offset [130.244.215.97] by smtp.alpha-soft.com (SMTPD32-6.00) id ACF324D30144; Wed, 17 May 2000 07:05:23 -0400 Reply-To: From: "Bud Millwood" To: DHCPv4 discussion list Subject: RE: zeroconf and non-zeroconf scenarios Date: Wed, 17 May 2000 13:10:55 +0200 Message-ID: <000301bfbff0$9231b290$3201a8c0@offset.weird.se> 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 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit We have a product that some of you following this thread may be interested in taking a look at. It's called DHCP Auto, and it's a self-bootstrapping DHCP server for Win95/98 that has to deal with a lot of zeroconf issues. In particular, you may be interested in the Technical Reference that ships with the demo that describes what the server does in different scenarios. You can find it at http://www.weird-solutions.com/product/index.html. DHCP Auto: a) bootstraps a Windows machine configured as a DHCP client by assigning itself an address (Win98 can do this automatically) b) runs in the background as a dynamic DHCP/dynamic BOOTP server c) handles multiple DHCP servers through simple elections d) handles nearly all cases of duplicate addresses by MAC hashing & arping e) integrates with corporate DHCP servers by shutting down upon discovering a corporate server (and retrieving an address from that server) f) is limited to single segments Re-reading this, it looks like an advertisement - it's not meant to be. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 70 566 7803 fax: +46 8 758 3687 mailto:budm@weird-solutions.com From owner-dhcp-v4@bucknell.edu Fri May 19 04:21:01 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA01619 for ; Fri, 19 May 2000 04:21:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id EAA06058; Fri, 19 May 2000 04:15:02 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id EAA31797; Fri, 19 May 2000 04:14:58 -0400 (EDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id BAA28658; Fri, 19 May 2000 01:14:54 -0700 (PDT) From: Bill Manning Message-Id: <200005190814.BAA28658@boreas.isi.edu> Subject: Re: Fwd: linklocal + DHCP servers To: DHCPv4 discussion list Date: Fri, 19 May 100 01:14:54 -0700 (PDT) Cc: dhcp-v4@bucknell.edu In-Reply-To: <4.2.2.20000504174406.00a61810@mail.bucknell.edu> from "Ralph Droms" at May 4, 0 05:48:07 pm X-Mailer: ELM [version 2.4 PL24 PGP6] Content-Type: text Reply-To: bmanning@ISI.EDU Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN % % Jay Goldschmidt posted the question below to the zeroconf mailing list; the % discussion morphed into the broader question about whether DHCP servers % should ever hand out link-local (169.254/16) addresses. Seemed like a good % question to ask on the DHCP mailing list, too... Whats the point? These are autoconfigured by the end systems. % There's a related question - after taking on a link-local address, should % the DHCP client use that link-local address or 0.0.0.0 as the source % address in subsequent broadcast DHCPDISCOVER messages? My take is that they use the link-local address as source. % % - Ralph % % >From: Jason Goldschmidt % >To: zeroconf@merit.edu % >Subject: linklocal + DHCP servers % > % >When a DHCP server comes up on a zeroconf network, are link-local % >configured devices considered as configured devices to the DHCP server? % > % >Or in other words: There is a zeroconf device that has configured itself % >w/ a link-local address. Can that device, send a DHCPREQUEST for its % >link-local address? And if so, what should the DHCP server do with that % >address request? % > % >A server might want to allow the zeroconf device to keep the address and % >then respond w/ additional configuration information in the subsequent % >DHCPACK. Though, doing so would still bring up the problems that Bernard % >just mentioned about NATing for link-local addresses. % > % >Thanks, % > % >-Jason % > % > % >*************************************) % >Jason Goldschmidt jgoldsch@acm.org *) % >http://coral.bucknell.edu/~jgoldsch *) % >"My Reality Check Bounced" *) % > -Scott Adams *) % >*************************************) % > % > % > % > % > % % -- --bill From owner-dhcp-v4@bucknell.edu Fri May 19 08:16:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03994 for ; Fri, 19 May 2000 08:16:43 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA31820; Fri, 19 May 2000 08:12:32 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA02156 for ; Fri, 19 May 2000 08:12:26 -0400 (EDT) Received: from droms-mac (pm3mi1-20.uplink.net [209.173.86.21]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA10706; Fri, 19 May 2000 08:12:21 -0400 (EDT) Message-Id: <4.2.2.20000519075252.00a723a0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 19 May 2000 07:58:32 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Fwd: linklocal + DHCP servers Cc: dhcp-v4@bucknell.edu In-Reply-To: <200005190814.BAA28658@boreas.isi.edu> References: <4.2.2.20000504174406.00a61810@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 01:14 AM 5/19/00 -0700, Bill Manning wrote: >% >% Jay Goldschmidt posted the question below to the zeroconf mailing list; the >% discussion morphed into the broader question about whether DHCP servers >% should ever hand out link-local (169.254/16) addresses. Seemed like a good >% question to ask on the DHCP mailing list, too... > > Whats the point? These are autoconfigured by the end systems. Autoconfiguration and link-local are two distinct characteristics of 169.254/24 addresses. I'm asking if DHCP-configured, link-local addresses might ever be of interest. And, if the question has been asked once, is it likely to be asked again - if so, we should make a decision and codify that decision in an appropriate spec so we don't revisit the question in the future. >% There's a related question - after taking on a link-local address, should >% the DHCP client use that link-local address or 0.0.0.0 as the source >% address in subsequent broadcast DHCPDISCOVER messages? > > My take is that they use the link-local address as source. According to RFC2131, DHCPDISCOVER messages are to be sent with source address 0.0.0.0 We should decide if we want to change that aspect of the DHCP spec to accommodate autoconfiguring hosts. There may be a DHCP server that drops incoming DHCPDISCOVER messages with non-zero source addresses. - Ralph From owner-dhcp-v4@bucknell.edu Fri May 19 10:46:52 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05862 for ; Fri, 19 May 2000 10:46:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA27860; Fri, 19 May 2000 10:42:45 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA25709; Fri, 19 May 2000 10:42:42 -0400 (EDT) Received: from kkinnear-nt (ch2-dhcp133-199.cisco.com [161.44.133.199]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA09019; Fri, 19 May 2000 10:16:50 -0400 (EDT) Message-Id: <4.2.0.58.20000519100936.01a024e0@funnel.cisco.com> X-Sender: kkinnear@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 19 May 2000 10:17:44 -0400 To: DHCPv4 discussion list From: Kim Kinnear Subject: Re: Fwd: linklocal + DHCP servers Cc: DHCPv4 discussion list , kkinnear@cisco.com In-Reply-To: <4.2.2.20000519075252.00a723a0@mail.bucknell.edu> References: <200005190814.BAA28658@boreas.isi.edu> <4.2.2.20000504174406.00a61810@mail.bucknell.edu> 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 At 07:58 AM 5/19/00 -0400, Ralph Droms wrote: >> [...] > >According to RFC2131, DHCPDISCOVER messages are to be sent with source >address 0.0.0.0 We should decide if we want to change that aspect >of the DHCP spec to accommodate autoconfiguring hosts. There may be >a DHCP server that drops incoming DHCPDISCOVER messages with non-zero >source addresses. > >- Ralph Interesting. I was under the impression that the IP source address was essentially a don't care for the DHCP protocol (though no doubt someone can quote me a paragraph or two that contains words that appear to counter my claim). But, semantically, what does the source address matter to the DHCP protocol? The only times we care about the current address of the client we require the client to explicitly put it in the ciaddr. I would say that we should revise RFC2131 to say that the protocol is independent of the source IP address (since apparently that is not explicit now) since all of the information used by the protocol is *inside* of the DHCP packet itself (which plays well with the forthcoming authentication). Or am I missing something here? Cheers -- Kim From owner-dhcp-v4@bucknell.edu Fri May 19 11:08:10 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06240 for ; Fri, 19 May 2000 11:08:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA04831; Fri, 19 May 2000 11:06:54 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA26089 for ; Fri, 19 May 2000 11:06:46 -0400 (EDT) Received: from droms-mac (pm3mi2-30.uplink.net [209.173.86.79]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA10787; Fri, 19 May 2000 11:06:43 -0400 (EDT) Message-Id: <4.2.2.20000519105504.00a7cb70@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 19 May 2000 11:02:11 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Fwd: linklocal + DHCP servers Cc: DHCPv4 discussion list , kkinnear@cisco.com In-Reply-To: <4.2.0.58.20000519100936.01a024e0@funnel.cisco.com> References: <4.2.2.20000519075252.00a723a0@mail.bucknell.edu> <200005190814.BAA28658@boreas.isi.edu> <4.2.2.20000504174406.00a61810@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 10:17 AM 5/19/00 -0400, Kim Kinnear wrote: >Interesting. I was under the impression that the IP source >address was essentially a don't care for the DHCP protocol >(though no doubt someone can quote me a paragraph or two that >contains words that appear to counter my claim). From RFC2131 (page 23) 4.1 Constructing and sending DHCP messages [...] DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0. If I remember correctly, we added that text for compliance with RFC1122 (and I'll offer to be corrected by an appropriate quote) that requires a source address of 0.0.0.0 for broadcast packets from a host that has not been assigned an IP address. > But, >semantically, what does the source address matter to the DHCP >protocol? The only times we care about the current address of >the client we require the client to explicitly put it in the >ciaddr. Agreed. I'm coming at this issue from the point of view of strict interpretation of the words in the RFC, not so much what is needed for correct operation. There is a related - although non-DHCP - issue: what does the IP spec day about IP datagrams with a link-local source address, and (as a practical matter) what do routers with those datagrams? I guess this question would apply to both 169.254/24 (IPv4) and IPv6 link-local addresses. >I would say that we should revise RFC2131 to say that the >protocol is independent of the source IP address (since >apparently that is not explicit now) since all of the information >used by the protocol is *inside* of the DHCP packet itself (which >plays well with the forthcoming authentication). I agree - with the caveat that we don't want to encourage the use of DHCP in a way that is non-interoperable with other protocols and legacy devices. - Ralph From owner-dhcp-v4@bucknell.edu Fri May 19 11:28:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06634 for ; Fri, 19 May 2000 11:28:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA15542; Fri, 19 May 2000 11:25:42 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA26742 for ; Fri, 19 May 2000 11:25:38 -0400 (EDT) Received: from droms-mac (pm3mi2-29.uplink.net [209.173.86.78]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id LAA10798 for ; Fri, 19 May 2000 11:25:36 -0400 (EDT) Message-Id: <4.2.2.20000519111844.00a799f0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 19 May 2000 11:25:18 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for "User Class Option for DHCP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "The User Class Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri May 19 11:32:23 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06757 for ; Fri, 19 May 2000 11:32:23 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA25632; Fri, 19 May 2000 11:29:59 -0400 (EDT) Received: from monitor.internaut.com (mg136-128.ricochet.net [204.179.136.128]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA15755; Fri, 19 May 2000 11:29:45 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id IAA19826; Fri, 19 May 2000 08:13:12 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Fwd: linklocal + DHCP servers Date: Fri, 19 May 2000 08:34:26 -0700 Message-ID: <004101bfc1a7$b8733380$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.2.2.20000519075252.00a723a0@mail.bucknell.edu> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4131.1600 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >% There's a related question - after taking on a link-local address, should >% the DHCP client use that link-local address or 0.0.0.0 as the source >% address in subsequent broadcast DHCPDISCOVER messages? > > My take is that they use the link-local address as source. The question is not so much what address is used as source, but what the DHCP server is expected to *use* the source address for. Is it being suggested that the DHCP server should use this as some kind of hint to offer the auto-configured address? From owner-dhcp-v4@bucknell.edu Fri May 19 11:35:29 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06839 for ; Fri, 19 May 2000 11:35:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA23602; Fri, 19 May 2000 11:34:22 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA27617 for ; Fri, 19 May 2000 11:34:15 -0400 (EDT) From: george.tsirtsis@bt.com Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Fri, 19 May 2000 15:32:17 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Fri, 19 May 2000 15:32:19 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB2078A5881@mbtlipnt02.btlabs.bt.co.uk> To: DHCPv4 discussion list Cc: jerome.privat@bt.com, george.tsirtsis@bt.com Subject: Triggering AAA from DHCP Relay Agents - New I-D Date: Fri, 19 May 2000 15:32:10 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Reply-To: george.tsirtsis@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN All, A number of proposals already suggest requirements for AAA - DHCP interactions. While we concur with the general drift of these proposals I think one important requirement is missing. This is the ability to trigger AAA functions from the DHCP Relay Agent rather than the DHCP Server, especially in environments that DHCP replaces traditional PPP based access (e.g: always on internet access). So, we just submitted a draft explaining why this is necessary and the implications to current DHCP. Your thoughts? Regards George and Jerome The following draft was submitted today ----------------------------------------------------------------------- INTERNET-DRAFT George Tsirtsis Expires in November 2000 Jerome Privat BT May 2000 Triggering AAA from DHCP Relay Agents draft-tsirtsis-dhc-AAA-RA-00.txt Abstract 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. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Introduction Traditionally DHCP has mainly been used in intranets such as corporate or campus networks. 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. The reason is that if DHCP is to replace PPP in some environments, there will be a strong requirement to make sure that ALL the Internet Access features supported by the PPP model can be replicated in DHCP-based Internet Access scenarios. However, there are fundamental differences between PPP-based and DHCP-based Internet access. On the one hand, PPP terminates on the Access Router (or Network Access Server-NAS) which becomes the Policy Enforcement Point between the network and the client. Typically the NAS is at the same time a PPP terminator, AAA client and possibly DHCP relay agent. This is a very powerful model since the NAS is the most sensible point at which to apply services such as Accounting, Resource Allocation, Authentication and many others. On the other hand, DHCP runs from the client to the DHCP server which is inside the Access Network and possibly several routers away from the Access Router. In the absence of PPP, the Access Router, as it stands at the moment, does not have a way to trigger the AAA functions that PPP based networks have. Although, DHCP relay agents will typically be operating in the Access Routers, these are considered to be very simple, and most importantly transparent, devices. In this document, we propose, that DHCP relay agents be used as AAA triggers intercepting and conveying relevant information from clients to AAA servers. This allows the PPP Internet Access model to be replicated in a non-PPP environment. 2. Currently proposed model: AAA from DHCP server 2.1 Description The currently proposed model for DHCP based roaming and mobile IP as described in [DHC-AAA] and [MOBILEIP-AAA] is shown in Figure 1. In this model the AAA procedure is invoked from the DHCP server. Local Domain Internet +-------------+ +----------------+ | +------+ | | +------+ | | | AAAL | | AAA Protocol | | AAAP | | | | +----------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------+ | | | | | | +--------+ | +---+---+ | | DHCP | DHCP | | DHCP | | | Client |-------|--| Server| | +--------+ | +-------+ | AAAP = Public authority | | AAAL = local authority +-------------+ Figure 1: DHCP/AAA Current Model Even with the use of a DHCP Relay Agent the above picture does not change fundamentally but only becomes Figure 2. Local Domain Internet +-------------+ +----------------+ | +------+ | | +------+ | | | AAAL | | AAA Protocol | | AAAP | | | | +----------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------+ | | | | | | +------+ +-----+ | +---+---+ | |DHCP | |DHCP | | | DHCP | | |Client|--|Relay|--|--| Server| | +------+ +-----+ | +-------+ | AAAP = Public authority | | AAAL = local authority +-------------+ Figure 2: DHCP/AAA Servers Model with Relay Agent 2.2 Limitations The above model is fine for traditional use of DHCP in corporate and other such networks where a level of trust already exists between the clients and the network. DHCP is, however, increasingly being used in other environments such as residential access over Cable modems or possibly xDSL and mobile networks. These new types of applications for DHCP have different requirements and characteristics in terms of security and trust. Before DHCP was considered in the above types of networks, PPP had been applied successfully providing similar functionality. PPP has a fundamental difference to DHCP in the way it treats new clients. All checks happen from the Access Point, i.e: the first point of attachment for the client, for example the NAS. Figure 3 shows this PPP model. Local Domain Internet +-------------+ +----------------+ | +------+ | | +------+ | | | AAAL | | AAA Protocol | | AAAP | | | | +----------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------+ | | | | | | +--------+ | +---+---+ | | PPP | PPP | |NAS/AAA| | | Client |-------|--| Client| | +--------+ | +-------+ | AAAP = Public authority | | AAAL = local authority +-------------+ Figure 3: PPP Model 3. New model: AAA from DHCP Relay Agent 3.1 Description If DHCP is to replace PPP in some environments, a similar model is needed so the client details are checked on the first node of attachment (CMTS, DSLAM, etc.). This would produce the layout of Figure 4. This is consistent with the approach followed in [DHC-AGENT] in that the access point is the first trusted point in the provider network. Local Domain Internet +-------------+ +----------------+ | +------+ | | +------+ | | | AAAL | | AAA Protocol | | AAAP | | | | +----------------------+ | | | +---+--+ | | +------+ | | | | | | | | | +----------------+ | | | | | +----------------+ +--------+ | +---+---+ +--------+ | | DHCP | DHCP | | DHCP | | DHCP | | | Client |-------|--| Relay |-------| Server | | +--------+ | +-------+ +--------+ | | | +------------------------------+ Figure 4: DHCP Relay Agent Model 3.2 Advantages The major benefit from this new model is the ability to enforce policy. In Figure 2, the DHCP server can only Authenticate the client details but not much else. In the PPP model, because the AAA check takes place at the NAS, it is possible to get detailed, customized configuration for the client and dynamically configure an access list on the NAS's interface to restrict/allow certain functions and resources. It could be argued that this customization is also possible in the currently proposed model (AAA from DHCP server). Once a user identity has been established using AAA, looking up access control lists and storing usage information could be done using LDAP or other existing means to communicate with databases/directories. However there is value for a provider in reusing as much as possible the same existing AAA mechanisms as currently deployed. 4. Impact on DHCP 4.1 Authenticating a user Discussion: In order to authenticate a user, a AAA server needs to be passed some information of the form username/password. How does the AAA client get this information? Does it get it through DHCP (either through existing options or through a new one) or does it get it through a separate challenge sent by the access point? Note that once an access point gets the username/password information, it can use it for the Agent Remote ID sub-option proposed in [DHC-AGENT]. 4.2 Relay Agent behaviour Discussion: Clearly, the relay agent behaviour needs to be specified when triggering AAA from DHCP messages. The relay agent needs to know: - Which DHCP message triggers a AAA check. - Which DHCP message triggers the download of policies (such as an access list) on the access point? Note that in order to install access lists, some information is required such as the IP address given to the client. - What action to take if no response is received from the AAA server (timer, notification sent back to client). The Relay agent must be able to terminate service to a client if not authorized by a AAA server. 5. Security considerations Authentication is presently being added to the DHCP protocol [DHC-AUTH]. This allows DHCP clients and servers to authenticate each other. Our purpose differs in that we want to authenticate and authorize a user before he accesses a provider network, to apply policy to customize this access connection and to account for the service. However it may be possible to re-use some elements of this authentication framework when coupling AAA to DHCP. 6. Acknowledgements The authors would like to thank their colleague Alan O'Neill, who initiated this work. 7. References [DHC-AAA] S. Das, A. McAuley, Telcordia, S. Baba, Y. Shobatake, Toshiba, "Authentication, Authorization, and Accounting Requirements for Roaming Nodes using DHCP", , March 2000 [MOBILEIP-AAA], S. Glass, Sun, T. Hiller, Lucent, S. Jacobs, GTE, C. Perkins, Nokia, "Mobile IP Authentication, Authorization, and Accounting Requirements", , March 2000. [DHC-AGENT] M. Patrick, Motorola, "DHCP Relay Agent Information Option", , May 2000 [DHC-ENHANCE], A. McAuley, S. Das, Telcordia, S. Baba, Y. Shobatake Toshiba, "Requirements for Extending DHCP into New Environments", , March 2000 [DHC-AUTH] R. Droms, Bucknell University, "Authentication for DHCP Messages", , October 1999 8. Authors George Tsirtsis Internet Futures Group Advanced Communications Research BT Phone: +44 20 88260073 Email: george.tsirtsis@bt.com Jerome Privat BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, IP5 3RE UK Phone: +44 1473 606304 Email: jerome.privat@bt.com Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. From owner-dhcp-v4@bucknell.edu Fri May 19 13:00:44 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08282 for ; Fri, 19 May 2000 13:00:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA18661; Fri, 19 May 2000 12:57:24 -0400 (EDT) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA04037; Fri, 19 May 2000 12:57:11 -0400 (EDT) Received: (from bmanning@localhost) by boreas.isi.edu (8.8.7/8.8.6) id JAA16025; Fri, 19 May 2000 09:57:09 -0700 (PDT) From: Bill Manning Message-Id: <200005191657.JAA16025@boreas.isi.edu> Subject: Re: Fwd: linklocal + DHCP servers To: DHCPv4 discussion list Date: Fri, 19 May 2000 09:57:09 -0700 (PDT) Cc: dhcp-v4@bucknell.edu (DHCPv4 discussion list), kkinnear@cisco.com In-Reply-To: <4.2.2.20000519105504.00a7cb70@mail.bucknell.edu> from "Ralph Droms" at May 19, 2000 11:02:11 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bmanning@ISI.EDU Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit % DHCP messages broadcast by a client prior to that client obtaining % its IP address must have the source address field in the IP header % set to 0. % % If I remember correctly, we added that text for compliance with RFC1122 % (and I'll offer to be corrected by an appropriate quote) that requires % a source address of 0.0.0.0 for broadcast packets from a host that has % not been assigned an IP address. Ah, but it has been assigned an IP address from link-local space. % There is a related - although non-DHCP - issue: what does the IP % spec day about IP datagrams with a link-local source address, and % (as a practical matter) what do routers with those datagrams? I % guess this question would apply to both 169.254/24 (IPv4) and IPv6 % link-local addresses. The IP spec has no concept of link-local. Routers et.al. should not forward packets w/ link-local addresses, heck they should not even be bridged, imho. (I've got a draft in on how this should occur.) --bill From owner-dhcp-v4@bucknell.edu Fri May 19 14:47:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA09411 for ; Fri, 19 May 2000 14:47:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA29169; Fri, 19 May 2000 14:43:54 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA16877 for ; Fri, 19 May 2000 14:43:52 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a47.pm3-29.theriver.com [206.102.195.111]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id UAA24478; Thu, 18 May 2000 20:04:19 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA00655; Fri, 19 May 2000 11:43:52 -0700 (MST) Message-Id: <200005191843.LAA00655@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Fwd: linklocal + DHCP servers In-Reply-To: Message from "Bernard Aboba" of "Fri, 19 May 2000 08:34:26 MST." <004101bfc1a7$b8733380$428939cc@ntdev.microsoft.com> Date: Fri, 19 May 2000 11:43:52 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > The question is not so much what address is used as source, but what the > DHCP server is expected to *use* the source address for. Is it being > suggested that the DHCP server should use this as some kind of hint > to offer the auto-configured address? The DHCP server can't know the source address reliably, since the source address is lost on relayed packets. So I hope the answer to this question is 'no'. :') _MelloN_ From owner-dhcp-v4@bucknell.edu Fri May 19 17:01:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11012 for ; Fri, 19 May 2000 17:01:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id QAA21787; Fri, 19 May 2000 16:57:16 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id QAA03610 for ; Fri, 19 May 2000 16:57:04 -0400 (EDT) Received: from droms-mac (pm3mi1-20.uplink.net [209.173.86.21]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id QAA10927 for ; Fri, 19 May 2000 16:57:03 -0400 (EDT) Message-Id: <4.2.2.20000519165434.00a624e0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 19 May 2000 16:55:27 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for name service search order option Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "The Name Service Search Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri May 19 17:11:48 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11084 for ; Fri, 19 May 2000 17:11:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA08065; Fri, 19 May 2000 17:11:10 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA12152 for ; Fri, 19 May 2000 17:11:07 -0400 (EDT) Received: from droms-mac (pm3mi1-20.uplink.net [209.173.86.21]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA10944 for ; Fri, 19 May 2000 17:11:06 -0400 (EDT) Message-Id: <4.2.2.20000519171000.00abb170@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 19 May 2000 17:10:55 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for name service search order option Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "The Subnet Selection Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri May 19 17:33:53 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11224 for ; Fri, 19 May 2000 17:33:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id RAA04880; Fri, 19 May 2000 17:31:13 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id RAA22450 for ; Fri, 19 May 2000 17:31:01 -0400 (EDT) Received: from droms-mac (pm3mi1-20.uplink.net [209.173.86.21]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id RAA10949 for ; Fri, 19 May 2000 17:31:00 -0400 (EDT) Message-Id: <4.2.2.20000519173020.00a5fd60@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 19 May 2000 17:30:50 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: WG last call for subnet selection option Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN (Resent 'cause I botched the subject in the previous message.) This message announces a DHC WG last call for "The Subnet Selection Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Sat May 20 10:36:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29732 for ; Sat, 20 May 2000 10:36:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA06886; Sat, 20 May 2000 10:31:38 -0400 (EDT) Received: from monitor.internaut.com (mg136-128.ricochet.net [204.179.136.128]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA23039 for ; Sat, 20 May 2000 10:31:28 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id HAA26315; Sat, 20 May 2000 07:14:38 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Cc: "'DHCPv4 discussion list'" Subject: RE: Fwd: linklocal + DHCP servers Date: Sat, 20 May 2000 07:36:11 -0700 Message-ID: <000001bfc268$bed4aee0$428939cc@ntdev.microsoft.com> 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 CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200005191843.LAA00655@grosse.manhattan.fugue.com> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4131.1600 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >The DHCP server can't know the source address reliably, since the >source address is lost on relayed packets. So I hope the answer to >this question is 'no'. :') It isn't possible to offer a linklocal address on relayed packets since there is no way for the DHCP server to determine whether the address is in use or not. On a local link, the DHCP server can ARP for the address. On a non-local link it is not possible to use ARP for conflict detection and you can't use PING either because linklocal addresses are not routable. From owner-dhcp-v6@bucknell.edu Sat May 20 12:04:43 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00119 for ; Sat, 20 May 2000 12:04:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA25522; Sat, 20 May 2000 12:00:45 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA02855 for ; Sat, 20 May 2000 12:00:43 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4KG0Jx21230 for ; Sat, 20 May 2000 18:00:21 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id SAA26065 for ; Sat, 20 May 2000 18:00:10 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id SAA23790 for ; Sat, 20 May 2000 18:01:26 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005201601.SAA23790@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: draft-ietf-dhc-dhcpv6-15.txt Date: Sat, 20 May 2000 18:01:26 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN The last DHCPv6 I-D, draft-ietf-dhc-dhcpv6-15.txt, uses many times the false assumption that a subnet prefix identifies a link but more than one link can share a subnet prefix (look at for instance draft-nordmark-ipv6-aaa-hooks-00.txt section 12 "Open issue" page 11, the problem is a subnet prefix can be "off-link", RFC 2461, section 4.6.2 Prefix Information "L flag", page 30). Regards Francis.Dupont@enst-bretagne.fr PS: I don't know how to fix it for all cases because interface indexes are local to a node (ie. to add an interface index in some messages will fix the relay -> client transmission (as I have already suggested) but not the binding index (two different nodes can have the same link-local address and share the same subnet prefix if there are not on the same link then link-local address + subnet prefix is not enough and for instance 11.6.1 Receipt of Request messages "the server checks if a binding already exists for the client" can give the wrong answer...) From owner-dhcp-v6@bucknell.edu Sat May 20 13:31:55 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00487 for ; Sat, 20 May 2000 13:31:55 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA07249; Sat, 20 May 2000 13:27:45 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA28653 for ; Sat, 20 May 2000 13:27:30 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id KAA10851 for ; Sat, 20 May 2000 10:27:14 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id KAA05060 for ; Sat, 20 May 2000 10:27:11 -0700 X-Virus-Scanned: Sat, 20 May 2000 10:27:11 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (icharliep-1.iprg.nokia.com [205.226.22.18]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma004915; Sat, 20 May 00 10:27:06 -0700 Message-ID: <3926C939.E29CABAB@iprg.nokia.com> Date: Sat, 20 May 2000 10:19:53 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: Re: draft-ietf-dhc-dhcpv6-15.txt References: <200005201601.SAA23790@givry.rennes.enst-bretagne.fr> 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 Hello, Then I would suggest that the DHCPv6 specification make a statement of applicability. Such links should be either be administered to make the requirements for DAD and relay connectivity come true, or else be ineligibility for configuration via DHCPv6. How many designs have been encouraged by allowing multiple isolated links to share a global IPv6 address prefix? Regards, Charlie P. Francis Dupont wrote: > The last DHCPv6 I-D, draft-ietf-dhc-dhcpv6-15.txt, uses many times > the false assumption that a subnet prefix identifies a link but > more than one link can share a subnet prefix (look at for instance > draft-nordmark-ipv6-aaa-hooks-00.txt section 12 "Open issue" page 11, > the problem is a subnet prefix can be "off-link", RFC 2461, > section 4.6.2 Prefix Information "L flag", page 30). > > Regards > > Francis.Dupont@enst-bretagne.fr > > PS: I don't know how to fix it for all cases because interface indexes > are local to a node (ie. to add an interface index in some messages > will fix the relay -> client transmission (as I have already suggested) > but not the binding index (two different nodes can have the same link-local > address and share the same subnet prefix if there are not on the same link > then link-local address + subnet prefix is not enough and for instance > 11.6.1 Receipt of Request messages "the server checks if a binding > already exists for the client" can give the wrong answer...) From owner-dhcp-v6@bucknell.edu Sat May 20 14:07:03 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00623 for ; Sat, 20 May 2000 14:07:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA11614; Sat, 20 May 2000 14:03:32 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA08793 for ; Sat, 20 May 2000 14:03:21 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4KI35x35517 for ; Sat, 20 May 2000 20:03:05 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id UAA27019 for ; Sat, 20 May 2000 20:03:03 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id UAA24127 for ; Sat, 20 May 2000 20:04:20 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005201804.UAA24127@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of Sat, 20 May 2000 10:19:53 PDT. <3926C939.E29CABAB@iprg.nokia.com> Date: Sat, 20 May 2000 20:04:20 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: Then I would suggest that the DHCPv6 specification make a statement of applicability. => I believe that you propose to restrict DHCPv6 to situations where no shared subnet prefix is used across multiple links? Such links should be either be administered to make the requirements for DAD and relay connectivity come true, or else be ineligibility for configuration via DHCPv6. => I don't understand this... How many designs have been encouraged by allowing multiple isolated links to share a global IPv6 address prefix? => the links have not to be isolated for sharing a common subnet prefix. I believe a case of application of "off-links" is a star of radio networks with a central router using a common prefix and Eric's host routing hook as a kind of micro-mobility. The only issue there is DAD (ie link-local multicast won't spread) and a nice solution, address allocation management by a DHCPv6 server, will not work because DHCPv6 can't deal with "off-link" prefixes... (the idea is to use the DHCPv6 server knowledge in order to detect and/or avoid duplicates between links) > The last DHCPv6 I-D, draft-ietf-dhc-dhcpv6-15.txt, uses many times > the false assumption that a subnet prefix identifies a link but > more than one link can share a subnet prefix (look at for instance > draft-nordmark-ipv6-aaa-hooks-00.txt section 12 "Open issue" page 11, > the problem is a subnet prefix can be "off-link", RFC 2461, > section 4.6.2 Prefix Information "L flag", page 30). Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Sat May 20 18:15:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01561 for ; Sat, 20 May 2000 18:15:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id SAA09681; Sat, 20 May 2000 18:12:47 -0400 (EDT) Received: from mailhost.iprg.nokia.com (mailhost.iprg.nokia.com [205.226.5.12]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id SAA06579 for ; Sat, 20 May 2000 18:12:31 -0400 (EDT) Received: from darkstar.iprg.nokia.com (darkstar.iprg.nokia.com [205.226.5.69]) by mailhost.iprg.nokia.com (8.9.3/8.9.3-GLGS) with ESMTP id PAA20631; Sat, 20 May 2000 15:12:11 -0700 (PDT) Received: (from root@localhost) by darkstar.iprg.nokia.com (8.9.3/8.9.3-VIRSCAN) id PAA25451; Sat, 20 May 2000 15:12:07 -0700 X-Virus-Scanned: Sat, 20 May 2000 15:12:07 -0700 Nokia Silicon Valley Email Exploit Scanner Received: from (icharliep-1.iprg.nokia.com [205.226.22.18]) by darkstar.iprg.nokia.com SMTP/WTS (12.69) xma025306; Sat, 20 May 00 15:12:02 -0700 Message-ID: <39270C01.CA4D238@iprg.nokia.com> Date: Sat, 20 May 2000 15:04:49 -0700 From: Charlie Perkins Organization: Nokia X-Mailer: Mozilla 4.61 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list CC: dhcp-v6@bucknell.edu Subject: Re: draft-ietf-dhc-dhcpv6-15.txt References: <200005201804.UAA24127@givry.rennes.enst-bretagne.fr> 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 Hello Francis, > => I believe that you propose to restrict DHCPv6 to situations > where no shared subnet prefix is used across multiple links? That seems almost reasonable to me, except that I would rather say that DHCPv6 entities should not be affected by the disconnected nature of the link. > Such links should be either be > administered to make the requirements for DAD and relay > connectivity come true, or else be ineligibility for configuration > via DHCPv6. > > => I don't understand this... It is almost like saying the same as the above in a different way. Either a link can do DAD, or the administrator can put in some bridge or other equipment to make it do DAD. And, if a relay is supposed to be on the same link as the DHCP client, the administrator has to make it look that way even if the link is partitioned. Otherwise, I suspect that the problem is too hard. And, do you already admit that no one has solved it for stateless? > How many designs have been encouraged by allowing > multiple isolated links to share a global IPv6 address > prefix? > > => the links have not to be isolated for sharing a common subnet prefix. > I believe a case of application of "off-links" is a star of radio > networks with a central router using a common prefix and Eric's > host routing hook as a kind of micro-mobility. The only issue there > is DAD (ie link-local multicast won't spread) and a nice solution, > address allocation management by a DHCPv6 server, will not work > because DHCPv6 can't deal with "off-link" prefixes... > (the idea is to use the DHCPv6 server knowledge in order to detect > and/or avoid duplicates between links) This is fine with me, but it amounts to an agreement to my suggested requirement: > Such links should be administered to make the requirements > for DAD and relay connectivity come true It has to be done by administration, because as you point out it is unlikely to be done by any natural means of communication. In some nightmare scenario, we could go about defining a new numbering space adjunct to the basic routing prefix, sort-of what has been suggested for site-local prefixes. I'd hate to see that. Regards, Charlie P. From owner-dhcp-v4@bucknell.edu Sat May 20 19:32:50 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01865 for ; Sat, 20 May 2000 19:32:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA07938; Sat, 20 May 2000 19:29:00 -0400 (EDT) Received: from luna.join.com (ns.join.com [209.125.77.130]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA05017 for ; Sat, 20 May 2000 19:28:51 -0400 (EDT) Received: from robspc (robspc [165.227.59.154]) by luna.join.com (8.10.0/8.10.0) with ESMTP id e4KNSo417800; Sat, 20 May 2000 16:28:50 -0700 (PDT) Message-Id: <4.2.2.20000520162137.00aae380@209.125.77.130> X-Sender: robs@209.125.77.130 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 20 May 2000 16:23:49 -0700 To: DHCPv4 discussion list From: Rob Stevens Subject: Re: Fwd: linklocal + DHCP servers Cc: DHCPv4 discussion list , DHCPv4 discussion list In-Reply-To: <200005191843.LAA00655@grosse.manhattan.fugue.com> References: <004101bfc1a7$b8733380$428939cc@ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: robs@join.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 11:43 AM 5/19/00 , Ted Lemon wrote: >The DHCP server can't know the source address reliably, since the >source address is lost on relayed packets. ... > > Is it? I thought this was a grey area. I distinctly remember posting this question to this group about 2 years back and getting no consensus answer. From owner-dhcp-v6@bucknell.edu Sun May 21 09:08:59 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07674 for ; Sun, 21 May 2000 09:08:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA24310; Sun, 21 May 2000 09:05:57 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA32089 for ; Sun, 21 May 2000 09:05:53 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4LD54x48491; Sun, 21 May 2000 15:05:04 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA02040; Sun, 21 May 2000 15:05:03 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA26737; Sun, 21 May 2000 15:06:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005211306.PAA26737@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list cc: dhcp-v6@bucknell.edu Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of Sat, 20 May 2000 15:04:49 PDT. <39270C01.CA4D238@iprg.nokia.com> Date: Sun, 21 May 2000 15:06:24 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: > => I believe that you propose to restrict DHCPv6 to situations > where no shared subnet prefix is used across multiple links? That seems almost reasonable to me, except that I would rather say that DHCPv6 entities should not be affected by the disconnected nature of the link. => there are some situations where the "off-link" property doesn't come from the disconnected nature of the link (a case where there is near no good solution) but does come from the spread of the subnet prefix over a set of (interconnected) links. In this (second) case DHCPv6 is a good central management tool and I'd like to be able to use it... > Such links should be either be > administered to make the requirements for DAD and relay > connectivity come true, or else be ineligibility for configuration > via DHCPv6. > > => I don't understand this... It is almost like saying the same as the above in a different way. Either a link can do DAD, or the administrator can put in some bridge or other equipment to make it do DAD. And, if a relay is supposed to be on the same link as the DHCP client, the administrator has to make it look that way even if the link is partitioned. Otherwise, I suspect that the problem is too hard. And, do you already admit that no one has solved it for stateless? => my concern is not about partitioned links. > How many designs have been encouraged by allowing > multiple isolated links to share a global IPv6 address > prefix? > > => the links have not to be isolated for sharing a common subnet prefix. > I believe a case of application of "off-links" is a star of radio > networks with a central router using a common prefix and Eric's > host routing hook as a kind of micro-mobility. The only issue there > is DAD (ie link-local multicast won't spread) and a nice solution, > address allocation management by a DHCPv6 server, will not work > because DHCPv6 can't deal with "off-link" prefixes... > (the idea is to use the DHCPv6 server knowledge in order to detect > and/or avoid duplicates between links) This is fine with me, but it amounts to an agreement to my suggested requirement: > Such links should be administered to make the requirements > for DAD and relay connectivity come true It has to be done by administration, because as you point out it is unlikely to be done by any natural means of communication. => yes, for me neighbor discovery DAD is obviously restricted to the link then with more than one link something else must be used. There are two immediate solutions: - use a multicast service at a larger scope (distributed solution) - use DHCPv6 because DHCPv6 has a global knowledge of all the used addresses when all nodes register them. In some nightmare scenario, we could go about defining a new numbering space adjunct to the basic routing prefix, sort-of what has been suggested for site-local prefixes. I'd hate to see that. => we can have "off-link" prefixes without a parallel address space like the site-local one (I don't like it too :-). Eric's "Host Routing" is a good example... Regards Francis.Dupont@enst-bretagne.fr (no more @inria.fr) From owner-dhcp-v4@bucknell.edu Sun May 21 19:35:28 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11178 for ; Sun, 21 May 2000 19:35:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id TAA21928; Sun, 21 May 2000 19:31:53 -0400 (EDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id TAA05510 for ; Sun, 21 May 2000 19:31:45 -0400 (EDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id QAA03284; Sun, 21 May 2000 16:29:53 -0700 (PDT) From: Bill Manning Message-Id: <200005212329.QAA03284@zephyr.isi.edu> Subject: Re: Fwd: linklocal + DHCP servers To: DHCPv4 discussion list Date: Sun, 21 May 2000 16:29:53 -0700 (PDT) Cc: dhcp-v4@bucknell.edu (DHCPv4 discussion list) In-Reply-To: <000001bfc268$bed4aee0$428939cc@ntdev.microsoft.com> from "Bernard Aboba" at May 20, 2000 07:36:11 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bmanning@ISI.EDU Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit % % >The DHCP server can't know the source address reliably, since the % >source address is lost on relayed packets. So I hope the answer to % >this question is 'no'. :') % % It isn't possible to offer a linklocal address on relayed packets % since there is no way for the DHCP server to determine whether % the address is in use or not. On a local link, the DHCP server % can ARP for the address. On a non-local link it is not possible % to use ARP for conflict detection and you can't use PING either % because linklocal addresses are not routable. % Er, they are not routable in the same way that RFC 1918 space is not routable. i.e. it is expected that operators will be smart and administrativly prohibit the routing. When the link-local space is routed, (and it is by some) then there is no inherent way to attempt to determine origin. --bill From owner-dhcp-v6@bucknell.edu Mon May 22 09:03:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01491 for ; Mon, 22 May 2000 09:03:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA10570; Mon, 22 May 2000 08:46:30 -0400 (EDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA00002 for ; Mon, 22 May 2000 08:46:21 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id 961BD768; Mon, 22 May 2000 07:46:02 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 562FC704 for ; Mon, 22 May 2000 07:46:02 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id IAA0000575875; Mon, 22 May 2000 08:45:58 -0400 (EDT) From: Jim Bound Message-Id: <200005221245.IAA0000575875@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of "Sat, 20 May 2000 18:01:26 +0200." <200005201601.SAA23790@givry.rennes.enst-bretagne.fr> Date: Mon, 22 May 2000 08:45:58 -0400 X-Mts: smtp 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 francis, i would like to approach this discussion differently with you OK. I do not see your issue for DAD, Stateless, etc. If the prefix and sum total of bits is equivalent to a GLOBAL IPv6 address. For IPv6 aggr addresses using a 64bit prefix len with the prefix and the prefix is global then the prefix does identify a link or the administrative domain has made an error. Similar to assigning 2 IPv4 addresses to a node in an admin domain. Lets just discuss global addresses first. Do you agree with the above. thanks /jim From owner-dhcp-v6@bucknell.edu Mon May 22 09:32:17 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01960 for ; Mon, 22 May 2000 09:32:15 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA23468; Mon, 22 May 2000 09:29:42 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA22536 for ; Mon, 22 May 2000 09:29:36 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4MDStD46792; Mon, 22 May 2000 15:28:56 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id PAA01459; Mon, 22 May 2000 15:28:54 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id PAA53866; Mon, 22 May 2000 15:30:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005221330.PAA53866@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list cc: bound@ZK3.DEC.COM Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of Mon, 22 May 2000 08:45:58 EDT. <200005221245.IAA0000575875@anw.zk3.dec.com> Date: Mon, 22 May 2000 15:30:08 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: For IPv6 aggr addresses using a 64bit prefix len with the prefix and the prefix is global then the prefix does identify a link or the administrative domain has made an error. => this is not what is written in RFC 2461 and 2462. Eric's draft-nordmark-ipv6-aaa-hooks-00.txt gives an example of a prefix shared across several links (and where DHCPv6 can provide a good answer to open issues). Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v4@bucknell.edu Mon May 22 10:06:08 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02676 for ; Mon, 22 May 2000 10:06:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA12921; Mon, 22 May 2000 10:01:35 -0400 (EDT) Received: from monitor.internaut.com (mg136-128.ricochet.net [204.179.136.128]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA31725 for ; Mon, 22 May 2000 10:01:24 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id GAA28626; Mon, 22 May 2000 06:44:21 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Cc: "'DHCPv4 discussion list'" Subject: RE: Fwd: linklocal + DHCP servers Date: Mon, 22 May 2000 07:06:22 -0700 Message-ID: <000701bfc3f6$ea608b30$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) X-Mimeole: Produced By Microsoft MimeOLE V5.50.4131.1600 In-Reply-To: <200005212329.QAA03284@zephyr.isi.edu> Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Er, they are not routable in the same way that RFC 1918 space is not >routable. i.e. it is expected that operators will be smart and >administrativly prohibit the routing. >When the link-local space is routed, (and it is by some) then >there is no inherent way to attempt to determine origin. Well, there are probably routers that don't treat 169.254/16 as a linklocal prefix. But that is what it was allocated as. In contrast, 192.168/16 was a private prefix, but it is not linklocal. From owner-dhcp-v4@bucknell.edu Mon May 22 10:10:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02751 for ; Mon, 22 May 2000 10:10:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA18327; Mon, 22 May 2000 10:08:10 -0400 (EDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA21425 for ; Mon, 22 May 2000 10:07:56 -0400 (EDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id HAA05290; Mon, 22 May 2000 07:06:05 -0700 (PDT) From: Bill Manning Message-Id: <200005221406.HAA05290@zephyr.isi.edu> Subject: Re: Fwd: linklocal + DHCP servers To: DHCPv4 discussion list Date: Mon, 22 May 2000 07:06:04 -0700 (PDT) Cc: bmanning@ISI.EDU ('Bill Manning'), dhcp-v4@bucknell.edu ('DHCPv4 discussion list') In-Reply-To: <000701bfc3f6$ea608b30$428939cc@ntdev.microsoft.com> from "Bernard Aboba" at May 22, 2000 07:06:22 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bmanning@ISI.EDU Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit % % >Er, they are not routable in the same way that RFC 1918 space is not % >routable. i.e. it is expected that operators will be smart and % >administrativly prohibit the routing. % >When the link-local space is routed, (and it is by some) then % >there is no inherent way to attempt to determine origin. % % Well, there are probably routers that don't treat 169.254/16 as % a linklocal prefix. But that is what it was allocated as. In % contrast, 192.168/16 was a private prefix, but it is not linklocal. Given the derth of publication on the IPv4 link-local address, I'd be surprised if -any- code base treats the 169.254.0.0/16 prefix as unique. And given its recent vintage and a lack of understanding of the longer term impact, I'd be shocked if this had even made it to SOP status. It will be a -very- long time before this has the same status as the loopback space. --bill From owner-dhcp-v6@bucknell.edu Mon May 22 10:14:46 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02883 for ; Mon, 22 May 2000 10:14:46 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA05850; Mon, 22 May 2000 10:13:36 -0400 (EDT) Received: from zmamail03.zma.compaq.com (zmamail03.zma.compaq.com [161.114.64.103]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA21099 for ; Mon, 22 May 2000 10:13:28 -0400 (EDT) Received: by zmamail03.zma.compaq.com (Postfix, from userid 12345) id 07F2A51C; Mon, 22 May 2000 10:13:12 -0400 (EDT) Received: from yquarry.zk3.dec.com (oquarry.zk3.dec.com [16.140.112.6]) by zmamail03.zma.compaq.com (Postfix) with ESMTP id CEFB249E for ; Mon, 22 May 2000 10:13:12 -0400 (EDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id KAA0000030139; Mon, 22 May 2000 10:13:12 -0400 (EDT) From: Jim Bound Message-Id: <200005221413.KAA0000030139@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: DHCPv6 discussion list Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of "Mon, 22 May 2000 15:30:08 +0200." <200005221330.PAA53866@givry.rennes.enst-bretagne.fr> Date: Mon, 22 May 2000 10:13:12 -0400 X-Mts: smtp 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 Francis, You did not answer my question? It is important? Let me try another way? Do you believe global addresses are unique because of the IPv6 Prefix? yes or no? then we can discuss non global addresses. p.s. I will look at Eric's draft again too. thanks /jim From owner-dhcp-v6@bucknell.edu Mon May 22 10:43:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03137 for ; Mon, 22 May 2000 10:43:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA00111; Mon, 22 May 2000 10:40:44 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA02382 for ; Mon, 22 May 2000 10:40:33 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4MEdVD48155 for ; Mon, 22 May 2000 16:39:32 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id QAA02769 for ; Mon, 22 May 2000 16:39:31 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id QAA54222 for ; Mon, 22 May 2000 16:40:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005221440.QAA54222@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of Mon, 22 May 2000 10:13:12 EDT. <200005221413.KAA0000030139@yquarry.zk3.dec.com> Date: Mon, 22 May 2000 16:40:57 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: You did not answer my question? It is important? => I don't understand your question and its relationship with our issue. Let me try another way? Do you believe global addresses are unique because of the IPv6 Prefix? yes or no? => the problem is not here, you can share a (global) prefix and still have unique addresses. Of course DAD will not detect duplicate between links but there is a good tool which could do that: DHCPv6! then we can discuss non global addresses. => let us stay with global addresses. p.s. I will look at Eric's draft again too. => you should read it because it is the best example of "off-link"/shared subnet prefix usage. Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Mon May 22 11:40:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03985 for ; Mon, 22 May 2000 11:40:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA00651; Mon, 22 May 2000 11:37:49 -0400 (EDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA02713 for ; Mon, 22 May 2000 11:37:38 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id BA0D34E9; Mon, 22 May 2000 10:37:22 -0500 (CDT) Received: from yquarry.zk3.dec.com (oquarry.zk3.dec.com [16.140.112.6]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 4DDBE4D9 for ; Mon, 22 May 2000 10:37:22 -0500 (CDT) Received: from localhost by yquarry.zk3.dec.com (8.8.8/1.1.22.3/11Mar00-0650AM) id LAA0000017154; Mon, 22 May 2000 11:37:21 -0400 (EDT) From: Jim Bound Message-Id: <200005221537.LAA0000017154@yquarry.zk3.dec.com> X-Authentication-Warning: yquarry.zk3.dec.com: localhost [127.0.0.1] didn't use HELO protocol To: DHCPv6 discussion list Cc: bound@ZK3.DEC.COM Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of "Mon, 22 May 2000 16:40:57 +0200." <200005221440.QAA54222@givry.rennes.enst-bretagne.fr> Date: Mon, 22 May 2000 11:37:21 -0400 X-Mts: smtp 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 Francis, > In your previous mail you wrote: > > You did not answer my question? It is important? > >=> I don't understand your question and its relationship with our issue. What I am trying to do is use the logic model often referred to in computer science and physics called the "staircase of abstraction". I am well aware of the problem and at Compaq we ran such tests and even tried to repair links at the link-layer to understand the effect to the prefix. The **EFFECT** to this problem is different for global vs site-local. I first want to deal with Global to make a scientific point per IPv6 architecture. >> >> Let me try another way? >> >> Do you believe global addresses are unique because of the IPv6 Prefix? >> >> yes or no? >=> the problem is not here, you can share a (global) prefix and still have >unique addresses. Of course DAD will not detect duplicate between links >but there is a good tool which could do that: DHCPv6! Hold on here in the IPv6 Addressing Architecture it states clearly: Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. THis is the model dhcpv6 is trying to solve now. Clearly we have work-in-progress in the IETF for IPv6 and we will for the next decade just like we do for IPv4 as we speak. We do not have to fix this problem right now for DHCPv6. ALso we should not support the idea of an interface index in any protocol. An address should define its scope for global. Site is work-in-progress on ipng and semantics are not a done deal. DHCPv6 must move forward for what is deployed today. >=> you should read it because it is the best example of "off-link"/shared >subnet prefix usage. I have read it twice now. And I question whether it is allowed but that is an IPng discussion. The routing ramifications are phenomenal and I strongly beleive DHCPv6 should not fix this problem when there is NO CONSENSUS at all in the IETF on solving this problem in this manner. regards, /jim From owner-dhcp-v4@bucknell.edu Mon May 22 11:54:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04096 for ; Mon, 22 May 2000 11:54:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA05881; Mon, 22 May 2000 11:49:50 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA16554 for ; Mon, 22 May 2000 11:49:42 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a8.pm3-32.theriver.com [206.102.192.72]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA05529; Sun, 21 May 2000 17:10:08 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id IAA00776; Mon, 22 May 2000 08:49:41 -0700 (MST) Message-Id: <200005221549.IAA00776@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Fwd: linklocal + DHCP servers In-Reply-To: Message from Rob Stevens of "Sat, 20 May 2000 16:23:49 MST." <4.2.2.20000520162137.00aae380@209.125.77.130> Date: Mon, 22 May 2000 08:49:41 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Is it? I thought this was a grey area. I distinctly remember posting this > question to this group about 2 years back and getting no consensus > answer. The DHCP relay agent is a network service, with its own source address and so on. Some relay agents are implemented to act as clever routers, and I don't think this is explicitly forbidden by RFC951, but it's certainly not recommended either, and it's probably in violation of some other RFC somewhere. Not that this is something I think anybody really cares about, but the point is that even if a particular relay agent happens to have this quality, the implementor can't assume that all relay agents have this quality, so it can't be assumed that the IP source address of the broadcast DHCP packet will make it to the DHCP server intact. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon May 22 13:48:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06704 for ; Mon, 22 May 2000 13:48:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA20369; Mon, 22 May 2000 13:45:20 -0400 (EDT) Received: from melimelo.enst-bretagne.fr (melimelo.enst-bretagne.fr [192.108.115.36]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id NAA19271 for ; Mon, 22 May 2000 13:45:02 -0400 (EDT) Received: from rsm.rennes.enst-bretagne.fr (rsm.rennes.enst-bretagne.fr [192.44.77.1]) by melimelo.enst-bretagne.fr (8.10.1/8.10.1) with ESMTP id e4MHifD25230; Mon, 22 May 2000 19:44:43 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by rsm.rennes.enst-bretagne.fr (8.8.8/8.8.8) with ESMTP id TAA05461; Mon, 22 May 2000 19:44:39 +0200 (MET DST) Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.9.3/8.9.3) with ESMTP id TAA54832; Mon, 22 May 2000 19:45:40 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200005221745.TAA54832@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: DHCPv6 discussion list cc: bound@ZK3.DEC.COM Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of Mon, 22 May 2000 11:37:21 EDT. <200005221537.LAA0000017154@yquarry.zk3.dec.com> Date: Mon, 22 May 2000 19:45:40 +0200 Sender: owner-dhcp-v6@bucknell.edu Reply-To: dhcp-v6@bucknell.edu X-Sender: Francis.Dupont@enst-bretagne.fr X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN In your previous mail you wrote: > You did not answer my question? It is important? > >=> I don't understand your question and its relationship with our issue. What I am trying to do is use the logic model often referred to in computer science and physics called the "staircase of abstraction". I am well aware of the problem and at Compaq we ran such tests and even tried to repair links at the link-layer to understand the effect to the prefix. => Eric's proposal shows a case where a subnet prefix is not shared by many links by accident, ie. because a link has been broken in many (in general not connected) parts. His proposal is more similar to a CLNP network with an address per node, ES-IS and IS-IS for routing (this kind of topology has very different properties). >=> the problem is not here, you can share a (global) prefix and still have >unique addresses. Of course DAD will not detect duplicate between links >but there is a good tool which could do that: DHCPv6! Hold on here in the IPv6 Addressing Architecture it states clearly: Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. THis is the model dhcpv6 is trying to solve now. Clearly we have work-in-progress in the IETF for IPv6 and we will for the next decade just like we do for IPv4 as we speak. We do not have to fix this problem right now for DHCPv6. => then your proposal is to add a statement that DHCPv6 works only when a subnet prefix is never associated with more than one link? I've no objection if it is added before to be published as a proposed standard... ALso we should not support the idea of an interface index in any protocol. => I just proposed to add a scope ID (aka an interface index in this case) to link-local addresses in order to partially solve the problem with shared prefixes. If shared prefix support is a non-goal then there is nothing to fix. >=> you should read it because it is the best example of "off-link"/shared >subnet prefix usage. I have read it twice now. And I question whether it is allowed but that is an IPng discussion. The routing ramifications are phenomenal and I strongly beleive DHCPv6 should not fix this problem when there is NO CONSENSUS at all in the IETF on solving this problem in this manner. => you're closing the door, I'd like to get Eric's opinion about this issue because it will be hard to reopen the door after (and I like Eric's host routing :-). Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v6@bucknell.edu Mon May 22 22:53:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14352 for ; Mon, 22 May 2000 22:53:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id WAA10229; Mon, 22 May 2000 22:49:59 -0400 (EDT) Received: from ztxmail04.ztx.compaq.com (ztxmail04.ztx.compaq.com [161.114.1.208]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id WAA31342 for ; Mon, 22 May 2000 22:49:50 -0400 (EDT) Received: by ztxmail04.ztx.compaq.com (Postfix, from userid 12345) id B61F7545; Mon, 22 May 2000 21:49:34 -0500 (CDT) Received: from anw.zk3.dec.com (wasted.zk3.dec.com [16.140.32.3]) by ztxmail04.ztx.compaq.com (Postfix) with ESMTP id 230CF6E8; Mon, 22 May 2000 21:49:34 -0500 (CDT) Received: from localhost by anw.zk3.dec.com (8.9.3/1.1.22.2/08Sep98-0251PM) id WAA0000678821; Mon, 22 May 2000 22:49:33 -0400 (EDT) From: Jim Bound Message-Id: <200005230249.WAA0000678821@anw.zk3.dec.com> To: DHCPv6 discussion list Cc: dhcp-v6@bucknell.edu Subject: Re: draft-ietf-dhc-dhcpv6-15.txt In-reply-to: Your message of "Mon, 22 May 2000 19:45:40 +0200." <200005221745.TAA54832@givry.rennes.enst-bretagne.fr> Date: Mon, 22 May 2000 22:49:33 -0400 X-Mts: smtp 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 >=> Eric's proposal shows a case where a subnet prefix is not shared >by many links by accident, ie. because a link has been broken in many >(in general not connected) parts. His proposal is more similar to a CLNP >network with an address per node, ES-IS and IS-IS for routing (this kind >of topology has very different properties). Erik's proposal shows no such case but makes an assumption I don't agree with in the intro of the spec about ND regarding he "L" bit. But lets not discuss Erik's proposal here OK. We have to stop messing with Ipv6. Site-Locals and Multiple Prefixes across links are at best research areas. We have to do with DHCPv6 what we did with IPv6. Get a proposed std out, implement it and make sure its extensible. We will evolve DHCPv6 and IPv6 and Mobile IPv6. But we have real customer that want all three right now in mulitple markets. >=> the problem is not here, you can share a (global) prefix and still have >unique addresses. Of course DAD will not detect duplicate between links >but there is a good tool which could do that: DHCPv6! Hold on here in the IPv6 Addressing Architecture it states clearly: Currently IPv6 continues the IPv4 model that a subnet prefix is associated with one link. Multiple subnet prefixes may be assigned to the same link. THis is the model dhcpv6 is trying to solve now. Clearly we have work-in-progress in the IETF for IPv6 and we will for the next decade just like we do for IPv4 as we speak. We do not have to fix this problem right now for DHCPv6. >=> then your proposal is to add a statement that DHCPv6 works only >when a subnet prefix is never associated with more than one link? >I've no objection if it is added before to be published as a proposed >standard... I would rather not as I argue that IPv6 DOES NOT PERMIT MULTIPLE PREFIXES across LINKS of the EXACT number of BITS. If it does then IPv6 is broken and needs serious fixing. What we can do is state that DHCPv6 is applicable to such and such as Charlie suggested and what we do with most routing protocols today in the IETF. > ALso we should not support the idea of an interface index in any > protocol. > >=> I just proposed to add a scope ID (aka an interface index in this case) >to link-local addresses in order to partially solve the problem with >shared prefixes. If shared prefix support is a non-goal then there is >nothing to fix. If Ipv6 will require a scope-id to get link-locals to be unique on a link because of prefixes being multi-lingual then IPv6 is totally broken. For DHCPv6 we assume a prefix+link-local is unique if that is not true then DHCPv6 will not work. I believe it is true today. There is no way to gurantee that two scopes will not collide either. The problem if we do not assume what is specified in the Addressing Architecture TODAY is out of scope. >=> you should read it because it is the best example of "off-link"/shared >subnet prefix usage. I have read it twice now. And I question whether it is allowed but that is an IPng discussion. The routing ramifications are phenomenal and I strongly beleive DHCPv6 should not fix this problem when there is NO CONSENSUS at all in the IETF on solving this problem in this manner. >=> you're closing the door, I'd like to get Eric's opinion about this issue >because it will be hard to reopen the door after (and I like Eric's >host routing :-). I am closing the door yes. The door is not open. Erik's work is a first draft and thats all. It will take at least 1.5 years to parse we need to move DHCPv6 forward. The addr arch spec supports what I am saying 100%. Does that mean in the future we can do this, well that will be a long debate. Same for the use of Anycast Addresses for Hosts and not just routers. Ipv6 will evolve but trying to hack in what is unknown nor has consensus into DHCPv6 at this point is not a good idea and not a reason to hold up DHCPv6 to move forward. regards, /jim Regards Francis.Dupont@enst-bretagne.fr From owner-dhcp-v4@bucknell.edu Tue May 23 01:03:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA15587 for ; Tue, 23 May 2000 01:03:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id AAA21270; Tue, 23 May 2000 00:59:42 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id AAA18001 for ; Tue, 23 May 2000 00:59:30 -0400 (EDT) Received: from droms-mac (pm3mi1-18.uplink.net [209.173.86.19]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id AAA12578; Tue, 23 May 2000 00:59:23 -0400 (EDT) Message-Id: <4.2.2.20000522183726.00a5ad70@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 22 May 2000 18:37:39 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Fwd: linklocal + DHCP servers Cc: DHCPv4 discussion list In-Reply-To: <200005191843.LAA00655@grosse.manhattan.fugue.com> References: <004101bfc1a7$b8733380$428939cc@ntdev.microsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 11:43 AM 5/19/00 -0700, Ted Lemon wrote: > > The question is not so much what address is used as source, but what the > > DHCP server is expected to *use* the source address for. Is it being > > suggested that the DHCP server should use this as some kind of hint > > to offer the auto-configured address? > >The DHCP server can't know the source address reliably, since the >source address is lost on relayed packets. So I hope the answer to >this question is 'no'. :') Of course. Duh... Sorry for raising (and not thinking through) a silly issue. - Ralph From owner-dhcp-v4@bucknell.edu Tue May 23 10:36:32 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04228 for ; Tue, 23 May 2000 10:36:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA03219; Tue, 23 May 2000 10:31:37 -0400 (EDT) Received: from monitor.internaut.com (mg136-128.ricochet.net [204.179.136.128]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA16912; Tue, 23 May 2000 10:31:27 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id HAA29867; Tue, 23 May 2000 07:14:29 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Subject: RE: Fwd: linklocal + DHCP servers Date: Tue, 23 May 2000 07:36:51 -0700 Message-ID: <002d01bfc4c4$563bffb0$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <4.2.2.20000522183726.00a5ad70@mail.bucknell.edu> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4131.1600 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Sorry for raising (and not thinking through) a silly issue. It's not so silly. Since the DHCP server couldn't test for an address conflict in the case of a relayed packet, that case is moot anyway. The question therefore centers on the case where the DHCP server is on the same segment as the client. In that case, it *is* possible for the DHCP server to test for an address conflict, by ARP'ing for the address before allocating it. It is also possible for the DHCP server to examine the source IP address in making its decision, since this will not have been changed by a relay. The question is: is the benefit of allowing the clients to retain their address strong enough to be worth doing something special for this case? And what is that something special? From owner-dhcp-v4@bucknell.edu Tue May 23 10:37:02 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04240 for ; Tue, 23 May 2000 10:37:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id KAA03181; Tue, 23 May 2000 10:35:45 -0400 (EDT) Received: from monitor.internaut.com (mg136-128.ricochet.net [204.179.136.128]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id KAA03534 for ; Tue, 23 May 2000 10:35:35 -0400 (EDT) Received: from vaiobean (vaiobean.ntdev.microsoft.com [204.57.137.66] (may be forged)) by monitor.internaut.com (8.9.2/8.8.8) with SMTP id HAA29874; Tue, 23 May 2000 07:18:18 -0700 (PDT) Reply-To: From: "Bernard Aboba" To: DHCPv4 discussion list Cc: Subject: RE: Fwd: linklocal + DHCP servers Date: Tue, 23 May 2000 07:40:40 -0700 Message-ID: <002e01bfc4c4$dedf3f30$428939cc@ntdev.microsoft.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <200005221406.HAA05290@zephyr.isi.edu> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4131.1600 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit >Given the derth of publication on the IPv4 link-local address, >I'd be surprised if -any- code base treats the 169.254.0.0/16 >prefix as unique. And given its recent vintage and a lack of >understanding of the longer term impact, I'd be shocked if >this had even made it to SOP status. It will be a -very- long >time before this has the same status as the loopback space. So are you saying that we should just treat 169.254/16 as another private prefix and forget about it being linklocal? Or that additional precautions need to be taken, like sourcing packets from TTL=1? From owner-dhcp-v4@bucknell.edu Tue May 23 12:29:20 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06130 for ; Tue, 23 May 2000 12:29:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA13115; Tue, 23 May 2000 12:25:49 -0400 (EDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA06809 for ; Tue, 23 May 2000 12:25:48 -0400 (EDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA05866; Tue, 23 May 2000 09:23:51 -0700 (PDT) From: Bill Manning Message-Id: <200005231623.JAA05866@zephyr.isi.edu> Subject: Re: Fwd: linklocal + DHCP servers To: DHCPv4 discussion list Date: Tue, 23 May 2000 09:23:50 -0700 (PDT) Cc: bmanning@ISI.EDU, dhcp-v4@bucknell.edu ('DHCPv4 discussion list'), zeroconf@merit.edu In-Reply-To: <002e01bfc4c4$dedf3f30$428939cc@ntdev.microsoft.com> from "Bernard Aboba" at May 23, 2000 07:40:40 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bmanning@ISI.EDU Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit % % >Given the derth of publication on the IPv4 link-local address, % >I'd be surprised if -any- code base treats the 169.254.0.0/16 % >prefix as unique. And given its recent vintage and a lack of % >understanding of the longer term impact, I'd be shocked if % >this had even made it to SOP status. It will be a -very- long % >time before this has the same status as the loopback space. % % So are you saying that we should just treat 169.254/16 as % another private prefix and forget about it being linklocal? % Or that additional precautions need to be taken, like % sourcing packets from TTL=1? % Er no. I'm saying that presure ought to be placed on the IESG to get the damm draft out as an RFC. Link Local is not the same as private use... its more restrictive. TTL=1 is one indicator. -- --bill From owner-dhcp-v4@bucknell.edu Tue May 23 12:31:16 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06216 for ; Tue, 23 May 2000 12:31:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA10323; Tue, 23 May 2000 12:30:20 -0400 (EDT) Received: from zephyr.isi.edu (zephyr.isi.edu [128.9.160.160]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id MAA03576 for ; Tue, 23 May 2000 12:30:06 -0400 (EDT) Received: (from bmanning@localhost) by zephyr.isi.edu (8.8.7/8.8.6) id JAA06133; Tue, 23 May 2000 09:28:06 -0700 (PDT) From: Bill Manning Message-Id: <200005231628.JAA06133@zephyr.isi.edu> Subject: Re: Fwd: linklocal + DHCP servers To: DHCPv4 discussion list Date: Tue, 23 May 2000 09:28:05 -0700 (PDT) Cc: aboba@internaut.com, bmanning@ISI.EDU, dhcp-v4@bucknell.edu ('DHCPv4 discussion list'), zeroconf@merit.edu In-Reply-To: <392A98B7.506C4F22@senie.com> from "Daniel Senie" at May 23, 2000 10:41:59 AM X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bmanning@ISI.EDU Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit % > So are you saying that we should just treat 169.254/16 as % > another private prefix and forget about it being linklocal? % > Or that additional precautions need to be taken, like % > sourcing packets from TTL=1? % % It's worse than that... you'd also have to reject any DHCP relay % packets. The TTL on DHCP relay packets is not necessarily predictable. % All relay packets would be an indicator that the DHCP server has no % direct attachment to the LAN segment in question. % % There's also the issue of the DHCP server having to use the link info % along with the IP address for keeping its records. After all, the same % DHCP server might be serving multiple directly-attached LANs. So for % example, 169.254.45.109 might exist on three different LANs, but refer % to three different stations. If those were self-assigned, not assigned % by the DHCP server, the server must nonetheless track them. % % This whole area quickly becomes a significant can of worms, adding % complexity to an existing, deployed protocol, with questionable and % limited advantages. % % -- % ----------------------------------------------------------------- % Daniel Senie dts@senie.com % Amaranth Networks Inc. http://www.amaranth.com Well, if the TTL>1 then there is a breakdown in operations. 169.254.0.0 is -link-local- i.e. should -NEVER- be forwarded off the local wire. Not Routed. Not bridged. I guess a repeater might be ok, but I'd be looking closely. :) NO RELAY. -- --bill From owner-dhcp-v4@bucknell.edu Wed May 24 14:47:01 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10952 for ; Wed, 24 May 2000 14:47:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA05756; Wed, 24 May 2000 14:43:04 -0400 (EDT) Received: from leo.eg.bucknell.edu (dns.dhcp.org [134.82.56.120]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA15402 for ; Wed, 24 May 2000 14:43:01 -0400 (EDT) Received: from droms-mac (pm3mi1-3.uplink.net [209.173.86.4]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id OAA13936; Wed, 24 May 2000 14:42:57 -0400 (EDT) Message-Id: <4.2.2.20000524005215.00a19ac0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 24 May 2000 00:59:55 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Fwd: linklocal + DHCP servers In-Reply-To: <3911F6B8.C4040C2E@metaip.checkpoint.com> References: <4.2.2.20000504174406.00a61810@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 03:16 PM 5/4/00 -0700, Richard Jones wrote: >It's an excellent question. I can't imagine an admin wanting to configure >a network to run from a pool of link-local addresses, but it seems to >me that having the protocol start to carve up pieces of the address >space and call them off limits (or special cases) would be a bad >precedent, at the least. Yeah - I personally can't imagine running a network in which I centrally manage a pool of link-local addresses. But, it seemed like a good question to ask - someone, somewhere, might want to do just that... >It sounds like the idea is to have clients come up with their own >link-local addresses and have the DHCP server 'approve' them, >optionally adding configuration info. Sounds like a different protocol. There is the DHCPINFORM mechanism for obtaining other configuration parameters. Sounds like at least a separate question: do we want to define the behavior of a broadcast DHCPINFORM request, with a link-local source address, forwarded by a relay agent? >As far as the source address goes, (doesn't that refer to 'ciaddr'?), >it looks to me like 2131 is clear about it being zero during a >DHCPDISCOVER (not that I'm comfortable quoting that RFC to >you, Ralph ;-). I was thinking of the IP header source address. You've asked a different question - the client fills in 'ciaddr' when it knows it's own IP address. Table 5 (RFC2131, p. 37-38) requires that 'ciaddr' == 0 in a DHCPDISCOVER. - Ralph From owner-dhcp-v4@bucknell.edu Fri May 26 07:33:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12676 for ; Fri, 26 May 2000 07:33:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id HAA21335; Fri, 26 May 2000 07:30:16 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id HAA09430 for ; Fri, 26 May 2000 07:30:09 -0400 (EDT) Received: from droms-mac (sj-dial-4-120.cisco.com [171.68.181.249]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id HAA15369 for ; Fri, 26 May 2000 07:30:08 -0400 (EDT) Message-Id: <4.2.2.20000526065903.00a2d560@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 26 May 2000 06:59:36 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: REMINDER: WG last call for "User Class Option for DHCP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is a reminder about the DHC WG last call for "The User Class Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri May 26 08:09:30 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA13040 for ; Fri, 26 May 2000 08:09:29 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id IAA28634; Fri, 26 May 2000 08:05:35 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id IAA32287 for ; Fri, 26 May 2000 08:05:19 -0400 (EDT) Received: from droms-mac (sj-dial-4-120.cisco.com [171.68.181.249]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id IAA15392 for ; Fri, 26 May 2000 08:05:17 -0400 (EDT) Message-Id: <4.2.2.20000526070023.00a5c140@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 26 May 2000 08:05:00 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: REMINDER: WG last call for "The Subnet Selection Option for DHCP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is a reminder of the DHC WG last call for "The Subnet Selection Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri May 26 09:31:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15001 for ; Fri, 26 May 2000 09:31:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id JAA29181; Fri, 26 May 2000 09:24:55 -0400 (EDT) Received: from leo.eg.bucknell.edu (leo.eg.bucknell.edu [134.82.56.108]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id JAA23052 for ; Fri, 26 May 2000 09:24:51 -0400 (EDT) Received: from droms-mac (atlantis-dial-1-124.cisco.com [171.68.181.125]) by leo.eg.bucknell.edu (8.8.8+Sun/8.8.8) with ESMTP id JAA15431 for ; Fri, 26 May 2000 09:24:50 -0400 (EDT) Message-Id: <4.2.2.20000526092402.00a50bb0@mail.bucknell.edu> X-Sender: droms@mail.bucknell.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 26 May 2000 09:24:32 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: REMINDER: WG last call for "The Name Service Search Option for DHCP" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: droms@bucknell.edu Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is a reminder about the DHC WG last call for "The Name Service Search Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Fri May 26 11:56:51 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18793 for ; Fri, 26 May 2000 11:56:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id LAA19068; Fri, 26 May 2000 11:52:18 -0400 (EDT) Received: from mail.infolibria.com (mail.infolibria.com [199.103.137.198]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id LAA26054 for ; Fri, 26 May 2000 11:52:15 -0400 (EDT) Received: from il5.corp.infolibria.com (border [199.103.137.193]) by mail.infolibria.com (Postfix) with ESMTP id D4D21DDB88 for ; Thu, 1 Feb 1996 23:25:47 -0500 (EST) Received: from infolibria.com (hamlet.eng.infolibria.com [10.10.30.120]) by il5.corp.infolibria.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id LV55WAGP; Fri, 26 May 2000 11:50:31 -0400 Sender: owner-dhcp-v4@bucknell.edu Message-ID: <392E6557.A31908E7@infolibria.com> Date: Fri, 26 May 2000 07:51:51 -0400 From: Steve G X-Mailer: Mozilla 4.72 [en] (X11; U; BSD/OS 3.1 i386) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: User Class draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: sgonczi@infolibria.com X-Sender: sgonczi@infolibria.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello, How do y'all feel about adding an optional expiration field to the individual classes? After all, these are credentials of sorts.. Keep in mind that an user class may be used for a specific, short-term purpose ( e.g.: to grant extra bandwith for a video conference). Also, do not take it for granted that this will work sort of like a password. (i.e. the user enters it somehow on the host..) It is perfectly conceivable, that in real life, a CMTS will tag it on, similarly to the relay agent option. I understand the desire to make this simple, but there is also a need to make it useful. /sG From owner-dhcp-v4@bucknell.edu Fri May 26 12:37:31 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19702 for ; Fri, 26 May 2000 12:37:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA23030; Fri, 26 May 2000 12:33:18 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA06027 for ; Fri, 26 May 2000 12:33:14 -0400 (EDT) Received: (qmail 19712 invoked from network); 26 May 2000 16:33:17 -0000 Received: from unknown (HELO ULTRADNS6PMNFK) (12.22.21.65) by mail.ultradns.com with SMTP; 26 May 2000 16:33:17 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: REMINDER: WG last call for "User Class Option for DHCP" Date: Fri, 26 May 2000 09:34:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.2.20000526065903.00a2d560@mail.bucknell.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > > This message is a reminder about the DHC WG last call for "The User Class > Option for DHCP", . > > Please forward any comments you may have on this draft to > dhcp-v4@bucknell.edu by Friday, May 26. > ...the draft can be advanced as it stands, but if any objections are raised that will delay its advancement, I offer the following suggestion for clarifying section 4 regarding the 'Len' field: ----- begin suggested text ----- "The format of this option is as follows: Code Len Value +-----+-----+--------------------- . . . --+ | TBD | N | User Class Data ('Len' octets) | +-----+-----+--------------------- . . . --+ "where Value consists of zero or more instances of User Class Data. Each instance of User Class Data is formatted as follows: u-Len-n u-Class-Data-n +-------+------------------------ . . . --+ | L-n | Opaque-Data-n ('u-Len-n' octets) | +-------+------------------------ . . . --+ "and each u-Len-n MUST be non-zero (implying that the minimum length of any User Class Data instance is 2 octets. "The Code for this option is TBD. If any instances of User Class Data are present, the minimum value of Len is two (one for u-Len-1, and one for u-Class-Data-1.)" ----- end suggested text ----- My reason for suggesting this change is because the word "MAY" appears in the third paragraph of section 4, making possible an implementation that does NOT allow multiple User Classes to appear in the Value field of the option, but leaves an opening for the initial octet to be misinterpreted as 'Len1' rather than the first octet of an opaque string. Sorry to be so late with this, but when I reviewed Jerome's edits earlier I didn't notice this. --Barr From owner-dhcp-v4@bucknell.edu Fri May 26 12:39:19 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19763 for ; Fri, 26 May 2000 12:39:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA07606; Fri, 26 May 2000 12:34:30 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id MAA11022 for ; Fri, 26 May 2000 12:33:14 -0400 (EDT) Received: (qmail 19716 invoked from network); 26 May 2000 16:33:17 -0000 Received: from unknown (HELO ULTRADNS6PMNFK) (12.22.21.65) by mail.ultradns.com with SMTP; 26 May 2000 16:33:17 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: User Class draft Date: Fri, 26 May 2000 09:34:12 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <392E6557.A31908E7@infolibria.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Steve G (sgonczi@infolibria.com) > Sent: Friday, May 26, 2000 4:52 AM > How do y'all feel about adding an optional expiration field to the > individual classes? > > After all, these are credentials of sorts.. > > Keep in mind that an user class may be used for a specific, short-term > purpose ( e.g.: to grant extra bandwith for a video conference). > > Also, do not take it for granted that this will work sort of like a > password. > (i.e. the user enters it somehow on the host..) > It is perfectly conceivable, that in real life, a CMTS will tag it on, > similarly > to the relay agent option. > > I understand the desire to make this simple, but there is also a need to > make it > useful. > ...Steve, I don't mean to be difficult, but I believe this is the first time that there has been any discussion about User Class Identifiers having an expiration time, starting time, or any other sort of usage limits associated with them. While that could indeed be a very useful consideration for many DHCP options, I really don't want to go back and reinvent all of the options right now, nor do I think that adding this to the User Class draft at this point helps it any. --Barr From owner-dhcp-v4@bucknell.edu Fri May 26 13:05:45 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20407 for ; Fri, 26 May 2000 13:05:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA15353; Fri, 26 May 2000 13:03:31 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA16223 for ; Fri, 26 May 2000 13:03:20 -0400 (EDT) Received: (qmail 20066 invoked from network); 26 May 2000 17:03:24 -0000 Received: from unknown (HELO ULTRADNS6PMNFK) (12.22.21.65) by mail.ultradns.com with SMTP; 26 May 2000 17:03:24 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: REMINDER: WG last call for "The Subnet Selection Option for DHCP" Date: Fri, 26 May 2000 10:04:19 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.2.20000526070023.00a5c140@mail.bucknell.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > This message is a reminder of the DHC WG last call for "The Subnet > Selection Option for DHCP", . > ...this draft can be advanced as it stands.... --Barr From owner-dhcp-v4@bucknell.edu Fri May 26 13:06:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20420 for ; Fri, 26 May 2000 13:06:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA12427; Fri, 26 May 2000 13:05:08 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id NAA15840 for ; Fri, 26 May 2000 13:03:21 -0400 (EDT) Received: (qmail 20071 invoked from network); 26 May 2000 17:03:25 -0000 Received: from unknown (HELO ULTRADNS6PMNFK) (12.22.21.65) by mail.ultradns.com with SMTP; 26 May 2000 17:03:25 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: REMINDER: WG last call for "The Name Service Search Option for DHCP" Date: Fri, 26 May 2000 10:04:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4.2.2.20000526092402.00a50bb0@mail.bucknell.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > This message is a reminder about the DHC WG last call for > "The Name Service Search Option for DHCP", . > ...this draft can be advanced as it stands.... --Barr From owner-dhcp-v4@bucknell.edu Fri May 26 14:27:00 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22415 for ; Fri, 26 May 2000 14:27:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.9.3/8.9.3) with SMTP id OAA15652; Fri, 26 May 2000 14:20:22 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.9.3/8.9.3) with ESMTP id OAA12392 for ; Fri, 26 May 2000 14:20:12 -0400 (EDT) Received: from grosse.manhattan.fugue.com ([206.102.195.249]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id TAA24799; Thu, 25 May 2000 19:40:33 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id LAA00339; Fri, 26 May 2000 11:20:04 -0700 (MST) Message-Id: <200005261820.LAA00339@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: User Class draft In-Reply-To: Message from Steve G of "Fri, 26 May 2000 07:51:51 -0400." <392E6557.A31908E7@infolibria.com> Date: Fri, 26 May 2000 11:20:04 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > How do y'all feel about adding an optional expiration field to the > individual classes? No. The draft is in last call. Please don't try to change it. > After all, these are credentials of sorts.. No. These are not credentials. They are a voluntary description, provided by the client. The DHCP authentication draft talks about credentials. The user class has nothing to do with credentials. > Keep in mind that an user class may be used for a specific, short-term > purpose ( e.g.: to grant extra bandwith for a video conference). This is not what the user class option is for. > Also, do not take it for granted that this will work sort of like a > password. > (i.e. the user enters it somehow on the host..) > It is perfectly conceivable, that in real life, a CMTS will tag it on, > similarly > to the relay agent option. This is not what the draft says. The draft says that the option is provided by the client, and that the DHCP client should have a mechanism for letting the *user* specify the class. > I understand the desire to make this simple, but there is also a need to > make it > useful. You want a different option that does something different. Please propose that option, rather than trying to piggyback your needs onto an existing option that does something else. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue May 30 04:36:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22094 for ; Tue, 30 May 2000 04:36:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4U8TWW19181; Tue, 30 May 2000 04:29:33 -0400 (EDT) Received: from gandalf.axion.bt.co.uk (gandalf.axion.bt.co.uk [132.146.17.29]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e4U8TNW20966 for ; Tue, 30 May 2000 04:29:24 -0400 (EDT) Received: from cbtlipnt01.btlabs.bt.co.uk by gandalf (local) with ESMTP; Tue, 30 May 2000 09:28:43 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Tue, 30 May 2000 09:28:51 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB204087551@mbtlipnt02.btlabs.bt.co.uk> From: jerome.privat@bt.com To: DHCPv4 discussion list Subject: RE: User Class draft Date: Tue, 30 May 2000 09:28:14 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I agree with Ted on all the points. >From Ted's and Barr's emails and from previous discussion on this list, I think there is WG consensus NOT to add an optional expiration field to the individual classes. Jerome -----Original Message----- From: Ted Lemon [mailto:mellon@isc.org] Sent: 26 May 2000 19:20 To: DHCPv4 discussion list Cc: DHCPv4 discussion list Subject: Re: User Class draft > How do y'all feel about adding an optional expiration field to the > individual classes? No. The draft is in last call. Please don't try to change it. > After all, these are credentials of sorts.. No. These are not credentials. They are a voluntary description, provided by the client. The DHCP authentication draft talks about credentials. The user class has nothing to do with credentials. > Keep in mind that an user class may be used for a specific, short-term > purpose ( e.g.: to grant extra bandwith for a video conference). This is not what the user class option is for. > Also, do not take it for granted that this will work sort of like a > password. > (i.e. the user enters it somehow on the host..) > It is perfectly conceivable, that in real life, a CMTS will tag it on, > similarly > to the relay agent option. This is not what the draft says. The draft says that the option is provided by the client, and that the DHCP client should have a mechanism for letting the *user* specify the class. > I understand the desire to make this simple, but there is also a need to > make it > useful. You want a different option that does something different. Please propose that option, rather than trying to piggyback your needs onto an existing option that does something else. _MelloN_ From owner-dhcp-v4@bucknell.edu Tue May 30 04:47:57 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22144 for ; Tue, 30 May 2000 04:47:57 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4U8jLW21761; Tue, 30 May 2000 04:45:21 -0400 (EDT) Received: from marvin.axion.bt.co.uk (marvin.axion.bt.co.uk [132.146.16.82]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e4U8jIW22131 for ; Tue, 30 May 2000 04:45:18 -0400 (EDT) Received: from cbtlipnt01.btlabs.bt.co.uk by marvin (local) with ESMTP; Tue, 30 May 2000 09:44:09 +0100 Received: by cbtlipnt01.btlabs.bt.co.uk with Internet Mail Service (5.5.2651.88) id ; Tue, 30 May 2000 09:44:06 +0100 Message-ID: <5104D4DBC598D211B5FE0000F8FE7EB204087552@mbtlipnt02.btlabs.bt.co.uk> From: jerome.privat@bt.com To: DHCPv4 discussion list Subject: RE: REMINDER: WG last call for "User Class Option for DHCP" Date: Tue, 30 May 2000 09:43:36 +0100 X-Mailer: Internet Mail Service (5.5.2651.88) MIME-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Reply-To: jerome.privat@bt.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN ...the draft can be advanced as it stands, but if any objections are raised that will delay its advancement, I offer the following suggestion for clarifying section 4 regarding the 'Len' field: Barr, Thanks for your comments. As no other objections have been raised that will delay the advancement of the draft, I will suggest that it is advanced as it stands. [I do agree that your wording would be more explicit than the one in the draft, but still think that the present text strongly implies that a non-null L1 must be present even if there is only one User Class]. Is everybody all right with advancing the draft to the IESG as it stands? Jerome ----- begin suggested text ----- "The format of this option is as follows: Code Len Value +-----+-----+--------------------- . . . --+ | TBD | N | User Class Data ('Len' octets) | +-----+-----+--------------------- . . . --+ "where Value consists of zero or more instances of User Class Data. Each instance of User Class Data is formatted as follows: u-Len-n u-Class-Data-n +-------+------------------------ . . . --+ | L-n | Opaque-Data-n ('u-Len-n' octets) | +-------+------------------------ . . . --+ "and each u-Len-n MUST be non-zero (implying that the minimum length of any User Class Data instance is 2 octets. "The Code for this option is TBD. If any instances of User Class Data are present, the minimum value of Len is two (one for u-Len-1, and one for u-Class-Data-1.)" ----- end suggested text ----- My reason for suggesting this change is because the word "MAY" appears in the third paragraph of section 4, making possible an implementation that does NOT allow multiple User Classes to appear in the Value field of the option, but leaves an opening for the initial octet to be misinterpreted as 'Len1' rather than the first octet of an opaque string. Sorry to be so late with this, but when I reviewed Jerome's edits earlier I didn't notice this. --Barr From owner-dhcp-v4@bucknell.edu Tue May 30 09:26:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28249 for ; Tue, 30 May 2000 09:26:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4UDOVW13178; Tue, 30 May 2000 09:24:31 -0400 (EDT) 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 e4UDOFW12838; Tue, 30 May 2000 09:24:15 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:24:05 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBD2A@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: REMINDER: WG last call for "The Subnet Selection Option for D HCP" Date: Tue, 30 May 2000 09:24:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This draft also looks fine to me. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Friday, May 26, 2000 8:05 AM To: DHCPv4 discussion list Subject: REMINDER: WG last call for "The Subnet Selection Option for DHCP" This message is a reminder of the DHC WG last call for "The Subnet Selection Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue May 30 09:36:04 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28526 for ; Tue, 30 May 2000 09:36:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4UDJTW12154; Tue, 30 May 2000 09:19:29 -0400 (EDT) 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 e4UDJDW12091; Tue, 30 May 2000 09:19:13 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:18:58 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBD29@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: REMINDER: WG last call for "User Class Option for DHCP" Date: Tue, 30 May 2000 09:18:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Looks fine to me. (I think the formatting is a bit off, but I don't know who usually fixes that for RFC status.) - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Friday, May 26, 2000 7:00 AM To: DHCPv4 discussion list Subject: REMINDER: WG last call for "User Class Option for DHCP" This message is a reminder about the DHC WG last call for "The User Class Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue May 30 09:36:18 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28538 for ; Tue, 30 May 2000 09:36:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4UDYIW13279; Tue, 30 May 2000 09:34:18 -0400 (EDT) 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 e4UDY6W14512; Tue, 30 May 2000 09:34:06 -0400 (EDT) Received: by lespaul.process.com with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 09:33:51 -0400 Message-ID: <63D30D6E10CFD11190A90000F805FE8602BEBD2B@lespaul.process.com> From: Bernie Volz To: DHCPv4 discussion list Subject: RE: REMINDER: WG last call for "The Name Service Search Option fo r DHCP" Date: Tue, 30 May 2000 09:33:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Volz@ipworks.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This document has some (minor) problems. In particular in the following sentence: In the above diagram, ns1 and ns2 are 16-bit integers corresponding to two DHCP options which specify the IP addresses of two different types of name server. The current list of name services and their DHCP option codes, taken from RFC 2132, includes It does *NOT* specify "IP addresses" (the DHCP options do, but I think it makes the statement confusing). And, since this is supposed to present the generalized format, I would also suggest changing "ns1 and ns2" and "two" to be more general. How about we change it to: In the above diagram, ns1, ns2, ... are the 16-bit integers corresponding to the DHCP options numbers for the types of name services to be used, in order. The current list of name services and their DHCP option codes, taken from RFC 2132, includes We might also want to add the "0" value to the table of Name Services (perhaps with an asterisks to indicate it does not correspond to a DHCP option number). It may easily be missed as it appears in the text later. - Bernie Volz IPWorks, Inc. -----Original Message----- From: Ralph Droms [mailto:droms@bucknell.edu] Sent: Friday, May 26, 2000 9:25 AM To: DHCPv4 discussion list Subject: REMINDER: WG last call for "The Name Service Search Option for DHCP" This message is a reminder about the DHC WG last call for "The Name Service Search Option for DHCP", . Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, May 26. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue May 30 13:27:35 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04948 for ; Tue, 30 May 2000 13:27:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4UHNHW19095; Tue, 30 May 2000 13:23:17 -0400 (EDT) Received: from gidget.incognito.com (GIDGET.INCOGNITO.COM [207.102.214.80]) by mail.bucknell.edu (8.10.1/8.10.1) with ESMTP id e4UHN3W18467 for ; Tue, 30 May 2000 13:23:03 -0400 (EDT) Received: by GIDGET.INCOGNITO.COM with Internet Mail Service (5.5.2650.21) id ; Tue, 30 May 2000 10:26:08 -0700 Message-ID: <716D440F8C29D311991100A0C92048745EA017@GIDGET.INCOGNITO.COM> From: "Cosmo, Patrick" To: DHCPv4 discussion list Subject: is there an update on ?? Date: Tue, 30 May 2000 10:26:08 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: Patrick@incognito.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN is there a more appropriate place to ask this question? is now obsolete. Is there an anywhere? Or anything that's gone to rfc? thanks, Patrick Cosmo Incognito Software Inc. From owner-dhcp-v4@bucknell.edu Tue May 30 14:11:17 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06091 for ; Tue, 30 May 2000 14:11:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4UI7JW04248; Tue, 30 May 2000 14:07:19 -0400 (EDT) Received: from mail.ultradns.com (IDENT:qmailr@[64.41.145.150]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4UI7GW05578 for ; Tue, 30 May 2000 14:07:16 -0400 (EDT) Received: (qmail 21387 invoked from network); 30 May 2000 18:08:07 -0000 Received: from unknown (HELO ULTRADNS6PMNFK) (12.22.21.65) by mail.ultradns.com with SMTP; 30 May 2000 18:08:07 -0000 From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: is there an update on ?? Date: Tue, 30 May 2000 11:08:42 -0700 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.2911.0) In-Reply-To: <716D440F8C29D311991100A0C92048745EA017@GIDGET.INCOGNITO.COM> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Reply-To: rbhibbs@ultraDNS.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Cosmo, Patrick > Sent: Tuesday, May 30, 2000 10:26 AM > > is now obsolete. Is there an > anywhere? Or anything that's > gone to rfc? > ...I plan to issue a [hopefully] final draft before the Pittsburgh IETF meeting that incorporates fixes for a number of typos that have been discovered by various reviewers and to request that it go to last call shortly after.... --Barr From owner-dhcp-v4@bucknell.edu Wed May 31 05:43:15 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA02137 for ; Wed, 31 May 2000 05:43:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4V9cBW23475; Wed, 31 May 2000 05:38:15 -0400 (EDT) Received: from hotmail.com (law2-f147.hotmail.com [216.32.181.147]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4V9bvW25452 for ; Wed, 31 May 2000 05:37:57 -0400 (EDT) Received: (qmail 20538 invoked by uid 0); 31 May 2000 09:37:41 -0000 Message-ID: <20000531093741.20537.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Wed, 31 May 2000 02:37:41 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: multihomed DHCP Server Date: Wed, 31 May 2000 11:37:41 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Can i do the next NT server 4.0 configuration for the DHCP Server?: - Network adapter card #1: class C IP address: 192.168.200.1 subnetmask 255.255.255.0 to serve next range: 192.168.200.2 to 192.168.200.253 - Network adapter card #2: class C IP address: 192.168.201.1 subnetmask 255.255.255.0 to serve next range: 192.168.201.2 to 192.168.201.253 All the example is invented. I need to apply this in a real scenario, because the DHCP Server needs to serve more than 254 IP address. Thanks ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Wed May 31 08:26:33 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06238 for ; Wed, 31 May 2000 08:26:32 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4VCL5W02215; Wed, 31 May 2000 08:21:05 -0400 (EDT) Received: from hotmail.com (law2-f138.hotmail.com [216.32.181.138]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4VCKxW20351 for ; Wed, 31 May 2000 08:20:59 -0400 (EDT) Received: (qmail 97299 invoked by uid 0); 31 May 2000 12:20:43 -0000 Message-ID: <20000531122043.97298.qmail@hotmail.com> Received: from 195.77.235.2 by www.hotmail.com with HTTP; Wed, 31 May 2000 05:20:43 PDT X-Originating-IP: [195.77.235.2] From: "Marc" To: DHCPv4 discussion list Subject: Re: FW: [mcse] Multihomed DHCP Server Date: Wed, 31 May 2000 14:20:43 CEST Mime-Version: 1.0 Content-Type: text/plain; format=flowed Reply-To: marc_jaumandreu@hotmail.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Can i obtain the same results using the only one adapter card and adding one more IP address to that card? ----Original Message Follows---- From: WATILA Alex To: "'marc_jaumandreu@hotmail.com'" Subject: FW: [mcse] Multihomed DHCP Server Date: Wed, 31 May 2000 14:05:52 +0200 See if Q181774 can point you in the right direction. It has links to many other articles that relate to Multihomed machines and DHCP. I hope it helps you sort out your problem. Alex -----Original Message----- From: Marc [mailto:marc_jaumandreu@hotmail.com] Sent: Wednesday, May 31, 2000 2:33 PM To: mcse@mail.saluki.com; winnt-l@peach.ease.lsoft.com Subject: [mcse] Multihomed DHCP Server Can i do the next NT server 4.0 configuration for the DHCP Server?: * Network adapter card #1: class C IP address: 192.168.200.1 subnetmask 255.255.255.0 to serve next range: 192.168.200.2 to 192.168.200.253 * Network adapter card #2: class C IP address: 192.168.201.1 subnetmask 255.255.255.0 to serve next range: 192.168.201.2 to 192.168.201.253 All the example is invented. I need to apply this in a real scenario, because the DHCP Server needs to serve more than 254 IP address. Thanks ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com *************************************************************************** http://www.audiowhiz.com/?MD Gain valuable study time! Quiz yourself while commuting. Study cassettes & CDs. Free NT Server Software Test Demo. *************************************************************************** Boson Software, The Absolute Best Value in Practice Tests and Study Software, http://www.boson.com - List subscription page at http://saluki.com/mcsesub.html Have a question? See list FAQ athttp://www.mcseco-op.com/rules.htm Contact sarmstrong@saluki.org for problem resolution ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com From owner-dhcp-v4@bucknell.edu Wed May 31 12:24:42 2000 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15538 for ; Wed, 31 May 2000 12:24:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.10.1/8.10.1) with SMTP id e4VGKOW08874; Wed, 31 May 2000 12:20:24 -0400 (EDT) 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 e4VGKFW08244 for ; Wed, 31 May 2000 12:20:15 -0400 (EDT) Received: from grosse.manhattan.fugue.com (a15.pm3-30.theriver.com [206.102.195.127]) by toccata.fugue.com (8.9.3/8.6.11) with ESMTP id RAA14712; Tue, 30 May 2000 17:40:30 -0700 (PDT) Received: from grosse.manhattan.fugue.com (localhost [127.0.0.1]) by grosse.manhattan.fugue.com (8.9.3+3.2W/8.6.11) with ESMTP id JAA00500; Wed, 31 May 2000 09:20:15 -0700 (MST) Message-Id: <200005311620.JAA00500@grosse.manhattan.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: multihomed DHCP Server In-Reply-To: Message from "Marc" of "Wed, 31 May 2000 11:37:41 EST." <20000531093741.20537.qmail@hotmail.com> Date: Wed, 31 May 2000 09:20:15 -0700 From: Ted Lemon Reply-To: mellon@isc.org Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm not sure if I have your question clearly, but it sounds like you want to serve more than one IP subnet on the same physical network - is that right? If so, you really don't want to use two network cards - just configure an interface alias. I don't know precisely how the NT 4.0 DHCP server handles this, but it's a fairly common setup, so I imagine it does it just fine. Btw, you really really want an SP4 or higher DHCP server with NT 4.0. :') _MelloN_