From owner-dhcp-v6@bucknell.edu Wed Aug 1 00:53:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA26917; Wed, 1 Aug 2001 00:53:41 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f714rg320593; Wed, 1 Aug 2001 00:53:42 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f714rT320659 for ; Wed, 1 Aug 2001 00:53:29 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-38lcbhb.dialup.mindspring.com [209.86.46.43]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f714mff14417 for ; Tue, 31 Jul 2001 21:48:41 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f714r6l00362 for ; Tue, 31 Jul 2001 21:53:06 -0700 (MST) Message-Id: <200108010453.f714r6l00362@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Addresses and other parameters in Advertise and Solicit In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 31 Jul 2001 10:07:54 EST." <66F66129A77AD411B76200508B65AC697B3372@eambunt705.ena-east.ericsson.se> Date: Tue, 31 Jul 2001 21:53:06 -0700 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I don't understand your argument. A broken server is just that, > broken. What it will and will not allow a client to do is not an > issue - fix the server. In general, it is good to account for accidental or malicious breakage when designing protocols. You can't always easily eliminate a broken server, so it's good if the client has a chance to function even when there is a broken server present. > In fact, I believe having the actual assignment of addresses > deferred until the Reply is received is far more likely to result in > non-broken servers. A server, in the Advertise, just needs to tell > the client that it is willing to assign address. I'm not worried about preventing broken servers. I'm worried about the client being unable to deal with broken servers. > - Is Advertise a contract to give the client those addresses? No more so than a DHCPOFFER is. > - And, if it is a contract then MAY, SHOULD, or MUST the client > perform DAD before doing the Request. And, when can a client start > using an address? After Advertise? After Reply? After Reply, to both. Just like DHCPACK. > - In DHCPv4, other servers listen to the broadcast of the > DHCPREQUEST to learn that their offer has been DECLINED (see Section > 3.1). If we do what you and Jim propose, do we need this? No. > - In DHCPv4, the address is not checked until *AFTER* the > DHCPREQUEST/DHCPACK sequence > and a DHCPDECLINE is not valid > until after the REQUEST/ACK sequence. Right. > - In DHCPv4, the offered address is included in the DHCPREQUEST to > the server. If we're going to follow that convention, we need the > client to send the IA option it received from the server in the > REQUEST? Right. > - In DHCPv4, the server always has the ability to DHCPNACK the > address received in the DHCPREQUEST. We've had a dicussion about > NACKs before. But we would need to have a mechanism for the server > to tell the client, gee sorry, that address isn't available > now. Perhaps the mechanism is simply for the server not to include > that address in the IA in the Reply. Right, there's an error message for this. > But again, this behavoir would > not be needed if the addresses in the Advertise are just > informational (I will assign you addresses similar to these). No. "I will assign you this address unless something happens to prevent me from doing so." _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 1 11:56:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18383; Wed, 1 Aug 2001 11:56:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f71FuF331377; Wed, 1 Aug 2001 11:56:15 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f71Fu2300487 for ; Wed, 1 Aug 2001 11:56:02 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f71Fu4I32099; Wed, 1 Aug 2001 17:56:04 +0200 (CEST) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 64B0BC112; Wed, 1 Aug 2001 17:47:31 +0200 (CEST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3B68274E.305553F3@ccrle.nec.de> Date: Wed, 01 Aug 2001 17:59:10 +0200 From: Martin Stiemerling Organization: CCRLE, NEC Europe Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Subject: DHCP option for SIP server Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: stiemerling@mobility.ccrle.nec.de X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hello, I'm currently working on DHCPv6 and I'm interested in one option proposed by Schulzrinne and Nair for DHCP (draft-ietf-sip-dhcp-04.txt). It is the DHCP Option for SIP Servers and it looks like this: Code Len DNS name of SIP server +-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-- As far as I see, is this option only for IPv4 (due to that code and len are only 8 bit long and in DHCPv6 these both are 16 bit). Is there any plan to make an option for DHCPv6? With best regards Martin Stiemerling -- *************************************************** Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Fon: +49 6221 90511 13 Fax: +49 6221 90511 55 From owner-dhcp-v6@bucknell.edu Wed Aug 1 12:08:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19212; Wed, 1 Aug 2001 12:08:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f71G9M331932; Wed, 1 Aug 2001 12:09:22 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f71G9A332268 for ; Wed, 1 Aug 2001 12:09:10 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f71G8o511511 for ; Wed, 1 Aug 2001 11:08:50 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f71G8ob09532 for ; Wed, 1 Aug 2001 11:08:50 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Aug 01 11:08:32 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 1 Aug 2001 11:08:32 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3383@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Cc: "'Martin.Stiemerling@ccrle.nec.de'" Subject: RE: DHCP option for SIP server Date: Wed, 1 Aug 2001 11:08:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11AA4.34485980" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11AA4.34485980 Content-Type: text/plain; charset="iso-8859-1" The DHC WG is looking of suggestions on "core" options for DHCPv6 (those that are required to make the protocol work and useful). We are also looking for which other options to define, probably in a companion document to the DHCPv6 specification. This option should certainly be considered. Likely it would be defined in the companion document as it is not a "core" option required by most (if not all) of the DHCPv6 clients. The option would likely look as follows in DHCPv6: Code Len DNS name of SIP server +-----+-----+-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-----+-----+-- - Bernie Volz -----Original Message----- From: Martin Stiemerling [mailto:Martin.Stiemerling@ccrle.nec.de] Sent: Wednesday, August 01, 2001 11:59 AM To: DHCPv6 discussion list Subject: DHCP option for SIP server Hello, I'm currently working on DHCPv6 and I'm interested in one option proposed by Schulzrinne and Nair for DHCP (draft-ietf-sip-dhcp-04.txt). It is the DHCP Option for SIP Servers and it looks like this: Code Len DNS name of SIP server +-----+-----+-----+-----+-----+-----+-----+-- | TBD | n | s1 | s2 | s3 | s4 | s5 | ... +-----+-----+-----+-----+-----+-----+-----+-- As far as I see, is this option only for IPv4 (due to that code and len are only 8 bit long and in DHCPv6 these both are 16 bit). Is there any plan to make an option for DHCPv6? With best regards Martin Stiemerling -- *************************************************** Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Fon: +49 6221 90511 13 Fax: +49 6221 90511 55 ------_=_NextPart_001_01C11AA4.34485980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: DHCP option for SIP server

The DHC WG is looking of suggestions on = "core" options for DHCPv6 (those that
are required to make the protocol work and = useful).

We are also looking for which other options to = define, probably in a companion
document to the DHCPv6 specification.

This option should certainly be considered. Likely it = would be defined in the
companion document as it is not a "core" = option required by most (if not all)
of the DHCPv6 clients.

The option would likely look as follows in = DHCPv6:

     = Code        = Len      DNS name of SIP server
+-----+-----+-----+-----+-----+-----+-----+-----+-----+--
|    TBD    = |     n     | s1  | = s2  | s3  | s4  | s5  |  ...
+-----+-----+-----+-----+-----+-----+-----+-----+-----+--

- Bernie Volz

-----Original Message-----
From: Martin Stiemerling [mailto:Martin.Stiemerlin= g@ccrle.nec.de]
Sent: Wednesday, August 01, 2001 11:59 AM
To: DHCPv6 discussion list
Subject: DHCP option for SIP server


Hello,

I'm currently working on DHCPv6 and I'm interested in = one option
proposed by Schulzrinne and Nair for DHCP = (draft-ietf-sip-dhcp-04.txt).
It is the DHCP Option for SIP Servers and it looks = like this:

 Code  Len      = DNS name of SIP server
+-----+-----+-----+-----+-----+-----+-----+--
| TBD |  n  | s1  | s2  | = s3  | s4  | s5  |  ...
+-----+-----+-----+-----+-----+-----+-----+--

As far as I see, is this option only for IPv4 (due to = that code and len
are only 8 bit long and in DHCPv6 these both are 16 = bit). Is there any
plan to make an option for DHCPv6?

With best regards
Martin Stiemerling


--
***************************************************
Martin Stiemerling
NEC Europe = Ltd.         Network = Laboratories Europe
Fon: +49 6221 90511 13  Fax: +49 6221 90511 = 55

------_=_NextPart_001_01C11AA4.34485980-- From owner-dhcp-v6@bucknell.edu Thu Aug 2 05:30:41 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA18364; Thu, 2 Aug 2001 05:30:40 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f729R7318829; Thu, 2 Aug 2001 05:27:07 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f729Qh310737 for ; Thu, 2 Aug 2001 05:26:43 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f729QjI41070; Thu, 2 Aug 2001 11:26:46 +0200 (CEST) Received: from ccrle.nec.de (zipo.heidelberg.ccrle.nec.de [192.168.102.84]) by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0) with ESMTP id 2349BC112; Thu, 2 Aug 2001 11:18:06 +0200 (CEST) Sender: owner-dhcp-v6@bucknell.edu Message-ID: <3B691D8F.C9F8361D@ccrle.nec.de> Date: Thu, 02 Aug 2001 11:29:51 +0200 From: Martin Stiemerling Organization: CCRLE, NEC Europe Ltd. X-Mailer: Mozilla 4.76 [en] (X11; U; FreeBSD 4.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv6 discussion list Cc: sip@ietf.org, dhcp-v6@bucknell.edu Subject: Re: [Sip] DHCP option for SIP server References: <3B682831.5CC4F865@ccrle.nec.de> <3B683B4D.91BEF2E6@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu X-Sender: stiemerling@mobility.ccrle.nec.de X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit "Henning G. Schulzrinne" wrote: [...] > > are only 8 bit long and in DHCPv6 these both are 16 bit). Is there any > > plan to make an option for DHCPv6? > > > > No plan, but would be a good idea. Are you volunteering? Yes, I do. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs -- *************************************************** Martin Stiemerling NEC Europe Ltd. Network Laboratories Europe Fon: +49 6221 90511 13 Fax: +49 6221 90511 55 From owner-dhcp-v4@bucknell.edu Mon Aug 6 06:08:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA20742 for ; Mon, 6 Aug 2001 06:08:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f76A58316705; Mon, 6 Aug 2001 06:05:08 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f76A51312015 for ; Mon, 6 Aug 2001 06:05:01 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-57.cisco.com [10.82.80.57]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA29510; Mon, 6 Aug 2001 06:04:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20010806110054.00b87cf0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 06 Aug 2001 11:03:15 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: DHC ldap schema comments (FWD by Ralph Droms) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN (Forwarded for Leif Johansson ; please include his address in any replies - RD) Some comments on the -00 ldap schema draft. I am not a member of the dhc wg so please cc any comments to me. The comments based on a first reading: * The schema description should be rewritten in the usual form of schema drafts -- one section per schema element with the full rfc2252 format included. Currently the format is some kind of pseudo-formal but non-rfc2252 compliant format where the "ldif" format is in an appendix. Also the DESC fields of the schema seems to be part of the schema element specification and not as it should be a text string which can be displayed to a client or a management app. In fact imho you should be able to delete/ignore all DESC-fields and still be able to implement the schema. * I have a problem with the dhcpStatements attribute. It looks like a kitchen-sink attribute for anything not covered by other attributes. This strikes me as a bad idea. Also the syntax of the attribute is ia5string which is not very flexible. * I am glad to see that the authors have tried to avoid specifying an information model which place requirements on directory structure but there are still some places -- for instance dhcpService is specified to contain a certain set of object classes. Note that this is not possible to express in terms of ldap schema elements since ldap (as opposed to x.509) does not include naming and structure rules. I am not sure if this is a big problem in this particular case and I have to think more carefully about it. You should seriously consider if this kind of naming and/or structure requirements are needed or can at least be expressed in the schema (for instance using DN references). Cheers ----------------------------------------------------------------- Leif Johansson Phone: +46 8 164541 IT- and media services Stockholm University email: leifj@it.su.se From owner-dhcp-v4@bucknell.edu Mon Aug 6 14:47:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29357 for ; Mon, 6 Aug 2001 14:47:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f76Iil313488; Mon, 6 Aug 2001 14:44:47 -0400 (EDT) Received: from postal.metaip.checkpoint.com (metaip.checkpoint.com [204.29.28.25]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f76Iic325122 for ; Mon, 6 Aug 2001 14:44:38 -0400 (EDT) Received: from cartman.metainfo.com (localhost [127.0.0.1]) by postal.metaip.checkpoint.com (8.9.3/8.9.3VRJ666) with ESMTP id LAA21206 for ; Mon, 6 Aug 2001 11:07:53 -0700 Received: by cartman.metainfo.com with Internet Mail Service (5.5.2650.21) id <3X242SZD>; Mon, 6 Aug 2001 11:44:21 -0700 Message-ID: From: davidi@sea.checkpoint.com To: DHCPv4 discussion list Cc: marka@sea.checkpoint.com Subject: RFC 2242 NetWare/IP Information (DHCP Option 63) Date: Mon, 6 Aug 2001 11:44:15 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Reply-To: davidi@sea.checkpoint.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Greetings, I have a couple of questions regarding DHCP Option 63 and the NWIP_EXIST_IN_SNAME_FILE suboption (code 3). 1. Under what circumstances would an administrator use suboption NWIP_EXIST_IN_SNAME_FILE instead of NWIP_EXIST_IN_OPTIONS_AREA? Is there any advantage to using subcode 3 over subcode 2 ? 2. From reading the RFC, I'm assuming that if the NWIP_EXIST_IN_SNAME_FILE is present in opton 63, then option 62 (Netware IP domain Name) is encoded in the SNAME / FILE fields of the DHCPOFFER / DHCPACK packet but is not to be placed the options section of the DHCP packet. Is this correct? Thanks Dave Irizarry QA CheckPoint Software Technologies From owner-dhcp-v6@bucknell.edu Tue Aug 7 04:21:35 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27519; Tue, 7 Aug 2001 04:21:35 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f778LZ324996; Tue, 7 Aug 2001 04:21:35 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f778LT326751 for ; Tue, 7 Aug 2001 04:21:29 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-18.cisco.com [10.82.80.18]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA23221 for ; Tue, 7 Aug 2001 04:21:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20010807091803.034f94b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 09:19:25 +0100 To: DHCPv6 discussion list From: Ralph Droms Subject: List of issues for WG discussion, 8/8 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here's a draft list of issues in the -19 rev of the DHCPv6 spec. We will review mailing list discussion of these issues and come to consensus on resolution at the WG meeting on 8/8. I will post a message later today summarizing resolution for those issues where consensus seems to exist. - Ralph * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? * How and when does the client use DAD on addresses in Advertise and Reply messages? * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option * Should we consider a "quick" handshake for allowing a client to assign an address using a single exchange of two messages? * Servers will only assign complete addresses and not prefixes (e.g., to be used by the client for stateless autoconfiguration) * Tighten up text on T1/T2 to require T1/T2 occur prior to expiration of lifetimes of addresses in IA; no need to describe default at T1/T2 are fields in IA header and must be supplied by server * The semantics of the use of IA must be clarified (see Volz message of 7/19. In particular, what are the semantics of a Request containing an IA that the client has previously sent to the server? What are the semantics of a Requst containing a new IA? * Add 'secs' field to fixed header * Modify IA option so that all addresses in an IA are "regular" or "temporary". Modify text so that client indicates types of addresses to be assigned by sending appropriate IAs. Server then fills in each IA with assigned addresses. * Add "NAK" function: If the server finds that the prefix on one or more IP addresses in any IA in the {Request,Confirm,Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. * Add an "error code" option, to indicate errors not connected with a specific option * Define DUID to be one of: - Link-layer address plus time - Vendor-assigned unique ID - Link-layer address - IMSI - IMEI * Simplify release and decline simplified so the all of the addresses in an IA are released or declined, rather than allowing the client to release or decline just some addresses. * Separate IA option for temporary addresses rather than indicate the type of address in a single IA option * Describe message transmission and retransmission in a separate section of the spec and reference that text throughout the remainder of the spec * Discard the client unicast or recheck the entire spec for consistency in reference to message transmission * Remove client link-local address from client message header. Agent can then determine link-local from source (IP header) in client message and insert into agent->server message. Server responds to source from IP header (whether agent or client). * Tighten up language for unicasting Reconfigure-Init; in particular, the server may not have an appropriate address to use to send the message to the client. * Reply to a Confirm should be a simple ACK/NAK without changing any values in options * Reply to Decline or Release should carry no options * Server does not respond to Solicit when server has no addresses * Use IPsec for secure agent/server communication * Include only options specifically mentioned in the text in the DHCPv6 spec; move others to second doc or separate appendix From owner-dhcp-v6@bucknell.edu Tue Aug 7 07:19:59 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00821; Tue, 7 Aug 2001 07:19:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f77BJt319580; Tue, 7 Aug 2001 07:19:55 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f77BJr300787 for ; Tue, 7 Aug 2001 07:19:53 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-56.cisco.com [10.82.96.56]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA29590 for ; Tue, 7 Aug 2001 07:19:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20010807121350.00b68cb8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 07 Aug 2001 12:17:55 +0100 To: DHCPv6 discussion list From: Ralph Droms Subject: List of issues for WG meeting with resolution summaries Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here's a revision of the list of issues, with an annotation for each issue either explaining my understanding of WG consensus on resolution or marking the issue as open. Note that the list of issues has been somewhat rearranged from the list I sent out earlier to provide a little more logical grouping. Thanks to Bernie for his quick review and input on this list. Please review and reply with comments before tomorrow's meeting if possible... - Ralph * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Servers will only assign complete addresses and not prefixes (e.g., to be used by the client for stateless autoconfiguration) WG consensus: yes; prefix advertisement is handled through ND * Modify IA option so that all addresses in an IA are "regular" or "temporary". Modify text so that client indicates types of addresses to be assigned by sending appropriate IAs. Server then fills in each IA with assigned addresses. Open issue * Define separate IA option for temporary addresses rather than indicate the type of address in a single IA option Open issue * How and when does the client use DAD on addresses in Advertise and Reply messages? WG consensus: Client does DAD on addresses in Reply message and responds with Decline if addresses unacceptable (e.g., already in use) * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Should we consider a "quick" handshake for allowing a client to assign an address in a single exchange of two messages? WG consensus: defer for later reconsideration * Tighten up text on T1/T2 to require T1/T2 occur prior to expiration of lifetimes of addresses in IA; no need to describe default as T1/T2 are fields in IA header and must be supplied by server WG consensus: yes Open issue: what about selection of T1/T2 with temporary addresses and with addresses whose lifetimes won't be extended; e.g. addresses to be deprecated/discarded due to renumbering. * The semantics of the use of IA must be clarified (see Volz message of 7/19). In particular, what are the semantics of a Request containing an IA that the client has previously sent to the server? What are the semantics of a Requst containing a new IA? Open issue: rules about when to reuse old IA or use new IA * Simplify Release and Decline so the all of the addresses in an IA are released or declined, rather than allowing the client to release or decline just some addresses. WG consensus: yes * Add "NAK" function: If the server finds that the prefix on one or more IP addresses in any IA in the {Request,Confirm,Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" error code. Add text allowing client to ignore "NoPrefixMatch" from other servers if ACK received from at least one server. * Define DUID to be one of: - Link-layer address plus time - Vendor-assigned unique ID - Link-layer address - IMSI - IMEI WG consensus: yes; based on text submitted by Lemon with extensions from subsequent WG discussion * Use IPsec for secure agent/server communication WG consensus: yes; add text to draft * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes * Tighten up language for unicasting Reconfigure-Init; in particular, the server may not have an appropriate address to use to send the message to the client. WG consensus: yes * Reply to a Confirm should be a simple ACK/NAK without changing any values in options WG consensus: yes * Reply to Decline or Release should carry no options WG consensus: yes * Restrict options in Decline or Release to IA with text to allow other options in the future Open issue * Server does not respond to Solicit when server has no addresses Open issue * Include only options specifically mentioned in the text in the DHCPv6 spec; move others to second doc or separate appendix Open issue; generate list of options based on previous work * Add 'secs' field to fixed header Open issue * Describe message transmission and retransmission in a separate section of the spec and reference that text throughout the remainder of the spec Open issue * Discard the client unicast or recheck the entire spec for consistency in reference to message transmission Open issue * Remove client link-local address from client message header. Agent can then determine link-local from source (IP header) in client message and insert into agent->server message. Server responds to source from IP header (whether agent or client). Open issue From owner-dhcp-v6@bucknell.edu Tue Aug 7 16:07:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12031; Tue, 7 Aug 2001 16:07:27 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f77K6c323051; Tue, 7 Aug 2001 16:06:38 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f77K6b312794 for ; Tue, 7 Aug 2001 16:06:37 -0400 (EDT) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel2.hp.com (Postfix) with ESMTP id 739301B32 for ; Tue, 7 Aug 2001 13:06:30 -0700 (PDT) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id BAA02521; Wed, 8 Aug 2001 01:39:44 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200108072009.BAA02521@dce.india.hp.com> Subject: Re : List of issues for WG meeting with resolution summaries To: DHCPv6 discussion list Date: Wed, 8 Aug 2001 01:39:44 +0530 (IST) X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Hi, see my comments inline. > Here's a revision of the list of issues, with an annotation for each issue > either explaining my understanding of WG consensus on resolution or marking > the issue as open. Note that the list of issues has been somewhat > rearranged from the list I sent out earlier to provide a little more > logical grouping. Thanks to Bernie for his quick review and input on this > list. > > Please review and reply with comments before tomorrow's meeting if possible... > > - Ralph > > > > > * Should addresses in an Advertise message be "real" addresses or > "informational"; e.g., just prefixes? > > WG consensus: addresses in Advertise are the addresses the server > will return in a subsequent Reply; client supplies those addresses > to server in IA in Request message Isn't enough that, if the server sends the prefix in the IA? because, the server has to remember these OFFERED addresses. There should be some expiration time for these OFFERED addresses and in the case, if this time has expired, and the server has assigned this addresses to different clients, then the client has to accept different addresses. The main purpose of this sending the addresses is to show the client that the server is willing to serve the client with IP addresses. In the client point of view, whatever addresses it get, it doesn't matter. Do you think, do we need to include unnecessary load of remembering and maintaining the OFFERED addresses and keeping a time knob for those addresses? In the case, if it is finalised as the server SHOULD send the addresses, the text has to be added for the time knob for those OFFERED addresses and behaviour of the client, if it gets the different addresses, it has sent in the request. > > * Servers will only assign complete addresses and not prefixes (e.g., > to be used by the client for stateless autoconfiguration) > > WG consensus: yes; prefix advertisement is handled through ND > > * Modify IA option so that all addresses in an IA are "regular" or > "temporary". Modify text so that client indicates types of > addresses to be assigned by sending appropriate IAs. Server then > fills in each IA with assigned addresses. > > Open issue > > * Define separate IA option for temporary addresses rather than > indicate the type of address in a single IA option > > Open issue The two possible solutions for handling IA containing temporary addresses are, 1) modify the IA option by adding one bit before the "IA status" field and removing "T" bit before the "addr status". The IA option looks something like this. I have already posted this format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION IA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| IA status | num-addrs | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | IPv6 address | | (16 octets) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IPv6 address | | (16 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref. lifetime (cont.) | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid lifetime (cont.) | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | IPv6 address | | (16 octets) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Since the T bit before "addr status" field has no use and since we are not going to do something specific to a particular IP address in an IA (since, release or decline will be done for the whole IA only, not for some address in the IA), there is no use for "addr status" field. The whole status of the IA can be reflected in IA status itself. Thus, we can eliminate the "addr status" also. But, i'm not sure there may be some alignment problem, if we directly reomove that field. So, we can put an Must be Zero byte there. But, one thing, we need to take care is, if the number of addresses in the IA is large, then, we are wasting that much number of unused bytes. Alternatively, we can remove one byte from the IAID and make alignement proper. 2) Second solution is, keeping a different option for Temporary address IA. Since, the temporary addresses MUST not be renewed, there is no point in having T1 and T2 values for the IA. We can define a seperate option for Temporary Address IA similar to the IA option but without the T1 and T2 values. The temporary IA option will look like this. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION TMP IA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IA status | num-addrs | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | IPv6 address | | (16 octets) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IPv6 address | | (16 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref. lifetime (cont.) | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid lifetime (cont.) | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | (16 octets) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here, we don't need to have "T" bit before the IA option and TMP IA option also. The problem told by Bernie on this model was, a) According to the IA option defined in 19th rev, we need a "T" bit for identifying the temporary addresses. So, he told that even though "addr status" is unused, we need to allocate a byte for "T" bit, so we cannot remove it. Now, we can move the "T" bit before the "IA status" byte. So, this problem is solved. In the case, if we are defining seperate option, we don't need the "T" bit itself. b) ** comments from Bernie*** There are some issues with a new option - such as the IAID spaces must not overlap, and then what happens if the wrong option is used with an IAID in a Renew (or Release, ...). So, it gets messy and is probably not the best approach. **end of bernie's comments*** The problem of IAID spaces overlapping, if the client mistakenly allocates the same IAID for the 2 IAs. This is purely an implementation problem, the client MUST not allocate same IAID for two IAs. The second problem's solution is, if the client has an Temporary Address IA with IAID 36 and if it sends the renew/rebind as IA option with IAID 36, the server has to discard that option. because of following two reasons. i) It doesn't have the bindings of Temporary IA with IAID 36 ii) The temporary addresses cannot be renewed/rebinded. I prefer defining a seperate option for Temporary address IA, since the behaviour of the addresses inside the IAs are different for these two type of IAs. > > * How and when does the client use DAD on addresses in Advertise and > Reply messages? > > WG consensus: Client does DAD on addresses in Reply message and > responds with Decline if addresses unacceptable (e.g., already in > use) > > * Advertise message SHOULD include options for all OROs that were > included in the Solicit if the server is willing/capable of offering > a value for that option > > WG consensus: yes > > * Should we consider a "quick" handshake for allowing a client to > assign an address in a single exchange of two messages? > > WG consensus: defer for later reconsideration > > * Tighten up text on T1/T2 to require T1/T2 occur prior to expiration > of lifetimes of addresses in IA; no need to describe default as > T1/T2 are fields in IA header and must be supplied by server > > WG consensus: yes But, obviously, as per default definitions for T1 and T2, T1 wont expire before the expiration of lifetimes in the IA. Since T1 defaults to 50% of the preferred lifetime of the IP address with shortest life time. I think there is no harm in keeping this. > > Open issue: what about selection of T1/T2 with temporary addresses > and with addresses whose lifetimes won't be extended; > e.g. addresses to be deprecated/discarded due to > renumbering. If we are going to use seperate option for IA for normal addresses and IA for temporary addresses, then, this problem won't occur. If we are going to use same option for both, then, for IA containing temporary address, T1 and T2 should be infinity, meaning that, it SHOULD not contact the server for renewal. > > * The semantics of the use of IA must be clarified (see Volz message > of 7/19). In particular, what are the semantics of a Request > containing an IA that the client has previously sent to the server? > What are the semantics of a Requst containing a new IA? > > Open issue: rules about when to reuse old IA or use new IA > > * Simplify Release and Decline so the all of the addresses in an IA > are released or declined, rather than allowing the client to release > or decline just some addresses. > > WG consensus: yes > > * Add "NAK" function: > > If the server finds that the prefix on one or more IP addresses in > any IA in the {Request,Confirm,Rebind} message is not a valid > prefix for the link to which the client is connected, the server > MUST send an NoPrefixMatch status in the IA status field for that > IA in the DHCP Reply message. > > WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" > error code. Add text allowing client to ignore > "NoPrefixMatch" from other servers if ACK received from > at least one server. > > * Define DUID to be one of: > - Link-layer address plus time > - Vendor-assigned unique ID > - Link-layer address > - IMSI > - IMEI > > WG consensus: yes; based on text submitted by Lemon with extensions > from subsequent WG discussion > > * Use IPsec for secure agent/server communication > > WG consensus: yes; add text to draft > > * Add an "error code" option, to indicate errors not connected with a > specific option > > WG consensus: yes yes, this error option is necessary. Ebi has already given the format of the "error code" option and various error codes. Do you want me resend those details? > > * Tighten up language for unicasting Reconfigure-Init; in particular, > the server may not have an appropriate address to use to send the > message to the client. > > WG consensus: yes > > * Reply to a Confirm should be a simple ACK/NAK without changing any > values in options > > WG consensus: yes > > * Reply to Decline or Release should carry no options > > WG consensus: yes > > * Restrict options in Decline or Release to IA with text to allow > other options in the future > > Open issue > > * Server does not respond to Solicit when server has no addresses > > Open issue The server MUST respond with the remaining available parameters. eventhough it doesn't have the address to allocate. This is because, if the client has got a reponse from some other server which is capable of allocating IP addresses, but, not having one or few other parameters. For getting those remaining parameters, it can contact this server. > > * Include only options specifically mentioned in the text in the > DHCPv6 spec; move others to second doc or separate appendix > > Open issue; generate list of options based on previous work We have some extensions defined in DHCPv6 extension draft -12th version. Can we bring some of the valid extensions from there to here as options? (DNS server address was brought inside this draft already) This has to be done, because, at present DHCPv6 support very few options only. I have previously sent a mail about changing the format of ORO option (refer my mail on 7/19/01) to include parameter number and putting the index for those parameters. We need to include this. > > * Add 'secs' field to fixed header > > Open issue > > * Describe message transmission and retransmission in a separate > section of the spec and reference that text throughout the remainder > of the spec > > Open issue > > * Discard the client unicast or recheck the entire spec for > consistency in reference to message transmission > > Open issue > > * Remove client link-local address from client message header. Agent > can then determine link-local from source (IP header) in client > message and insert into agent->server message. Server responds to > source from IP header (whether agent or client). > > Open issue But, we cannot say that, the source address will always be a linklocal address. If the client sends the request with one of the address allocated by the server, as source address, and after sending the request, the address has expired, so the client deletes it, then, what will be the behaviour for the reply? how does the reply arrive the client? Do we need to include the text something like "client while sending the packet to agents/server, they MUST have to put the link local address as the From address". ~vijay From owner-dhcp-v6@bucknell.edu Wed Aug 8 00:48:54 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA19428; Wed, 8 Aug 2001 00:48:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f784n8304387; Wed, 8 Aug 2001 00:49:08 -0400 (EDT) Received: from i2soft_web ([211.240.20.130]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f784mv313589 for ; Wed, 8 Aug 2001 00:48:58 -0400 (EDT) Received: by i2soft_web with MERCUR-SMTP/POP3/IMAP4-Server (v3.00.25 RI-0000000) for at Wed, 8 Aug 2001 13:50:37 +0900 Reply-To: From: "JJI" To: DHCPv6 discussion list Subject: DHCPv6 adaptability and extension ? Date: Wed, 8 Aug 2001 13:48:52 +0900 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" 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.50.4522.1200 Importance: Normal Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.bucknell.edu id f784mx300048 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Dear Sir, My name is Jung Jongil at I2SOFT corp. in Korea. I am currently developing technologies related to IPv6, core-protocol of next generation Internet. My company is considering several elements of the DHCPv6 that is operating with the actual network for IPv6 deployment. DHCPv4 was capable of allocating and managing the IP-addresses. However, DHCPv6 could have more powerful and extended functions than DHCPv4. Especially, I think that the adaptability in mobile environment is also an important element. In relation to the points, I wonder two things. The first is where to apply, for instance mobile, home networking and ISP, and the second is where the function of DHCPv6 extends to, such as the range of the extension. I hope to hear from you soon. Thank you for your assistance. From owner-dhcp-v6@bucknell.edu Wed Aug 8 03:22:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07396; Wed, 8 Aug 2001 03:22:00 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f787Km330535; Wed, 8 Aug 2001 03:20:48 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f787Ka307817 for ; Wed, 8 Aug 2001 03:20:36 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f787KVp13822 for ; Wed, 8 Aug 2001 02:20:35 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f787KVK26368 for ; Wed, 8 Aug 2001 02:20:31 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Wed Aug 08 02:20:30 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 02:20:30 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69903F12@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Re : List of issues for WG meeting with resolution summaries Date: Wed, 8 Aug 2001 02:20:29 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C11FDA.9A7CDB50" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C11FDA.9A7CDB50 Content-Type: text/plain; charset="iso-8859-1" Vijay: See my comments inline (prefixed by BV>). - Bernie -----Original Message----- From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com] Sent: Tuesday, August 07, 2001 4:10 PM To: DHCPv6 discussion list Subject: Re : List of issues for WG meeting with resolution summaries Hi, see my comments inline. > Here's a revision of the list of issues, with an annotation for each issue > either explaining my understanding of WG consensus on resolution or marking > the issue as open. Note that the list of issues has been somewhat > rearranged from the list I sent out earlier to provide a little more > logical grouping. Thanks to Bernie for his quick review and input on this > list. > > Please review and reply with comments before tomorrow's meeting if possible... > > - Ralph > > > > > * Should addresses in an Advertise message be "real" addresses or > "informational"; e.g., just prefixes? > > WG consensus: addresses in Advertise are the addresses the server > will return in a subsequent Reply; client supplies those addresses > to server in IA in Request message Isn't enough that, if the server sends the prefix in the IA? because, the server has to remember these OFFERED addresses. There should be some expiration time for these OFFERED addresses and in the case, if this time has expired, and the server has assigned this addresses to different clients, then the client has to accept different addresses. The main purpose of this sending the addresses is to show the client that the server is willing to serve the client with IP addresses. In the client point of view, whatever addresses it get, it doesn't matter. Do you think, do we need to include unnecessary load of remembering and maintaining the OFFERED addresses and keeping a time knob for those addresses? In the case, if it is finalised as the server SHOULD send the addresses, the text has to be added for the time knob for those OFFERED addresses and behaviour of the client, if it gets the different addresses, it has sent in the request. BV> I agree, as I've argued several times in discussions on this subject. BV> I too would like the offered addresses to just be samples and not BV> necessarily be the addresses the client will get. I think it will improve BV> server performance since these addresses do not need to be remembered. > > * Servers will only assign complete addresses and not prefixes (e.g., > to be used by the client for stateless autoconfiguration) > > WG consensus: yes; prefix advertisement is handled through ND > > * Modify IA option so that all addresses in an IA are "regular" or > "temporary". Modify text so that client indicates types of > addresses to be assigned by sending appropriate IAs. Server then > fills in each IA with assigned addresses. > > Open issue > > * Define separate IA option for temporary addresses rather than > indicate the type of address in a single IA option > > Open issue The two possible solutions for handling IA containing temporary addresses are, 1) modify the IA option by adding one bit before the "IA status" field and removing "T" bit before the "addr status". The IA option looks something like this. I have already posted this format. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION IA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | T2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T| IA status | num-addrs | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | IPv6 address | | (16 octets) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IPv6 address | | (16 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref. lifetime (cont.) | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid lifetime (cont.) | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | | IPv6 address | | (16 octets) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Since the T bit before "addr status" field has no use and since we are not going to do something specific to a particular IP address in an IA (since, release or decline will be done for the whole IA only, not for some address in the IA), there is no use for "addr status" field. The whole status of the IA can be reflected in IA status itself. Thus, we can eliminate the "addr status" also. But, i'm not sure there may be some alignment problem, if we directly reomove that field. So, we can put an Must be Zero byte there. But, one thing, we need to take care is, if the number of addresses in the IA is large, then, we are wasting that much number of unused bytes. Alternatively, we can remove one byte from the IAID and make alignement proper. 2) Second solution is, keeping a different option for Temporary address IA. Since, the temporary addresses MUST not be renewed, there is no point in having T1 and T2 values for the IA. We can define a seperate option for Temporary Address IA similar to the IA option but without the T1 and T2 values. The temporary IA option will look like this. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION TMP IA | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IAID (4 octets) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IA status | num-addrs | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | IPv6 address | | (16 octets) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | IPv6 address | | (16 octets) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | preferred lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref. lifetime (cont.) | valid lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | valid lifetime (cont.) | prefix length | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | IPv6 address | | (16 octets) | | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Here, we don't need to have "T" bit before the IA option and TMP IA option also. The problem told by Bernie on this model was, a) According to the IA option defined in 19th rev, we need a "T" bit for identifying the temporary addresses. So, he told that even though "addr status" is unused, we need to allocate a byte for "T" bit, so we cannot remove it. Now, we can move the "T" bit before the "IA status" byte. So, this problem is solved. In the case, if we are defining seperate option, we don't need the "T" bit itself. b) ** comments from Bernie*** There are some issues with a new option - such as the IAID spaces must not overlap, and then what happens if the wrong option is used with an IAID in a Renew (or Release, ...). So, it gets messy and is probably not the best approach. **end of bernie's comments*** The problem of IAID spaces overlapping, if the client mistakenly allocates the same IAID for the 2 IAs. This is purely an implementation problem, the client MUST not allocate same IAID for two IAs. The second problem's solution is, if the client has an Temporary Address IA with IAID 36 and if it sends the renew/rebind as IA option with IAID 36, the server has to discard that option. because of following two reasons. i) It doesn't have the bindings of Temporary IA with IAID 36 ii) The temporary addresses cannot be renewed/rebinded. I prefer defining a seperate option for Temporary address IA, since the behaviour of the addresses inside the IAs are different for these two type of IAs. BV> Either approach is fine. If new option used, IAID issue isn't major, BV> just has to be considered. > > * How and when does the client use DAD on addresses in Advertise and > Reply messages? > > WG consensus: Client does DAD on addresses in Reply message and > responds with Decline if addresses unacceptable (e.g., already in > use) > > * Advertise message SHOULD include options for all OROs that were > included in the Solicit if the server is willing/capable of offering > a value for that option > > WG consensus: yes > > * Should we consider a "quick" handshake for allowing a client to > assign an address in a single exchange of two messages? > > WG consensus: defer for later reconsideration > > * Tighten up text on T1/T2 to require T1/T2 occur prior to expiration > of lifetimes of addresses in IA; no need to describe default as > T1/T2 are fields in IA header and must be supplied by server > > WG consensus: yes But, obviously, as per default definitions for T1 and T2, T1 wont expire before the expiration of lifetimes in the IA. Since T1 defaults to 50% of the preferred lifetime of the IP address with shortest life time. I think there is no harm in keeping this. BV> We just need to state something like that the T1/T2 times must give the BV> client a chance to renew any addresses that the server will potentially BV> allow the client to renew. If temporary addresses are not to be renewed, BV> T1 (& T2) can be much longer than these lifeimes. If an address can be BV> renewed, the T1/T2 times should allow for it to happen. The server should BV> be responsible for setting the T1/T2 times - always. > > Open issue: what about selection of T1/T2 with temporary addresses > and with addresses whose lifetimes won't be extended; > e.g. addresses to be deprecated/discarded due to > renumbering. If we are going to use seperate option for IA for normal addresses and IA for temporary addresses, then, this problem won't occur. If we are going to use same option for both, then, for IA containing temporary address, T1 and T2 should be infinity, meaning that, it SHOULD not contact the server for renewal. > > * The semantics of the use of IA must be clarified (see Volz message > of 7/19). In particular, what are the semantics of a Request > containing an IA that the client has previously sent to the server? > What are the semantics of a Requst containing a new IA? > > Open issue: rules about when to reuse old IA or use new IA > > * Simplify Release and Decline so the all of the addresses in an IA > are released or declined, rather than allowing the client to release > or decline just some addresses. > > WG consensus: yes > > * Add "NAK" function: > > If the server finds that the prefix on one or more IP addresses in > any IA in the {Request,Confirm,Rebind} message is not a valid > prefix for the link to which the client is connected, the server > MUST send an NoPrefixMatch status in the IA status field for that > IA in the DHCP Reply message. > > WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" > error code. Add text allowing client to ignore > "NoPrefixMatch" from other servers if ACK received from > at least one server. > > * Define DUID to be one of: > - Link-layer address plus time > - Vendor-assigned unique ID > - Link-layer address > - IMSI > - IMEI > > WG consensus: yes; based on text submitted by Lemon with extensions > from subsequent WG discussion > > * Use IPsec for secure agent/server communication > > WG consensus: yes; add text to draft > > * Add an "error code" option, to indicate errors not connected with a > specific option > > WG consensus: yes yes, this error option is necessary. Ebi has already given the format of the "error code" option and various error codes. Do you want me resend those details? > > * Tighten up language for unicasting Reconfigure-Init; in particular, > the server may not have an appropriate address to use to send the > message to the client. > > WG consensus: yes > > * Reply to a Confirm should be a simple ACK/NAK without changing any > values in options > > WG consensus: yes > > * Reply to Decline or Release should carry no options > > WG consensus: yes > > * Restrict options in Decline or Release to IA with text to allow > other options in the future > > Open issue > > * Server does not respond to Solicit when server has no addresses > > Open issue The server MUST respond with the remaining available parameters. eventhough it doesn't have the address to allocate. This is because, if the client has got a reponse from some other server which is capable of allocating IP addresses, but, not having one or few other parameters. For getting those remaining parameters, it can contact this server. BV> I agree. It should not send back the IA option. But should otherwise BV> respond. It may well be that it is the only server and most addresses BV> were assigned via stateless and so the client can function - provided BV> it gets other configuration information. > > * Include only options specifically mentioned in the text in the > DHCPv6 spec; move others to second doc or separate appendix > > Open issue; generate list of options based on previous work We have some extensions defined in DHCPv6 extension draft -12th version. Can we bring some of the valid extensions from there to here as options? (DNS server address was brought inside this draft already) This has to be done, because, at present DHCPv6 support very few options only. I have previously sent a mail about changing the format of ORO option (refer my mail on 7/19/01) to include parameter number and putting the index for those parameters. We need to include this. > > * Add 'secs' field to fixed header > > Open issue > > * Describe message transmission and retransmission in a separate > section of the spec and reference that text throughout the remainder > of the spec > > Open issue > > * Discard the client unicast or recheck the entire spec for > consistency in reference to message transmission > > Open issue > > * Remove client link-local address from client message header. Agent > can then determine link-local from source (IP header) in client > message and insert into agent->server message. Server responds to > source from IP header (whether agent or client). > > Open issue But, we cannot say that, the source address will always be a linklocal address. If the client sends the request with one of the address allocated by the server, as source address, and after sending the request, the address has expired, so the client deletes it, then, what will be the behaviour for the reply? how does the reply arrive the client? Do we need to include the text something like "client while sending the packet to agents/server, they MUST have to put the link local address as the From address". BV> If the client is unicasting to the server, it must use an address that BV> will be valid for the duration of the exchange. The client must pick BV> the address carefully and can only use unicast to the server if it has BV> an address that meets the qualifications. Otherwise, is must use BV> multicast (AND LINK LOCAL!) and communicate via relay (or server if on BV> same link). ~vijay ------_=_NextPart_001_01C11FDA.9A7CDB50 Content-Type: text/html; charset="iso-8859-1" RE: Re : List of issues for WG meeting with resolution summaries

Vijay:

See my comments inline (prefixed by BV>).

- Bernie

-----Original Message-----
From: Vijay Bhaskar A K [mailto:vijayak@india.hp.com]
Sent: Tuesday, August 07, 2001 4:10 PM
To: DHCPv6 discussion list
Subject: Re : List of issues for WG meeting with resolution summaries


Hi,
see my comments inline.

> Here's a revision of the list of issues, with an annotation for each issue
> either explaining my understanding of WG consensus on resolution or marking
> the issue as open.  Note that the list of issues has been somewhat
> rearranged from the list I sent out earlier to provide a little more
> logical grouping.  Thanks to Bernie for his quick review and input on this
> list.
>
> Please review and reply with comments before tomorrow's meeting if possible...
>
> - Ralph
>
>
>
>
> * Should addresses in an Advertise message be "real" addresses or
>    "informational"; e.g., just prefixes?
>
>    WG consensus: addresses in Advertise are the addresses the server
>    will return in a subsequent Reply; client supplies those addresses
>    to server in IA in Request message

Isn't  enough that, if the server  sends the prefix in the IA?  because,
the server has to remember  these  OFFERED  addresses.  There  should be
some  expiration  time for these OFFERED  addresses  and in the case, if
this time has expired, and the server has  assigned  this  addresses  to
different  clients, then the client has to accept  different  addresses.
The main  purpose of this  sending the  addresses  is to show the client
that the  server is willing to serve the client  with IP  addresses.  In
the client point of view, whatever  addresses it get, it doesn't matter.
Do you think, do we need to include  unnecessary load of remembering and
maintaining  the  OFFERED  addresses  and  keeping a time knob for those
addresses?

In the case, if it is finalised as the server SHOULD send the addresses,
the text has to be added for the time knob for those  OFFERED  addresses
and behaviour of the client, if it gets the different  addresses, it has
sent in the request.

BV> I agree, as I've argued several times in discussions on this subject.
BV> I too would like the offered addresses to just be samples and not
BV> necessarily be the addresses the client will get. I think it will improve
BV> server performance since these addresses do not need to be remembered.

>
> * Servers will only assign complete addresses and not prefixes (e.g.,
>    to be used by the client for stateless autoconfiguration)
>
>    WG consensus: yes; prefix advertisement is handled through ND
>
> * Modify IA option so that all addresses in an IA are "regular" or
>    "temporary".  Modify text so that client indicates types of
>    addresses to be assigned by sending appropriate IAs.  Server then
>    fills in each IA with assigned addresses.
>
>    Open issue
>
> * Define separate IA option for temporary addresses rather than
>    indicate the type of address in a single IA option
>
>    Open issue

The  two  possible  solutions  for  handling  IA  containing   temporary
addresses are,

1) modify the IA option by adding one bit before the "IA  status"  field
and  removing  "T" bit  before the "addr  status".  The IA option  looks
something like this. I have already posted this format.

        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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           OPTION IA           |          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        IAID (4 octets)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T1                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                              T2                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |T| IA status   |   num-addrs   | prefix length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |      preferred lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |        valid lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      preferred lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | pref. lifetime (cont.)        |        valid lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | valid lifetime (cont.)        | prefix length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Since the T bit before "addr  status"  field has no use and since we are
not going to do something  specific to a particular  IP address in an IA
(since,  release or decline  will be done for the whole IA only, not for
some address in the IA), there is no use for "addr  status"  field.  The
whole status of the IA can be reflected  in IA status  itself.  Thus, we
can eliminate  the "addr  status"  also.  But, i'm not sure there may be
some alignment  problem, if we directly  reomove that field.  So, we can
put an Must be Zero byte  there.  But, one  thing, we need to take  care
is, if the number of addresses  in the IA is large, then, we are wasting
that much number of unused bytes.  Alternatively, we can remove one byte
from the IAID and make alignement proper.

2) Second solution is, keeping a different option for Temporary  address
IA.  Since, the  temporary  addresses  MUST not be renewed,  there is no
point in having T1 and T2 values  for the IA.  We can  define a seperate
option for Temporary Address IA similar to the IA option but without the
T1 and T2 values.  The temporary IA option will look like this.

        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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           OPTION TMP IA       |          option-len           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                        IAID (4 octets)                        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   IA status   |   num-addrs   | prefix length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               |
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |      preferred lifetime                       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |        valid lifetime                         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               | prefix length |                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                               |      preferred lifetime       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | pref. lifetime (cont.)        |        valid lifetime         |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | valid lifetime (cont.)        | prefix length |               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         IPv6 address                          |
     |                          (16 octets)                          |
     |                                                               |
     +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |               |              ...                              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here, we don't  need to have "T" bit  before  the IA  option  and TMP IA
option also.

The problem told by Bernie on this model was,

a) According to the IA option defined in 19th rev, we need a "T" bit for
identifying the temporary addresses.  So, he told that even though "addr
status" is unused, we need to  allocate a byte for "T" bit, so we cannot
remove it.  Now, we can move the "T" bit  before the "IA  status"  byte.
So, this  problem is solved.  In the case, if we are  defining  seperate
option, we don't need the "T" bit itself.

b) ** comments from Bernie***
There are some issues with a new option - such as the IAID spaces must not
overlap, and then what happens if the wrong option is used with an IAID in
a Renew (or Release, ...). So, it gets messy and is probably not the best
approach.
**end of bernie's comments***

The  problem  of  IAID  spaces  overlapping,  if the  client  mistakenly
allocates the same IAID for the 2 IAs.  This is purely an implementation
problem, the client MUST not allocate same IAID for two IAs.

The second problem's solution is, if the client has an Temporary Address
IA with IAID 36 and if it sends the  renew/rebind as IA option with IAID
36, the server has to discard  that  option.  because of  following  two
reasons.

i) It doesn't have the bindings of Temporary IA with IAID 36
ii) The temporary addresses cannot be renewed/rebinded.

I prefer defining a seperate option for Temporary  address IA, since the
behaviour of the  addresses  inside the IAs are different  for these two
type of IAs.

BV> Either approach is fine. If new option used, IAID issue isn't major,
BV> just has to be considered.

>
> * How and when does the client use DAD on addresses in Advertise and
>    Reply messages?
>
>    WG consensus: Client does DAD on addresses in Reply message and
>    responds with Decline if addresses unacceptable (e.g., already in
>    use)
>
> * Advertise message SHOULD include options for all OROs that were
>    included in the Solicit if the server is willing/capable of offering
>    a value for that option
>
>    WG consensus: yes
>
> * Should we consider a "quick" handshake for allowing a client to
>    assign an address in a single exchange of two messages?
>
>    WG consensus: defer for later reconsideration
>
> * Tighten up text on T1/T2 to require T1/T2 occur prior to expiration
>    of lifetimes of addresses in IA; no need to describe default as
>    T1/T2 are fields in IA header and must be supplied by server
>
>    WG consensus: yes

But, obviously, as per default definitions for T1 and T2, T1 wont expire
before the  expiration of lifetimes in the IA.  Since T1 defaults to 50%
of the preferred  lifetime of the IP address with shortest life time.  I
think there is no harm in keeping this.

BV> We just need to state something like that the T1/T2 times must give the
BV> client a chance to renew any addresses that the server will potentially
BV> allow the client to renew. If temporary addresses are not to be renewed,
BV> T1 (& T2) can be much longer than these lifeimes. If an address can be
BV> renewed, the T1/T2 times should allow for it to happen. The server should
BV> be responsible for setting the T1/T2 times - always.

>
>    Open issue: what about selection of T1/T2 with temporary addresses
>                and with addresses whose lifetimes won't be extended;
>                e.g. addresses to be deprecated/discarded due to
>                renumbering.

If we are going to use seperate  option for IA for normal  addresses and
IA for temporary addresses, then, this problem won't occur.

If we are going to use same  option  for both,  then, for IA  containing
temporary address, T1 and T2 should be infinity, meaning that, it SHOULD
not contact the server for renewal.

>
> * The semantics of the use of IA must be clarified (see Volz message
>    of 7/19).  In particular, what are the semantics of a Request
>    containing an IA that the client has previously sent to the server?
>    What are the semantics of a Requst containing a new IA?
>
>    Open issue: rules about when to reuse old IA or use new IA
>
> * Simplify Release and Decline so the all of the addresses in an IA
>    are released or declined, rather than allowing the client to release
>    or decline just some addresses.
>
>    WG consensus: yes
>
> * Add "NAK" function:
>
>     If the server finds that the prefix on one or more IP addresses in
>     any IA in the {Request,Confirm,Rebind} message is not a valid
>     prefix for the link to which the client is connected, the server
>     MUST send an NoPrefixMatch status in the IA status field for that
>     IA in the DHCP Reply message.
>
>    WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch"
>                  error code.  Add text allowing client to ignore
>                  "NoPrefixMatch" from other servers if ACK received from
>                  at least one server.
>
> * Define DUID to be one of:
>    - Link-layer address plus time
>    - Vendor-assigned unique ID
>    - Link-layer address
>    - IMSI
>    - IMEI
>
>    WG consensus: yes; based on text submitted by Lemon with extensions
>                  from subsequent WG discussion
>
> * Use IPsec for secure agent/server communication
>
>    WG consensus: yes; add text to draft
>
> * Add an "error code" option, to indicate errors not connected with a
>    specific option
>
>    WG consensus: yes

yes, this error option is  necessary.  Ebi has already  given the format
of the "error  code"  option and  various  error  codes.  Do you want me
resend those details?

>
> * Tighten up language for unicasting Reconfigure-Init; in particular,
>    the server may not have an appropriate address to use to send the
>    message to the client.
>
>    WG consensus: yes
>
> * Reply to a Confirm should be a simple ACK/NAK without changing any
>    values in options
>
>    WG consensus: yes
>
> * Reply to Decline or Release should carry no options
>
>    WG consensus: yes
>
> * Restrict options in Decline or Release to IA with text to allow
>    other options in the future
>
>    Open issue
>
> * Server does not respond to Solicit when server has no addresses
>
>    Open issue

The  server  MUST  respond  with  the  remaining  available  parameters.
eventhough it doesn't have the address to allocate.  This is because, if
the client has got a reponse  from some other server which is capable of
allocating IP  addresses,  but, not having one or few other  parameters.
For getting those remaining parameters, it can contact this server.

BV> I agree. It should not send back the IA option. But should otherwise
BV> respond. It may well be that it is the only server and most addresses
BV> were assigned via stateless and so the client can function - provided
BV> it gets other configuration information.

>
> * Include only options specifically mentioned in the text in the
>    DHCPv6 spec; move others to second doc or separate appendix
>
>    Open issue; generate list of options based on previous work

We have some extensions defined in DHCPv6 extension draft -12th version.
Can we bring some of the valid extensions from there to here as options?
(DNS server  address was brought  inside this draft already) This has to
be done, because, at present DHCPv6 support very few options only.

I have  previously  sent a mail about  changing the format of ORO option
(refer my mail on 7/19/01) to include  parameter  number and putting the
index for those parameters.

We need to include this.

>
> * Add 'secs' field to fixed header
>
>    Open issue
>
> * Describe message transmission and retransmission in a separate
>    section of the spec and reference that text throughout the remainder
>    of the spec
>
>    Open issue
>
> * Discard the client unicast or recheck the entire spec for
>    consistency in reference to message transmission
>
>    Open issue
>
> * Remove client link-local address from client message header.  Agent
>    can then determine link-local from source (IP header) in client
>    message and insert into agent->server message.  Server responds to
>    source from IP header (whether agent or client).
>
>    Open issue

But, we cannot say that, the source  address  will always be a linklocal
address.  If the  client  sends  the  request  with  one of the  address
allocated  by the  server,  as source  address,  and after  sending  the
request,  the address has expired, so the client  deletes it, then, what
will be the  behaviour  for the  reply?  how does the reply  arrive  the
client?  Do we need to include the text  something  like  "client  while
sending  the  packet to  agents/server,  they MUST  have to put the link
local address as the From address".

BV> If the client is unicasting to the server, it must use an address that
BV> will be valid for the duration of the exchange. The client must pick
BV> the address carefully and can only use unicast to the server if it has
BV> an address that meets the qualifications. Otherwise, is must use
BV> multicast (AND LINK LOCAL!) and communicate via relay (or server if on
BV> same link).

~vijay

------_=_NextPart_001_01C11FDA.9A7CDB50-- From owner-dhcp-v6@bucknell.edu Wed Aug 8 07:54:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10568; Wed, 8 Aug 2001 07:54:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78Bsr314068; Wed, 8 Aug 2001 07:54:53 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78Bsq318399 for ; Wed, 8 Aug 2001 07:54:52 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f78Bnof29208 for ; Wed, 8 Aug 2001 04:49:50 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f78BshO00459 for ; Wed, 8 Aug 2001 04:54:43 -0700 (MST) Message-Id: <200108081154.f78BshO00459@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Re : List of issues for WG meeting with resolution summaries In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 08 Aug 2001 02:20:29 EST." <66F66129A77AD411B76200508B65AC69903F12@eambunt705.ena-east.ericsson.se> Date: Wed, 08 Aug 2001 12:54:43 +0100 From: Ted Lemon 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 > BV> I agree, as I've argued several times in discussions on this subject. > BV> I too would like the offered addresses to just be samples and not > BV> necessarily be the addresses the client will get. I think it will improve > BV> server performance since these addresses do not need to be remembered. This is a bit of a red herring. The server does not need to remember the address it offered, nor to reserve it in any special way. The ISC DHCP server doesn't do this in DHCPv4 - it just places the address at the back of the allocation queue, offering the client its best guess that, absent serious address consumption problems, it will assign the client that address if the client requests it. If the network is congested, the client's DHCPREQUEST will be NAKed. In the case of DHCPv6, if the address is no longer available, but some other address is available, the server could indicate an error in the Reply message when the client requested the address. Server implementors that do not want to reserve addresses they have offered to clients don't have to do so. But it would be a mistake to make it impossible for them to do this, IMHO. In DHCPv4, it is possible for clients to get consistent addresses even in the presence of multiple servers if they so desire. In DHCPv6, without the ability of a server to "offer" an address, this is not possible. There's an additional point - the client needs to be able to say "please give me this address if you can", by sending a sample IA to the server as a hint in the Solicit message. I've heard people argue that address stability is not important, but this is not really true - until we have a DNS system that provides guaranteed up-to-date information, which I don't think is likely to happen, address stability has real value. Designing the protocol in such a way that address stability can only happen if there is only one server strikes me as a bad idea. In the case of a high-performance environment where address stability is not an issue, it would be acceptable to me if the client were permitted to indicate that it didn't care about what address it got by not including an IA as a hint. Since a client that cares about address stability will need to send a hint IA, the server can, in the case where no such IA is presented, simply return an advertise message with no IA at all. This solves your performance problem without losing a key piece of functionality that I suspect many people will want. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 8 08:03:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10684; Wed, 8 Aug 2001 08:03:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78C4U329776; Wed, 8 Aug 2001 08:04:31 -0400 (EDT) Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78C4M310392 for ; Wed, 8 Aug 2001 08:04:22 -0400 (EDT) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.2.19]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id f78C2IJ21008 for ; Wed, 8 Aug 2001 05:02:18 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.10.1/8.10.1) with ESMTP id f78C45Z24674 for ; Wed, 8 Aug 2001 05:04:05 -0700 (PDT) Received: from MJS-W2K.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id FAA12863 for ; Wed, 8 Aug 2001 05:04:03 -0700 (PDT) Message-Id: <4.3.2.7.2.20010807144904.0385e008@localhost> X-Sender: mjs@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Aug 2001 13:03:23 +0100 To: DHCPv6 discussion list From: Mark Stapp Subject: Re: List of issues for WG meeting with resolution summaries Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks, Ralph, for this excellent summary. This will help a great deal this afternoon. Some comments inline, and a couple of questions at the end. >* Should we consider a "quick" handshake for allowing a client to > assign an address in a single exchange of two messages? > > WG consensus: defer for later reconsideration Agreed. I'm one of the people who'd really like to see this, but I think it can run in a parallel spec. Adding such a capability, though, would be more straight-forward if there was a flags or capabilities field. That could be used by a client to solicit a 'committed offer'. >* Modify IA option so that all addresses in an IA are "regular" or > "temporary". Modify text so that client indicates types of > addresses to be assigned by sending appropriate IAs. Server then > fills in each IA with assigned addresses. > > Open issue > >* Define separate IA option for temporary addresses rather than > indicate the type of address in a single IA option > > Open issue This would be a good simplification. Could we consider turning that 'status' field into a more-general flags field? I think all of that 'status' stuff is a legacy of an older revision that focussed on hypothetical application-level interactions with the client implementation. References to the 'status' field and the 'application' that's supposed to benefit from it should all go away until we actually have to specify an api. At that time, we can either update with a new IA format, or add a 'status' option. Could this level of question be a hint that the IA format is already breaking down? We spent a little time talking about an alternative method of representing multiple addresses in a single message; maybe we should consider that again. The existing IA option packs a bunch of stuff into a set of fixed-length chunks. The number of chunks is verying, but the size and order of the data in each chunk is fixed. If we wish to attach some information to a single member of the set, we have to extend the fixed format, or find ways to overload existing fields. In this model, options are only used to carry data that applies to the entire message. It should be a concern that this representation may not be flexible or extensible. The experience that we have with dhcpv4 suggests that we will be asked to support a wide range of new environments and applications, and that means new options. Address selection in v6 is still clearly being worked on, and we must anticipate that we may be asked, soon or eventually, to make additional information available to help clients characterize addresses. The current specification is severely limited in that it cannot include new options that apply to a subset of the addresses in an IA. There's no way to point a new option at one member of a set of addresses. The c-struct version of IA has broken down when applied to temp addresses, and to DECLINE cases where the client only wants to DECLINE a single address. That should be a signal that we need a more capable mechanism in the protocol. I suggest an alternative at the end of this message. >* Tighten up text on T1/T2 to require T1/T2 occur prior to expiration > of lifetimes of addresses in IA; no need to describe default as > T1/T2 are fields in IA header and must be supplied by server > > WG consensus: yes > > Open issue: what about selection of T1/T2 with temporary addresses > and with addresses whose lifetimes won't be extended; > e.g. addresses to be deprecated/discarded due to > renumbering. Could we consider getting t1/t2 out of the fixed part of the IA? Is that really something that's going to vary with each address? Could we specify the calculation that clients should make by default from the preferred lifetime, and only send options that override that when necessary? Or (subtle eh?) is this another sign that the c-struct version of IA may not be sufficiently extensible? I actually would like to have it possible for clients to contact the server, and to encourage that by having the clients calculate T1/T2 or by sending those options explicitly to the clients. Periodic contact gives the server the opportunity to convey other configuration changes, and should be independent of lease 'expiration'. >* Remove client link-local address from client message header. Agent > can then determine link-local from source (IP header) in client > message and insert into agent->server message. Server responds to > source from IP header (whether agent or client). > > Open issue I very much prefer that all of the necessary protocol data be present in the protocol packets themselves. That's been a strength of the existing v4 protocol. Additional questions: 1. Could we consider some other header fixups? The 'preference' value is in every header, although it's used in only 2 of the 10 messages. Use of the 'pref' field is very watered down: 13.3.3 says that a client is allowed to just plain ignore it if "... a less-preferred server [...] has a better set of advertised parameters ..." Could we make the preference an option, since it's used rarely, and since it seems pretty advisory as specified? 2. I ask that in part because I'd like the header to include a flags field. I think that'd be an excellent place for clients and servers to indicate their capabilities and intentions. A client might set a 'temp addresses' or 'i desire privacy addresses' bit as a hint that the server should allocate special categories of address if it can. A server might, in turn, set a bit that says, 'i support temp addresses. go ahead and ask me for some' if it could help a client which didn't ask explicitly. More-general protocol features or capabilities that apply to the client or server as a whole should be communicated in a more-general place, like the basic message header. More-specific data that relates to an IA or to a single address should be communicated with that more-specific protocol component. 3. I made some observations about the limitations of the c-struct IA. An alternative would be to use options for most of the per-address data as well as for the data that applies to the whole message. Being able to supply information that characterizes an address or list of addresses would permit conveying 'these are privacy addresses', and it would support 'this is a global address, but it's a WAN link, so you may want to treat it as a backup for the other global address I leased you'. I've tried to include some examples because it seems easier to me to see how a different mechanism might work very effectively in both complex and simple configurations. The dhcpv4 failover protocol supports a format like this to allow servers to convey information about a bunch of clients in a single message. One option - the option that carries the address or addresses - acts as a marker that distinguishes one group of options from another, dividing the options area into frames almost. Options that apply to the entire message are placed first, and then each address demarcates each of its own more-specific option data. The next address option begins a new frame, and ends the one that preceded it. In the v6 context, I'd suggest these rules: a. Options that apply to the entire message are at the beginning of the options area. b. A new IA option - just a marker that identifies a 'frame' of 1 or more addresses - signals the beginning of the options that apply to that IA. The IA ends when the next IA option is encountered, or when the packet ends. c. Within an IA 'frame', the options that apply to the entire IA are first, before any addresses. d. A simpler 'ip address' option would carry one or more ip6 addresses (and a prefix-len byte for each). If other options are present after the address option, they are associated with the address(es). The 'address frame' ends when the next address option is found in the IA, or when the 'IA frame' ends. The hierarchy that this establishes offers plenty of flexibility for future per-address characterization, but it can also be used to exchange very straightforward messages which aren't forced to include redundant data. If a server leases an organizational and a global address to a client, and if those are both leased for the same time period and have the same t1 and t2, the packet involved is very simple: a DUID, an IA marker, a single ip-address option containing the two addresses, and a lease-time. If the server needs to override the default t1 or t2, it could include that option or those options too. In simple cases, this would just let us do what we want to do now, but are hving trouble shoe-horning into the existing IA option. A client who got sent two addresses, a site-scoped and a global, for example, could DAD them and DECLINE one by sending just a DUID, an IA option, the address option with the address being declined, and the error option (maybe) with an error code. I expect to raise this during this afternoon's discussion. -- Mark From owner-dhcp-v6@bucknell.edu Wed Aug 8 08:26:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11067; Wed, 8 Aug 2001 08:26:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78CQp302085; Wed, 8 Aug 2001 08:26:51 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78CQf320094 for ; Wed, 8 Aug 2001 08:26:42 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f78CLdf29253 for ; Wed, 8 Aug 2001 05:21:40 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f78CQUO00533 for ; Wed, 8 Aug 2001 05:26:30 -0700 (MST) Message-Id: <200108081226.f78CQUO00533@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: IA option... In-Reply-To: Message from Mark Stapp of "Wed, 08 Aug 2001 13:03:23 BST." <4.3.2.7.2.20010807144904.0385e008@localhost> Date: Wed, 08 Aug 2001 13:26:30 +0100 From: Ted Lemon 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 One method we talked about for encapsulating IAs in the past was to have the IA be an encapsulation of options, one of which would be an IP address option. I'm not sure what happened to that idea, but I thought it was a good one. I tend to agree that the present IA format is a bit problematic, and would prefer the encapsulation approach, but it's a bit late in the game to completely redefine the IA format. I'm not against it, but I'm not exactly for it either - I think we should have a pretty strong consensus that it's the right thing to do before doing it, and if we do do it, we had better do it quickly and not argue too much about it. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 8 09:33:33 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12248; Wed, 8 Aug 2001 09:33:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78DXh307580; Wed, 8 Aug 2001 09:33:43 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78DXU312320 for ; Wed, 8 Aug 2001 09:33:30 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f78DSSf29359 for ; Wed, 8 Aug 2001 06:28:28 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f78DXER00337 for ; Wed, 8 Aug 2001 14:33:14 +0100 (BST) Message-Id: <200108081333.f78DXER00337@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: An issue regarding relay-forward/relay-reply... Date: Wed, 08 Aug 2001 14:33:14 +0100 From: Ted Lemon 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 Bill Squier just pointed out a problem with relay agent messages that I think we should address. We are currently overloading the use of the relay-agent-address field in the relay-forward message. It performs two functions - one is to tell the DHCP server what prefix to use to allocate the client's IP address, and the other is to tell the DHCP server to what address to send its response. We have a hack in DHCPv4 to get around this option - the relay agent subnet selection option and the subnet selection option. However, there's no real justification for this hack. IPv6 has a well-defined API. We can get the IP source address from the packet. So I think we should send the Relay-reply to the IP source address of the Relay-forward, not to the IP address in the relay-agent-address field. I think this is a lot cleaner than what we're doing now. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 8 09:56:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12731; Wed, 8 Aug 2001 09:56:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78DuZ308246; Wed, 8 Aug 2001 09:56:35 -0400 (EDT) Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78DuP326445 for ; Wed, 8 Aug 2001 09:56:25 -0400 (EDT) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.69.24.12]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id f78DuOY23207 for ; Wed, 8 Aug 2001 06:56:24 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.10.1/8.10.1) with ESMTP id f78Du8K11903 for ; Wed, 8 Aug 2001 06:56:08 -0700 (PDT) Received: from MJS-W2K.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id GAA28136 for ; Wed, 8 Aug 2001 06:56:07 -0700 (PDT) Message-Id: <4.3.2.7.2.20010808145228.03961120@localhost> X-Sender: mjs@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 08 Aug 2001 14:56:47 +0100 To: DHCPv6 discussion list From: Mark Stapp Subject: Re: IA option... In-Reply-To: <200108081226.f78CQUO00533@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010807144904.0385e008@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Yes, I'm not trying to pick nits about this. I'm concerned that the existing decision is just my not be the right, and success in representing this information is fundamental to the success of the protocol going forward. I agree that we should converge quickly. -- Mark At 01:26 PM 8/8/2001 +0100, you wrote: >One method we talked about for encapsulating IAs in the past was to >have the IA be an encapsulation of options, one of which would be an >IP address option. I'm not sure what happened to that idea, but I >thought it was a good one. I tend to agree that the present IA >format is a bit problematic, and would prefer the encapsulation >approach, but it's a bit late in the game to completely redefine the >IA format. I'm not against it, but I'm not exactly for it either - I >think we should have a pretty strong consensus that it's the right >thing to do before doing it, and if we do do it, we had better do it >quickly and not argue too much about it. > > _MelloN_ From owner-dhcp-v4@bucknell.edu Wed Aug 8 11:05:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14404 for ; Wed, 8 Aug 2001 11:05:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78F1m300061; Wed, 8 Aug 2001 11:01:49 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78F1e326273 for ; Wed, 8 Aug 2001 11:01:40 -0400 (EDT) Received: from BarrFS9RB01 (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with SMTP id A776A3190C; Wed, 8 Aug 2001 08:01:21 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv4 discussion list Cc: "DHCPv4 discussion list" Subject: Request for information about vendor-specific options Date: Wed, 8 Aug 2001 08:01:12 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 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 In the DHC working group meeting in London, Ralph Droms asked if we could consolidate the vendor-specific options implemented or supported by various vendors of DHCP clients, servers, relay agents, and ancillary elements (such as packet sniffers/decoders) which will become an informational RFC, that I imagine would be updated 1 or 2 times per year as implementations change. My request is that if you know of any non-proprietary vendor-specific options, would you please send them to me, following the option description in RFC2133, including the vendor and product identification, so that I can gather them together before the Salt Lake City working groups meeting in December. Thanks in advance for your help! --Barr From owner-dhcp-v4@bucknell.edu Wed Aug 8 11:13:53 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14643 for ; Wed, 8 Aug 2001 11:13:53 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78FE7300241; Wed, 8 Aug 2001 11:14:07 -0400 (EDT) Received: from gidget.incognito.com ([207.102.214.80]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78FDx330302 for ; Wed, 8 Aug 2001 11:13:59 -0400 (EDT) Received: by gidget.incognito.com with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 08:14:22 -0700 Message-ID: <4FB49E60CFBA724E88867317DAA3D198EFCC@homer.incognito.com.> From: "Kostur, Andre" To: DHCPv4 discussion list Subject: RE: Request for information about vendor-specific options Date: Wed, 8 Aug 2001 08:15:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1201C.E5799C50" Reply-To: Andre@incognito.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1201C.E5799C50 Content-Type: text/plain; charset="iso-8859-1" > -----Original Message----- > From: Barr Hibbs [mailto:Barr.Hibbs@Nominum.com] > Sent: Wednesday, August 8, 2001 8:01 AM > To: DHCPv4 discussion list > Cc: DHCPv4 discussion list > Subject: Request for information about vendor-specific options > > My request is that if you know of any non-proprietary vendor-specific > options, would you please send them to me, following the > option description > in RFC2133, including the vendor and product identification, > so that I can > gather them together before the Salt Lake City working groups > meeting in > December. Not to be picky, but what does RFC 2133 (Basic Socket Interface Extensions for IPv6) have to do with vendor-specific options? :) Did you mean RFC 2132? ------_=_NextPart_001_01C1201C.E5799C50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Request for information about vendor-specific = options

> -----Original Message-----
> From: Barr Hibbs [mailto:Barr.Hibbs@Nominum.com= ]
> Sent: Wednesday, August 8, 2001 8:01 AM
> To: DHCPv4 discussion list
> Cc: DHCPv4 discussion list
> Subject: Request for information about = vendor-specific options
>
> My request is that if you know of any = non-proprietary vendor-specific
> options, would you please send them to me, = following the
> option description
> in RFC2133, including the vendor and product = identification,
> so that I can
> gather them together before the Salt Lake City = working groups
> meeting in
> December.

Not to be picky, but what does RFC 2133 (Basic Socket = Interface Extensions for IPv6) have to do with vendor-specific options? = :)  Did you mean RFC 2132?

------_=_NextPart_001_01C1201C.E5799C50-- From owner-dhcp-v4@bucknell.edu Wed Aug 8 11:19:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14851 for ; Wed, 8 Aug 2001 11:19:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78FJu327581; Wed, 8 Aug 2001 11:19:56 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78FJi315967 for ; Wed, 8 Aug 2001 11:19:44 -0400 (EDT) Received: from BarrFS9RB01 (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with SMTP id 128803190C; Wed, 8 Aug 2001 08:19:28 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv4 discussion list Subject: RE: Request for information about vendor-specific options Date: Wed, 8 Aug 2001 08:19:18 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C11FE2.D1F50410" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4FB49E60CFBA724E88867317DAA3D198EFCC@homer.incognito.com.> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C11FE2.D1F50410 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Request for information about vendor-specific optionsoops! Thanks for picking this up... I really did mean RFC2132.... --Barr -----Original Message----- From: Kostur, Andre [mailto:Andre@incognito.com] Sent: Wednesday, August 08, 2001 08:15 Not to be picky, but what does RFC 2133 (Basic Socket Interface Extensions for IPv6) have to do with vendor-specific options? :) Did you mean RFC 2132? ------=_NextPart_000_0005_01C11FE2.D1F50410 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Request for information about vendor-specific = options
oops!   Thanks for picking this = up...  I=20 really did mean RFC2132....
 
--Barr
 
 
 -----Original Message-----
From: Kostur, Andre=20 [mailto:Andre@incognito.com]
Sent: Wednesday, August 08, 2001=20 08:15

Not to be picky, but what does RFC 2133 (Basic = Socket=20 Interface Extensions for IPv6) have to do with vendor-specific = options?=20 :)  Did you mean RFC 2132?

------=_NextPart_000_0005_01C11FE2.D1F50410-- From owner-dhcp-v6@bucknell.edu Wed Aug 8 13:41:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18067; Wed, 8 Aug 2001 13:41:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78Hex313346; Wed, 8 Aug 2001 13:40:59 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78Hes316435 for ; Wed, 8 Aug 2001 13:40:54 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f78HZpf29864 for ; Wed, 8 Aug 2001 10:35:52 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f78HeMR01182 for ; Wed, 8 Aug 2001 18:40:22 +0100 (BST) Message-Id: <200108081740.f78HeMR01182@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Discussion on configuring stateless clients. Date: Wed, 08 Aug 2001 18:40:22 +0100 From: Ted Lemon 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 We had a big discussion about configuring stateless clients (clients with no persistent storage) in the WG meeting today. The idea is that we'd like a stateless client to get the same IP address every time, but we're not sure how to do that. One point that was raised is that we need to make sure that a stateless client doesn't generate a new IAID every time it boots, because if it reboots a lot that could consume addresses without limit. One solution is to just insist that a stateless client implementation be written in such a way that as long as the physical configuration of the device doesn't change, the client MUST always generate the same IAIDs. My objection to this is that it's complicated to specify on the client side, and I'm afraid client implementors won't implement it. Another solution is to have the client send a message saying "I don't remember my previous state - does any server remember it?" In this case, a server that remembered previous state for the client could reply with the IA(s) that it remembers. The client could then choose the server that remembered it. An objection was raised that we have covered this ground before, with the 'R' bit, which meant "I've forgotten my state - you please forget it too." Another objection was that this is a big can of worms that we don't want to open right now. We need to solve this problem. Either solution will work. I'm leery of specifying anything complicated on the client, because client implementors frequently get things wrong, and are much less likely to actually talk to someone who groks DHCP before deploying their broken client. So I favor the solution of having the client able to ask the server what its state is. I'd like to know what others think about this. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 8 14:02:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18373; Wed, 8 Aug 2001 14:02:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78I3C305229; Wed, 8 Aug 2001 14:03:12 -0400 (EDT) Received: from INET-VRS-07.redmond.corp.microsoft.com ([131.107.3.51]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78I3A320276 for ; Wed, 8 Aug 2001 14:03:10 -0400 (EDT) Received: from 157.54.9.101 by INET-VRS-07.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Wed, 08 Aug 2001 11:02:54 -0700 Received: from red-imc-02.redmond.corp.microsoft.com ([157.54.9.107]) by inet-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Aug 2001 11:02:37 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-02.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Aug 2001 11:02:25 -0700 Received: from win-msg-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.52]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 8 Aug 2001 11:01:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5701.0 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: Discussion on configuring stateless clients. Date: Wed, 8 Aug 2001 11:01:30 -0700 Message-ID: <2E33960095B58E40A4D3345AB9F65EC162B724@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Thread-Topic: Discussion on configuring stateless clients. thread-index: AcEgMxJFDKEp9ehhQgOHTTdKlCMfxgAAHRAg From: "Thirumalesh Bhat" To: DHCPv6 discussion list X-OriginalArrivalTime: 08 Aug 2001 18:01:30.0812 (UTC) FILETIME=[27051FC0:01C12034] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f78I3B318350 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit I think this topic needs further discussion. (a) What are the scenarios where the client has to get the same IP every time? (b) If the client says that I don't know my state to the server, it has to identify itself somehow to the server. This worked on V4 based on client id or hardware address. What is the mechanism for the client to identify itself in v6? (c) when can the client say that it has forgotten its state? Is it when it is doing a solicit or when doing a request? thx -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, August 08, 2001 10:40 AM To: DHCPv6 discussion list Subject: Discussion on configuring stateless clients. We had a big discussion about configuring stateless clients (clients with no persistent storage) in the WG meeting today. The idea is that we'd like a stateless client to get the same IP address every time, but we're not sure how to do that. One point that was raised is that we need to make sure that a stateless client doesn't generate a new IAID every time it boots, because if it reboots a lot that could consume addresses without limit. One solution is to just insist that a stateless client implementation be written in such a way that as long as the physical configuration of the device doesn't change, the client MUST always generate the same IAIDs. My objection to this is that it's complicated to specify on the client side, and I'm afraid client implementors won't implement it. Another solution is to have the client send a message saying "I don't remember my previous state - does any server remember it?" In this case, a server that remembered previous state for the client could reply with the IA(s) that it remembers. The client could then choose the server that remembered it. An objection was raised that we have covered this ground before, with the 'R' bit, which meant "I've forgotten my state - you please forget it too." Another objection was that this is a big can of worms that we don't want to open right now. We need to solve this problem. Either solution will work. I'm leery of specifying anything complicated on the client, because client implementors frequently get things wrong, and are much less likely to actually talk to someone who groks DHCP before deploying their broken client. So I favor the solution of having the client able to ask the server what its state is. I'd like to know what others think about this. _MelloN_ From owner-dhcp-v6@bucknell.edu Wed Aug 8 17:03:45 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21490; Wed, 8 Aug 2001 17:03:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78L3p307913; Wed, 8 Aug 2001 17:03:52 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78L3d304870 for ; Wed, 8 Aug 2001 17:03:43 -0400 (EDT) Received: from BarrFS9RB01 (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with SMTP id 3D6F73190E for ; Wed, 8 Aug 2001 14:03:22 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Discussion on configuring stateless clients. Date: Wed, 8 Aug 2001 14:03:21 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: <200108081740.f78HeMR01182@grosse.bisbee.fugue.com> Importance: Normal Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Ted Lemon > Sent: Wednesday, August 08, 2001 10:40 *Snip!* > One point that was raised is that we need to make sure that a > stateless client doesn't generate a new IAID every time it boots, > because if it reboots a lot that could consume addresses without > limit. One solution is to just insist that a stateless client > implementation be written in such a way that as long as the physical > configuration of the device doesn't change, the client MUST always > generate the same IAIDs. > > My objection to this is that it's complicated to specify on the client > side, and I'm afraid client implementors won't implement it. > ...How about some wording such as, "If a stateless client implementation is capable of generating a repeatable IAID (for example, one algorithmically derived from a fixed entity such as a system serial number burned into ROM) the client MUST do so, else a stateless client MUST be capable of generating a message to the server requesting it's (the client's) previous state. If a stateless client does not receive a message from a server with it's (the client's) previous state, the client MUST NOT randomly select an IAID for use, but remain silent." I put that last bit in to actively discourage client implementors from taking the lazy way out and dumping all responsibility on the server for dealing with statelessness, but then rudely insisting on a bit of self-configuration when they cannot find a cooperative server. > Another solution is to have the client send a message saying "I don't > remember my previous state - does any server remember it?" In this > case, a server that remembered previous state for the client could > reply with the IA(s) that it remembers. The client could then choose > the server that remembered it. > ...this requires a means of resolution if there is no server with knowledge of the previous state -- my clear preference is to prohibit connectivity if no server answers. > An objection was raised that we have covered this ground before, with > the 'R' bit, which meant "I've forgotten my state - you please forget > it too." Another objection was that this is a big can of worms that > we don't want to open right now. > ...this one really works only if the client is capable of generating a reasonable IAID itself, so I'd vote against this one at the moment.... > We need to solve this problem. Either solution will work. I'm > leery of specifying anything complicated on the client, because client > implementors frequently get things wrong, and are much less likely to > actually talk to someone who groks DHCP before deploying their broken > client. So I favor the solution of having the client able to ask the > server what its state is. I'd like to know what others think about > this. > ...right, if the server is incapable of regenerating an IAID from something (relatively) fixed, then asking for it is the better of the two approaches, at least to my mind --Barr From owner-dhcp-v6@bucknell.edu Wed Aug 8 19:29:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA23592; Wed, 8 Aug 2001 19:29:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f78NTg301106; Wed, 8 Aug 2001 19:29:42 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f78NTd332643 for ; Wed, 8 Aug 2001 19:29:39 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f78NTdp19612 for ; Wed, 8 Aug 2001 18:29:39 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f78NTcs15166 for ; Wed, 8 Aug 2001 18:29:38 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Aug 08 18:29:37 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 8 Aug 2001 18:29:37 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69903F37@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Discussion on configuring stateless clients. Date: Wed, 8 Aug 2001 18:29:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12061.FB5F7C20" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12061.FB5F7C20 Content-Type: text/plain; charset="iso-8859-1" In thinking about this some: Why is it difficult to state this for client implementations? Simply say "If a client has no permanent storage to store IAIDs that it was using across boots, it MUST assign IAIDs using a consistent pattern every time it boots. For example, 0, 1, 2, ....". I'm not sure why configuration changes matter. After all, if the client has no way to storage anything across boots, how can it know whether the configuration changed? Why would it make any difference anyway? Next, >Another solution is to have the client send a message saying "I don't >remember my previous state - does any server remember it?" Seems like Solicit/Advertise would be a neat way to do this. But, I haven't thought of any clever way to do this since if the client doesn't include an IAID option in the Solicit, what would a server send back in the Advertise to communicate, yes I can assign you addresses. So, it is a catch-22 unless multiple Solicit/Advertise are done. I still think the solution is to specify the behavoir for the client. Use the same IAID space. One item that we should address in the -20 draft is some recommendations on when to assign new IAID values and when to keep old ones (or perhaps when a client or server may 'delete' old ones). For example, I would suggest that we say "A server may NOT delete all knowledge of a client's IAID until there are no more valid addresses for the IAID (ie, the valid lifetime has expired)." On a different issue, suppose a client has held onto lots of IAIDs that it has accummulated over time (as it has moved from network to network). I would assume it is acceptable for that client, when it (re)boots or detects a network change, to Confirm *ALL* of the IAIDs it has (either in one or multiple messages). So, this has an implication for whether clients want to retain "old" IAIDs or not. And, what they might do with them if they do. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, August 08, 2001 1:40 PM To: DHCPv6 discussion list Subject: Discussion on configuring stateless clients. We had a big discussion about configuring stateless clients (clients with no persistent storage) in the WG meeting today. The idea is that we'd like a stateless client to get the same IP address every time, but we're not sure how to do that. One point that was raised is that we need to make sure that a stateless client doesn't generate a new IAID every time it boots, because if it reboots a lot that could consume addresses without limit. One solution is to just insist that a stateless client implementation be written in such a way that as long as the physical configuration of the device doesn't change, the client MUST always generate the same IAIDs. My objection to this is that it's complicated to specify on the client side, and I'm afraid client implementors won't implement it. Another solution is to have the client send a message saying "I don't remember my previous state - does any server remember it?" In this case, a server that remembered previous state for the client could reply with the IA(s) that it remembers. The client could then choose the server that remembered it. An objection was raised that we have covered this ground before, with the 'R' bit, which meant "I've forgotten my state - you please forget it too." Another objection was that this is a big can of worms that we don't want to open right now. We need to solve this problem. Either solution will work. I'm leery of specifying anything complicated on the client, because client implementors frequently get things wrong, and are much less likely to actually talk to someone who groks DHCP before deploying their broken client. So I favor the solution of having the client able to ask the server what its state is. I'd like to know what others think about this. _MelloN_ ------_=_NextPart_001_01C12061.FB5F7C20 Content-Type: text/html; charset="iso-8859-1" RE: Discussion on configuring stateless clients.

In thinking about this some:

Why is it difficult to state this for client implementations? Simply
say "If a client has no permanent storage to store IAIDs that it was
using across boots, it MUST assign IAIDs using a consistent pattern
every time it boots. For example, 0, 1, 2, ....".

I'm not sure why configuration changes matter. After all, if the client
has no way to storage anything across boots, how can it know whether the
configuration changed? Why would it make any difference anyway?

Next,

>Another solution is to have the client send a message saying "I don't
>remember my previous state - does any server remember it?" 

Seems like Solicit/Advertise would be a neat way to do this. But, I haven't
thought of any clever way to do this since if the client doesn't include an
IAID option in the Solicit, what would a server send back in the Advertise
to communicate, yes I can assign you addresses. So, it is a catch-22 unless
multiple Solicit/Advertise are done.

I still think the solution is to specify the behavoir for the client. Use
the same IAID space.

One item that we should address in the -20 draft is some recommendations on
when to assign new IAID values and when to keep old ones (or perhaps when
a client or server may 'delete' old ones).

For example, I would suggest that we say "A server may NOT delete all knowledge
of a client's IAID until there are no more valid addresses for the IAID (ie,
the valid lifetime has expired)."


On a different issue, suppose a client has held onto lots of IAIDs that it has
accummulated over time (as it has moved from network to network). I would assume
it is acceptable for that client, when it (re)boots or detects a network change,
to Confirm *ALL* of the IAIDs it has (either in one or multiple messages). So,
this has an implication for whether clients want to retain "old" IAIDs or not.
And, what they might do with them if they do.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]
Sent: Wednesday, August 08, 2001 1:40 PM
To: DHCPv6 discussion list
Subject: Discussion on configuring stateless clients.



We had a big discussion about configuring stateless clients (clients
with no persistent storage) in the WG meeting today.  The idea is that
we'd like a stateless client to get the same IP address every time,
but we're not sure how to do that.

One point that was raised is that we need to make sure that a
stateless client doesn't generate a new IAID every time it boots,
because if it reboots a lot that could consume addresses without
limit.   One solution is to just insist that a stateless client
implementation be written in such a way that as long as the physical
configuration of the device doesn't change, the client MUST always
generate the same IAIDs.

My objection to this is that it's complicated to specify on the client
side, and I'm afraid client implementors won't implement it.

Another solution is to have the client send a message saying "I don't
remember my previous state - does any server remember it?"   In this
case, a server that remembered previous state for the client could
reply with the IA(s) that it remembers.   The client could then choose
the server that remembered it.

An objection was raised that we have covered this ground before, with
the 'R' bit, which meant "I've forgotten my state - you please forget
it too."   Another objection was that this is a big can of worms that
we don't want to open right now.

We need to solve this problem.   Either solution will work.   I'm
leery of specifying anything complicated on the client, because client
implementors frequently get things wrong, and are much less likely to
actually talk to someone who groks DHCP before deploying their broken
client.   So I favor the solution of having the client able to ask the
server what its state is.   I'd like to know what others think about
this.

                               _MelloN_

------_=_NextPart_001_01C12061.FB5F7C20-- From owner-dhcp-v6@bucknell.edu Thu Aug 9 03:59:49 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16746; Thu, 9 Aug 2001 03:59:49 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f797xw321854; Thu, 9 Aug 2001 03:59:58 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f797xl315995 for ; Thu, 9 Aug 2001 03:59:47 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f797shf00685 for ; Thu, 9 Aug 2001 00:54:44 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f797xGD00328 for ; Thu, 9 Aug 2001 08:59:16 +0100 (BST) Message-Id: <200108090759.f797xGD00328@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Discussion on configuring stateless clients. In-Reply-To: Message from "Thirumalesh Bhat" of "Wed, 08 Aug 2001 11:01:30 PDT." <2E33960095B58E40A4D3345AB9F65EC162B724@win-msg-01.wingroup.windeploy.ntdev.microsoft.com> Date: Thu, 09 Aug 2001 08:59:16 +0100 From: Ted Lemon 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 > (a) What are the scenarios where the client has to get the same IP every > time? E.g., a laser printer with an ethernet card. You don't want it to change its IP address every time it's power cycled, because the DNS may not follow quickly enough, and users may lose access to the service unexpectedly. > (b) If the client says that I don't know my state to the server, it has > to identify itself somehow to the server. This worked on V4 based on > client id or hardware address. What is the mechanism for the client to > identify itself in v6? The DUID. The client sends a DUID but no IAID, and the server, if it remembers an IA for the DUID, sends the IAID back to the client. The client can then choose among DHCP Advertise messages based on whether they contain IAIDs. > (c) when can the client say that it has forgotten its state? Is it when > it is doing a solicit or when doing a request? Solicit only (IMHO). _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Aug 9 04:09:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16903; Thu, 9 Aug 2001 04:09:18 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7989s300845; Thu, 9 Aug 2001 04:09:54 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7989g302937 for ; Thu, 9 Aug 2001 04:09:43 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7984cf00711; Thu, 9 Aug 2001 01:04:39 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7989AD00382; Thu, 9 Aug 2001 09:09:10 +0100 (BST) Message-Id: <200108090809.f7989AD00382@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: Discussion on configuring stateless clients. In-Reply-To: Message from "Barr Hibbs" of "Wed, 08 Aug 2001 14:03:21 PDT." Date: Thu, 09 Aug 2001 09:09:03 +0100 From: Ted Lemon 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 > ...How about some wording such as, "If a stateless client implementation is > capable of generating a repeatable IAID (for example, one algorithmically > derived from a fixed entity such as a system serial number burned into ROM) > the client MUST do so, else a stateless client MUST be capable of generating > a message to the server requesting it's (the client's) > previous state. If a stateless client does not receive a > message from a server with it's (the client's) previous state, the client > MUST NOT randomly select an IAID for use, but remain silent." Right. My concern is that a client implementor is going to look at this, not grok it, do the wrong thing, and deploy. I would rather not depend on the client implementor to get this right, based on past experience. > ...this requires a means of resolution if there is no server with knowledge > of the previous state -- my clear preference is to prohibit connectivity if > no server answers. Any server willing to give the client an address should answer! _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Aug 9 04:26:52 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17284; Thu, 9 Aug 2001 04:26:52 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f798RQ312784; Thu, 9 Aug 2001 04:27:26 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f798RH302796 for ; Thu, 9 Aug 2001 04:27:17 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f798MDf00722 for ; Thu, 9 Aug 2001 01:22:14 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f798QiD00426 for ; Thu, 9 Aug 2001 09:26:44 +0100 (BST) Message-Id: <200108090826.f798QiD00426@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Discussion on configuring stateless clients. In-Reply-To: Message from "Bernie Volz (EUD)" of "Wed, 08 Aug 2001 18:29:34 CDT." <66F66129A77AD411B76200508B65AC69903F37@eambunt705.ena-east.ericsson.se> Date: Thu, 09 Aug 2001 09:26:44 +0100 From: Ted Lemon 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 > Seems like Solicit/Advertise would be a neat way to do this. But, I haven't > thought of any clever way to do this since if the client doesn't include an > IAID option in the Solicit, what would a server send back in the Advertise > to communicate, yes I can assign you addresses. So, it is a catch-22 unless > multiple Solicit/Advertise are done. We could add an option signifying that the Solicit means "I want you to tell me my state or assign me an address" rather than "I just want to get DHCP information, and don't need an address," which I think is what no IAID means now in an advertise message. > I still think the solution is to specify the behavoir for the client. Use > the same IAID space. I think this is the ideal solution. I am just afraid is is not the right solution given past experience. THe problem is that the cost to the client implementor of doing this wrong is relatively low, so if a mistake is made we may just have to live with it. If we provide the client implementor with an easy way to do this, I think it's more likely to happen, even if it complicates things slightly on the server. I certainly don't mind the extra complexity - I don't think it's very substantial. :'} > For example, I would suggest that we say "A server may NOT delete > all knowledge of a client's IAID until there are no more valid > addresses for the IAID (ie, the valid lifetime has expired)." Sounds like a good plan. Can it be a SHOULD NOT rather than a MUST NOT? > On a different issue, suppose a client has held onto lots of IAIDs > that it has accummulated over time (as it has moved from network to > network). I would assume it is acceptable for that client, when it > (re)boots or detects a network change, to Confirm *ALL* of the IAIDs > it has (either in one or multiple messages). So, this has an > implication for whether clients want to retain "old" IAIDs or not. > And, what they might do with them if they do. I don't really know why clients would make up new IAIDs, other than at the request of an application - what's the scenario you're thinking of here? Are you suggesting that the client should, for example, have a different IAID for each network to which it connects? I'm not sure how that can be made to work, frankly, since it doesn't necessarily know what to network it's connected when it sends a Solicit or Confirm. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Aug 9 04:43:24 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17658; Thu, 9 Aug 2001 04:43:24 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f798hA327686; Thu, 9 Aug 2001 04:43:10 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f798h6324846 for ; Thu, 9 Aug 2001 04:43:06 -0400 (EDT) Received: from BarrFS9RB01 (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with SMTP id 146F73190E for ; Thu, 9 Aug 2001 01:42:50 -0700 (PDT) Reply-To: From: "Barr Hibbs" To: DHCPv6 discussion list Subject: RE: Discussion on configuring stateless clients. Date: Thu, 9 Aug 2001 01:42:50 -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) Importance: Normal In-Reply-To: <200108090826.f798QiD00426@grosse.bisbee.fugue.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit > > I still think the solution is to specify the behavoir for the > client. Use > > the same IAID space. > > I think this is the ideal solution. I am just afraid is is not the > right solution given past experience. THe problem is that the cost > to the client implementor of doing this wrong is relatively low, so if > a mistake is made we may just have to live with it. If we provide > the client implementor with an easy way to do this, I think it's more > likely to happen, even if it complicates things slightly on the > server. I certainly don't mind the extra complexity - I don't think > very substantial. :'} > ...which is why I proposed raising the "cost" to a lazy client implementation by insisting that if they cannot be consistent in their IAID use, they should not be able to continue communicating > > For example, I would suggest that we say "A server may NOT delete > > all knowledge of a client's IAID until there are no more valid > > addresses for the IAID (ie, the valid lifetime has expired)." > > Sounds like a good plan. Can it be a SHOULD NOT rather than a MUST > NOT? > ...SHOULD NOT works for me! --Barr From owner-dhcp-v6@bucknell.edu Thu Aug 9 04:48:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17755; Thu, 9 Aug 2001 04:48:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f798mR315346; Thu, 9 Aug 2001 04:48:27 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f798mJ325280 for ; Thu, 9 Aug 2001 04:48:20 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f798hCf00759; Thu, 9 Aug 2001 01:43:12 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f798lfD00510; Thu, 9 Aug 2001 09:47:41 +0100 (BST) Message-Id: <200108090847.f798lfD00510@grosse.bisbee.fugue.com> To: DHCPv6 discussion list cc: DHCPv6 discussion list Subject: Re: Discussion on configuring stateless clients. In-Reply-To: Message from "Barr Hibbs" of "Thu, 09 Aug 2001 01:42:50 PDT." Date: Thu, 09 Aug 2001 09:47:41 +0100 From: Ted Lemon 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 > ...which is why I proposed raising the "cost" to a lazy client > implementation by insisting that if they cannot be consistent in their IAID > use, they should not be able to continue communicating There's no way to specify this other than by administrative policy, which isn't likely to help us. That is, you can tell the server "only allow the client 5 IAs at a time", for example, but we can't say that in the standard, because the server administrator may need to allow more addresses than that. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Aug 9 04:52:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17818; Thu, 9 Aug 2001 04:52:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f798qf320043; Thu, 9 Aug 2001 04:52:41 -0400 (EDT) Received: from yamato.ccrle.nec.de (yamato.ccrle.nec.de [195.37.70.1]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f798qW329412 for ; Thu, 9 Aug 2001 04:52:33 -0400 (EDT) Received: from citadel.mobility.ccrle.nec.de ([192.168.156.1]) by yamato.ccrle.nec.de (8.11.3/8.10.1) with ESMTP id f798qjI24280 for ; Thu, 9 Aug 2001 10:52:45 +0200 (CEST) Received: by citadel.mobility.ccrle.nec.de (Postfix on SuSE eMail Server 2.0, from userid 30) id CA5A2C112; Thu, 9 Aug 2001 10:42:59 +0200 (CEST) To: DHCPv6 discussion list Subject: Re: Discussion on configuring stateless clients. Message-ID: <997346579.3b724d13bc1f6@citadel.mobility.ccrle.nec.de> Date: Thu, 09 Aug 2001 10:42:59 +0200 (CEST) From: Martin.Stiemerling@ccrle.nec.de References: <200108090759.f797xGD00328@grosse.bisbee.fugue.com> In-Reply-To: <200108090759.f797xGD00328@grosse.bisbee.fugue.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.3 X-Originating-IP: 192.168.102.83 Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Hi, the comments are inline. Quoting Ted Lemon > > > (a) What are the scenarios where the client has to get the same IP > every > > time? > > E.g., a laser printer with an ethernet card. You don't want it to > change its IP address every time it's power cycled, because the DNS > may not follow quickly enough, and users may lose access to the > service unexpectedly. And there are a lot of LANs where the system administrator likes it, that every computer has always the same IP address. Especially if he doesn't like dynamic DNS... > [...] > > The DUID. The client sends a DUID but no IAID, and the server, if it > remembers an IA for the DUID, sends the IAID back to the client. The > client can then choose among DHCP Advertise messages based on whether > they contain IAIDs. > I always thought, that the DUID is the central information on which the server relies to assign data. So it seems a good idea to link the available IAIDs together with the DUID. > > (c) when can the client say that it has forgotten its state? Is it > when > > it is doing a solicit or when doing a request? > > Solicit only (IMHO). In the solicit, because it is the first message after a crash/reboot. Martin P.S. Yesterday I asked Ralph Droms about who is implementing DHCPv6 and he isn't aware who is doing so. The reason for this is, that I'm currently implementing the DHCPv6 stuff and I'm looking for future test partners. From owner-dhcp-v6@bucknell.edu Thu Aug 9 04:57:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17915; Thu, 9 Aug 2001 04:57:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f798vd302746; Thu, 9 Aug 2001 04:57:39 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f798va319767 for ; Thu, 9 Aug 2001 04:57:36 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-24.cisco.com [10.82.80.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id EAA20103 for ; Thu, 9 Aug 2001 04:57:15 -0400 (EDT) Message-Id: <4.3.2.7.2.20010809094123.01ffbe88@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Aug 2001 09:44:44 +0100 To: DHCPv6 discussion list From: Ralph Droms Subject: Notes from DHCPv6 discussion at WG meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here are my raw notes from the DHC WG discussion on DHCPv6. Those of you who were at the discussion will recognize these notes as the notes I was editing in real time during the discussion. One major result of the discussion is that Ted Lemon, Mark Stapp and Bernie Volz have volunteered to redesign the IA option format and document that design with draft-ready text by 8/24. Because of that effort, several related issues have been deferred for resolution in the Lemon-Stapp-Volz IA design or after the design has been submitted. - Ralph ----- * Mark Stapp suggests a number of problems have arisen because of "C struct"-like structure of IA option. Mark suggests a solution like that used in failover: IP address marks a "frame", in which options specific to that address follow the IP address; IA option then marks start of a frame that carries options specific to the IA. WG consensus: Bernie, Mark and Ted will develop text defining new IA structure. The draft text will be complete and submitted to the WG for review by 8/24. WG will review and definition will be integrated into -20 draft if approved by WG. * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Servers will only assign complete addresses and not prefixes (e.g., to be used by the client for stateless autoconfiguration) WG consensus: yes; prefix advertisement is handled through ND * Modify IA option so that all addresses in an IA are "regular" or "temporary". Modify text so that client indicates types of addresses to be assigned by sending appropriate IAs. Server then fills in each IA with assigned addresses. Open issue - hold for new IA definition (WG has already agreed that client can ask for regular or temporary addresses) * Define separate IA option for temporary addresses rather than indicate the type of address in a single IA option Open issue - hold for new IA definition * How and when does the client use DAD on addresses in Advertise and Reply messages? WG consensus: Client does DAD on addresses in Reply message and responds with Decline if addresses unacceptable (e.g., already in use) * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Should we consider a "quick" handshake for allowing a client to assign an address in a single exchange of two messages? WG consensus: defer for later reconsideration * Tighten up text on T1/T2 to require T1/T2 occur prior to expiration of lifetimes of addresses in IA; no need to describe default as T1/T2 are fields in IA header and must be supplied by server WG consensus: Mark, Ted and Bernie will do it... Open issue: what about selection of T1/T2 with temporary addresses and with addresses whose lifetimes won't be extended; e.g. addresses to be deprecated/discarded due to renumbering. Notes: T1/T2 are independent of "regular"/"temporary" characteristic. T1/T2 might even be used for clients that do not have any assigned addresses for periodic renewal of other information * The semantics of the use of IA must be clarified (see Volz message of 7/19). In particular, what are the semantics of a Request containing an IA that the client has previously sent to the server? What are the semantics of a Request containing a new IA? Open issue: rules about when to reuse old IA or use new IA WG consensus: When the client submits an IA that the server has seen in the past, the server should interpret the request as a request for the current state of the existing IA. When the client submits an IA that the server has not seen before, the server should interpret the request as a request for additional addresses to be assigned to the new IA. Discussion to continue on WG mailing list * Simplify Release and Decline so the all of the addresses in an IA are released or declined, rather than allowing the client to release or decline just some addresses. WG consensus: Wait for Bernie to fix in IA definition * Add "NAK" function: If the server finds that the prefix on one or more IP addresses in any IA in the {Request,Confirm,Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" error code. Add text allowing client to ignore "NoPrefixMatch" from other servers if ACK received from at least one server. * Define DUID to be one of: - Link-layer address plus time - Vendor-assigned unique ID - Link-layer address - IMSI - IMEI WG consensus: yes; based on text submitted by Lemon with extensions from subsequent WG discussion * Use IPsec for secure agent/server communication WG consensus: yes; add text to draft * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes; should allow inclusion of text message * Tighten up language for unicasting Reconfigure-Init; in particular, the server may not have an appropriate address to use to send the message to the client. WG consensus: yes * Reply to a Confirm should be a simple ACK/NAK without changing any values in options WG consensus: Discussion to be taken to mailing list Note: check to make sure there is text in the draft describing behavior if no response is heard to a Confirm * Reply to Decline or Release should carry no options WG consensus: yes * Restrict options in Decline or Release to IA with text to allow other options in the future WG consensus: no; this is an overspecification * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond * Include only options specifically mentioned in the text in the DHCPv6 spec; move others to second doc or separate appendix WG consensus: anything we have consensus on stays; anything else gets punted to a separate draft. * Add 'secs' field to fixed header WG consensus: if client retransmits, MUST send option called "milliseconds" * Make the preference field an option WG consensus: yes * Describe message transmission and retransmission in a separate section of the spec and reference that text throughout the remainder of the spec WG consensus: yes * Discard the client unicast or recheck the entire spec for consistency in reference to message transmission WG consensus: yes, authors to fix spec * Remove client link-local address from client message header. Agent can then determine link-local from source (IP header) in client message and insert into agent->server message. Server responds to source from IP header (whether agent or client). WG consensus: Yes From owner-dhcp-v6@bucknell.edu Thu Aug 9 05:09:18 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18189; Thu, 9 Aug 2001 05:09:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7999F322509; Thu, 9 Aug 2001 05:09:15 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f79993312575; Thu, 9 Aug 2001 05:09:03 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-24.cisco.com [10.82.80.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA20527; Thu, 9 Aug 2001 05:08:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20010809100118.01fea008@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Aug 2001 10:07:05 +0100 To: DHCPv6 discussion list From: Ralph Droms Subject: Minutes from DHCPv4 discussion at WG meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks to Stuart Cheshire for taking the notes on which this summary is based. Please respond with comments, additions, corrections by 8/13 so I can submit and publish the minutes. The final minutes will include both these notes from DHCPv4 and the notes from the DHCPv6 discussion I previously posted to the DHCPv6 mailing list. - Ralph Ralph gave a summary of WG status and activities: The DHCP Reconfigure Extension has been reviewed by IESG; it was subsequently revised and resubmitted by the authors. The draft is now waiting IESG re-review. Ralph asked if there are any existing or planned implementations of DHCP Authnetication. None are existing. One person said they had a planned implementation. Several drafts are ready for WG Last Call: * Encoding Long DHCP Options * The Classless Static Route Option for DHCP * DHCP Domain Search Option * The DHCP Client FQDN Option * Resolution of DNS Name Conflicts Among DHCP Clients * Subnet Selection sub-option for the Relay Agent Information Option * Addition of Device Class to Agent Options Ralph will initiate WG last call for these drafts after IETF-51. Ralph asked for someone to volunteer to write a document listing all known DHCP vendor options. Barr Hibbs volunteered. Failover Protocol, Mark Stapp ------------------------------------ Mark asked whether draft is ready for last-call. The hum from WG indicated the WG thinks it is. Ralph will initiate a WG last call after IETF-51. 802.1X WEP Key Management using DHCP, Bill Arbaugh -------------------------------------------------- Bill's draft proposed doing key management via a DHCP option. Every time client renews its lease it gets a new WEP key. This could allow the WEP key to be changed fairly frequently - e.g. every five minutes. Stuart Cheshire asked if this functions duplicates 802.1X functionality? Answer: Yes, but 802.1X is not widespread yet, and we want this now. However, it's not clear how long this will take to get deployed. For example, the Mac OS 9 DHCP client would need to be updated to request this new option, and no new updates are planned for OS 9 now that all Apple's efforts are focussed on OS X. In contrast, an 802.1X client can be implemented by any third-party without any special support from the OS, so it is likely that 802.1X could be implemented far quicker than this DHCP extension. Mark Stapp thought the draft was worth pursuing. Erik Nordmark expressed concern that pursuing this option confuses users by providing two ways to do key management, and ultimately slows adoption of either. It is better to focus efforts on deploying 802.1X. Show of hands for who would like work to continue on this draft: Only Ralph raised his hand. DHCP mDNS Enable Option, Erik Guttman -------------------------------------- Erik presented a summary of client mDNS default behavior and the function of a proposed option to enable the use of mDNS. Stuart Cheshire pointed out that the proposed default behaviour, if the DHCP server does not support this option, is that Multicast DNS should not be used. This basically means that today, Multicast DNS will not be allowed to work on any network where DHCP servers are present, which in turn means that there is no incentive for anyone to implement Multicast DNS. Resolution? LDAP Schema for DHCP, Vijay Nanjundaswamy ----------------------------------- Vijay K. N. spoke about the latest LDAP schema definition. Mark Stapp noted that including lease information has huge performance implications. Ted Lemon gave the opinion that if the schema can be defined to accommodate the DHCP server data and work at some scale, then the schema is valid and the performance problem should be tackled separately. The schema recommends isolating leases in a container object to improve manageability. There is a server-specific extension that holds information that is only relevant to one particular implementation server. Mark Stapp asked if the authors had surveyed DHCP implementations to see if there is enough common configuration or operational information to make an interesting schema. Erik Guttman notes that the DMTF stays away details like this schema for individual services. Vijay identified an action item to survey existing servers to determine common functions. Ted Lemon pointed out that claiming improved reliability through the use of and LDAP store just moves the single point of failure from the DHCP server to the LDAP server. Mark Stapp asked if there is enough commonality between the configuration options and features of different DHCP Servers for a common LDAP schema to be useful? Authors responded that they will do a summary of existing servers to determine applicability of a common LDPA schema. Erik Guttman asked who actually wants this? Ted Lemon suggested that the authors should try implementing it first before talking about publishing it as an RFC. The authors have received comments from the WG and modified the draft according to those comments (where appropriate). The authors have also made some other changes independent of WG feedback. VPN Identifier sub-option for the Relay Agent Information Option, DHCP VPN Information option Mark Stapp ----------------------------------------------------------------- These drafts carry similar information through a DHCP option and a relay agent sub-option. The drafts give two encodings for VPN identifier: vrfs and RFC2685 vpn id. No response from WG. From owner-dhcp-v4@bucknell.edu Thu Aug 9 05:12:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18254 for ; Thu, 9 Aug 2001 05:12:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7999F302844; Thu, 9 Aug 2001 05:09:15 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f79993312575; Thu, 9 Aug 2001 05:09:03 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-24.cisco.com [10.82.80.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id FAA20527; Thu, 9 Aug 2001 05:08:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20010809100118.01fea008@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Aug 2001 10:07:05 +0100 To: DHCPv4 discussion list From: Ralph Droms Subject: Minutes from DHCPv4 discussion at WG meeting Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks to Stuart Cheshire for taking the notes on which this summary is based. Please respond with comments, additions, corrections by 8/13 so I can submit and publish the minutes. The final minutes will include both these notes from DHCPv4 and the notes from the DHCPv6 discussion I previously posted to the DHCPv6 mailing list. - Ralph Ralph gave a summary of WG status and activities: The DHCP Reconfigure Extension has been reviewed by IESG; it was subsequently revised and resubmitted by the authors. The draft is now waiting IESG re-review. Ralph asked if there are any existing or planned implementations of DHCP Authnetication. None are existing. One person said they had a planned implementation. Several drafts are ready for WG Last Call: * Encoding Long DHCP Options * The Classless Static Route Option for DHCP * DHCP Domain Search Option * The DHCP Client FQDN Option * Resolution of DNS Name Conflicts Among DHCP Clients * Subnet Selection sub-option for the Relay Agent Information Option * Addition of Device Class to Agent Options Ralph will initiate WG last call for these drafts after IETF-51. Ralph asked for someone to volunteer to write a document listing all known DHCP vendor options. Barr Hibbs volunteered. Failover Protocol, Mark Stapp ------------------------------------ Mark asked whether draft is ready for last-call. The hum from WG indicated the WG thinks it is. Ralph will initiate a WG last call after IETF-51. 802.1X WEP Key Management using DHCP, Bill Arbaugh -------------------------------------------------- Bill's draft proposed doing key management via a DHCP option. Every time client renews its lease it gets a new WEP key. This could allow the WEP key to be changed fairly frequently - e.g. every five minutes. Stuart Cheshire asked if this functions duplicates 802.1X functionality? Answer: Yes, but 802.1X is not widespread yet, and we want this now. However, it's not clear how long this will take to get deployed. For example, the Mac OS 9 DHCP client would need to be updated to request this new option, and no new updates are planned for OS 9 now that all Apple's efforts are focussed on OS X. In contrast, an 802.1X client can be implemented by any third-party without any special support from the OS, so it is likely that 802.1X could be implemented far quicker than this DHCP extension. Mark Stapp thought the draft was worth pursuing. Erik Nordmark expressed concern that pursuing this option confuses users by providing two ways to do key management, and ultimately slows adoption of either. It is better to focus efforts on deploying 802.1X. Show of hands for who would like work to continue on this draft: Only Ralph raised his hand. DHCP mDNS Enable Option, Erik Guttman -------------------------------------- Erik presented a summary of client mDNS default behavior and the function of a proposed option to enable the use of mDNS. Stuart Cheshire pointed out that the proposed default behaviour, if the DHCP server does not support this option, is that Multicast DNS should not be used. This basically means that today, Multicast DNS will not be allowed to work on any network where DHCP servers are present, which in turn means that there is no incentive for anyone to implement Multicast DNS. Resolution? LDAP Schema for DHCP, Vijay Nanjundaswamy ----------------------------------- Vijay K. N. spoke about the latest LDAP schema definition. Mark Stapp noted that including lease information has huge performance implications. Ted Lemon gave the opinion that if the schema can be defined to accommodate the DHCP server data and work at some scale, then the schema is valid and the performance problem should be tackled separately. The schema recommends isolating leases in a container object to improve manageability. There is a server-specific extension that holds information that is only relevant to one particular implementation server. Mark Stapp asked if the authors had surveyed DHCP implementations to see if there is enough common configuration or operational information to make an interesting schema. Erik Guttman notes that the DMTF stays away details like this schema for individual services. Vijay identified an action item to survey existing servers to determine common functions. Ted Lemon pointed out that claiming improved reliability through the use of and LDAP store just moves the single point of failure from the DHCP server to the LDAP server. Mark Stapp asked if there is enough commonality between the configuration options and features of different DHCP Servers for a common LDAP schema to be useful? Authors responded that they will do a summary of existing servers to determine applicability of a common LDPA schema. Erik Guttman asked who actually wants this? Ted Lemon suggested that the authors should try implementing it first before talking about publishing it as an RFC. The authors have received comments from the WG and modified the draft according to those comments (where appropriate). The authors have also made some other changes independent of WG feedback. VPN Identifier sub-option for the Relay Agent Information Option, DHCP VPN Information option Mark Stapp ----------------------------------------------------------------- These drafts carry similar information through a DHCP option and a relay agent sub-option. The drafts give two encodings for VPN identifier: vrfs and RFC2685 vpn id. No response from WG. From owner-dhcp-v6@bucknell.edu Thu Aug 9 05:54:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA19427; Thu, 9 Aug 2001 05:54:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f799rm326984; Thu, 9 Aug 2001 05:53:48 -0400 (EDT) Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f799ri330966 for ; Thu, 9 Aug 2001 05:53:44 -0400 (EDT) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.130]) by sj-msg-core-4.cisco.com (8.11.3/8.9.1) with ESMTP id f799rdJ11388 for ; Thu, 9 Aug 2001 02:53:39 -0700 (PDT) Received: from mailman.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.10.1/8.10.1) with ESMTP id f799rdS17392 for ; Thu, 9 Aug 2001 02:53:39 -0700 (PDT) Received: from MJS-W2K.cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/CISCO.SERVER.1.2) with ESMTP id CAA05541 for ; Thu, 9 Aug 2001 02:53:26 -0700 (PDT) Message-Id: <4.3.2.7.2.20010809101418.01b06ad8@localhost> X-Sender: mjs@localhost X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 09 Aug 2001 10:53:55 +0100 To: DHCPv6 discussion list From: Mark Stapp Subject: Re: Discussion on configuring stateless clients. In-Reply-To: <200108090809.f7989AD00382@grosse.bisbee.fugue.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I've tried to summarize this problem, and make a proposal at the end. 1) DUID + IAID really identifies a unique binding (or request for a unique binding). The presence of the IA is the signal that a client wants addresses. That means that a client which sends SOLICITS with a variety of IAIDs will get a set of config info and addresses for each ID. 2) That's why the stateless client is a potential problem: if it generates a new ID each time it boots, the servers have no choice but to allocate it new addresses (and retain state for the previous IDs, which the client is not actually using any more). 3) Clients SHOULD respect the semantics of the IAID, and SHOULD NOT generate new ones when they don't intend to ask for new bindings. 4) Stateless clients need to obey (3), and if they do (say by always using ID 0, they'll be ok. There's a concern that they won't do (3) right, and that'll lead to address instability, extra dns updates, and wasted bindings that servers remember on behalf of clients that have forgotten them. 5) So we either need to live with the risk that the dependency on (3) is acceptable, or provide an explicit mechanism that clients can use to indicate that their state is gone. 6) I actually like (5), and I'd like to propose that that be available and unambiguous. Here are some sample words: If a client has no state (because it is a brand-new client booting for the first time, because it lost its state through misadventure, or becasue it is a stateless client), it SHOULD set the 'N'o State bit in the flags field in the header in its SOLICIT messages. It SHOULD include an IA if it wants addresses to be allocated; that IAID SHOULD be 0. If a client sets the 'N' bit, it MUST NOT continue to use any addresses that it obtained via DHCP, and it MUST NOT rely on information which it received from previous DHCP messages. Servers which have state for the DUID MAY reply with advertisements that contain the valid (unexpired) IAs (and IAIDs) that they remember, and SHOULD NOT allocate additional IAs. We expect that to be the normal response to the presence of that bit, and we expect that to be the mode in which most servers operate. There are several important properties of this mode. It allows the client to resume use of addresses by which it was known, which might be significant if the client provided services to others - if it is a printer or other device, for example. At sites which use DNS update, this mode avoids DNS updates to remove DNS records related to old bindings and additional DNS updates to reflect new bindings. Finally, this mode allows the client to avoid allocating additional resources. Alternatively, servers MAY take advantage of the client's indication to discard state for some or all of the existing bindings it finds for that client, if it is configured to do so. Administrators may want to send updated or changed information and free existing bindings, and may consider the potential cost of changed addresses for the client, additional DNS updates, etc. to be acceptable. Servers SHOULD be able to be implement that policy. What do people think about (6)? Is that adequate, too much, not enough? I like it (duh) because it's unambiguous (I think), it doesn't overload the IA, and it suggests that servers do the 'normal' thing most of the time, but it allows that there may be reasons to do different things in some situations. -- Mark From owner-dhcp-v4@bucknell.edu Fri Aug 10 03:38:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA00556 for ; Fri, 10 Aug 2001 03:38:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7A7Z9305829; Fri, 10 Aug 2001 03:35:09 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7A7Z5313359 for ; Fri, 10 Aug 2001 03:35:05 -0400 (EDT) Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1]) by palrel2.hp.com (Postfix) with ESMTP id 346A518DB for ; Fri, 10 Aug 2001 00:35:01 -0700 (PDT) Received: from india.hp.com (bansal@tohfa.india.hp.com [15.10.44.199]) by postbox.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id NAA27457 for ; Fri, 10 Aug 2001 13:10:59 +0530 (IST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3B738E6D.379E9E14@india.hp.com> Date: Fri, 10 Aug 2001 13:04:05 +0530 From: AJAY BANSAL Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: help Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bansal@india.hp.com X-Sender: bansal@india.hp.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Can anyone tell me: Which vendors have their DHCP servers enabled for rfc 3011 and 3046(sub-net selection option and Realy agent information option)? thanks. From owner-dhcp-v4@bucknell.edu Fri Aug 10 06:45:56 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03199 for ; Fri, 10 Aug 2001 06:45:56 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7AAeK317479; Fri, 10 Aug 2001 06:40:20 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7AAeA323631 for ; Fri, 10 Aug 2001 06:40:10 -0400 (EDT) Received: from grosse.bisbee.fugue.com (host217-33-142-7.ietf.ignite.net [217.33.142.7]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7AAYSf03211; Fri, 10 Aug 2001 03:34:28 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7AAciG00547; Fri, 10 Aug 2001 11:38:44 +0100 (BST) Message-Id: <200108101038.f7AAciG00547@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: help In-Reply-To: Message from AJAY BANSAL of "Fri, 10 Aug 2001 13:04:05 +0530." <3B738E6D.379E9E14@india.hp.com> Date: Fri, 10 Aug 2001 11:38:44 +0100 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Which vendors have their DHCP servers enabled for > rfc 3011 and 3046(sub-net selection option and Realy agent information > option)? ISC does. I'll bet Cisco does... :') _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Aug 10 07:00:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03418 for ; Fri, 10 Aug 2001 07:00:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7AAts323770; Fri, 10 Aug 2001 06:55:54 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7AAto305314 for ; Fri, 10 Aug 2001 06:55:50 -0400 (EDT) Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1]) by palrel2.hp.com (Postfix) with ESMTP id 579DB192A for ; Fri, 10 Aug 2001 03:55:48 -0700 (PDT) Received: from india.hp.com (bansal@tohfa.india.hp.com [15.10.44.199]) by postbox.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id QAA28266 for ; Fri, 10 Aug 2001 16:31:48 +0530 (IST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3B73BD7D.CD3277B4@india.hp.com> Date: Fri, 10 Aug 2001 16:24:54 +0530 From: AJAY BANSAL Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: doubt in rfc 3011 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bansal@india.hp.com X-Sender: bansal@india.hp.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit While studying the rfc 3011 document ( The IPv4 Subnet SelectionOption for DHCP document), I had some doubts. The doubts are: 1) Is this option only meant for public networks? And where else can it be used besides the example given in rfc document? 2)Will the client be never IP connected with the server when this option is used? 3) In this paragraph in section 2: " During an address renew, the DHCP server may send a DHCPACK directly to the allocated address, however packets from the DHCP server may not be routable to the address. Thus, in all packets that the DHCP client sends that contain the subnet selection option, the giaddr field in the BOOTP header MUST be set to an IPv4 address on which the DHCP client will accept DHCP packets (e.g.: the address on the subnet connected to the internal network)." When you say "Thus, in all packets that the DHCP....." , do you mean the packets for renewal only or all the packets ( DISCOVER, REQUEST etc. ) literally. Moreover, how a client is supposed to know "an IPv4 address on which the DHCP client will accept DHCP packets " and whose address it is exactly. I am a newcomer in this field. Please help. thanks and regards, Ajay Bansal. From owner-dhcp-v4@bucknell.edu Fri Aug 10 09:25:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04730 for ; Fri, 10 Aug 2001 09:25:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7ADL6316621; Fri, 10 Aug 2001 09:21:06 -0400 (EDT) Received: from quadntweb.quadritek.com ([198.200.138.211]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7ADL3317964 for ; Fri, 10 Aug 2001 09:21:04 -0400 (EDT) Received: from agrabilnt ([10.100.30.254]) by quadntweb.quadritek.com (Post.Office MTA v3.5.3 release 223 ID# 0-59484U200L100S0V35) with SMTP id com for ; Fri, 10 Aug 2001 09:13:26 -0400 From: "A. Gregory Rabil" To: DHCPv4 discussion list Subject: RE: help Date: Fri, 10 Aug 2001 09:20:35 -0400 Message-ID: <005601c1219f$3ddbdba0$fe1e640a@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 CWS, Build 9.0.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: <200108101038.f7AAciG00547@grosse.bisbee.fugue.com> Reply-To: grabil@lucent.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Lucent does as well... Greg > -----Original Message----- > From: owner-dhcp-v4@bucknell.edu [mailto:owner-dhcp-v4@bucknell.edu]On > Behalf Of Ted Lemon > Sent: Friday, August 10, 2001 6:39 AM > To: DHCPv4 discussion list > Cc: DHCPv4 discussion list > Subject: Re: help > > > > > Which vendors have their DHCP servers enabled for > > rfc 3011 and 3046(sub-net selection option and Realy agent > information > > option)? > > ISC does. I'll bet Cisco does... :') > > _MelloN_ > > From owner-dhcp-v4@bucknell.edu Fri Aug 10 10:03:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05093 for ; Fri, 10 Aug 2001 10:03:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7ADxx303373; Fri, 10 Aug 2001 09:59:59 -0400 (EDT) Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7ADxj312239 for ; Fri, 10 Aug 2001 09:59:45 -0400 (EDT) Received: from there ([193.12.201.10]) by fep01-svc.swip.net with SMTP id <20010810135929.DSHC29813.fep01-svc.swip.net@there>; Fri, 10 Aug 2001 15:59:29 +0200 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: DHCPv4 discussion list Subject: Re: help Date: Fri, 10 Aug 2001 16:02:21 +0200 X-Mailer: KMail [version 1.2.3] References: <3B738E6D.379E9E14@india.hp.com> In-Reply-To: <3B738E6D.379E9E14@india.hp.com> MIME-Version: 1.0 Message-Id: <20010810135929.DSHC29813.fep01-svc.swip.net@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by mail.bucknell.edu id f7ADxk321885 Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 8bit Ours does as well - DHCP Turbo at http://www.weird-solutions.com. > Which vendors have their DHCP servers enabled for > rfc 3011 and 3046(sub-net selection option and Realy agent information > option)? > > thanks. -- 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-v6@bucknell.edu Fri Aug 10 10:50:44 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05708; Fri, 10 Aug 2001 10:50:44 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7AEoj311858; Fri, 10 Aug 2001 10:50:45 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7AEoe311963 for ; Fri, 10 Aug 2001 10:50:40 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7AEodp20329 for ; Fri, 10 Aug 2001 09:50:39 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7AEocB08261 for ; Fri, 10 Aug 2001 09:50:39 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Aug 10 09:50:38 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 10 Aug 2001 09:50:38 -0500 Message-ID: <66F66129A77AD411B76200508B65AC69903F6E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Discussion on configuring stateless clients. Date: Fri, 10 Aug 2001 09:50:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C121AB.D1452B60" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C121AB.D1452B60 Content-Type: text/plain; charset="iso-8859-1" Mark: I like it. It does require clients to honor 4 but I don't see why that should be any problem. One minor issue - we SHOULD use a "No-State Option" instead of a flag bit as we don't really have a means to signal flags (at present, but I'm sure you'd add a flags field). It could simple be a 2-byte option code followed by 0 length (no data). That way, it is fairly short. Personally, I feel it would be good to stay away from flag bits because we'd have to allocate some number of them, and that number is fixed. Options already exist and allow us to handle this in a much more standard manner. (In terms of the scoping rules, we should allow options to be GLOBAL - which means they MAY appear anywhere (SHOULD appear early in the message) and have only global scope regardless of where they are.) Just to confirm I understand, the "No-State" indication (flag bit or option) means to a server either return the most recent IA information for the client OR discard all IAs for the client and assign new one (for the IAID). Also, you state "Servers which have state for the DUID MAY reply with advertisements that contain the valid (unexpired) IAs (and IAIDs) that they remember, and SHOULD NOT allocate additional IAs." I agree that additional IAs should not be allocated. However, what happens if IAID 0 (or whatever IAID is included in the Solicit) doesn't have any addresses? Should the server allocate addresses for this IA or not? Also, while you are silent about allocating additional IAIDs, what about additional addresses? Might be best to leave both these activities for Request(s). THERE is just ONE minor issue that servers must be careful about - that is duplicated Solicit messages from the client. This really won't do major damage - especially since we no longer consider the Advertised addresses as being a "contract" to lease those addresses (if they were, a server would have to take care if it wanted to assign new addresses since it could be that an earlier Advertise response was delayed). - Bernie -----Original Message----- From: Mark Stapp [mailto:mjs@cisco.com] Sent: Thursday, August 09, 2001 5:54 AM To: DHCPv6 discussion list Subject: Re: Discussion on configuring stateless clients. I've tried to summarize this problem, and make a proposal at the end. 1) DUID + IAID really identifies a unique binding (or request for a unique binding). The presence of the IA is the signal that a client wants addresses. That means that a client which sends SOLICITS with a variety of IAIDs will get a set of config info and addresses for each ID. 2) That's why the stateless client is a potential problem: if it generates a new ID each time it boots, the servers have no choice but to allocate it new addresses (and retain state for the previous IDs, which the client is not actually using any more). 3) Clients SHOULD respect the semantics of the IAID, and SHOULD NOT generate new ones when they don't intend to ask for new bindings. 4) Stateless clients need to obey (3), and if they do (say by always using ID 0, they'll be ok. There's a concern that they won't do (3) right, and that'll lead to address instability, extra dns updates, and wasted bindings that servers remember on behalf of clients that have forgotten them. 5) So we either need to live with the risk that the dependency on (3) is acceptable, or provide an explicit mechanism that clients can use to indicate that their state is gone. 6) I actually like (5), and I'd like to propose that that be available and unambiguous. Here are some sample words: If a client has no state (because it is a brand-new client booting for the first time, because it lost its state through misadventure, or becasue it is a stateless client), it SHOULD set the 'N'o State bit in the flags field in the header in its SOLICIT messages. It SHOULD include an IA if it wants addresses to be allocated; that IAID SHOULD be 0. If a client sets the 'N' bit, it MUST NOT continue to use any addresses that it obtained via DHCP, and it MUST NOT rely on information which it received from previous DHCP messages. Servers which have state for the DUID MAY reply with advertisements that contain the valid (unexpired) IAs (and IAIDs) that they remember, and SHOULD NOT allocate additional IAs. We expect that to be the normal response to the presence of that bit, and we expect that to be the mode in which most servers operate. There are several important properties of this mode. It allows the client to resume use of addresses by which it was known, which might be significant if the client provided services to others - if it is a printer or other device, for example. At sites which use DNS update, this mode avoids DNS updates to remove DNS records related to old bindings and additional DNS updates to reflect new bindings. Finally, this mode allows the client to avoid allocating additional resources. Alternatively, servers MAY take advantage of the client's indication to discard state for some or all of the existing bindings it finds for that client, if it is configured to do so. Administrators may want to send updated or changed information and free existing bindings, and may consider the potential cost of changed addresses for the client, additional DNS updates, etc. to be acceptable. Servers SHOULD be able to be implement that policy. What do people think about (6)? Is that adequate, too much, not enough? I like it (duh) because it's unambiguous (I think), it doesn't overload the IA, and it suggests that servers do the 'normal' thing most of the time, but it allows that there may be reasons to do different things in some situations. -- Mark ------_=_NextPart_001_01C121AB.D1452B60 Content-Type: text/html; charset="iso-8859-1" RE: Discussion on configuring stateless clients.

Mark:

I like it. It does require clients to honor 4 but I don't see why that should be
any problem.

One minor issue - we SHOULD use a "No-State Option" instead of a flag bit as
we don't really have a means to signal flags (at present, but I'm sure you'd
add a flags field). It could simple be a 2-byte option code followed by 0 length
(no data). That way, it is fairly short.

Personally, I feel it would be good to stay away from flag bits because we'd have
to allocate some number of them, and that number is fixed. Options already exist
and allow us to handle this in a much more standard manner. (In terms of the scoping
rules, we should allow options to be GLOBAL - which means they MAY appear anywhere
(SHOULD appear early in the message) and have only global scope regardless of where
they are.)

Just to confirm I understand, the "No-State" indication (flag bit or option) means
to a server either return the most recent IA information for the client OR
discard all IAs for the client and assign new one (for the IAID).

Also, you state "Servers which have state for the DUID MAY reply with
advertisements that contain the valid (unexpired) IAs (and IAIDs) that they
remember, and SHOULD NOT allocate additional IAs." I agree that additional IAs
should not be allocated. However, what happens if IAID 0 (or whatever IAID is
included in the Solicit) doesn't have any addresses? Should the server allocate
addresses for this IA or not? Also, while you are silent about allocating additional
IAIDs, what about additional addresses? Might be best to leave both these activities
for Request(s).

THERE is just ONE minor issue that servers must be careful about - that is duplicated
Solicit messages from the client. This really won't do major damage - especially
since we no longer consider the Advertised addresses as being a "contract" to lease
those addresses (if they were, a server would have to take care if it wanted to
assign new addresses since it could be that an earlier Advertise response was
delayed).

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Thursday, August 09, 2001 5:54 AM
To: DHCPv6 discussion list
Subject: Re: Discussion on configuring stateless clients.


I've tried to summarize this problem, and make a proposal at the end.

1) DUID + IAID really identifies a unique binding (or request for a unique
binding). The presence of the IA is the signal that a client wants
addresses. That means that a client which sends SOLICITS with a variety of
IAIDs will get a set of config info and addresses for each ID.

2) That's why the stateless client is a potential problem: if it generates
a new ID each time it boots, the servers have no choice but to allocate it
new addresses (and retain state for the previous IDs, which the client is
not actually using any more).

3) Clients SHOULD respect the semantics of the IAID, and SHOULD NOT
generate new ones when they don't intend to ask for new bindings.

4) Stateless clients need to obey (3), and if they do (say by always using
ID 0, they'll be ok. There's a concern that they won't do (3) right, and
that'll lead to address instability, extra dns updates, and wasted bindings
that servers remember on behalf of clients that have forgotten them.

5) So we either need to live with the risk that the dependency on (3) is
acceptable, or provide an explicit mechanism that clients can use to
indicate that their state is gone.

6) I actually like (5), and I'd like to propose that that be available and
unambiguous. Here are some sample words:
If a client has no state (because it is a brand-new client booting for the
first time, because it lost its state through misadventure, or becasue it
is a stateless client), it SHOULD set the 'N'o State bit in the flags field
in the header in its SOLICIT messages. It SHOULD include an IA if it wants
addresses to be allocated; that IAID SHOULD be 0. If a client sets the 'N'
bit, it MUST NOT continue to use any addresses that it obtained via DHCP,
and it MUST NOT rely on information which it received from previous DHCP
messages. Servers which have state for the DUID MAY reply with
advertisements that contain the valid (unexpired) IAs (and IAIDs) that they
remember, and SHOULD NOT allocate additional IAs. We expect that to be the
normal response to the presence of that bit, and we expect that to be the
mode in which most servers operate. There are several important properties
of this mode. It allows the client to resume use of addresses by which it
was known, which might be significant if the client provided services to
others - if it is a printer or other device, for example. At sites which
use DNS update, this mode avoids DNS updates to remove DNS records related
to old bindings and additional DNS updates to reflect new bindings.
Finally, this mode allows the client to avoid allocating additional resources.

Alternatively, servers MAY take advantage of the client's indication to
discard state for some or all of the existing bindings it finds for that
client, if it is configured to do so. Administrators may want to send
updated or changed information and free existing bindings, and may consider
the potential cost of changed addresses for the client, additional DNS
updates, etc. to be acceptable. Servers SHOULD be able to be implement that
policy.

What do people think about (6)? Is that adequate, too much, not enough? I
like it (duh) because it's unambiguous (I think), it doesn't overload the
IA, and it suggests that servers do the 'normal' thing most of the time,
but it allows that there may be reasons to do different things in some
situations.

-- Mark

------_=_NextPart_001_01C121AB.D1452B60-- From owner-dhcp-v4@bucknell.edu Mon Aug 13 06:18:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12978 for ; Mon, 13 Aug 2001 06:18:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DAF7324811; Mon, 13 Aug 2001 06:15:08 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DAF2310049 for ; Mon, 13 Aug 2001 06:15:02 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-83.cisco.com [10.21.96.83]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA08140 for ; Mon, 13 Aug 2001 06:14:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20010809104300.00b4c978@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 03:00:00 +0100 To: DHCPv4 discussion list From: Ralph Droms Subject: Announcement of WG last call for Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "The Classless Static Route Option for DHCP" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms From owner-dhcp-v4@bucknell.edu Mon Aug 13 08:20:11 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16749 for ; Mon, 13 Aug 2001 08:20:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DCHl304068; Mon, 13 Aug 2001 08:17:47 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DCHc300926 for ; Mon, 13 Aug 2001 08:17:38 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7DCHL501572 for ; Mon, 13 Aug 2001 07:17:22 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7DCHL726297 for ; Mon, 13 Aug 2001 07:17:21 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Aug 13 07:17:20 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 07:17:19 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B33D2@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Cc: "'Ted.Lemon@nominum.com'" , "'rdroms@cisco.com'" Subject: RE: Announcement of WG last call for Date: Mon, 13 Aug 2001 07:17:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C123F1.E5D708D0" Reply-To: Bernie.Volz@am1.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C123F1.E5D708D0 Content-Type: text/plain; charset="iso-8859-1" The draft looks very good. I just have a few minor nits that we might want to consider: 1) It never indicates the order of the IPv4 address (subnet numbers). While we all assume it is network byte order, I think it would be wise to be explicit. Perhaps simply changing: "This encoding consists of one octet describing the width of the subnet mask, followed by all the non-zero octets of the subnet number." to: "This encoding consists of one octet describing the width of the subnet mask, followed by all the non-zero octets of the subnet number in network byte order." would do the trick? 2) The case on two section headings should be corrected: Requirements to avoid sizing constraints --> Requirements to Avoid Sizing Constraints DHCP Server administrator responsibilities --> DHCP Server Administrator Responsibilities (Perhaps the RFC Editor will do this kind of fix up anyway?) 3) The sections are not numbered? Should they be (again, perhaps RFC editor will do this)? - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Sunday, August 12, 2001 10:00 PM To: DHCPv4 discussion list Subject: Announcement of WG last call for This message announces a DHC WG last call for "The Classless Static Route Option for DHCP" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms ------_=_NextPart_001_01C123F1.E5D708D0 Content-Type: text/html; charset="iso-8859-1" RE: Announcement of WG last call for <draft-ietf-dhc-csr-05.txt>

The draft looks very good.

I just have a few minor nits that we might want to consider:

1) It never indicates the order of the IPv4 address (subnet numbers). While we all
assume it is network byte order, I think it would be wise to be explicit.

Perhaps simply changing:

"This encoding consists of one octet describing the width of the subnet
mask, followed by all the non-zero octets of the subnet number."

to:

"This encoding consists of one octet describing the width of the subnet
mask, followed by all the non-zero octets of the subnet number in network
byte order."

would do the trick?

2) The case on two section headings should be corrected:

Requirements to avoid sizing constraints --> Requirements to Avoid Sizing Constraints

DHCP Server administrator responsibilities --> DHCP Server Administrator Responsibilities

(Perhaps the RFC Editor will do this kind of fix up anyway?)

3) The sections are not numbered? Should they be (again, perhaps RFC editor will
do this)?

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Sunday, August 12, 2001 10:00 PM
To: DHCPv4 discussion list
Subject: Announcement of WG last call for <draft-ietf-dhc-csr-05.txt>


This message announces a DHC WG last call for "The Classless Static Route
Option for DHCP" <draft-ietf-dhc-csr-05.txt>.  At the WG meeting in London
the WG agreed to go to WG last call for this draft immediately after IETF-51.

Please forward any comments you may have on this draft to
dhcp-v4@bucknell.edu by Friday, August 24.

- Ralph Droms

------_=_NextPart_001_01C123F1.E5D708D0-- From owner-dhcp-v4@bucknell.edu Mon Aug 13 10:57:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21463 for ; Mon, 13 Aug 2001 10:57:34 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DEsH315936; Mon, 13 Aug 2001 10:54:17 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DEsC331995 for ; Mon, 13 Aug 2001 10:54:12 -0400 (EDT) Received: from grosse.bisbee.fugue.com (1Cust82.tnt3.nyc3.da.uu.net [63.23.110.82]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7DEmsf09571; Mon, 13 Aug 2001 07:48:54 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7DEKlQ01422; Mon, 13 Aug 2001 10:20:47 -0400 (EDT) Message-Id: <200108131420.f7DEKlQ01422@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list , "'rdroms@cisco.com'" Subject: Re: Announcement of WG last call for In-Reply-To: Message from "Bernie Volz (EUD)" of "Mon, 13 Aug 2001 07:17:19 CDT." <66F66129A77AD411B76200508B65AC697B33D2@eambunt705.ena-east.ericsson.se> Date: Mon, 13 Aug 2001 10:20:47 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Are you saying that we should not go to RFC now because of these three issues? _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Aug 13 11:06:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21633 for ; Mon, 13 Aug 2001 11:06:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DF6g326444; Mon, 13 Aug 2001 11:06:42 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DF6U312511 for ; Mon, 13 Aug 2001 11:06:30 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-108.cisco.com [161.44.149.108]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA00354; Mon, 13 Aug 2001 11:06:12 -0400 (EDT) Message-Id: <4.3.2.7.2.20010813110158.053b8068@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 11:04:26 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: Announcement of WG last call for Cc: DHCPv4 discussion list , "'Ted.Lemon@nominum.com'" In-Reply-To: <66F66129A77AD411B76200508B65AC697B33D2@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN These problems can be fixed with a final rev of the I-D before submission to the IESG. I'll check to find out how close to final RFC format the I-D needs to be in its final rev. - Ralph At 07:17 AM 8/13/2001 -0500, Bernie Volz (EUD) wrote: >The draft looks very good. > >I just have a few minor nits that we might want to consider: > >1) It never indicates the order of the IPv4 address (subnet numbers). >While we all >assume it is network byte order, I think it would be wise to be explicit. > >Perhaps simply changing: > >"This encoding consists of one octet describing the width of the subnet >mask, followed by all the non-zero octets of the subnet number." > >to: > >"This encoding consists of one octet describing the width of the subnet >mask, followed by all the non-zero octets of the subnet number in network >byte order." > >would do the trick? > >2) The case on two section headings should be corrected: > >Requirements to avoid sizing constraints --> Requirements to Avoid Sizing >Constraints > >DHCP Server administrator responsibilities --> DHCP Server Administrator >Responsibilities > >(Perhaps the RFC Editor will do this kind of fix up anyway?) > >3) The sections are not numbered? Should they be (again, perhaps RFC >editor will >do this)? > >- Bernie Volz > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Sunday, August 12, 2001 10:00 PM >To: DHCPv4 discussion list >Subject: Announcement of WG last call for > >This message announces a DHC WG last call for "The Classless Static Route >Option for DHCP" . At the WG meeting in London >the WG agreed to go to WG last call for this draft immediately after IETF-51. > >Please forward any comments you may have on this draft to >dhcp-v4@bucknell.edu by Friday, August 24. > >- Ralph Droms From owner-dhcp-v4@bucknell.edu Mon Aug 13 11:22:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22005 for ; Mon, 13 Aug 2001 11:22:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DFKV316907; Mon, 13 Aug 2001 11:20:31 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DFKM319372 for ; Mon, 13 Aug 2001 11:20:22 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7DFKJp26840 for ; Mon, 13 Aug 2001 10:20:20 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7DFKJ708120 for ; Mon, 13 Aug 2001 10:20:19 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Aug 13 10:18:23 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 13 Aug 2001 10:18:24 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B33D5@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Cc: DHCPv4 discussion list , "'rdroms@cisco.com'" Subject: RE: Announcement of WG last call for Date: Mon, 13 Aug 2001 10:18:23 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1240B.31359580" Reply-To: Bernie.Volz@am1.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C1240B.31359580 Content-Type: text/plain; charset="iso-8859-1" By all means NO (to be clear, we *SHOULD* go to RFC). As Ralph indicated, these are minor edits and should easily be able to be added before IETF last call. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Monday, August 13, 2001 10:21 AM To: Bernie Volz (EUD) Cc: DHCPv4 discussion list; 'rdroms@cisco.com' Subject: Re: Announcement of WG last call for Are you saying that we should not go to RFC now because of these three issues? _MelloN_ ------_=_NextPart_001_01C1240B.31359580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Announcement of WG last call for = <draft-ietf-dhc-csr-05.txt>

By all means NO (to be clear, we *SHOULD* go to = RFC).

As Ralph indicated, these are minor edits and should = easily be able to be added before
IETF last call.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Monday, August 13, 2001 10:21 AM
To: Bernie Volz (EUD)
Cc: DHCPv4 discussion list; = 'rdroms@cisco.com'
Subject: Re: Announcement of WG last call for
<draft-ietf-dhc-csr-05.txt>



Are you saying that we should not go to RFC now = because of these three
issues?

        =         =                _MelloN_

------_=_NextPart_001_01C1240B.31359580-- From owner-dhcp-v4@bucknell.edu Mon Aug 13 13:04:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24963 for ; Mon, 13 Aug 2001 13:04:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DH2C316895; Mon, 13 Aug 2001 13:02:12 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DH1w332135 for ; Mon, 13 Aug 2001 13:01:58 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-108.cisco.com [161.44.149.108]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA14153 for ; Mon, 13 Aug 2001 13:01:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20010809104739.02015710@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 13:00:00 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Announcement of WG last call for Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "Encoding Long DHCP Options" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms From owner-dhcp-v4@bucknell.edu Mon Aug 13 14:17:04 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26506 for ; Mon, 13 Aug 2001 14:17:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DIEa304458; Mon, 13 Aug 2001 14:14:36 -0400 (EDT) Received: from diablo.cisco.com (diablo.cisco.com [171.68.224.210]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DIET310181 for ; Mon, 13 Aug 2001 14:14:29 -0400 (EDT) Received: from JSCHNIZL-W2K1.cisco.com (rtp-vpn1-11.cisco.com [10.82.224.11]) by diablo.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA14267; Mon, 13 Aug 2001 11:14:11 -0700 (PDT) Message-Id: <4.3.2.7.2.20010813140349.03311f08@diablo.cisco.com> X-Sender: jschnizl@diablo.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 14:14:02 -0400 To: DHCPv4 discussion list From: John Schnizlein Subject: Re: Announcement of WG last call for Cc: DHCPv4 discussion list In-Reply-To: <4.3.2.7.2.20010809104739.02015710@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: jschnizl@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN At 01:00 PM 8/13/2001, Ralph Droms wrote: >This message announces a DHC WG last call for "Encoding Long DHCP Options" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. > >Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. Sorry I did not catch this earlier. Before going much further, let's get the spelling errors fixed: "rendesvous" should be "rendezvous" "behaviour" should be "behavior" "seperate" should be "separate". Clippings for the context where these errors occur below: Behavior and separate spelling errors are repeated consistently (as if the dictionary rather than the author is wrong). John Options DHCP options are collections of data with type codes that indicate how the options should be used. Options can specify information that is required for the DHCP protocol, IP stack configuration parameters for the client, information allowing the client to rendesvous with DHCP servers, and so on. The aggregate option buffer This behaviour only applies in cases where this specification is applicable, as previously defined in the Applicability section. DHCP options can be stored in the DHCP packet in three seperate portions of the packet. ... This complicates the description of the option splitting mechanism because there are three seperate buffers into which split options may be stored. From owner-dhcp-v4@bucknell.edu Mon Aug 13 14:57:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27081 for ; Mon, 13 Aug 2001 14:57:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DItD304196; Mon, 13 Aug 2001 14:55:13 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DIt6314371 for ; Mon, 13 Aug 2001 14:55:07 -0400 (EDT) Received: from grosse.bisbee.fugue.com (1Cust82.tnt3.nyc3.da.uu.net [63.23.110.82]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7DInZf09978; Mon, 13 Aug 2001 11:49:39 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7DIrXQ01813; Mon, 13 Aug 2001 14:53:33 -0400 (EDT) Message-Id: <200108131853.f7DIrXQ01813@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Announcement of WG last call for In-Reply-To: Message from John Schnizlein of "Mon, 13 Aug 2001 14:14:02 EDT." <4.3.2.7.2.20010813140349.03311f08@diablo.cisco.com> Date: Mon, 13 Aug 2001 14:53:33 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Before going much further, let's get the spelling errors fixed: I think fixing speling erors is a great idea, but it is also trivial. I will fix those, but the real question is, are there substantive issues that we should be aware of. :'} _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Aug 13 15:41:21 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27662 for ; Mon, 13 Aug 2001 15:41:21 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DJcT329570; Mon, 13 Aug 2001 15:38:29 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DJcL327316 for ; Mon, 13 Aug 2001 15:38:21 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-108.cisco.com [161.44.149.108]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA08454 for ; Mon, 13 Aug 2001 15:37:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20010813153001.039fa4b8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 15:36:09 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Re: Announcement of WG last call for In-Reply-To: <200108131853.f7DIrXQ01813@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010813140349.03311f08@diablo.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN WG members - during WG last call discussions, comments on problems like speling erors can go directly to the draft authors, while the mailing list should be reserved for comments on more substantive issues. - Ralph At 02:53 PM 8/13/2001 -0400, Ted Lemon wrote: > > Before going much further, let's get the spelling errors fixed: > >I think fixing speling erors is a great idea, but it is also trivial. >I will fix those, but the real question is, are there substantive >issues that we should be aware of. :'} > > _MelloN_ From owner-dhcp-v4@bucknell.edu Mon Aug 13 15:42:13 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27694 for ; Mon, 13 Aug 2001 15:42:12 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DJgO332488; Mon, 13 Aug 2001 15:42:24 -0400 (EDT) Received: from anchor-post-34.mail.demon.net (anchor-post-34.mail.demon.net [194.217.242.92]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DJgI328467 for ; Mon, 13 Aug 2001 15:42:18 -0400 (EDT) Received: from fronty.demon.co.uk ([158.152.191.225] helo=dell) by anchor-post-34.mail.demon.net with smtp (Exim 2.12 #1) id 15WNbG-0000n8-0Y for dhcp-v4@bucknell.edu; Mon, 13 Aug 2001 20:42:10 +0100 Message-ID: <00a501c12430$454897a0$0101010a@dell> From: "Paul Roberts" To: DHCPv4 discussion list References: <200108131853.f7DIrXQ01813@grosse.bisbee.fugue.com> Subject: Re: Announcement of WG last call for Date: Mon, 13 Aug 2001 20:39:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Reply-To: paul.roberts@intranet-solutions.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Just my 2p's worth, was the draft written by a Brit? We do actually spell behaviour with a "u" - in fact it looks downright weird without it, but let's not get into the way American's have canibalised the English language since achieving independence! ;-) Paul (tongue firmly in cheek!) ----- Original Message ----- From: Ted Lemon To: DHCPv4 discussion list Cc: DHCPv4 discussion list Sent: Monday, August 13, 2001 7:53 PM Subject: Re: Announcement of WG last call for > > > Before going much further, let's get the spelling errors fixed: > > I think fixing speling erors is a great idea, but it is also trivial. > I will fix those, but the real question is, are there substantive > issues that we should be aware of. :'} > > _MelloN_ > > From owner-dhcp-v4@bucknell.edu Mon Aug 13 17:04:38 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28675 for ; Mon, 13 Aug 2001 17:04:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7DL2E300795; Mon, 13 Aug 2001 17:02:14 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7DL1w314026 for ; Mon, 13 Aug 2001 17:01:58 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-108.cisco.com [161.44.149.108]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA21184 for ; Mon, 13 Aug 2001 17:01:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20010809104938.0201fe28@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 13 Aug 2001 17:00:00 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Announcement of WG last call for Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "The DHCP Client FQDN Option . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue Aug 14 08:43:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00674 for ; Tue, 14 Aug 2001 08:43:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7ECeE332765; Tue, 14 Aug 2001 08:40:14 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7ECeC319961 for ; Tue, 14 Aug 2001 08:40:12 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-dial-1-165.cisco.com [10.83.97.165]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA12346 for ; Tue, 14 Aug 2001 08:39:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20010809112537.00b76d38@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Aug 2001 08:00:00 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Announcement of WG last call for Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "Resolution of DNS Name Conflicts Among DHCP Clients" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue Aug 14 13:07:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10487 for ; Tue, 14 Aug 2001 13:07:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7EH25310075; Tue, 14 Aug 2001 13:02:05 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7EH20313940 for ; Tue, 14 Aug 2001 13:02:00 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-43.cisco.com [10.21.96.43]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA15363 for ; Tue, 14 Aug 2001 13:01:44 -0400 (EDT) Message-Id: <4.3.2.7.2.20010810080126.00b753b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Aug 2001 13:00:00 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Announcement of WG last call for Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "DHCP Domain Search Option" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue Aug 14 13:24:30 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11060 for ; Tue, 14 Aug 2001 13:24:30 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7EHNE332405; Tue, 14 Aug 2001 13:23:14 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7EHN8317619 for ; Tue, 14 Aug 2001 13:23:08 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7EHN7p26496 for ; Tue, 14 Aug 2001 12:23:07 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7EHN7M03609 for ; Tue, 14 Aug 2001 12:23:07 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Aug 14 12:23:06 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 14 Aug 2001 12:23:07 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B33EA@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Subject: RE: Announcement of WG last call for Date: Tue, 14 Aug 2001 12:23:04 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C124E5.C6E2FD40" Reply-To: Bernie.Volz@am1.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C124E5.C6E2FD40 Content-Type: text/plain; charset="iso-8859-1" Should the last call be based on the 04 version: -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Tuesday, August 14, 2001 7:01 AM Subject: I-D ACTION:draft-aboba-dhc-domsearch-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Domain Search Option Author(s) : B. Aboba Filename : draft-aboba-dhc-domsearch-04.txt Pages : 5 Date : 13-Aug-01 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration. RFC 2132 allows DHCP servers to specify configuration information for various kinds of name services to be passed to DHCP clients. In some circumstances, it is useful for the DHCP client to be configured with the domain search list. This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the domain seach list when resolving hostnames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aboba-dhc-domsearch-04.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-aboba-dhc-domsearch-04.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 -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, August 14, 2001 1:00 PM To: DHCPv4 discussion list Subject: Announcement of WG last call for This message announces a DHC WG last call for "DHCP Domain Search Option" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms ------_=_NextPart_001_01C124E5.C6E2FD40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Announcement of WG last call for = <draft-aboba-dhc-domsearch-03.txt>

Should the last call be based on the 04 = version:


-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Tuesday, August 14, 2001 7:01 AM
Subject: I-D = ACTION:draft-aboba-dhc-domsearch-04.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = DHCP Domain Search Option
        Author(s)       : B. = Aboba
        Filename        : = draft-aboba-dhc-domsearch-04.txt
        Pages           : = 5
        Date    =         : 13-Aug-01
       =20
The Dynamic Host Configuration Protocol (DHCP) = provides a mechanism for
host configuration. RFC 2132 allows DHCP servers to = specify
configuration information for various kinds of name = services to be
passed to DHCP clients.  In some circumstances, = it is useful for the
DHCP client to be configured with the domain search = list.  This document
defines a new DHCP option which is passed from the = DHCP Server to the
DHCP Client to specify the domain seach list when = resolving hostnames.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aboba-dhc-do= msearch-04.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-aboba-dhc-domsearch-04.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



-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, August 14, 2001 1:00 PM
To: DHCPv4 discussion list
Subject: Announcement of WG last call for
<draft-aboba-dhc-domsearch-03.txt>


This message announces a DHC WG last call for = "DHCP Domain Search Option"
<draft-aboba-dhc-domsearch-03.txt>.  At = the WG meeting in London the WG
agreed to go to WG last call for this draft = immediately after IETF-51.

Please forward any comments you may have on this = draft to
dhcp-v4@bucknell.edu by Friday, August 24.

- Ralph Droms
      

------_=_NextPart_001_01C124E5.C6E2FD40-- From owner-dhcp-v4@bucknell.edu Tue Aug 14 13:46:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11513 for ; Tue, 14 Aug 2001 13:46:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7EHhW310890; Tue, 14 Aug 2001 13:43:32 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7EHhI316810 for ; Tue, 14 Aug 2001 13:43:18 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-24.cisco.com [10.21.96.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA20496 for ; Tue, 14 Aug 2001 13:43:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20010814133622.00b8c540@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Aug 2001 13:41:11 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: RE: Announcement of WG last call for In-Reply-To: <66F66129A77AD411B76200508B65AC697B33EA@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Oops - Yes, of course the last call should be based on the -04 rev of the doc. Good catch... - Ralph At 12:23 PM 8/14/2001 -0500, Bernie Volz (EUD) wrote: >Should the last call be based on the 04 version: > >-----Original Message----- >From: Internet-Drafts@ietf.org >[mailto:Internet-Drafts@ietf.org] >Sent: Tuesday, August 14, 2001 7:01 AM >Subject: I-D ACTION:draft-aboba-dhc-domsearch-04.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : DHCP Domain Search Option > Author(s) : B. Aboba > Filename : draft-aboba-dhc-domsearch-04.txt > Pages : 5 > Date : 13-Aug-01 > >The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for >host configuration. RFC 2132 allows DHCP servers to specify >configuration information for various kinds of name services to be >passed to DHCP clients. In some circumstances, it is useful for the >DHCP client to be configured with the domain search list. This document >defines a new DHCP option which is passed from the DHCP Server to the >DHCP Client to specify the domain seach list when resolving hostnames. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-aboba-dhc-domsearch-04.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-aboba-dhc-domsearch-04.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 > > > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Tuesday, August 14, 2001 1:00 PM >To: DHCPv4 discussion list >Subject: Announcement of WG last call for > > >This message announces a DHC WG last call for "DHCP Domain Search Option" >. At the WG meeting in London the WG >agreed to go to WG last call for this draft immediately after IETF-51. > >Please forward any comments you may have on this draft to >dhcp-v4@bucknell.edu by Friday, August 24. > >- Ralph Droms > From owner-dhcp-v4@bucknell.edu Tue Aug 14 17:04:46 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15115 for ; Tue, 14 Aug 2001 17:04:45 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7EL2X325239; Tue, 14 Aug 2001 17:02:33 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7EL2K325264 for ; Tue, 14 Aug 2001 17:02:20 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-24.cisco.com [10.21.96.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA18382 for ; Tue, 14 Aug 2001 17:02:04 -0400 (EDT) Message-Id: <4.3.2.7.2.20010810080332.00b8f7e0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Aug 2001 17:00:00 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: : Announcement of WG last call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "Subnet Selection sub-option for the Relay Agent Information Option" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms From owner-dhcp-v4@bucknell.edu Tue Aug 14 17:05:01 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15134 for ; Tue, 14 Aug 2001 17:05:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7EL5K319721; Tue, 14 Aug 2001 17:05:20 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7EL4C312538 for ; Tue, 14 Aug 2001 17:04:12 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn1-24.cisco.com [10.21.96.24]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA18603 for ; Tue, 14 Aug 2001 17:03:55 -0400 (EDT) Message-Id: <4.3.2.7.2.20010814170118.03ab8948@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 14 Aug 2001 17:02:09 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Announcement of WG last call for (corrected ID reference) Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: rdroms@cisco.com 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 "DHCP Domain Search Option" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Aug 15 06:19:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11776 for ; Wed, 15 Aug 2001 06:19:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7FAGE322441; Wed, 15 Aug 2001 06:16:14 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7FAG9311167 for ; Wed, 15 Aug 2001 06:16:09 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-36.cisco.com [10.82.224.36]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA02201 for ; Wed, 15 Aug 2001 06:15:53 -0400 (EDT) Message-Id: <4.3.2.7.2.20010810080422.00b745b8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 15 Aug 2001 08:00:00 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: : Announcement of WG last call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "Addition of Device Class to Agent Options" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms From owner-dhcp-v4@bucknell.edu Thu Aug 16 09:10:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04371 for ; Thu, 16 Aug 2001 09:10:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7GD7M308089; Thu, 16 Aug 2001 09:07:22 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7GD7G329951 for ; Thu, 16 Aug 2001 09:07:16 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7GD6x515942 for ; Thu, 16 Aug 2001 08:07:00 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7GD6xr16625 for ; Thu, 16 Aug 2001 08:06:59 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Aug 16 08:06:58 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 16 Aug 2001 08:06:58 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3415@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv4 discussion list Subject: RE: WG Last Call draft-aboba-dhc-domsearch-*.txt Date: Thu, 16 Aug 2001 08:06:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C12654.54A4F650" Reply-To: Bernie.Volz@am1.ericsson.se Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C12654.54A4F650 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12654.54A4F650" ------_=_NextPart_001_01C12654.54A4F650 Content-Type: text/plain; charset="iso-8859-1" Bernard seems to be publishing revisions of this document faster than we can review them! Based on the 05 revision, I fully support this document. Hopefully, this document will be submitted after draft-ietf-dhc-concat-01.txt goes to RFC (or in parallel) such that the RFC can be referenced. - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, August 14, 2001 5:02 PM To: DHCPv4 discussion list Subject: Announcement of WG last call for (corrected ID reference) This message announces a DHC WG last call for "DHCP Domain Search Option" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, August 24. - Ralph Droms -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Thursday, August 16, 2001 7:01 AM Subject: I-D ACTION:draft-aboba-dhc-domsearch-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : DHCP Domain Search Option Author(s) : B. Aboba Filename : draft-aboba-dhc-domsearch-05.txt Pages : 5 Date : 15-Aug-01 The Dynamic Host Configuration Protocol (DHCP) provides a mechanism for host configuration. RFC 2132 allows DHCP servers to specify configuration information for various kinds of name services to be passed to DHCP clients. In some circumstances, it is useful for the DHCP client to be configured with the domain search list. This document defines a new DHCP option which is passed from the DHCP Server to the DHCP Client to specify the domain seach list when resolving hostnames. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-aboba-dhc-domsearch-05.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-aboba-dhc-domsearch-05.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-aboba-dhc-domsearch-05.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_001_01C12654.54A4F650 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: WG Last Call draft-aboba-dhc-domsearch-*.txt

Bernard seems to be publishing revisions of this = document faster than we can
review them!

Based on the 05 revision, I fully support this = document.

Hopefully, this document will be submitted after = draft-ietf-dhc-concat-01.txt
goes to RFC (or in parallel) such that the RFC can = be referenced.

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, August 14, 2001 5:02 PM
To: DHCPv4 discussion list
Subject: Announcement of WG last call for
<draft-aboba-dhc-domsearch-04.txt> (corrected = ID reference)


This message announces a DHC WG last call for = "DHCP
Domain Search Option" = <draft-aboba-dhc-domsearch-04.txt>.
At the WG meeting in London the WG agreed to go to = WG
last call for this draft immediately after = IETF-51.

Please forward any comments you may have on this = draft
to dhcp-v4@bucknell.edu by Friday, August 24.

- Ralph Droms
     

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Thursday, August 16, 2001 7:01 AM
Subject: I-D = ACTION:draft-aboba-dhc-domsearch-05.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.


        Title           : = DHCP Domain Search Option
        Author(s)       : B. = Aboba
        Filename        : = draft-aboba-dhc-domsearch-05.txt
        Pages           : = 5
        Date    =         : 15-Aug-01
       =20
The Dynamic Host Configuration Protocol (DHCP) = provides a mechanism for
host configuration. RFC 2132 allows DHCP servers to = specify
configuration information for various kinds of name = services to be
passed to DHCP clients.  In some circumstances, = it is useful for the
DHCP client to be configured with the domain search = list.  This document
defines a new DHCP option which is passed from the = DHCP Server to the
DHCP Client to specify the domain seach list when = resolving hostnames.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-aboba-dhc-do= msearch-05.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-aboba-dhc-domsearch-05.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-aboba-dhc-domsearch-05.txt".
       =20
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.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C12654.54A4F650-- ------_=_NextPart_000_01C12654.54A4F650 Content-Type: message/rfc822 To: Subject: Date: Thu, 16 Aug 2001 08:06:58 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C12654.54A4F650" ------_=_NextPart_002_01C12654.54A4F650 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C12654.54A4F650" ------_=_NextPart_003_01C12654.54A4F650 Content-Type: text/plain ------_=_NextPart_003_01C12654.54A4F650 Content-Type: text/html

  ------_=_NextPart_003_01C12654.54A4F650-- ------_=_NextPart_002_01C12654.54A4F650 Content-Type: application/octet-stream; name="ATT91955" Content-Disposition: attachment; filename="ATT91955" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20010815144852.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-aboba-dhc-domsearch-05.txt ------_=_NextPart_002_01C12654.54A4F650 Content-Type: message/external-body; site="internet-drafts"; dir="draft-aboba-dhc-domsearch-05.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C12654.54A4F650-- ------_=_NextPart_000_01C12654.54A4F650-- From owner-dhcp-v4@bucknell.edu Fri Aug 17 06:26:28 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22833 for ; Fri, 17 Aug 2001 06:26:28 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7HANX323205; Fri, 17 Aug 2001 06:23:33 -0400 (EDT) Received: from palrel2.hp.com (palrel2.hp.com [156.153.255.234]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7HANQ310028 for ; Fri, 17 Aug 2001 06:23:26 -0400 (EDT) Received: from postbox.india.hp.com (postbox.india.hp.com [15.10.45.1]) by palrel2.hp.com (Postfix) with ESMTP id E7C8F16B0 for ; Fri, 17 Aug 2001 03:23:23 -0700 (PDT) Received: from india.hp.com (bansal@tohfa.india.hp.com [15.10.44.199]) by postbox.india.hp.com (8.9.3 (PHNE_18546)/8.9.3 SMKit7.02) with ESMTP id PAA12983 for ; Fri, 17 Aug 2001 15:59:34 +0530 (IST) Sender: owner-dhcp-v4@bucknell.edu Message-ID: <3B7CF064.D94B6AF7@india.hp.com> Date: Fri, 17 Aug 2001 15:52:28 +0530 From: AJAY BANSAL Organization: HP-ISO X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/712) X-Accept-Language: en MIME-Version: 1.0 To: DHCPv4 discussion list Subject: isc dhcp ver-3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: bansal@india.hp.com X-Sender: bansal@india.hp.com X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Content-Transfer-Encoding: 7bit Does the latest version of ISC DHCP implementation support 'sub-net selection option" i.e. rfc 3011? thanks and regards, Ajay Bansal. From owner-dhcp-v4@bucknell.edu Fri Aug 17 07:04:50 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23475 for ; Fri, 17 Aug 2001 07:04:50 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7HB3N319735; Fri, 17 Aug 2001 07:03:23 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7HB3K322572 for ; Fri, 17 Aug 2001 07:03:20 -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 HAA23172; Fri, 17 Aug 2001 07:02:06 -0400 (EDT) Message-Id: <200108171102.HAA23172@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-pv4-reconfigure-06.txt Date: Fri, 17 Aug 2001 07:02:06 -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 reconfigure extension Author(s) : Y. T'Joens, C. Hublet, P. De Schrijver Filename : draft-ietf-dhc-pv4-reconfigure-06.txt Pages : 6 Date : 16-Aug-01 This draft defines extensions to DHCP [DHCP] to allow dynamic reconfiguration of a single host triggered by the DHCP server (eg. a new IP address and/or local configuration parameters). This is achieved by introducing a unicast FORCERENEW message which forces the client to the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-pv4-reconfigure-06.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-pv4-reconfigure-06.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-pv4-reconfigure-06.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: <20010816080052.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-pv4-reconfigure-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-pv4-reconfigure-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20010816080052.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-dhcp-v6@bucknell.edu Fri Aug 17 07:37:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24447; Fri, 17 Aug 2001 07:37:20 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7HBbP319824; Fri, 17 Aug 2001 07:37:25 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7HBbK300726 for ; Fri, 17 Aug 2001 07:37:20 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7HBbGp26725 for ; Fri, 17 Aug 2001 06:37:20 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7HBbFN25404 for ; Fri, 17 Aug 2001 06:37:16 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Aug 17 06:37:15 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 17 Aug 2001 06:37:14 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3434@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: Quick-exchange when not getting addresses? Date: Fri, 17 Aug 2001 06:37:12 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12710.F4D2A4D0" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12710.F4D2A4D0 Content-Type: text/plain; charset="iso-8859-1" Folks: While for now we have agreed to defer the "quick-exchange" (2 message - "request"/"reply") exchange for configuration, I'm wondering whether we *CAN* allow for this if a client is simply getting non-address based configuration (such as the domain name, the domain name search list, ...)? And, if so, that this is simply done by doing a Solicit (with an approporiate ORO) and using the results from one of the received Advertises? Put another way, what's preventing a client from doing this anyway? (It could do this even in DHCP v4 if it did't care to get an address. Do any clients do this?) If people feel, hey we agreed not to go there for now, we can defer this. There are just some applications where this would be extremely beneficial to specify this now. > Bernie Volz > Chief Technical Officer - DNS & DHCP Development Unit > Ericsson, Inc. > Tel: +1-508-875-3162 > Fax: +1-508-875-3018 > Mobile: +1-617-513-9060 > mailto:bernie.volz@ericsson.com > > ------_=_NextPart_001_01C12710.F4D2A4D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Quick-exchange when not getting addresses?

Folks:

While for now we have agreed to defer = the "quick-exchange" (2 message - = "request"/"reply") exchange for configuration, I'm = wondering whether we *CAN* allow for this if a client is simply getting = non-address based configuration (such as the domain name, the domain = name search list, ...)? And, if so, that this is simply done by doing a = Solicit (with an approporiate ORO) and using the results from one of = the received Advertises? Put another way, what's preventing a client = from doing this anyway? (It could do this even in DHCP v4 if it did't = care to get an address. Do any clients do this?)

If people feel, hey we agreed not to = go there for now, we can defer this. There are just some applications = where this would be extremely beneficial to specify this = now.

Bernie Volz
Chief Technical Officer - = DNS & DHCP Development Unit
Ericsson, Inc.
Tel: +1-508-875-3162
Fax: +1-508-875-3018
Mobile: = +1-617-513-9060
mailto:bernie.volz@ericsson.com=


------_=_NextPart_001_01C12710.F4D2A4D0-- From owner-dhcp-v4@bucknell.edu Fri Aug 17 09:17:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29349 for ; Fri, 17 Aug 2001 09:17:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7HDEK327555; Fri, 17 Aug 2001 09:14:20 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7HDEE322938 for ; Fri, 17 Aug 2001 09:14:14 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2ive00p.dialup.mindspring.com [165.247.0.25]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7HD8Of19531; Fri, 17 Aug 2001 06:08:24 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7HD9js03132; Fri, 17 Aug 2001 09:09:45 -0400 (EDT) Message-Id: <200108171309.f7HD9js03132@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: isc dhcp ver-3 In-Reply-To: Message from AJAY BANSAL of "Fri, 17 Aug 2001 15:52:28 +0530." <3B7CF064.D94B6AF7@india.hp.com> Date: Fri, 17 Aug 2001 09:09:45 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > Does the latest version of ISC DHCP implementation > support 'sub-net selection option" i.e. rfc 3011? Yes. _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Aug 17 09:17:20 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29370; Fri, 17 Aug 2001 09:17:19 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7HDGs329663; Fri, 17 Aug 2001 09:16:54 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7HDGm309329 for ; Fri, 17 Aug 2001 09:16:48 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2ive00p.dialup.mindspring.com [165.247.0.25]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7HDBNf19539 for ; Fri, 17 Aug 2001 06:11:24 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7HDCis03145 for ; Fri, 17 Aug 2001 09:12:44 -0400 (EDT) Message-Id: <200108171312.f7HDCis03145@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Quick-exchange when not getting addresses? In-Reply-To: Message from "Bernie Volz (EUD)" of "Fri, 17 Aug 2001 06:37:12 CDT." <66F66129A77AD411B76200508B65AC697B3434@eambunt705.ena-east.ericsson.se> Date: Fri, 17 Aug 2001 09:12:44 -0400 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I actually suggested at one point that we have a DHCPINFORM/DHCPreply message pair to solve this problem, but I decided not to push for it because it would be too much work under the present circumstances. I think overloading it onto existing messages is less of a good idea than having a seperate DHCP Information Request message, in terms of the work involved in specifying it. _MelloN_ From owner-dhcp-v6@bucknell.edu Mon Aug 20 17:49:09 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05054; Mon, 20 Aug 2001 17:49:08 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7KLn3q07018; Mon, 20 Aug 2001 17:49:03 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7KLmwq13336; Mon, 20 Aug 2001 17:48:58 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-34.cisco.com [10.82.224.34]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA17613; Mon, 20 Aug 2001 17:48:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20010820171119.03cd47b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Aug 2001 17:48:42 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Moving DHC WG mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm in the process of moving the DHC WG mailing lists to the IETF mailing list service. You will receive a message about your subscription to the new mailing list in the near future. I've created the new list by merging the old dhcp-v4 and dhcp-v6 mailing lists. I took a pass across the merged list to weed out dups and other problems; however, I can't guarantee I caught every duplicate. If I have missed a duplicate or there is some other problem with your subscription, your intro message from the new list will include instructions on managing your subscription. Also, if you *don't* receive an intro message, you can sign yourself up at http://www.ietf.org/mailman/listinfo/dhcwg - Ralph Droms Chair, DHC WG From owner-dhcp-v4@bucknell.edu Mon Aug 20 17:54:26 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05181 for ; Mon, 20 Aug 2001 17:54:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7KLn3q15316; Mon, 20 Aug 2001 17:49:05 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7KLmwq13336; Mon, 20 Aug 2001 17:48:58 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-34.cisco.com [10.82.224.34]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA17613; Mon, 20 Aug 2001 17:48:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20010820171119.03cd47b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Aug 2001 17:48:42 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Moving DHC WG mailing list Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I'm in the process of moving the DHC WG mailing lists to the IETF mailing list service. You will receive a message about your subscription to the new mailing list in the near future. I've created the new list by merging the old dhcp-v4 and dhcp-v6 mailing lists. I took a pass across the merged list to weed out dups and other problems; however, I can't guarantee I caught every duplicate. If I have missed a duplicate or there is some other problem with your subscription, your intro message from the new list will include instructions on managing your subscription. Also, if you *don't* receive an intro message, you can sign yourself up at http://www.ietf.org/mailman/listinfo/dhcwg - Ralph Droms Chair, DHC WG From dhcwg-admin@ietf.org Mon Aug 20 17:58:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05274 for ; Mon, 20 Aug 2001 17:58:31 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14888 for ; Mon, 20 Aug 2001 17:59:47 -0400 (EDT) Date: Mon, 20 Aug 2001 17:59:47 -0400 (EDT) Message-Id: <200108202159.RAA14888@optimus.ietf.org> From: dhcwg-admin@ietf.org Subject: Welcome To "Dhcwg"! To: DHC-ARCHIVE@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: Welcome to the Dhcwg@ietf.org mailing list! ********** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. ********* To post to this list, send your email to: dhcwg@ietf.org General information about the mailing list is at: http://www1.ietf.org/mailman/listinfo/dhcwg If you ever want to unsubscribe or change your options (eg, switch to or from digest mode, change your password, etc.), visit your subscription page at: http://www1.ietf.org/mailman/options/dhcwg/dhc-archive@lists.ietf.org You can also make such adjustments via email by sending a message to: Dhcwg-request@ietf.org with the word `help' in the subject or body (don't include the quotes), and you will get back a message with instructions. You must know your password to change your options (including changing the password, itself) or to unsubscribe. It is: aCBd If you forget your password, don't worry, you will receive a monthly reminder telling you what all your ietf.org mailing list passwords are, and how to unsubscribe or change your options. There is also a button on your options page that will email your current password to you. You may also have your password mailed to you automatically off of the Web page noted above. From dhcwg-admin@ietf.org Mon Aug 20 18:13:22 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05646; Mon, 20 Aug 2001 18:13:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17716; Mon, 20 Aug 2001 18:11:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17693 for ; Mon, 20 Aug 2001 18:11:46 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05592 for ; Mon, 20 Aug 2001 18:10:28 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-34.cisco.com [10.82.224.34]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA19864 for ; Mon, 20 Aug 2001 18:11:14 -0400 (EDT) Message-Id: <4.3.2.7.2.20010820180733.03ce4ee8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Aug 2001 18:11:20 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Dhcwg] Launch message for dhcwg@ietf.org Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Welcome to the dhcwg@ietf.org mailing list. www.dhcp.org is going to be off-line until further notice while I find it a new home... - Ralph _______________________________________________ Dhcwg mailing list Dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From owner-dhcp-v6@bucknell.edu Mon Aug 20 20:11:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08031; Mon, 20 Aug 2001 20:11:01 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7L0BLq23025; Mon, 20 Aug 2001 20:11:21 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7L0BIq19793 for ; Mon, 20 Aug 2001 20:11:18 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-87.cisco.com [10.82.240.87]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id UAA27842 for ; Mon, 20 Aug 2001 20:11:01 -0400 (EDT) Message-Id: <4.3.2.7.2.20010820200800.036b5530@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 20 Aug 2001 20:11:04 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Changes to Solicit/Advertise message exchange Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Here is the new text describing the Solicit/Advertise message exchange. Note that the section numbers have changed. This text addresses the following action items from the WG meeting in London: * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond * Make the preference field an option WG consensus: yes The changes in this text include: * Moved some text from "implementor guides" to Solicit/Advertise section * Clarified that the server sends addresses to be assigned in IAs to client * Clarified use of ORO by server to determine options in Advertise * Added section describing address and option value selection; this section to be referenced in later sections. * Added text for Preference option Affected text: -------------- 12. Selecting addresses for assignment to an IA A server selects addresses to be assigned to an IA according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from the following sources: - The link to which the client is attached: * If the server receives the message directly from the client, then the client is on the same link to which the interface over which the message was received is attached * If the server receives the message from a forwarding relay agent, then the client is on the same link as the interface to which the relay's address in the message from the relay is attached - The DUID supplied by the client - Other information in options supplied by the client - Other information in options supplied by the relay agent 13. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. 13.1. Solicit Message Validation Clients MUST silently discard any received Solicit messages. Agents MUST silently discard any received Solicit messages if the "client-link-local-address" field does not contain a valid link-local address. 13.2. Advertise Message Validation Servers MUST discard any received Advertise messages. Clients MUST discard any Advertise messages that meet any of the following criteria: o The "Transaction-ID" field value does not match the value the client used in its Solicit message. o The "client-link-local-address" field value does not match the link-local address of the interface upon which the client sent the Solicit message. 13.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. 13.3.1. Creation and sending of the Solicit message The client sets the "msg-type" field to SOLICIT, and places the link-local address of the interface it wishes to configure in the "client-link-local-address" field. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. The client sends the Solicit message to the 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. 13.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 MAY choose to stop trying to DHCP configure the interface. An event external to DHCP is required to restart the DHCP configuration process. A DHCP client MAY, alternatively, choose to continue sending Solicit messages at the ADV_MSG_MAX interval. Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5. 13.3.3. Receipt of Advertise messages A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message to collect Advertise messages, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 18.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional 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 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, the client may choose a server that returned an advertisement with configuration options of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as server preference value, addresses 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. If the client needs to select an alternate server in the case that a chosen server does not respond, the client chooses the server with the next highest preference value. The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. 13.4. Server Behavior A server sends an Advertise message in response to Solicit messages it receives to announce the availability of the server to the client. 13.4.1. Receipt of Solicit messages The server determines the information about the client and its location as described in section 12. If administrative policy permits the server to respond to the client, the server will generate and send an Advertise message to the client. 13.4.2. Creation and sending of Advertise messages The server sets the "msg-type" field to ADVERTISE and copies the values of the following fields from the client's Solicit to the Advertise message: o transaction-ID o client-link-local-address The server places one of its IP addresses (determined through administrator setting) in the "server-address" field of the Advertise message. The server MAY add a Preference option to carry the preference value for the Advertise message. The server implementation SHOULD allow the setting of a server preference value by the administrator. The server preference value MUST default to zero unless otherwise configured by the server administrator. The server MUST include options to the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MAY choose to send an Advertise message to the client that includes no IA options. The server MAY include other options the server will return to the client in a subsequent Reply message. The information in these options will be used by the client in the selection of a server if the client receives more than one Advertise message. The server SHOULD include options specifying values for options requested by the client in an Option Request Option included in the Solicit message. If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "server-message" option. The server unicasts the Relay-reply message to the address in the "relay-address" field from the Relay-forward message. If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the "client-link-local-address" field value as the destination address. The Advertise message MUST be unicast through the interface on which the Solicit message was received. 18.5. Preference option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PREFERENCE | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref value | +-+-+-+-+-+-+-+-+ option-code OPTION_PREFERENCE (3) option-len MUST be 1 option-data The server's preference value for this message. From owner-dhcp-v6@bucknell.edu Tue Aug 21 09:39:34 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12291; Tue, 21 Aug 2001 09:39:33 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7LDcmq19528; Tue, 21 Aug 2001 09:38:49 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7LDcdq16257 for ; Tue, 21 Aug 2001 09:38:40 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7LDcN524050 for ; Tue, 21 Aug 2001 08:38:24 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7LDcNe00887 for ; Tue, 21 Aug 2001 08:38:23 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Tue Aug 21 08:38:23 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Tue, 21 Aug 2001 08:38:22 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B345E@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Changes to Solicit/Advertise message exchange Date: Tue, 21 Aug 2001 08:38:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12A46.8894E060" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12A46.8894E060 Content-Type: text/plain; charset="iso-8859-1" Ralph: Thanks for supplying the text. Some comments inline below (prefixed by BV>). - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, August 20, 2001 8:11 PM To: DHCPv6 discussion list Subject: Changes to Solicit/Advertise message exchange Here is the new text describing the Solicit/Advertise message exchange. Note that the section numbers have changed. This text addresses the following action items from the WG meeting in London: * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond * Make the preference field an option WG consensus: yes The changes in this text include: * Moved some text from "implementor guides" to Solicit/Advertise section * Clarified that the server sends addresses to be assigned in IAs to client * Clarified use of ORO by server to determine options in Advertise * Added section describing address and option value selection; this section to be referenced in later sections. * Added text for Preference option Affected text: -------------- 12. Selecting addresses for assignment to an IA A server selects addresses to be assigned to an IA according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from the following sources: - The link to which the client is attached: * If the server receives the message directly from the client, then the client is on the same link to which the interface over which the message was received is attached * If the server receives the message from a forwarding relay agent, then the client is on the same link as the interface to which the relay's address in the message from the relay is attached BV> If this section applies to *ALL* cases where the server does address BV> assignment (not just the Solicit/Advertise phase), this is incomplete BV> as there is the case of the client unicasting to the server - in BV> which case, the above assumptions do not work. BV> BV> I would order the list to match better the processing as follows: BV> * ... relay forward message BV> * If the server receives the message directly from the client: BV> * if the source address is not a link-local address and the BV> client is allowed to unicast, then the server must determine BV> the location of the client from the non-link-local address. BV> * otherwise, the interface on which the message was received. - The DUID supplied by the client - Other information in options supplied by the client - Other information in options supplied by the relay agent 13. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. 13.1. Solicit Message Validation Clients MUST silently discard any received Solicit messages. Agents MUST silently discard any received Solicit messages if the "client-link-local-address" field does not contain a valid link-local address. BV> Are we keeping this "client-link-local-address" field or are we using BV> the source address of the packet and dropping this field. As we don't BV> have the complete text, it is difficult to know. If we are using the BV> IPv6 source address field, then it should specify that field. 13.2. Advertise Message Validation Servers MUST discard any received Advertise messages. Clients MUST discard any Advertise messages that meet any of the following criteria: o The "Transaction-ID" field value does not match the value the client used in its Solicit message. o The "client-link-local-address" field value does not match the link-local address of the interface upon which the client sent the Solicit message. BV> What about relays? Shouldn't it be "Agents MUST discard any received BV> Advertise messages."? A relay will only receive these in relay-reply BV> messages. 13.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. 13.3.1. Creation and sending of the Solicit message The client sets the "msg-type" field to SOLICIT, and places the link-local address of the interface it wishes to configure in the "client-link-local-address" field. BV> See earlier about this "client-link-locak-address" field. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request BV> Regarding these "hint" addresses: BV> 1) They probably won't be in the the IAs (at least not in the IA BV> option). BV> 2) Are these supposed to be complete addresses (not just prefixes)? BV> How is the client supposed to determine these? If it already BV> had addresses and wants to renew, why is it using Solicit? Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. The client sends the Solicit message to the 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. 13.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 MAY choose to stop trying to DHCP configure the interface. An event external to DHCP is required to restart the DHCP configuration process. A DHCP client MAY, alternatively, choose to continue sending Solicit messages at the ADV_MSG_MAX interval. Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5. BV> Wasn't there a single section written earlier that described the BV> general retransmission algorithm? Can't we just point to that instead BV> of having to write it out here? 13.3.3. Receipt of Advertise messages A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message to collect Advertise messages, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 18.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional 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 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, the client may choose a server that returned an advertisement with configuration options of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as server preference value, addresses 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. If the client needs to select an alternate server in the case that a chosen server does not respond, the client chooses the server with the next highest preference value. The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. 13.4. Server Behavior A server sends an Advertise message in response to Solicit messages it receives to announce the availability of the server to the client. 13.4.1. Receipt of Solicit messages The server determines the information about the client and its location as described in section 12. If administrative policy permits the server to respond to the client, the server will generate and send an Advertise message to the client. 13.4.2. Creation and sending of Advertise messages The server sets the "msg-type" field to ADVERTISE and copies the values of the following fields from the client's Solicit to the Advertise message: o transaction-ID o client-link-local-address BV> See earlier regarding this field. The server places one of its IP addresses (determined through administrator setting) in the "server-address" field of the Advertise message. The server MAY add a Preference option to carry the preference value for the Advertise message. The server implementation SHOULD allow the setting of a server preference value by the administrator. The server preference value MUST default to zero unless otherwise configured by the server administrator. The server MUST include options to the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MAY choose to send an Advertise message to the client that includes no IA options. The server MAY include other options the server will return to the client in a subsequent Reply message. The information in these options will be used by the client in the selection of a server if the client receives more than one Advertise message. The server SHOULD include options specifying values for options requested by the client in an Option Request Option included in the Solicit message. If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "server-message" option. The server unicasts the Relay-reply message to the address in the "relay-address" field from the Relay-forward message. If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the "client-link-local-address" field value as the destination address. The Advertise message MUST be unicast through the interface on which the Solicit message was received. BV> The above is broken regarding the sending of responses if we are going BV> to support server unicast. We really should change this to: BV> If Relay-forward received, send Relay-reply OTHERWISE unicast Solicit BV> to source IPv6 address of Solicit message. [Perhaps this is overkill BV> in the cast of Solicit/Advertise since the client should never be BV> unicasting Solicits. But I think it is just simpler and more consistent BV> to have *ONE* send policy. Also, we were considering dropping the BV> "client-link-local-address" field. 18.5. Preference option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PREFERENCE | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref value | +-+-+-+-+-+-+-+-+ option-code OPTION_PREFERENCE (3) option-len MUST be 1 option-data The server's preference value for this message. BV> Perhaps add a comment that higher numbers indicate a greater preference BV> for this server. If no perf value supplied in an Advertise, the default BV> is 0 (lowest preference). ------_=_NextPart_001_01C12A46.8894E060 Content-Type: text/html; charset="iso-8859-1" RE: Changes to Solicit/Advertise message exchange

Ralph:

Thanks for supplying the text. Some comments inline below (prefixed by BV>).

- Bernie Volz

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, August 20, 2001 8:11 PM
To: DHCPv6 discussion list
Subject: Changes to Solicit/Advertise message exchange


Here is the new text describing the Solicit/Advertise message
exchange.  Note that the section numbers have changed.  This
text addresses the following action items from the WG
meeting in London:

* Should addresses in an Advertise message be "real" addresses or
  "informational"; e.g., just prefixes?

  WG consensus: addresses in Advertise are the addresses the server
  will return in a subsequent Reply; client supplies those addresses
  to server in IA in Request message

* Advertise message SHOULD include options for all OROs that were
  included in the Solicit if the server is willing/capable of offering
  a value for that option

  WG consensus: yes

* Server does not respond to Solicit when client wants addresses and
  server has no addresses

  WG consensus: Server should be allowed to respond

* Make the preference field an option

  WG consensus: yes

The changes in this text include:

* Moved some text from "implementor guides" to Solicit/Advertise
  section
* Clarified that the server sends addresses to be assigned in IAs to
  client
* Clarified use of ORO by server to determine options in Advertise
* Added section describing address and option value selection; this
  section to be referenced in later sections.
* Added text for Preference option

Affected text:
--------------

12. Selecting addresses for assignment to an IA

   A server selects addresses to be assigned to an IA according to the
   address assignment policies determined by the server administrator
   and the specific information the server determines about the client
   from the following sources:

    -  The link to which the client is attached:

        *  If the server receives the message directly from the client,
           then the client is on the same link to which the interface
           over which the message was received is attached

        *  If the server receives the message from a forwarding relay
           agent, then the client is on the same link as the interface
           to which the relay's address in the message from the relay is
           attached

BV> If this section applies to *ALL* cases where the server does address
BV> assignment (not just the Solicit/Advertise phase), this is incomplete
BV> as there is the case of the client unicasting to the server - in
BV> which case, the above assumptions do not work.
BV>
BV> I would order the list to match better the processing as follows:
BV>   * ... relay forward message
BV>   * If the server receives the message directly from the client:
BV>        * if the source address is not a link-local address and the
BV>          client is allowed to unicast, then the server must determine
BV>          the location of the client from the non-link-local address.
BV>        * otherwise, the interface on which the message was received.

    -  The DUID supplied by the client

    -  Other information in options supplied by the client

    -  Other information in options supplied by the relay agent


13. DHCP Server Solicitation

   This section describes how a client locates servers.  The behavior
   of client and server implementations is discussed, along with the
   messages they use.


13.1. Solicit Message Validation

   Clients MUST silently discard any received Solicit messages.

   Agents MUST silently discard any received Solicit messages if the
   "client-link-local-address" field does not contain a valid link-local
   address.

BV> Are we keeping this "client-link-local-address" field or are we using
BV> the source address of the packet and dropping this field. As we don't
BV> have the complete text, it is difficult to know. If we are using the
BV> IPv6 source address field, then it should specify that field.

13.2. Advertise Message Validation

   Servers MUST discard any received Advertise messages.

   Clients MUST discard any Advertise messages that meet any of the
   following criteria:

     o The "Transaction-ID" field value does not match the value the
       client used in its Solicit message.

     o The "client-link-local-address" field value does not match the
       link-local address of the interface upon which the client sent
       the Solicit message.

BV> What about relays? Shouldn't it be "Agents MUST discard any received
BV> Advertise messages."? A relay will only receive these in relay-reply
BV> messages.

13.3. Client Behavior

   A client uses the Solicit message to discover DHCP servers configured
   to serve addresses on the link to which the client is attached.


13.3.1. Creation and sending of the Solicit message

   The client sets the "msg-type" field to SOLICIT, and places the
   link-local address of the interface it wishes to configure in the
   "client-link-local-address" field.
BV> See earlier about this "client-link-locak-address" field.

   The client generates a transaction ID and inserts this value in the
   "transaction-ID" field.

   The client includes a DUID option to identify itself to the server.
   The client MUST include options for any IAs to which it wants the
   server to assign addresses.  The client may include addresses in the
   IAs as a hint to the server about addresses for which the client
   may have a preference.  The client MAY include an Option Request
BV> Regarding these "hint" addresses:
BV>  1) They probably won't be in the the IAs (at least not in the IA
BV>     option).
BV>  2) Are these supposed to be complete addresses (not just prefixes)?
BV>     How is the client supposed to determine these? If it already
BV>     had addresses and wants to renew, why is it using Solicit?
   Option in the Solicit message.  The client MUST NOT include any other
   options except those specifically allowed as defined by specific
   options.

   The client sends the Solicit message to the 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.


13.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 MAY choose to stop trying to DHCP
   configure the interface.  An event external to DHCP is required
   to restart the DHCP configuration process.  A DHCP client MAY,
   alternatively, choose to continue sending Solicit messages at the
   ADV_MSG_MAX interval.

   Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY,
   ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5.
BV> Wasn't there a single section written earlier that described the
BV> general retransmission algorithm? Can't we just point to that instead
BV> of having to write it out here?

13.3.3. Receipt of Advertise messages

   A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP
   Solicit message to collect Advertise messages, unless it receives an
   Advertise message with a preference value of 255.  The preference
   value is carried in the Preference option (section  18.5).  Any
   Solicit that does not include a Preference option is considered to
   have a preference value of 0.  If the client receives an Advertise
   message with a preference value of 255, then the client MAY act
   immediately on that Advertise message without waiting for any more
   additional 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
       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, the client may choose a server that
       returned an advertisement with configuration options of interest
       to the client.

   Once a client has selected Advertise message(s), the client will
   typically store information about each server, such as server
   preference value, addresses 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.

   If the client needs to select an alternate server in the case that a
   chosen server does not respond, the client chooses the server with
   the next highest preference value.

   The client MAY choose a less-preferred server if that server has a
   better set of advertised parameters, such as the available addresses
   advertised in IAs.


13.4. Server Behavior

   A server sends an Advertise message in response to Solicit messages
   it receives to announce the availability of the server to the client.


13.4.1. Receipt of Solicit messages

   The server determines the information about the client and its
   location as described in section 12.  If administrative policy
   permits the server to respond to the client, the server will generate
   and send an Advertise message to the client.


13.4.2. Creation and sending of Advertise messages

   The server sets the "msg-type" field to ADVERTISE and copies the
   values of the following fields from the client's Solicit to the
   Advertise message:

     o transaction-ID

     o client-link-local-address
BV> See earlier regarding this field.

   The server places one of its IP addresses (determined through
   administrator setting) in the "server-address" field of the Advertise
   message.  The server MAY add a Preference option to carry the
   preference value for the Advertise message.

   The server implementation SHOULD allow the setting of a server
   preference value by the administrator.  The server preference value
   MUST default to zero unless otherwise configured by the server
   administrator.

   The server MUST include options to the Advertise message containing
   any addresses that would be assigned to IAs contained in the Solicit
   message from the client.  If the server will not assign any addresses
   to IAs in a subsequent Request from the client, the server MAY choose
   to send an Advertise message to the client that includes no IA
   options.  The server MAY include other options the server will return
   to the client in a subsequent Reply message.  The information in
   these options will be used by the client in the selection of a server
   if the client receives more than one Advertise message.  The server
   SHOULD include options specifying values for options requested by the
   client in an Option Request Option included in the Solicit message.

   If the Solicit message was received in a Relay-forward message, the
   server constructs a Relay-reply message with the Advertise message in
   the payload of a "server-message" option.  The server unicasts the
   Relay-reply message to the address in the "relay-address" field from
   the Relay-forward message.

   If the Solicit message was received directly by the server, the
   server unicasts the Advertise message directly to the client using
   the "client-link-local-address" field value as the destination
   address.  The Advertise message MUST be unicast through the interface
   on which the Solicit message was received.
BV> The above is broken regarding the sending of responses if we are going
BV> to support server unicast. We really should change this to:
BV>   If Relay-forward received, send Relay-reply OTHERWISE unicast Solicit
BV>   to source IPv6 address of Solicit message. [Perhaps this is overkill
BV>   in the cast of Solicit/Advertise since the client should never be
BV>   unicasting Solicits. But I think it is just simpler and more consistent
BV>   to have *ONE* send policy. Also, we were considering dropping the
BV>   "client-link-local-address" field.


18.5. Preference option

      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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       OPTION_PREFERENCE       |                1              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  pref value   |
     +-+-+-+-+-+-+-+-+



      option-code   OPTION_PREFERENCE (3)

      option-len    MUST be 1

      option-data   The server's preference value for this message.

BV> Perhaps add a comment that higher numbers indicate a greater preference
BV> for this server. If no perf value supplied in an Advertise, the default
BV> is 0 (lowest preference).

------_=_NextPart_001_01C12A46.8894E060-- From owner-dhcp-v6@bucknell.edu Tue Aug 21 09:57:02 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13580; Tue, 21 Aug 2001 09:57:02 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7LDvQq12841; Tue, 21 Aug 2001 09:57:26 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7LDvCq09303 for ; Tue, 21 Aug 2001 09:57:12 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-50.cisco.com [10.82.224.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA10607 for ; Tue, 21 Aug 2001 09:57:06 -0400 (EDT) Message-Id: <4.3.2.7.2.20010821095022.03aa6f00@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Aug 2001 09:57:01 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Changes to Solicit/Advertise message exchange Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Bernie - I've included a couple of quick comments in line. Some of your questions are artifacts, I think, of dealing with one issue at a time. For example, I expect to make the changes concerning the link-local-address field and client unicast - just haven't done those, yet. - Ralph ===== To: DHCPv6 discussion list Subject: RE: Changes to Solicit/Advertise message exchange Ralph: Thanks for supplying the text. Some comments inline below (prefixed by BV>). - Bernie Volz -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, August 20, 2001 8:11 PM To: DHCPv6 discussion list Subject: Changes to Solicit/Advertise message exchange Here is the new text describing the Solicit/Advertise message exchange. Note that the section numbers have changed. This text addresses the following action items from the WG meeting in London: * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond * Make the preference field an option WG consensus: yes The changes in this text include: * Moved some text from "implementor guides" to Solicit/Advertise section * Clarified that the server sends addresses to be assigned in IAs to client * Clarified use of ORO by server to determine options in Advertise * Added section describing address and option value selection; this section to be referenced in later sections. * Added text for Preference option Affected text: -------------- 12. Selecting addresses for assignment to an IA A server selects addresses to be assigned to an IA according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from the following sources: - The link to which the client is attached: * If the server receives the message directly from the client, then the client is on the same link to which the interface over which the message was received is attached * If the server receives the message from a forwarding relay agent, then the client is on the same link as the interface to which the relay's address in the message from the relay is attached BV> If this section applies to *ALL* cases where the server does address BV> assignment (not just the Solicit/Advertise phase), this is incomplete BV> as there is the case of the client unicasting to the server - in BV> which case, the above assumptions do not work. RD> To be fixed when I recheck entire doc for client unicast. BV> I would order the list to match better the processing as follows: BV> * ... relay forward message BV> * If the server receives the message directly from the client: BV> * if the source address is not a link-local address and the BV> client is allowed to unicast, then the server must determine BV> the location of the client from the non-link-local address. BV> * otherwise, the interface on which the message was received. RD> OK - The DUID supplied by the client - Other information in options supplied by the client - Other information in options supplied by the relay agent 13. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. 13.1. Solicit Message Validation Clients MUST silently discard any received Solicit messages. Agents MUST silently discard any received Solicit messages if the "client-link-local-address" field does not contain a valid link-local address. BV> Are we keeping this "client-link-local-address" field or are we using BV> the source address of the packet and dropping this field. As we don't BV> have the complete text, it is difficult to know. If we are using the BV> IPv6 source address field, then it should specify that field. RD> link-local-address will be removed... 13.2. Advertise Message Validation Servers MUST discard any received Advertise messages. Clients MUST discard any Advertise messages that meet any of the following criteria: o The "Transaction-ID" field value does not match the value the client used in its Solicit message. o The "client-link-local-address" field value does not match the link-local address of the interface upon which the client sent the Solicit message. BV> What about relays? Shouldn't it be "Agents MUST discard any received BV> Advertise messages."? A relay will only receive these in relay-reply BV> messages. RD> Right; good catch 13.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. 13.3.1. Creation and sending of the Solicit message The client sets the "msg-type" field to SOLICIT, and places the link-local address of the interface it wishes to configure in the "client-link-local-address" field. BV> See earlier about this "client-link-local-address" field. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request BV> Regarding these "hint" addresses: BV> 1) They probably won't be in the the IAs (at least not in the IA BV> option). RD> If not the IAs, then where? BV> 2) Are these supposed to be complete addresses (not just prefixes)? BV> How is the client supposed to determine these? If it already BV> had addresses and wants to renew, why is it using Solicit? RD> This is an issue for WG discussion. Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. The client sends the Solicit message to the 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. 13.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 MAY choose to stop trying to DHCP configure the interface. An event external to DHCP is required to restart the DHCP configuration process. A DHCP client MAY, alternatively, choose to continue sending Solicit messages at the ADV_MSG_MAX interval. Default and initial values for MIN_SOL_DELAY, MAX_SOL_DELAY, ADV_MSG_TIMEOUT, AND ADV_MSG_MAX are documented in section 7.5. BV> Wasn't there a single section written earlier that described the BV> general retransmission algorithm? Can't we just point to that instead BV> of having to write it out here? RD> I haven't made that change yet. 13.3.3. Receipt of Advertise messages A client MUST wait for SRVR_PREF_WAIT seconds after sending a DHCP Solicit message to collect Advertise messages, unless it receives an Advertise message with a preference value of 255. The preference value is carried in the Preference option (section 18.5). Any Solicit that does not include a Preference option is considered to have a preference value of 0. If the client receives an Advertise message with a preference value of 255, then the client MAY act immediately on that Advertise message without waiting for any more additional 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 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, the client may choose a server that returned an advertisement with configuration options of interest to the client. Once a client has selected Advertise message(s), the client will typically store information about each server, such as server preference value, addresses 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. If the client needs to select an alternate server in the case that a chosen server does not respond, the client chooses the server with the next highest preference value. The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs. 13.4. Server Behavior A server sends an Advertise message in response to Solicit messages it receives to announce the availability of the server to the client. 13.4.1. Receipt of Solicit messages The server determines the information about the client and its location as described in section 12. If administrative policy permits the server to respond to the client, the server will generate and send an Advertise message to the client. 13.4.2. Creation and sending of Advertise messages The server sets the "msg-type" field to ADVERTISE and copies the values of the following fields from the client's Solicit to the Advertise message: o transaction-ID o client-link-local-address BV> See earlier regarding this field. The server places one of its IP addresses (determined through administrator setting) in the "server-address" field of the Advertise message. The server MAY add a Preference option to carry the preference value for the Advertise message. The server implementation SHOULD allow the setting of a server preference value by the administrator. The server preference value MUST default to zero unless otherwise configured by the server administrator. The server MUST include options to the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MAY choose to send an Advertise message to the client that includes no IA options. The server MAY include other options the server will return to the client in a subsequent Reply message. The information in these options will be used by the client in the selection of a server if the client receives more than one Advertise message. The server SHOULD include options specifying values for options requested by the client in an Option Request Option included in the Solicit message. If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "server-message" option. The server unicasts the Relay-reply message to the address in the "relay-address" field from the Relay-forward message. If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the "client-link-local-address" field value as the destination address. The Advertise message MUST be unicast through the interface on which the Solicit message was received. BV> The above is broken regarding the sending of responses if we are going BV> to support server unicast. We really should change this to: BV> If Relay-forward received, send Relay-reply OTHERWISE unicast Solicit BV> to source IPv6 address of Solicit message. [Perhaps this is overkill BV> in the cast of Solicit/Advertise since the client should never be BV> unicasting Solicits. But I think it is just simpler and more consistent BV> to have *ONE* send policy. Also, we were considering dropping the BV> "client-link-local-address" field. RD> To be fixed soon. 18.5. Preference option 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_PREFERENCE | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | pref value | +-+-+-+-+-+-+-+-+ option-code OPTION_PREFERENCE (3) option-len MUST be 1 option-data The server's preference value for this message. BV> Perhaps add a comment that higher numbers indicate a greater preference BV> for this server. If no perf value supplied in an Advertise, the default BV> is 0 (lowest preference). RD> OK. From owner-dhcp-v6@bucknell.edu Tue Aug 21 11:40:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21091; Tue, 21 Aug 2001 11:40:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7LFe4q08844; Tue, 21 Aug 2001 11:40:05 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7LFe2q04039 for ; Tue, 21 Aug 2001 11:40:02 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-50.cisco.com [10.82.224.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA26081 for ; Tue, 21 Aug 2001 11:39:45 -0400 (EDT) Message-Id: <4.3.2.7.2.20010821113929.00bbfee8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Aug 2001 11:39:44 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Minutes from WG meeting in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Please reply to the mailing list with any comments about the draft minutes I posted from the DHC WG meeting in London. - Ralph From owner-dhcp-v4@bucknell.edu Tue Aug 21 11:45:25 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21293 for ; Tue, 21 Aug 2001 11:45:25 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7LFe4q15398; Tue, 21 Aug 2001 11:40:07 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7LFe3q30960 for ; Tue, 21 Aug 2001 11:40:03 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-50.cisco.com [10.82.224.50]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA26089 for ; Tue, 21 Aug 2001 11:39:47 -0400 (EDT) Message-Id: <4.3.2.7.2.20010821113043.00b6e970@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 21 Aug 2001 11:39:28 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Several reminders Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I have some reminders to send along... Please reply to the mailing list with any comments about the draft minutes I posted from the DHC WG meeting in London. If you gave a presentation at the WG meeting, please send me a copy for inclusion in the proceedings. WG last calls have been posted for all of the following docs; please be sure to respond with comments by the end of the last call period (8/24): The Classless Static Route Option for DHCP Encoding Long DHCP Options The DHCP Client FQDN Option Resolution of DNS Name Conflicts Among DHCP Clients DHCP Domain Search Option Subnet Selection sub-option for the Relay Agent Information Option Addition of Device Class to Agent Options From owner-dhcp-v6@bucknell.edu Wed Aug 22 07:42:48 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00544; Wed, 22 Aug 2001 07:42:48 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7MBhEq10176; Wed, 22 Aug 2001 07:43:14 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7MBh7q08227; Wed, 22 Aug 2001 07:43:07 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjck-dial-gw5-215.cisco.com [10.19.238.216]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26544; Wed, 22 Aug 2001 07:42:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20010822073358.03ba4410@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Aug 2001 07:42:51 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Minutes from WG meeting in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Please reply to the mailing list with any comments about the draft minutes (included below) from the DHC WG meeting in London. - Ralph dhc - Wednesday, 3:30PM ======================= Thanks to Stuart Cheshire for taking the notes on which this summary is based. Ralph gave a summary of WG status and activities: The DHCP Reconfigure Extension has been reviewed by IESG; it was subsequently revised and resubmitted by the authors. The draft is now waiting IESG re-review. Ralph asked if there are any existing or planned implementations of DHCP Reconfigure. None are existing. One person said they had a planned implementation. Several drafts are ready for WG Last Call: * Encoding Long DHCP Options * The Classless Static Route Option for DHCP * DHCP Domain Search Option * The DHCP Client FQDN Option * Resolution of DNS Name Conflicts Among DHCP Clients * Subnet Selection sub-option for the Relay Agent Information Option * Addition of Device Class to Agent Options Ralph will initiate WG last call for these drafts after IETF-51. Ralph asked for someone to volunteer to write a document listing all known DHCP vendor options. Barr Hibbs volunteered. Failover Protocol, Mark Stapp ------------------------------------ Mark asked whether draft is ready for last-call. The hum from WG indicated the WG thinks it is. Ralph will initiate a WG last call after IETF-51. 802.1X WEP Key Management using DHCP, Bill Arbaugh -------------------------------------------------- Bill's draft proposed doing key management via a DHCP option. Every time client renews its lease it gets a new WEP key. This could allow the WEP key to be changed fairly frequently - e.g. every five minutes. Stuart Cheshire asked if this functions duplicates 802.1X functionality? Answer: Yes, but 802.1X is not widespread yet, and we want this now. However, it's not clear how long this will take to get deployed. For example, the Mac OS 9 DHCP client would need to be updated to request this new option, and no new updates are planned for OS 9 now that all Apple's efforts are focused on OS X. In contrast, an 802.1X client can be implemented by any third-party without any special support from the OS, so it is likely that 802.1X could be implemented far quicker than this DHCP extension. Mark Stapp thought the draft was worth pursuing. Erik Nordmark expressed concern that pursuing this option confuses users by providing two ways to do key management, and ultimately slows adoption of either. It is better to focus efforts on deploying 802.1X. Show of hands for who would like work to continue on this draft: Only Ralph raised his hand. DHCP mDNS Enable Option, Erik Guttman -------------------------------------- Erik presented a summary of client mDNS default behavior and the function of a proposed option to enable the use of mDNS. Stuart Cheshire pointed out that the proposed default behavior, if the DHCP server does not support this option, is that Multicast DNS should not be used. This basically means that today, Multicast DNS will not be allowed to work on any network where DHCP servers are present, which in turn means that there is no incentive for anyone to implement Multicast DNS. Resolution - zeroconf WG will cotinue work on this option; dhc WG will review any option on standards track LDAP Schema for DHCP, Vijay Nanjundaswamy ----------------------------------- Vijay K. N. spoke about the latest LDAP schema definition. Mark Stapp noted that including lease information has huge performance implications. Ted Lemon gave the opinion that if the schema can be defined to accommodate the DHCP server data and work at some scale, then the schema is valid and the performance problem should be tackled separately. The schema recommends isolating leases in a container object to improve manageability. There is a server-specific extension that holds information that is only relevant to one particular implementation server. Mark Stapp asked if the authors had surveyed DHCP implementations to see if there is enough common configuration or operational information to make an interesting schema. Erik Guttman notes that the DMTF stays away details like this schema for individual services. Vijay identified an action item to survey existing servers to determine common functions. Ted Lemon pointed out that claiming improved reliability through the use of and LDAP store just moves the single point of failure from the DHCP server to the LDAP server. Mark Stapp asked if there is enough commonality between the configuration options and features of different DHCP Servers for a common LDAP schema to be useful? Authors responded that they will do a summary of existing servers to determine applicability of a common LDPA schema. Erik Guttman asked who actually wants this? Ted Lemon suggested that the authors should try implementing it first before talking about publishing it as an RFC. The authors have received comments from the WG and modified the draft according to those comments (where appropriate). The authors have also made some other changes independent of WG feedback. VPN Identifier sub-option for the Relay Agent Information Option, DHCP VPN Information option Mark Stapp ----------------------------------------------------------------- These drafts carry similar information through a DHCP option and a relay agent sub-option. The drafts give two encodings for VPN identifier: vrfs and RFC2685 vpn id. No response from WG. Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Jim Bound, Ralph Droms ------------------------------------------------------ This draft is currently the highest numbered draft in the ID directory. Ralph proposed to go through list of action items and try to establish where we have consensus. Mark Stapp suggested the WG should discuss structure of IA option first, because it affects other discussion. * Mark Stapp suggested a number of problems have arisen because of "C struct"-like structure of IA option. Mark suggests a solution like that used in failover: IP address marks a "frame", in which options specific to that address follow the IP address; IA option then marks start of a frame that carries options specific to the IA. Ted Lemon said that the current structure of the IA option is quite complicated. It would be good to simplify it. Ted suggested that, since we're under time pressure, we should establish a deadline, and if we don't have a new proposal by then, we just go with the old IA option. WG consensus: Bernie, Mark and Ted will develop text defining new IA structure. The draft text will be complete and submitted to the WG for review by 8/24. WG will review and definition will be integrated into -20 draft if approved by WG. * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Servers will only assign complete addresses and not prefixes (e.g., to be used by the client for stateless autoconfiguration) WG consensus: yes; prefix advertisement is handled through ND * Modify IA option so that all addresses in an IA are "regular" or "temporary". Modify text so that client indicates types of addresses to be assigned by sending appropriate IAs. Server then fills in each IA with assigned addresses. Open issue - hold for new IA definition (WG has already agreed that client can ask for regular or temporary addresses) * Define separate IA option for temporary addresses rather than indicate the type of address in a single IA option Open issue - hold for new IA definition * How and when does the client use DAD on addresses in Advertise and Reply messages? WG consensus: Client does DAD on addresses in Reply message and responds with Decline if addresses unacceptable (e.g., already in use) * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Should we consider a "quick" handshake for allowing a client to assign an address in a single exchange of two messages? WG consensus: defer for later reconsideration * Tighten up text on T1/T2 to require T1/T2 occur prior to expiration of lifetimes of addresses in IA; no need to describe default as T1/T2 are fields in IA header and must be supplied by server WG consensus: Mark, Ted and Bernie will do it... Open issue: what about selection of T1/T2 with temporary addresses and with addresses whose lifetimes won't be extended; e.g. addresses to be deprecated/discarded due to renumbering. Notes: T1/T2 are independent of "regular"/"temporary" characteristic. T1/T2 might even be used for clients that do not have any assigned addresses for periodic renewal of other information * The semantics of the use of IA must be clarified (see Volz message of 7/19). In particular, what are the semantics of a Request containing an IA that the client has previously sent to the server? What are the semantics of a Request containing a new IA? Open issue: rules about when to reuse old IA or use new IA WG consensus: When the client submits an IA that the server has seen in the past, the server should interpret the request as a request for the current state of the existing IA. When the client submits an IA that the server has not seen before, the server should interpret the request as a request for additional addresses to be assigned to the new IA. Discussion to continue on WG mailing list * Simplify Release and Decline so the all of the addresses in an IA are released or declined, rather than allowing the client to release or decline just some addresses. WG consensus: Wait for Bernie to fix in IA definition * Add "NAK" function: If the server finds that the prefix on one or more IP addresses in any IA in the {Request,Confirm,Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" error code. Add text allowing client to ignore "NoPrefixMatch" from other servers if ACK received from at least one server. * Define DUID to be one of: - Link-layer address plus time - Vendor-assigned unique ID - Link-layer address - IMSI - IMEI WG consensus: yes; based on text submitted by Lemon with extensions from subsequent WG discussion * Use IPsec for secure agent/server communication WG consensus: yes; add text to draft * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes; should allow inclusion of text message * Tighten up language for unicasting Reconfigure-Init; in particular, the server may not have an appropriate address to use to send the message to the client. WG consensus: yes * Reply to a Confirm should be a simple ACK/NAK without changing any values in options WG consensus: Discussion to be taken to mailing list Note: check to make sure there is text in the draft describing behavior if no response is heard to a Confirm * Reply to Decline or Release should carry no options WG consensus: yes * Restrict options in Decline or Release to IA with text to allow other options in the future WG consensus: no; this is an overspecification * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond * Include only options specifically mentioned in the text in the DHCPv6 spec; move others to second doc or separate appendix WG consensus: anything we have consensus on stays; anything else gets punted to a separate draft. * Add 'secs' field to fixed header WG consensus: if client retransmits, MUST send option called "milliseconds" * Make the preference field an option WG consensus: yes * Describe message transmission and retransmission in a separate section of the spec and reference that text throughout the remainder of the spec WG consensus: yes * Discard the client unicast or recheck the entire spec for consistency in reference to message transmission WG consensus: yes, authors to fix spec * Remove client link-local address from client message header. Agent can then determine link-local from source (IP header) in client message and insert into agent->server message. Server responds to source from IP header (whether agent or client). WG consensus: Yes From owner-dhcp-v4@bucknell.edu Wed Aug 22 07:46:16 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00737 for ; Wed, 22 Aug 2001 07:46:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7MBgTq12848; Wed, 22 Aug 2001 07:42:29 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7MBgEq14496 for ; Wed, 22 Aug 2001 07:42:14 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjck-dial-gw5-215.cisco.com [10.19.238.216]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26495 for ; Wed, 22 Aug 2001 07:42:09 -0400 (EDT) Message-Id: <4.3.2.7.2.20010822072742.03bc5738@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Aug 2001 07:29:52 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: : Announcement of WG last call Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This message announces a DHC WG last call for "Failover Protocol" . At the WG meeting in London the WG agreed to go to WG last call for this draft immediately after IETF-51. Please forward any comments you may have on this draft to dhcp-v4@bucknell.edu by Friday, September 7. - Ralph Droms From owner-dhcp-v4@bucknell.edu Wed Aug 22 07:46:31 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00753 for ; Wed, 22 Aug 2001 07:46:31 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7MBiEq03852; Wed, 22 Aug 2001 07:44:14 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7MBh7q08227; Wed, 22 Aug 2001 07:43:07 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjck-dial-gw5-215.cisco.com [10.19.238.216]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA26544; Wed, 22 Aug 2001 07:42:49 -0400 (EDT) Message-Id: <4.3.2.7.2.20010822073358.03ba4410@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 22 Aug 2001 07:42:51 -0400 To: DHCPv4 discussion list From: Ralph Droms Subject: Minutes from WG meeting in London Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: rdroms@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Please reply to the mailing list with any comments about the draft minutes (included below) from the DHC WG meeting in London. - Ralph dhc - Wednesday, 3:30PM ======================= Thanks to Stuart Cheshire for taking the notes on which this summary is based. Ralph gave a summary of WG status and activities: The DHCP Reconfigure Extension has been reviewed by IESG; it was subsequently revised and resubmitted by the authors. The draft is now waiting IESG re-review. Ralph asked if there are any existing or planned implementations of DHCP Reconfigure. None are existing. One person said they had a planned implementation. Several drafts are ready for WG Last Call: * Encoding Long DHCP Options * The Classless Static Route Option for DHCP * DHCP Domain Search Option * The DHCP Client FQDN Option * Resolution of DNS Name Conflicts Among DHCP Clients * Subnet Selection sub-option for the Relay Agent Information Option * Addition of Device Class to Agent Options Ralph will initiate WG last call for these drafts after IETF-51. Ralph asked for someone to volunteer to write a document listing all known DHCP vendor options. Barr Hibbs volunteered. Failover Protocol, Mark Stapp ------------------------------------ Mark asked whether draft is ready for last-call. The hum from WG indicated the WG thinks it is. Ralph will initiate a WG last call after IETF-51. 802.1X WEP Key Management using DHCP, Bill Arbaugh -------------------------------------------------- Bill's draft proposed doing key management via a DHCP option. Every time client renews its lease it gets a new WEP key. This could allow the WEP key to be changed fairly frequently - e.g. every five minutes. Stuart Cheshire asked if this functions duplicates 802.1X functionality? Answer: Yes, but 802.1X is not widespread yet, and we want this now. However, it's not clear how long this will take to get deployed. For example, the Mac OS 9 DHCP client would need to be updated to request this new option, and no new updates are planned for OS 9 now that all Apple's efforts are focused on OS X. In contrast, an 802.1X client can be implemented by any third-party without any special support from the OS, so it is likely that 802.1X could be implemented far quicker than this DHCP extension. Mark Stapp thought the draft was worth pursuing. Erik Nordmark expressed concern that pursuing this option confuses users by providing two ways to do key management, and ultimately slows adoption of either. It is better to focus efforts on deploying 802.1X. Show of hands for who would like work to continue on this draft: Only Ralph raised his hand. DHCP mDNS Enable Option, Erik Guttman -------------------------------------- Erik presented a summary of client mDNS default behavior and the function of a proposed option to enable the use of mDNS. Stuart Cheshire pointed out that the proposed default behavior, if the DHCP server does not support this option, is that Multicast DNS should not be used. This basically means that today, Multicast DNS will not be allowed to work on any network where DHCP servers are present, which in turn means that there is no incentive for anyone to implement Multicast DNS. Resolution - zeroconf WG will cotinue work on this option; dhc WG will review any option on standards track LDAP Schema for DHCP, Vijay Nanjundaswamy ----------------------------------- Vijay K. N. spoke about the latest LDAP schema definition. Mark Stapp noted that including lease information has huge performance implications. Ted Lemon gave the opinion that if the schema can be defined to accommodate the DHCP server data and work at some scale, then the schema is valid and the performance problem should be tackled separately. The schema recommends isolating leases in a container object to improve manageability. There is a server-specific extension that holds information that is only relevant to one particular implementation server. Mark Stapp asked if the authors had surveyed DHCP implementations to see if there is enough common configuration or operational information to make an interesting schema. Erik Guttman notes that the DMTF stays away details like this schema for individual services. Vijay identified an action item to survey existing servers to determine common functions. Ted Lemon pointed out that claiming improved reliability through the use of and LDAP store just moves the single point of failure from the DHCP server to the LDAP server. Mark Stapp asked if there is enough commonality between the configuration options and features of different DHCP Servers for a common LDAP schema to be useful? Authors responded that they will do a summary of existing servers to determine applicability of a common LDPA schema. Erik Guttman asked who actually wants this? Ted Lemon suggested that the authors should try implementing it first before talking about publishing it as an RFC. The authors have received comments from the WG and modified the draft according to those comments (where appropriate). The authors have also made some other changes independent of WG feedback. VPN Identifier sub-option for the Relay Agent Information Option, DHCP VPN Information option Mark Stapp ----------------------------------------------------------------- These drafts carry similar information through a DHCP option and a relay agent sub-option. The drafts give two encodings for VPN identifier: vrfs and RFC2685 vpn id. No response from WG. Dynamic Host Configuration Protocol for IPv6 (DHCPv6), Jim Bound, Ralph Droms ------------------------------------------------------ This draft is currently the highest numbered draft in the ID directory. Ralph proposed to go through list of action items and try to establish where we have consensus. Mark Stapp suggested the WG should discuss structure of IA option first, because it affects other discussion. * Mark Stapp suggested a number of problems have arisen because of "C struct"-like structure of IA option. Mark suggests a solution like that used in failover: IP address marks a "frame", in which options specific to that address follow the IP address; IA option then marks start of a frame that carries options specific to the IA. Ted Lemon said that the current structure of the IA option is quite complicated. It would be good to simplify it. Ted suggested that, since we're under time pressure, we should establish a deadline, and if we don't have a new proposal by then, we just go with the old IA option. WG consensus: Bernie, Mark and Ted will develop text defining new IA structure. The draft text will be complete and submitted to the WG for review by 8/24. WG will review and definition will be integrated into -20 draft if approved by WG. * Should addresses in an Advertise message be "real" addresses or "informational"; e.g., just prefixes? WG consensus: addresses in Advertise are the addresses the server will return in a subsequent Reply; client supplies those addresses to server in IA in Request message * Servers will only assign complete addresses and not prefixes (e.g., to be used by the client for stateless autoconfiguration) WG consensus: yes; prefix advertisement is handled through ND * Modify IA option so that all addresses in an IA are "regular" or "temporary". Modify text so that client indicates types of addresses to be assigned by sending appropriate IAs. Server then fills in each IA with assigned addresses. Open issue - hold for new IA definition (WG has already agreed that client can ask for regular or temporary addresses) * Define separate IA option for temporary addresses rather than indicate the type of address in a single IA option Open issue - hold for new IA definition * How and when does the client use DAD on addresses in Advertise and Reply messages? WG consensus: Client does DAD on addresses in Reply message and responds with Decline if addresses unacceptable (e.g., already in use) * Advertise message SHOULD include options for all OROs that were included in the Solicit if the server is willing/capable of offering a value for that option WG consensus: yes * Should we consider a "quick" handshake for allowing a client to assign an address in a single exchange of two messages? WG consensus: defer for later reconsideration * Tighten up text on T1/T2 to require T1/T2 occur prior to expiration of lifetimes of addresses in IA; no need to describe default as T1/T2 are fields in IA header and must be supplied by server WG consensus: Mark, Ted and Bernie will do it... Open issue: what about selection of T1/T2 with temporary addresses and with addresses whose lifetimes won't be extended; e.g. addresses to be deprecated/discarded due to renumbering. Notes: T1/T2 are independent of "regular"/"temporary" characteristic. T1/T2 might even be used for clients that do not have any assigned addresses for periodic renewal of other information * The semantics of the use of IA must be clarified (see Volz message of 7/19). In particular, what are the semantics of a Request containing an IA that the client has previously sent to the server? What are the semantics of a Request containing a new IA? Open issue: rules about when to reuse old IA or use new IA WG consensus: When the client submits an IA that the server has seen in the past, the server should interpret the request as a request for the current state of the existing IA. When the client submits an IA that the server has not seen before, the server should interpret the request as a request for additional addresses to be assigned to the new IA. Discussion to continue on WG mailing list * Simplify Release and Decline so the all of the addresses in an IA are released or declined, rather than allowing the client to release or decline just some addresses. WG consensus: Wait for Bernie to fix in IA definition * Add "NAK" function: If the server finds that the prefix on one or more IP addresses in any IA in the {Request,Confirm,Rebind} message is not a valid prefix for the link to which the client is connected, the server MUST send an NoPrefixMatch status in the IA status field for that IA in the DHCP Reply message. WG consensus: yes; indicate "NAK" through return of "NoPrefixMatch" error code. Add text allowing client to ignore "NoPrefixMatch" from other servers if ACK received from at least one server. * Define DUID to be one of: - Link-layer address plus time - Vendor-assigned unique ID - Link-layer address - IMSI - IMEI WG consensus: yes; based on text submitted by Lemon with extensions from subsequent WG discussion * Use IPsec for secure agent/server communication WG consensus: yes; add text to draft * Add an "error code" option, to indicate errors not connected with a specific option WG consensus: yes; should allow inclusion of text message * Tighten up language for unicasting Reconfigure-Init; in particular, the server may not have an appropriate address to use to send the message to the client. WG consensus: yes * Reply to a Confirm should be a simple ACK/NAK without changing any values in options WG consensus: Discussion to be taken to mailing list Note: check to make sure there is text in the draft describing behavior if no response is heard to a Confirm * Reply to Decline or Release should carry no options WG consensus: yes * Restrict options in Decline or Release to IA with text to allow other options in the future WG consensus: no; this is an overspecification * Server does not respond to Solicit when client wants addresses and server has no addresses WG consensus: Server should be allowed to respond * Include only options specifically mentioned in the text in the DHCPv6 spec; move others to second doc or separate appendix WG consensus: anything we have consensus on stays; anything else gets punted to a separate draft. * Add 'secs' field to fixed header WG consensus: if client retransmits, MUST send option called "milliseconds" * Make the preference field an option WG consensus: yes * Describe message transmission and retransmission in a separate section of the spec and reference that text throughout the remainder of the spec WG consensus: yes * Discard the client unicast or recheck the entire spec for consistency in reference to message transmission WG consensus: yes, authors to fix spec * Remove client link-local address from client message header. Agent can then determine link-local from source (IP header) in client message and insert into agent->server message. Server responds to source from IP header (whether agent or client). WG consensus: Yes From owner-dhcp-v6@bucknell.edu Thu Aug 23 12:07:37 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26510; Thu, 23 Aug 2001 12:07:37 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7NG7Fq11229; Thu, 23 Aug 2001 12:07:15 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7NG79q14708 for ; Thu, 23 Aug 2001 12:07:09 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sj-dial-4-59.cisco.com [171.68.181.188]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA18832 for ; Thu, 23 Aug 2001 12:06:33 -0400 (EDT) Message-Id: <4.3.2.7.2.20010823095116.00b5fa30@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 23 Aug 2001 09:55:04 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Change to 'seconds' field in DHCP message header Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN This change eliminates the 'seconds' field from the message header and replaces it with the "Elapsed Time" option. The transaction-ID is now 24 bits. The "Elapsed Time" option carries a 16 bit integer, giving the number of seconds elapsed since the client began its current transaction. The number of seconds is expressed in hundredths of a second (10^-2 seconds). The "Elapsed Time" option can indicate times in the range of 0 to 655 seconds, in increments of 10^-2 seconds. This change address the following issue from the London WG meeting: * Add 'secs' field to fixed header WG consensus: if client retransmits, MUST send option called "milliseconds" Affected text: -------------- 8. Message Formats Each DHCP message has an identical fixed format header; some messages also allow a variable format area for options. Not all fields in the header are used in every message. In this section, every field is described for every message and fields that are not used in a message are marked as "unused". All unused fields in a message MUST be transmitted as zeroes and ignored by the receiver of the message. The DHCP message header: 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 | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | client-link-local-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . options . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18.6. Elapsed Time 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ELAPSED_TIME | option_len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | elapsed time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_ELAPSED_TIME (4) option-len MUST be 2 option-data The amount of time since the client began its current DHCP transaction. This time is expressed in hundredths of a second (10-2seconds): If a client retransmits a DHCP message, it MUST include an Elapsed Time option in the message to indicate how long the client has been trying to complete a DHCP transaction. Servers MAY use the data value in this option as input to policy controlling how a server responds to a client message. From owner-dhcp-v6@bucknell.edu Thu Aug 23 12:18:51 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26807; Thu, 23 Aug 2001 12:18:51 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7NGJ3q18897; Thu, 23 Aug 2001 12:19:03 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7NGIoq13002 for ; Thu, 23 Aug 2001 12:18:50 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2ive2hf.dialup.mindspring.com [165.247.10.47]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7NGDBf02359 for ; Thu, 23 Aug 2001 09:13:11 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7NG7ZZ07195 for ; Thu, 23 Aug 2001 12:07:35 -0400 (EDT) Message-Id: <200108231607.f7NG7ZZ07195@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from Ralph Droms of "Thu, 23 Aug 2001 09:55:04 EDT." <4.3.2.7.2.20010823095116.00b5fa30@funnel.cisco.com> Date: Thu, 23 Aug 2001 12:07:35 -0400 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN I would change "Servers MAY use the data value" to "Servers and Relay agents MAY use the data value", since it is presently the case that some relay agents use the secs field in DHCPv4, and this seems like a legitimate thing to do. _MelloN_ From owner-dhcp-v6@bucknell.edu Thu Aug 23 14:00:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28273; Thu, 23 Aug 2001 14:00:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7NHxmq22889; Thu, 23 Aug 2001 13:59:48 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7NHxbq11586 for ; Thu, 23 Aug 2001 13:59:37 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7NHxH505411 for ; Thu, 23 Aug 2001 12:59:21 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7NHxHR02376 for ; Thu, 23 Aug 2001 12:59:17 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Aug 23 12:59:16 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 23 Aug 2001 12:59:16 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3492@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Change to 'seconds' field in DHCP message header Date: Thu, 23 Aug 2001 12:59:08 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12BFD.4E871380" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12BFD.4E871380 Content-Type: text/plain; charset="iso-8859-1" Perhaps also worth saying that if the elapsed time is >655.35 seconds, 655.35 seconds should be used? It probably will never be the case that a client waits that long, but just in case (since it would be bad to have it wrap around and start at low values again). I agree with Ted's comment to add Relays. But, perhaps it should be a new sentence, such as "Relays MAY use the data value in this option as input to policy controlling to which server(s) the relay forwards the client's message." - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, August 23, 2001 9:55 AM To: DHCPv6 discussion list Subject: Change to 'seconds' field in DHCP message header This change eliminates the 'seconds' field from the message header and replaces it with the "Elapsed Time" option. The transaction-ID is now 24 bits. The "Elapsed Time" option carries a 16 bit integer, giving the number of seconds elapsed since the client began its current transaction. The number of seconds is expressed in hundredths of a second (10^-2 seconds). The "Elapsed Time" option can indicate times in the range of 0 to 655 seconds, in increments of 10^-2 seconds. This change address the following issue from the London WG meeting: * Add 'secs' field to fixed header WG consensus: if client retransmits, MUST send option called "milliseconds" Affected text: -------------- 8. Message Formats Each DHCP message has an identical fixed format header; some messages also allow a variable format area for options. Not all fields in the header are used in every message. In this section, every field is described for every message and fields that are not used in a message are marked as "unused". All unused fields in a message MUST be transmitted as zeroes and ignored by the receiver of the message. The DHCP message header: 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 | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | client-link-local-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . options . | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 18.6. Elapsed Time 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_ELAPSED_TIME | option_len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | elapsed time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_ELAPSED_TIME (4) option-len MUST be 2 option-data The amount of time since the client began its current DHCP transaction. This time is expressed in hundredths of a second (10-2seconds): If a client retransmits a DHCP message, it MUST include an Elapsed Time option in the message to indicate how long the client has been trying to complete a DHCP transaction. Servers MAY use the data value in this option as input to policy controlling how a server responds to a client message. ------_=_NextPart_001_01C12BFD.4E871380 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Change to 'seconds' field in DHCP message header

Perhaps also worth saying that if the elapsed time is = >655.35 seconds,
655.35 seconds should be used? It probably will = never be the case that
a client waits that long, but just in case (since it = would be bad to
have it wrap around and start at low values = again).

I agree with Ted's comment to add Relays. But, = perhaps it should be a
new sentence, such as "Relays MAY use the data = value in this option as
input to policy controlling to which server(s) the = relay forwards the
client's message."

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, August 23, 2001 9:55 AM
To: DHCPv6 discussion list
Subject: Change to 'seconds' field in DHCP message = header


This change eliminates the 'seconds' field from the = message header and
replaces it with the "Elapsed Time" = option.  The transaction-ID is now
24 bits.

The "Elapsed Time" option carries a 16 bit = integer, giving the number
of seconds elapsed since the client began its = current transaction.
The number of seconds is expressed in hundredths of = a second (10^-2
seconds). The "Elapsed Time" option can = indicate times in the range of
0 to 655 seconds, in increments of 10^-2 = seconds.

This change address the following issue from the = London WG meeting:

* Add 'secs' field to fixed header

  WG consensus: if client retransmits, MUST send = option called
  "milliseconds"

Affected text:
--------------

8. Message Formats

   Each DHCP message has an identical fixed = format header; some messages
   also allow a variable format area for = options.  Not all fields in
   the header are used in every = message.  In this section, every field
   is described for every message and = fields that are not used in a
   message are marked as = "unused".  All unused fields in a message MUST
   be transmitted as zeroes and ignored by = the receiver of the message.

   The DHCP message header:
      = 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   = |            = ;   = transaction-ID         &nbs= p;        |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;       = client-link-local-address        = ;           |
     = |            = ;            = ;  (16 = octets)           = ;            = ;   |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;            = ; = server-address         &nbs= p;           &nbs= p;  |
     = |            = ;            = ;  (16 = octets)           = ;            = ;   |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
     = .           &nbs= p;           &nbs= p;    = options           = ;            = ;     .
     = |            = ;            = ;  = (variable)          &n= bsp;           &n= bsp;    |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=



18.6. Elapsed Time

      = 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
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |      = OPTION_ELAPSED_TIME      = |           = option_len          = |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
     = |          elapsed = time         |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      = option-code   OPTION_ELAPSED_TIME (4)

      = option-len    MUST be 2

      = option-data   The amount of time since the client began = its
          &nb= sp;         current DHCP = transaction.  This time is expressed in
          &nb= sp;         hundredths of a = second (10-2seconds):

   If a client retransmits a DHCP message, = it MUST include an Elapsed
   Time option in the message to indicate = how long the client has been
   trying to complete a DHCP = transaction.  Servers MAY use the data value
   in this option as input to policy = controlling how a server responds
   to a client message.

------_=_NextPart_001_01C12BFD.4E871380-- From owner-dhcp-v6@bucknell.edu Fri Aug 24 06:25:10 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27991; Fri, 24 Aug 2001 06:25:10 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7OAOUq04077; Fri, 24 Aug 2001 06:24:30 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7OAOOq02499 for ; Fri, 24 Aug 2001 06:24:24 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn1-10.cisco.com [10.82.224.10]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id GAA12471 for ; Fri, 24 Aug 2001 06:24:07 -0400 (EDT) Message-Id: <4.3.2.7.2.20010824062026.00b8bef8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Aug 2001 06:24:05 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: RE: Change to 'seconds' field in DHCP message header In-Reply-To: <66F66129A77AD411B76200508B65AC697B3492@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Thanks for the feedback; comments in line. - Ralph At 12:59 PM 8/23/2001 -0500, Bernie Volz (EUD) wrote: >Perhaps also worth saying that if the elapsed time is >655.35 seconds, >655.35 seconds should be used? It probably will never be the case that >a client waits that long, but just in case (since it would be bad to >have it wrap around and start at low values again). OK. >I agree with Ted's comment to add Relays. But, perhaps it should be a >new sentence, such as "Relays MAY use the data value in this option as >input to policy controlling to which server(s) the relay forwards the >client's message." I think I prefer a more general statement; is there a chance that, in the future, a relay agent may make a decision about the contents of a relay agent option based on the Elapsed Time option value? >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, August 23, 2001 9:55 AM >To: DHCPv6 discussion list >Subject: Change to 'seconds' field in DHCP message header > >This change eliminates the 'seconds' field from the message header and >replaces it with the "Elapsed Time" option. The transaction-ID is now >24 bits. > >The "Elapsed Time" option carries a 16 bit integer, giving the number >of seconds elapsed since the client began its current transaction. >The number of seconds is expressed in hundredths of a second (10^-2 >seconds). The "Elapsed Time" option can indicate times in the range of >0 to 655 seconds, in increments of 10^-2 seconds. > >This change address the following issue from the London WG meeting: > >* Add 'secs' field to fixed header > > WG consensus: if client retransmits, MUST send option called > "milliseconds" > >Affected text: >-------------- > >8. Message Formats > > Each DHCP message has an identical fixed format header; some messages > also allow a variable format area for options. Not all fields in > the header are used in every message. In this section, every field > is described for every message and fields that are not used in a > message are marked as "unused". All unused fields in a message MUST > be transmitted as zeroes and ignored by the receiver of the message. > > The DHCP message header: > 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 | transaction-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | client-link-local-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | server-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . options . > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >18.6. Elapsed Time > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_ELAPSED_TIME | option_len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | elapsed time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > option-code OPTION_ELAPSED_TIME (4) > > option-len MUST be 2 > > option-data The amount of time since the client began its > current DHCP transaction. This time is expressed in > hundredths of a second (10-2seconds): > > If a client retransmits a DHCP message, it MUST include an Elapsed > Time option in the message to indicate how long the client has been > trying to complete a DHCP transaction. Servers MAY use the data value > in this option as input to policy controlling how a server responds > to a client message. From owner-dhcp-v6@bucknell.edu Fri Aug 24 12:09:17 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08300; Fri, 24 Aug 2001 12:09:16 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7OG8qq07424; Fri, 24 Aug 2001 12:08:52 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7OG8eq27513 for ; Fri, 24 Aug 2001 12:08:40 -0400 (EDT) Received: from grosse.bisbee.fugue.com (1Cust104.tnt2.nyc3.da.uu.net [63.28.109.104]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7OG2wf04189 for ; Fri, 24 Aug 2001 09:02:59 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7OFvGn00504 for ; Fri, 24 Aug 2001 11:57:16 -0400 (EDT) Message-Id: <200108241557.f7OFvGn00504@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from Ralph Droms of "Fri, 24 Aug 2001 06:24:05 EDT." <4.3.2.7.2.20010824062026.00b8bef8@mail.bucknell.edu> Date: Fri, 24 Aug 2001 11:57:16 -0400 From: Ted Lemon 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 > >Perhaps also worth saying that if the elapsed time is >655.35 seconds, > >655.35 seconds should be used? It probably will never be the case that > >a client waits that long, but just in case (since it would be bad to > >have it wrap around and start at low values again). > > OK. Ga-zikes, is the field only 16 bits? I think 655 seconds is not very long for some possible applications. Is there any reason not to make this a 32-bit field? _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Aug 24 12:35:03 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08947; Fri, 24 Aug 2001 12:35:03 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7OGYWq24209; Fri, 24 Aug 2001 12:34:32 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7OGYOq29208 for ; Fri, 24 Aug 2001 12:34:24 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-112.cisco.com [10.82.240.112]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA15092 for ; Fri, 24 Aug 2001 12:34:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20010824122936.00b7e5f0@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 24 Aug 2001 12:31:53 -0400 To: DHCPv6 discussion list From: Ralph Droms Subject: Re: Change to 'seconds' field in DHCP message header In-Reply-To: <200108241557.f7OFvGn00504@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010824062026.00b8bef8@mail.bucknell.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Yup - as a first pass, I took the initiative to define the field to be 16 bits. I'm happy to make it 32 bits, 64 bits - measured in milliseconds, microseconds or the time between the light turning green and the guy behind me honking his horn here in Boston. Other feedback - 16 bits, measured in 10^-2 seconds seemed like enough to me... - Ralph At 11:57 AM 8/24/2001 -0400, you wrote: >> >Perhaps also worth saying that if the elapsed time is >655.35 seconds, >> >655.35 seconds should be used? It probably will never be the case that >> >a client waits that long, but just in case (since it would be bad to >> >have it wrap around and start at low values again). >> >> OK. > >Ga-zikes, is the field only 16 bits? I think 655 seconds is not very >long for some possible applications. Is there any reason not to make >this a 32-bit field? > > _MelloN_ From owner-dhcp-v6@bucknell.edu Fri Aug 24 14:01:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11125; Fri, 24 Aug 2001 14:01:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7OI0Wq08727; Fri, 24 Aug 2001 14:00:32 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7OI0Eq31318 for ; Fri, 24 Aug 2001 14:00:14 -0400 (EDT) Received: from grosse.bisbee.fugue.com (2Cust82.tnt2.nyc3.da.uu.net [63.28.96.210]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7OHsWf04329 for ; Fri, 24 Aug 2001 10:54:32 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7OHmgn00705 for ; Fri, 24 Aug 2001 13:48:42 -0400 (EDT) Message-Id: <200108241748.f7OHmgn00705@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from Ralph Droms of "Fri, 24 Aug 2001 12:31:53 EDT." <4.3.2.7.2.20010824122936.00b7e5f0@mail.bucknell.edu> Date: Fri, 24 Aug 2001 13:48:41 -0400 From: Ted Lemon 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 > Other feedback - 16 bits, measured in 10^-2 seconds seemed like enough to me... Yeah, I saw that. I tend to agree, except that 10 minutes is actually within two orders of magnitude of a reasonable timeout, so I'd like a little more breathing room, since there may be some cases where long timeouts might be wanted. I can't see a use for this offhand, but it doesn't seem like it's worth saving two bytes here, since milliseconds will only be sent in exceptional cases anyway, and only in the client payload, which is generally small. _MelloN_ From owner-dhcp-v4@bucknell.edu Fri Aug 24 21:17:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17726 for ; Fri, 24 Aug 2001 21:17:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7P1FBq26388; Fri, 24 Aug 2001 21:15:11 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7P1F2q30709 for ; Fri, 24 Aug 2001 21:15:02 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id SAA24884 for ; Fri, 24 Aug 2001 18:15:01 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 24 Aug 2001 18:15:00 -0700 Received: from [206.111.147.149] (vpn-gh-1104.apple.com [17.254.140.79]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f7P1F0w08521 for ; Fri, 24 Aug 2001 18:15:00 -0700 (PDT) Message-Id: <200108250115.f7P1F0w08521@scv2.apple.com> Subject: Re: Several reminders Date: Fri, 24 Aug 2001 18:14:59 -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 >I have some reminders to send along... > >WG last calls have been posted for all of the following docs; please be >sure to respond with comments by the end of the last call period (8/24): The comments below apply to concat-01.txt, domsearch-05.txt, csr-04.txt and ddns-resolution-02.txt. References are supposed to be an addition to written prose, not a substitute for it. References are there so that when an inexperienced reader doesn't understand a statement you make, they know where to look for more information. References are there so that when an *experienced* reader doesn't *agree* with a statement you make, they can find upon what prior work you are basing your assertion. You should be able to delete the references from a piece of text and have it still make sense to an experienced reader. Put another way, the reader shouldn't have to keep flipping to the back of the document to understand what a sentence is saying. There are several places in these drafts that fail this test. For example: >The DHCP packet format is based on the BOOTP packet format defined in [4]. Without the list of references to hand, this is not a complete sentence. You can fix this two ways: 1. Delete spurious words: >The DHCP packet format is based on the BOOTP packet format [4]. 2. Write complete prose: > The DHCP packet format is based on the BOOTP packet format defined > in the Bootstrap Protocol specification [4]. I also prefer semidescriptive references instead of numeric references so an experienced reader can recognise the reference in context, instead of having to flip to the back of the document to find out what "[4]" means: >The DHCP packet format is based on the BOOTP packet format [RFC950]. RFC950? Internet Standard Subnetting Procedure, by Mogul & Postel? I don't think that's the document that was intended to be referenced by [4]. I think RFC951 is the one that defines the BOOTP packet format. I think I've made my point why descriptive references are more useful than anonymous numbers. Some other examples of sentences that make no sense until you flip to the back of the document to fill in the missing words: >multiple options may be used, as described in [ ]. >searchstrings in the searchlist are concatenated and encoded >using the technique described in section 4.1.4 of [ ]. >Thus the compression method described in [ ] is both useful >and likely to be effective. >This maintains consistency with section 4.1 of [ ]. >DHCP servers sending this option MUST use the technique described in [ ] >FOr this purpose, a DHCID RR, described in [ ], is used to associate >client identification information with a DNS name and the A or PTR >RR associated with that name. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Fri Aug 24 21:19:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17738 for ; Fri, 24 Aug 2001 21:19:05 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7P1JRq24129; Fri, 24 Aug 2001 21:19:27 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7P1GHq30611 for ; Fri, 24 Aug 2001 21:16:17 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id SAA25118 for ; Fri, 24 Aug 2001 18:16:16 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 24 Aug 2001 18:16:16 -0700 Received: from [206.111.147.149] (vpn-gh-1104.apple.com [17.254.140.79]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f7P1GFw08712 for ; Fri, 24 Aug 2001 18:16:15 -0700 (PDT) Message-Id: <200108250116.f7P1GFw08712@scv2.apple.com> Subject: Re: Last call for Date: Fri, 24 Aug 2001 18:16:15 -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 Some minor suggestions: 1. Encoding agent behaviour I think it would be very helpful to make it explicit that *no* semantic information is encoded by whether (or where) an option is split. After the "Options MAY be split on any octet boundary" paragraph, add: No semantic information is encoded by whether (or where) an option is split. In particular, this means that adding two small options with the same option code to a packet is no different to adding a single option containing the data from the two separate options concatenated together. For example, suppose a DHCP packet contains two instances of DHCP option 61 (Client-Identifier). RFC 2132 does not specify whether the receiver should disregard the second one in the packet, or let the second Client-Identifier supersede the first, or interpret this as meaning that the client has two Client-Identifiers. If DHCP option 61 had been defined to use the concatenation behaviour specified by this document (which it was not) then the meaning would be clear and unambiguous: The client has one and only one Client-Identifier, and its value is the data from the two Client-Identifier options concatenated together. I mention this because I think that this will be an easy implementation mistake to make with the domsearch option. Consider the three domsearch options below: +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | TBD | 8 | 3 | 'i' | 's' | 'c' | 3 | 'o' | 'r' | 'g' | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | TBD | 10 | 5 | 'a' | 'p' | 'p' | 'l' | 'e' | 3 | 'c' | 'o' | 'm' | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ | TBD | 9 | 3 | 'm' | 'i' | 't' | 3 | 'e' | 'd' | 'u' | 0 | +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+ An incorrect client could easily treat this as an indication to add three domains, "isc.org", "apple.com", and "mit.edu" to the search list. This would be incorrect. The domsearch options above encode a single domain to be added to the search list, and that domain is "isc.org.apple.com.mit.edu." This may be pretty counterintuitive to most people, which is why I think it needs to be explained clearly. 2. Example I think the example would better if it showed a real option being split, rather than a hypothetical example where the intended semantics are less obvious. Perhaps the domsearch example above would work. 3. References I don't think reference 4 is what you meant. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Fri Aug 24 21:20:12 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17757 for ; Fri, 24 Aug 2001 21:20:11 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7P1Khq10319; Fri, 24 Aug 2001 21:20:43 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7P1Hhq12482 for ; Fri, 24 Aug 2001 21:17:43 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id SAA25249 for ; Fri, 24 Aug 2001 18:17:43 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 24 Aug 2001 18:15:49 +0100 Received: from [206.111.147.149] (vpn-gh-1104.apple.com [17.254.140.79]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id SAA13998; Fri, 24 Aug 2001 18:17:41 -0700 (PDT) Message-Id: <200108250117.SAA13998@scv1.apple.com> Subject: Re: Last call for Date: Fri, 24 Aug 2001 18:17:41 -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 Some minor suggestions: 1. The document contains some tab characters, which mess up formatting on systems where tabs are not necessarily eight spaces. 2. Classless Route Option Format > Destination descriptors describe the IP subnet number and subnet > mask of a particular destination using a compact encoding. This > encoding consists of one octet describing the width of the subnet > mask, followed by all the non-zero octets of the subnet number. You don't mean, "non-zero octets of the subnet number." Suppose I want to set a static route to 10.0.127/22. Do I only include the non-zero octets? I suggest: mask, followed by all significant octets of the subnet number. Similarly: > The non-zero portion of the subnet number is simply all of the > octets of the subnet number, with the least significant octets that > are zero omitted. For a subnet mask width of between 25 and 32, > the subnet number will be four octets. Mask widths of between 17 > and 24 indicate a three-octet subnet number; between 9 and 16 > indicate a two-octet subnet number, between 1 and 8 indicate a > one-octet number. This text suggests an optimization which doesn't actually work. Omitting the "least significant octets that are zero" suggests that you can encode the destination "10.0.0.0/24" as just "24.10". This works only so long as the receiver has some other way to detect the end of the destination descriptor, which it does not. If the sender encodes "10.0.0.0/24" as just "24.10", the receiver would have no way to know where the destination descriptor ends and the IP address of the router begins. I suggest: The significant portion of the subnet number is simply all of the octets of the subnet number where the corresponding octet in the subnet mask is non-zero. The number of significant octets is the width of the subnet mask divided by eight, rounding up, as shown in the following table: Width of subnet mask Number of significant octets 0 0 1- 8 1 9-16 2 17-24 3 25-32 4 3. DHCP Client Behavior > DHCP clients > that support this option and send a parameter request list MUST NOT > request the Static Routes option. Can you explain the rationale for this? If I change the Mac OS DHCP client to NOT request the Static Routes option, then Macs will stop working on certain networks that rely on this. It is important to Apple to have one DHCP client which works on all networks -- making the user configure a 'mode' for the DHCP client is contrary to the spirit of DHCP, which is to automate network configuration. (We'd need a DHCP option to automatically set that configuration option for the client :-) I suggest: DHCP clients that support this option and send a parameter request list MAY also request the Static Routes option, for compatibility with older servers that don't support Classless Static Routes. Also: > The Classless Static Routes > option code SHOULD appear in the parameter request list prior to > the Router option code. This should say, "MUST", or should be removed. If it says "MUST" then server implementers can rely on it, so it is useful. If it says "SHOULD", then server implementers cannot rely on it, so what's the point? I suggest: The Classless Static Routes option code MUST appear in the parameter request list prior to both the Router option code and the Static Routes option code, if present. 4. Requirements to avoid sizing constraints > clients implementing the Classless Static Route option SHOULD send > a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP > stack is capable of reassembling fragmented IP datagrams. In this > case, the client SHOULD set the value of this option to the MTU of > the interface that the client is configuring. If the client > supports UDP fragmentation, it MAY set the value of this option to > the size of the largest UDP packet it is prepared to accept. There's no such thing as UDP fragmentation. Fragmentation and defragmentation is an IP-layer function. The only question is if the UDP software has some size limitation. I suggest: clients implementing the Classless Static Route option SHOULD send a Maximum DHCP Message Size [2] option if the DHCP client's TCP/IP stack is capable of reassembling fragmented IP datagrams. In this case, the client SHOULD set the value of this option to at least the MTU of the interface that the client is configuring. If the client is able to receive UDP packets larger than the MTU of the interface, then the client MAY set the value of this option higher, up to the size of the largest UDP packet it is prepared to accept. (Note that the value specified in the Maximum DHCP Message Size option is the total maximum packet size, including IP and UDP headers.) 5. DHCP Server Considerations > When a DHCP client requests both the Router option and the > Classless Static Routes option, and the DHCP server is configured > with both a Classless Static Routes option and a Router option > that applies to the client, the DHCP server MAY exclude the Router > option from its response. Add text about Static Routes option too: When a DHCP client requests the Classless Static Routes option and also requests either or both of the Router option and the Static Routes option, and the DHCP server is sending Classless Static Routes options to that client, the server MAY choose to save space in the reply packet by not including Router or Static Routes options. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Fri Aug 24 21:31:27 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17838 for ; Fri, 24 Aug 2001 21:31:26 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7P1Vjq29096; Fri, 24 Aug 2001 21:31:45 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7P1Vhq19302 for ; Fri, 24 Aug 2001 21:31:43 -0400 (EDT) Received: from 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 SAA03007 for ; Fri, 24 Aug 2001 18:31:41 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 24 Aug 2001 18:31:40 -0700 Received: from [206.111.147.149] (vpn-gh-1104.apple.com [17.254.140.79]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f7P1Vew11312; Fri, 24 Aug 2001 18:31:40 -0700 (PDT) Message-Id: <200108250131.f7P1Vew11312@scv2.apple.com> Subject: Re: Last call for Date: Fri, 24 Aug 2001 18:31:39 -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 Excluding boilerplate and references, a one-page specification. Truly remarkable! I hate to have to add text to such a succinct specification, but there are a couple of things I think should be clarified: 1. Compression offsets >For use in this specification, the pointer refers to the offset >within the SearchString portion of the option. If multiple >searchlist options are present, then the SearchString portion of >all the options are concatenated and the pointer refers to the >offset within the concatenated SearchString. In the diagram, there are *two* SearchString portions shown in the example option. Which does the text refer to? I suggest: For use in this specification, the pointer refers to the offset within the data portion of the DHCP option (not including the preceding DHCP option code byte or DHCP option length byte). If multiple Domain Search Options are present, then the data portions of all the Domain Search Options are concatenated together as specified in "Encoding Long DHCP Options" [7] and the pointer indicates an offset within the complete aggregate block of data. 2. Null root label The draft does not state explicitly that every search domain name MUST end with the null root label, otherwise, all the search domains run together into one long domain name. As described in my example in my previous mail about draft-ietf-dhc-concat-01.txt, naive implementers may assume they can put each search domain in its own search option, and use option boundaries to indicate the boundaries between names. I think a diagram showing example encoding would clarify use of concatenation, compression offsets, and the requirement for a null root label at the end of every name. I suggest: Example encoding of a search list consisting of "eng.apple.com." and "marketing.apple.com.": +---+---+---+---+---+---+---+---+---+---+---+ |TBD| 9 | 3 |'e'|'n'|'g'| 5 |'a'|'p'|'p'|'l'| +---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+ |TBD| 9 |'e'| 3 |'c'|'o'|'m'| 0 | 9 |'m'|'a'| +---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+---+---+---+---+ |TBD| 9 |'r'|'k'|'e'|'t'|'i'|'n'|'g'|xC0|x04| +---+---+---+---+---+---+---+---+---+---+---+ Note: (i) The encoding of has been split (for this example) into three Domain Search Options. All Domain Search Options are logically concatenated into one block of data before being interpreted by the client. (ii) The encoding of "eng.apple.com." ends with a zero, the null root label, to mark the end of the name, as required by RFC 1035. (iii)The encoding of "marketing" (for "marketing.apple.com.") ends with the two-octet compression pointer C004 (hex), which points to offset 4 in the complete aggregated block of Domain Search Option data, where another validly encoded domain name can be found to complete the name ("apple.com."). Every search domain name must end either with a zero or with a two-octet compression pointer. If the receiver is part-way through decoding a search domain name when it reaches the end of the complete aggregated block of searchlist option data, without finding a zero or a valid two-octet compression pointer, then the partially read name must be discarded as invalid. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Sat Aug 25 01:06:36 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21559 for ; Sat, 25 Aug 2001 01:06:36 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7P54dq18997; Sat, 25 Aug 2001 01:04:39 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7P54Nq05756 for ; Sat, 25 Aug 2001 01:04:23 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id WAA10570 for ; Fri, 24 Aug 2001 22:04:21 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 24 Aug 2001 22:04:21 -0700 Received: from [206.111.147.149] (vpn-gh-1031.apple.com [17.254.140.6]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f7P54Kw12906 for ; Fri, 24 Aug 2001 22:04:20 -0700 (PDT) Message-Id: <200108250504.f7P54Kw12906@scv2.apple.com> Subject: Re: Last call for Date: Fri, 24 Aug 2001 22:04:17 -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 A bunch of comments on draft-ietf-dhc-fqdn-option-02.txt: I agree that it may be useful to have a way to request the DHCP server to update the PTR record for the address it assigned to you. The DHCP server has authority to hand out addresses in a certain range; therefore it makes sense for it to also control the PTR records for addresses in that range. Where I am less convinced is in the vague security arguments about why it is desirable to have the DHCP server update the hosts "A" record too: At the London IETF meeting, my laptop was always reachable at the name "stu.dyndns.org.", because my DynDNS client updated my "A" record every time my address changed. Having the IETF DHCP server try to update that record would have been futile, because it doesn't have the credentials to update it. > if the server sets both the "S" > and the "O" bits (the two least-significant bits) in the option's > flags field, the DHCP client MUST NOT initiate an update Having the IETF DHCP server set the "S" and "O" bits to try to prohibit my DynDNS client from updating its own "A" record would also have been futile, because the DynDNS client currently ignores those bits, and I expect it will continue to do so, because it has nothing to gain by deliberately not working in certain situations. The draft even acknowledges this: > Furthermore, this specification applies only to DHCP client and > server processes: it does not apply to other processes which > initiate DNS updates. How do you define the "client process"? Is the Dynamic DNS client exempted from honoring the "S" and "O" bits if it is in a separate address space? In a separate library? Compiled from a separate "C" file? Implemented in a separate function in the same "C" file that also holds the DHCP code? You could say that any code that does Dynamic DNS updates is, by definition, a Dynamic DNS client, not a DHCP client, so by definition none of this document applies to any code that does DNS updates. I'm sure that's not what you intended. When most people read "DHCP client", they are going to assume it means "the machine acquiring the DHCP address." When they observe a DHCP client acquiring a DHCP address and then promptly update its DNS record, in violation of the "S" and "O" bits, they are probably going to conclude that the client is violating this specification. They are probably not going to conclude that this is perfectly correct, because the DNS update was done by a piece of DNS update code, not by DHCP code. > A DHCP client may be given authority over mapping its own A > RRs, or that authority may be restricted to a server to > prevent the client from listing arbitrary addresses or > associating its address with arbitrary domain names. What's the point of "restricted authority to prevent the client associating its address with arbitrary domain names" if you then provide a way for an unauthenticated DHCP client to ask the DHCP server on its behalf to associate its address with arbitrary domain names? Either you have a secure way of knowing the identity of the client, or you don't, and if you don't, the extra layer of indirection doesn't make it any more secure. > This document describes a new DHCP option which a client can use to > convey all or part of its domain name to a DHCP server. Why not use the existing Host Name Option (code 12) to carry a fully qualified host name, as described in RFC 2132? > The data in the Domain Name field may appear in one of two formats: > ASCII, or DNS-style binary encoding What's the benefit of providing this choice? It just makes the lives of server writers harder because now they have to support both. > Implementors should note that EDNS0 describes a mechanism for > extending the length of a DNS RCODE to 12 bits. EDNS0 is specified > in RFC2671[8]. Only the least-significant 8 bits of the RCODE from a > DNS update will be carried in the Client FQDN DHCP Option. This > provides enough number space to accomodate the RCODEs defined in the > DNS update specification. Why provide RCODE fields that are known to be too small to hold the possible range of RCODE values? Isn't this just setting us up for later problems? Why not just make the fields large enough? > If a client that owns/maintains its own FQDN wants to be responsible > for updating the FQDN to IP address mapping for the FQDN and > address(es) used by the client, then the client MUST include the > Client FQDN option in the DHCPREQUEST message originated by the > client. The DHCP client on my Mac cannot comply with this "MUST", because there is no way for it to know that some time later in the day I might choose to run my DynDNS client. If when you say, "If a client ... wants to be responsible for updating ... then the client MUST ..." you're not talking about my machine as the "client", but specifically only the DHCP code on the machine, then the "if" clause is trivially false. My DHCP code only ever sends and receives DHCP packets. Any code on my machine that sends and receives DNS Update packets is by definition DNS Update code, not DHCP code. > A client that delegates the responsibility for updating the FQDN to > IP address mapping to a server might not receive any indication > (either positive or negative) from the server whether the server was > able to perform the update. In this case the client MAY use a DNS > query to check whether the mapping is updated. And do what if it finds it failed? > The server MAY complete the update before the server sends the > DHCPACK message to the client. In this case the RCODE from the > update MUST be carried to the client in the RCODE1 field of the > Client FQDN option in the DHCPACK message. Alternatively, the server > MAY send the DHCPACK message to the client without waiting for the > update to be completed. In this case the RCODE1 field of the Client > FQDN option in the DHCPACK message MUST be set to 255. The choice > between the two alternatives is entirely determined by the > configuration of the DHCP server. Servers SHOULD support both > configuration options. What's the benefit of providing this choice? It just makes the lives of client writers harder because now they have to support both. > If a server terminates a lease on an address prior to the lease's > expiration time, for instance by sending a DHCPNAK to a client, Servers can never terminate a lease. Once a client has a lease, it can use it until it expires, without ever having to talk to the server again. That's one of the basic principles of DHCP (unless something has changed recently that I don't know about). > Unauthenticated updates to the DNS can lead to tremendous confusion, > through malicious attack or through inadvertent misconfiguration. > Administrators should be wary of permitting unsecured DNS updates But this draft specifies a way for unauthenticated clients to have a trusted DHCP server do inadvertent or malicious DNS updates on their behalf. How is that better? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Sat Aug 25 01:32:40 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25096 for ; Sat, 25 Aug 2001 01:32:38 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7P5Vvq22713; Sat, 25 Aug 2001 01:31:57 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7P5Vnq08615 for ; Sat, 25 Aug 2001 01:31:49 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id WAA13689 for ; Fri, 24 Aug 2001 22:31:48 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Fri, 24 Aug 2001 22:31:48 -0700 Received: from [206.111.147.149] (vpn-gh-1031.apple.com [17.254.140.6]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f7P5Vlw17510 for ; Fri, 24 Aug 2001 22:31:47 -0700 (PDT) Message-Id: <200108250531.f7P5Vlw17510@scv2.apple.com> Subject: Re: Last call for Date: Fri, 24 Aug 2001 22:31:45 -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 > Furthermore, this specification > applies only to DHCP client and server processes: it does not apply > to other processes which initiate DNS updates. Same comment as for draft-ietf-dhc-fqdn-option: Protocol specifications need to specify what packets are valid on the wire -- how the code is implemented shouldn't matter. If two hosts send identical packet sequences, it makes no sense to say that one is legal and the other is not because one host used different "processes" to send the packets and the other host did it using a single "process". > At many sites, the difficulties with distributing DNS update > credentials to all of the DHCP clients lead to the desire for the > DHCP servers to perform A RR updates on behalf of their clients. If the clients don't have any credentials to prove they are not rogue clients, how secure is it to allow rogue clients to ask a middleman to do updates for them? > FOr this purpose, a DHCID RR, described in [6], is used to associate > client identification information with a DNS name and the A or PTR > RR associated with that name. When either a client or server adds an > A or PTR RR for a client, it also adds a DHCID RR which specifies a > unique client identity (based on a "client specifier" created from > the data in the client's DHCPREQUEST message). In this model, only > one A RR is associated with a given DNS name at a time. I don't think this works. The purpose of the DHCID RR is to protect against two clients that are accidentally configured to think they have the same host name. Adding the DHCID RR is just another level of indirection to the same problem: what do you do if two clients are accidentally configured to think they have the same DHCID? If the DHCID RR is derived from the Client Identifier Option (code 61) then there's no protection against two clients being accidentally configured with the same value, so this option hasn't solved the "unique identifier" problem. If the DHCID RR is derived from the client's link-layer network address, then it is harder to have accidental collisions because user's don't normally manually set their link-layer address, but now you have the opposite problem: false negatives, as described below: What about the user who uses a laptop on Ethernet in the office, and then uses 802.11 wireless in the conference room, and then uses PPP over a modem when dialing in from home? When they leave their office Ethernet try to access the network from the conference room using wireless, the DNS update will fail because they are accessing the network from a different link-layer address, so they appear to be a different client trying to steal a DNS name that's already in use. When they dial in from home in the evening, their modem doesn't even have a link-layer address to use to derive the DHCID. Even supposing that they are connecting from home using a 802.11 wireless and a DSL line, so they do have a link-layer address, what chance is there that the Cisco DNS servers are going to let Pacific Bell's DHCP servers do unauthenticated DNS updates? I think the main benefit of Dynamic DNS updates is to allow mobile clients to be reached using a constant name, no matter where they are. I think a mobility solution that only works as long as users don't leave their office Ethernet has limited applicability. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org From owner-dhcp-v4@bucknell.edu Sat Aug 25 11:21:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12381 for ; Sat, 25 Aug 2001 11:21:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7PFGnq00819; Sat, 25 Aug 2001 11:16:49 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7PFGbq01950 for ; Sat, 25 Aug 2001 11:16:37 -0400 (EDT) Received: from grosse.bisbee.fugue.com (1Cust77.tnt13.nyc3.da.uu.net [63.23.139.77]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7PFAsf06084; Sat, 25 Aug 2001 08:10:54 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7PF4dm00573; Sat, 25 Aug 2001 11:04:39 -0400 (EDT) Message-Id: <200108251504.f7PF4dm00573@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Several reminders In-Reply-To: Message from Stuart Cheshire of "Fri, 24 Aug 2001 18:14:59 PDT." <200108250115.f7P1F0w08521@scv2.apple.com> Date: Sat, 25 Aug 2001 11:04:38 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > References are supposed to be an addition to written prose, not a > substitute for it. Actually, this is not true, and is a dangerous idea. If I define the format of something that's authoritatively defined elsewhere in my own draft, and I make a mistake in transcribing or paraphrasing the authoritative source, this is likely to create interoperability problems when someone doesn't refer to the source. So I _must_ refer to the authoritative source, and _must not_ paraphrase it. _MelloN_ From owner-dhcp-v4@bucknell.edu Sat Aug 25 11:38:00 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12528 for ; Sat, 25 Aug 2001 11:37:59 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7PFbiq21430; Sat, 25 Aug 2001 11:37:44 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7PFbaq28866 for ; Sat, 25 Aug 2001 11:37:36 -0400 (EDT) Received: from grosse.bisbee.fugue.com (1Cust77.tnt13.nyc3.da.uu.net [63.23.139.77]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7PFVqf06101; Sat, 25 Aug 2001 08:31:53 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7PFPam00596; Sat, 25 Aug 2001 11:25:36 -0400 (EDT) Message-Id: <200108251525.f7PFPam00596@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Last call for In-Reply-To: Message from Stuart Cheshire of "Fri, 24 Aug 2001 18:17:41 PDT." <200108250117.SAA13998@scv1.apple.com> Date: Sat, 25 Aug 2001 11:25:36 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > > DHCP clients > > that support this option and send a parameter request list MUST NOT > > request the Static Routes option. > > Can you explain the rationale for this? > > If I change the Mac OS DHCP client to NOT request the Static Routes > option, then Macs will stop working on certain networks that rely on this. I find it difficult to believe that any existing, deployed network depends on the correct operation of the existing static routes option. Do you know of such a network, or are you speaking hypothetically? CIDR is close to a decade old now, and I find it difficult to believe that there exists a network where the static routes option is needed and where it can correctly represent the routing table that one would need to send to the client. I don't find it hard to believe that someone is abusing the old static routesoption in a way that happens to work in some cases, but that's not the same thing. I don't know of any DHCP servers that can't be configured to use CSR right now - the ISC and Microsoft servers can both be configured to send binary data in an option. I don't envision first-class support for CSR in servers lagging behind support for it in clients. So this seems like a non-issue. If people _are_ able to kludge the old static routes option to work, that will continue to work for clients that don't support CSR, but kludging this draft to support the old static routes option side-by-side CSR *would* break new clients. The reason for the exclusion is that these options are huge, and if the server is asked to send both, it is likely that one of them won't fit, or that some other important option won't be sent. I see no other way to avoid this - I don't think that RFC2131/2132 specify an order for dropping options if they don't all fit, and I don't think it would be appropriate to specify such an ordering in this draft. You do make a number of good points in your criticism, but I wonder if it is necessary that I make the changes you have proposed in order for the draft to be usable, or if they are clarifications of perfectly understandable language that will not actually result in misunderstandings. The reason that I ask is that I would like to get these drafts done, and revising them as you have proposed will then require another long review period, and may introduce mistakes that actually damage the draft. There is no such thing as a draft that cannot be meaningfully clarified - the question is, does it *need* to be clarified. I have at the request of a variety of different people in the WG made changes and clarifications to the draft over time, and the result is that we still don't have a CSR option, some three years after the first draft was written. If we'd just released the draft three years ago, in a perhaps somewhat less clear state, I believe that CSR would be deployed now, and would be working just fine. _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Aug 26 19:45:58 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16554; Sun, 26 Aug 2001 19:45:58 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7QNhpq20799; Sun, 26 Aug 2001 19:43:51 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7QNhnq02697 for ; Sun, 26 Aug 2001 19:43:50 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7QNhmp02695 for ; Sun, 26 Aug 2001 18:43:49 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7QNhmR03424 for ; Sun, 26 Aug 2001 18:43:48 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Sun Aug 26 18:43:47 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 26 Aug 2001 18:43:47 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3498@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Change to 'seconds' field in DHCP message header Date: Sun, 26 Aug 2001 18:43:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12E88.F25CEA10" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12E88.F25CEA10 Content-Type: text/plain; charset="iso-8859-1" More general statement is fine with regard to the relay. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, August 24, 2001 6:24 AM To: DHCPv6 discussion list Subject: RE: Change to 'seconds' field in DHCP message header Thanks for the feedback; comments in line. - Ralph At 12:59 PM 8/23/2001 -0500, Bernie Volz (EUD) wrote: >Perhaps also worth saying that if the elapsed time is >655.35 seconds, >655.35 seconds should be used? It probably will never be the case that >a client waits that long, but just in case (since it would be bad to >have it wrap around and start at low values again). OK. >I agree with Ted's comment to add Relays. But, perhaps it should be a >new sentence, such as "Relays MAY use the data value in this option as >input to policy controlling to which server(s) the relay forwards the >client's message." I think I prefer a more general statement; is there a chance that, in the future, a relay agent may make a decision about the contents of a relay agent option based on the Elapsed Time option value? >- Bernie > >-----Original Message----- >From: Ralph Droms [mailto:rdroms@cisco.com] >Sent: Thursday, August 23, 2001 9:55 AM >To: DHCPv6 discussion list >Subject: Change to 'seconds' field in DHCP message header > >This change eliminates the 'seconds' field from the message header and >replaces it with the "Elapsed Time" option. The transaction-ID is now >24 bits. > >The "Elapsed Time" option carries a 16 bit integer, giving the number >of seconds elapsed since the client began its current transaction. >The number of seconds is expressed in hundredths of a second (10^-2 >seconds). The "Elapsed Time" option can indicate times in the range of >0 to 655 seconds, in increments of 10^-2 seconds. > >This change address the following issue from the London WG meeting: > >* Add 'secs' field to fixed header > > WG consensus: if client retransmits, MUST send option called > "milliseconds" > >Affected text: >-------------- > >8. Message Formats > > Each DHCP message has an identical fixed format header; some messages > also allow a variable format area for options. Not all fields in > the header are used in every message. In this section, every field > is described for every message and fields that are not used in a > message are marked as "unused". All unused fields in a message MUST > be transmitted as zeroes and ignored by the receiver of the message. > > The DHCP message header: > 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 | transaction-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | client-link-local-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | server-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . > . options . > | (variable) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > >18.6. Elapsed Time > > 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 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | OPTION_ELAPSED_TIME | option_len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | elapsed time | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > option-code OPTION_ELAPSED_TIME (4) > > option-len MUST be 2 > > option-data The amount of time since the client began its > current DHCP transaction. This time is expressed in > hundredths of a second (10-2seconds): > > If a client retransmits a DHCP message, it MUST include an Elapsed > Time option in the message to indicate how long the client has been > trying to complete a DHCP transaction. Servers MAY use the data value > in this option as input to policy controlling how a server responds > to a client message. ------_=_NextPart_001_01C12E88.F25CEA10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Change to 'seconds' field in DHCP message header

More general statement is fine with regard to the = relay.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, August 24, 2001 6:24 AM
To: DHCPv6 discussion list
Subject: RE: Change to 'seconds' field in DHCP = message header


Thanks for the feedback; comments in line.

- Ralph

At 12:59 PM 8/23/2001 -0500, Bernie Volz (EUD) = wrote:

>Perhaps also worth saying that if the elapsed = time is >655.35 seconds,
>655.35 seconds should be used? It probably will = never be the case that
>a client waits that long, but just in case = (since it would be bad to
>have it wrap around and start at low values = again).

OK.

>I agree with Ted's comment to add Relays. But, = perhaps it should be a
>new sentence, such as "Relays MAY use the = data value in this option as
>input to policy controlling to which server(s) = the relay forwards the
>client's message."

I think I prefer a more general statement; is there a = chance that,
in the future, a relay agent may make a decision = about the
contents of a relay agent option based on the = Elapsed Time
option value?

>- Bernie
>
>-----Original Message-----
>From: Ralph Droms [<mailto:rdroms@cisco.com>mailto:rdroms@cisco.com]
>Sent: Thursday, August 23, 2001 9:55 AM
>To: DHCPv6 discussion list
>Subject: Change to 'seconds' field in DHCP = message header
>
>This change eliminates the 'seconds' field from = the message header and
>replaces it with the "Elapsed Time" = option.  The transaction-ID is now
>24 bits.
>
>The "Elapsed Time" option carries a 16 = bit integer, giving the number
>of seconds elapsed since the client began its = current transaction.
>The number of seconds is expressed in hundredths = of a second (10^-2
>seconds). The "Elapsed Time" option = can indicate times in the range of
>0 to 655 seconds, in increments of 10^-2 = seconds.
>
>This change address the following issue from the = London WG meeting:
>
>* Add 'secs' field to fixed header
>
>  WG consensus: if client retransmits, MUST = send option called
>  "milliseconds"
>
>Affected text:
>--------------
>
>8. Message Formats
>
>   Each DHCP message has an identical = fixed format header; some messages
>   also allow a variable format area = for options.  Not all fields in
>   the header are used in every = message.  In this section, every field
>   is described for every message and = fields that are not used in a
>   message are marked as = "unused".  All unused fields in a message MUST
>   be transmitted as zeroes and = ignored by the receiver of the message.
>
>   The DHCP message header:
>      = 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   = |            = ;   = transaction-ID         &nbs= p;        |
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
>     = |            = ;            = ;            = ;            = ;            = ;   |
>     = |            = ;       = client-link-local-address        = ;           |
>     = |            = ;            = ;  (16 = octets)           = ;            = ;   |
>     = |            = ;            = ;            = ;            = ;            = ;   |
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
>     = |            = ;            = ;            = ;            = ;            = ;   |
>     = |            = ;            = ; = server-address         &nbs= p;           &nbs= p;  |
>     = |            = ;            = ;  (16 = octets)           = ;            = ;   |
>     = |            = ;            = ;            = ;            = ;            = ;   |
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
>     = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
>     = .           &nbs= p;           &nbs= p;    = options           = ;            = ;     .
>     = |            = ;            = ;  = (variable)          &n= bsp;           &n= bsp;    |
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
>
>
>18.6. Elapsed Time
>
>      = 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
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
>     = |      = OPTION_ELAPSED_TIME      = |           = option_len          | =
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =
>     = |          elapsed = time         |
>     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>      = option-code   OPTION_ELAPSED_TIME (4)
>
>      = option-len    MUST be 2
>
>      = option-data   The amount of time since the client began its =
>          = ;          current DHCP = transaction.  This time is expressed in
>          = ;          hundredths of a = second (10-2seconds):
>
>   If a client retransmits a DHCP = message, it MUST include an Elapsed
>   Time option in the message to = indicate how long the client has been
>   trying to complete a DHCP = transaction.  Servers MAY use the data value
>   in this option as input to policy = controlling how a server responds
>   to a client message.

------_=_NextPart_001_01C12E88.F25CEA10-- From owner-dhcp-v6@bucknell.edu Sun Aug 26 19:46:47 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16574; Sun, 26 Aug 2001 19:46:47 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7QNlPq08369; Sun, 26 Aug 2001 19:47:26 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7QNlCq12260 for ; Sun, 26 Aug 2001 19:47:12 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7QNkt516346 for ; Sun, 26 Aug 2001 18:46:55 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7QNktR03595 for ; Sun, 26 Aug 2001 18:46:55 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sun Aug 26 18:46:54 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Sun, 26 Aug 2001 18:46:54 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B3499@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Change to 'seconds' field in DHCP message header Date: Sun, 26 Aug 2001 18:46:52 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12E89.619E5C10" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12E89.619E5C10 Content-Type: text/plain; charset="iso-8859-1" I think 16-bits is enough (with the counter maxing out). If an attempt goes on that long, no server is probably available and the relays (or servers) will likely long have taken alternative actions (which probably failed as well). So, I see little need to make this more than 16-bits. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Friday, August 24, 2001 12:32 PM To: DHCPv6 discussion list Subject: Re: Change to 'seconds' field in DHCP message header Yup - as a first pass, I took the initiative to define the field to be 16 bits. I'm happy to make it 32 bits, 64 bits - measured in milliseconds, microseconds or the time between the light turning green and the guy behind me honking his horn here in Boston. Other feedback - 16 bits, measured in 10^-2 seconds seemed like enough to me... - Ralph At 11:57 AM 8/24/2001 -0400, you wrote: >> >Perhaps also worth saying that if the elapsed time is >655.35 seconds, >> >655.35 seconds should be used? It probably will never be the case that >> >a client waits that long, but just in case (since it would be bad to >> >have it wrap around and start at low values again). >> >> OK. > >Ga-zikes, is the field only 16 bits? I think 655 seconds is not very >long for some possible applications. Is there any reason not to make >this a 32-bit field? > > _MelloN_ ------_=_NextPart_001_01C12E89.619E5C10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Change to 'seconds' field in DHCP message header

I think 16-bits is enough (with the counter maxing = out). If an attempt goes
on that long, no server is probably available and = the relays (or servers)
will likely long have taken alternative actions = (which probably failed as
well). So, I see little need to make this more than = 16-bits.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Friday, August 24, 2001 12:32 PM
To: DHCPv6 discussion list
Subject: Re: Change to 'seconds' field in DHCP = message header


Yup - as a first pass, I took the initiative to = define the field to be 16 bits.

I'm happy to make it 32 bits, 64 bits - measured in = milliseconds, microseconds or the time between the light turning green = and the guy behind me honking his horn here in Boston.

Other feedback - 16 bits, measured in 10^-2 seconds = seemed like enough to me...

- Ralph

At 11:57 AM 8/24/2001 -0400, you wrote:

>> >Perhaps also worth saying that if the = elapsed time is >655.35 seconds,
>> >655.35 seconds should be used? It = probably will never be the case that
>> >a client waits that long, but just in = case (since it would be bad to
>> >have it wrap around and start at low = values again).
>>
>> OK.
>
>Ga-zikes, is the field only 16 bits?   = I think 655 seconds is not very
>long for some possible applications.   = Is there any reason not to make
>this a 32-bit field?
>
>          = ;            = ;         _MelloN_

------_=_NextPart_001_01C12E89.619E5C10-- From owner-dhcp-v6@bucknell.edu Sun Aug 26 22:42:06 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19372; Sun, 26 Aug 2001 22:42:06 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7R2gRq25498; Sun, 26 Aug 2001 22:42:27 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7R2gCq14675 for ; Sun, 26 Aug 2001 22:42:12 -0400 (EDT) Received: from grosse.bisbee.fugue.com (1Cust218.tnt3.nyc3.da.uu.net [63.23.110.218]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7R2aKf08282 for ; Sun, 26 Aug 2001 19:36:24 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7R2flI00349 for ; Sun, 26 Aug 2001 22:41:47 -0400 (EDT) Message-Id: <200108270241.f7R2flI00349@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from "Bernie Volz (EUD)" of "Sun, 26 Aug 2001 18:43:45 CDT." <66F66129A77AD411B76200508B65AC697B3498@eambunt705.ena-east.ericsson.se> Date: Sun, 26 Aug 2001 22:41:47 -0400 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > >I agree with Ted's comment to add Relays. But, perhaps it should be a > >new sentence, such as "Relays MAY use the data value in this option as > >input to policy controlling to which server(s) the relay forwards the > >client's message." > > I think I prefer a more general statement; is there a chance that, > in the future, a relay agent may make a decision about the > contents of a relay agent option based on the Elapsed Time > option value? Right, AFAIK there's no reason to be so specific about how this will be used. _MelloN_ From owner-dhcp-v6@bucknell.edu Sun Aug 26 22:44:42 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA19396; Sun, 26 Aug 2001 22:44:42 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7R2iMq06660; Sun, 26 Aug 2001 22:44:22 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7R2iDq06178 for ; Sun, 26 Aug 2001 22:44:13 -0400 (EDT) Received: from grosse.bisbee.fugue.com (1Cust218.tnt3.nyc3.da.uu.net [63.23.110.218]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7R2cQf08286 for ; Sun, 26 Aug 2001 19:38:26 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7R2i3I00359 for ; Sun, 26 Aug 2001 22:44:03 -0400 (EDT) Message-Id: <200108270244.f7R2i3I00359@grosse.bisbee.fugue.com> To: DHCPv6 discussion list Subject: Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from "Bernie Volz (EUD)" of "Sun, 26 Aug 2001 18:46:52 CDT." <66F66129A77AD411B76200508B65AC697B3499@eambunt705.ena-east.ericsson.se> Date: Sun, 26 Aug 2001 22:44:02 -0400 From: Ted Lemon Reply-To: dhcp-v6@bucknell.edu Sender: owner-dhcp-v6@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > I think 16-bits is enough (with the counter maxing out). If an attempt goes > on that long, no server is probably available and the relays (or servers) > will likely long have taken alternative actions (which probably failed as > well). So, I see little need to make this more than 16-bits. That's a pretty set of suppositions, but you may well be wrong. Why not make sure that it works if you are? _MelloN_ From dhcwg-admin@ietf.org Mon Aug 27 09:13:24 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16671; Mon, 27 Aug 2001 09:13:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19050; Mon, 27 Aug 2001 09:12:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA19024 for ; Mon, 27 Aug 2001 09:12:06 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16559 for ; Mon, 27 Aug 2001 09:10:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA19797 for ; Mon, 27 Aug 2001 09:11:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827091121.00b648b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 09:11:35 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [Dhcwg] Re: Change to 'seconds' field in DHCP message header Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org (Please note that this message has been sent to the new dhc WG mailing list, dhcwg@ietf.org. The current mailing lists, dhcp-v4@bucknell.edu and dhcp-v6@bucknell.edu, will be taken off line tomorrow, Aug 28, around 4PM. I will arrange for e-mail to the old lists to be forwarded to dhcwg@ietf.org for a couple of months. I will also save the archives from the old lists and make them available on line as soon as possible. - RD) Another alternative for greater range would be to define the units of the data value to be tenths of a second. My intuition is that tenths of a second should be sufficiently precise... Can anyone give us the benefit of experience with the 'secs' field in DHCPv4? There hasn't been any interest in defining a new option with greater range or precision than the current 0-255 seconds measured in seconds. Has the range or precision in DHCPv4 been inadequate in any specific instance? - Ralph At 10:44 PM 8/26/2001 -0400, you wrote: >> I think 16-bits is enough (with the counter maxing out). If an attempt goes >> on that long, no server is probably available and the relays (or servers) >> will likely long have taken alternative actions (which probably failed as >> well). So, I see little need to make this more than 16-bits. > >That's a pretty set of suppositions, but you may well be wrong. Why >not make sure that it works if you are? > > _MelloN_ _______________________________________________ Dhcwg mailing list Dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From owner-dhcp-v6@bucknell.edu Mon Aug 27 09:42:05 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18049; Mon, 27 Aug 2001 09:42:04 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7RDfiq09782; Mon, 27 Aug 2001 09:41:44 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7RDfaq28357 for ; Mon, 27 Aug 2001 09:41:36 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.92.14]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7RDfK518521 for ; Mon, 27 Aug 2001 08:41:21 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7RDfKa17278 for ; Mon, 27 Aug 2001 08:41:20 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Mon Aug 27 08:41:13 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 08:41:12 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B349A@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: DHCPv6 discussion list Subject: RE: Change to 'seconds' field in DHCP message header Date: Mon, 27 Aug 2001 08:41:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12EFD.EEC7A730" 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 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12EFD.EEC7A730 Content-Type: text/plain; charset="iso-8859-1" Because it wastes several additional bytes for what I believe is very little gain. Perhaps there are some bizarre future applications where we want to wait for "long" periods of time, but I can't see any value in this. What this is to be used for is failover type support (either failover protocol or just multiple servers, one which is to be used unless the other fails). If we're really concerned about being able to store long times, why don't we just make this seconds? I can't see any need to make the resolution 100ths of seconds and with seconds we can store many hours worth of time. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Sunday, August 26, 2001 10:44 PM To: DHCPv6 discussion list Subject: Re: Change to 'seconds' field in DHCP message header > I think 16-bits is enough (with the counter maxing out). If an attempt goes > on that long, no server is probably available and the relays (or servers) > will likely long have taken alternative actions (which probably failed as > well). So, I see little need to make this more than 16-bits. That's a pretty set of suppositions, but you may well be wrong. Why not make sure that it works if you are? _MelloN_ ------_=_NextPart_001_01C12EFD.EEC7A730 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Change to 'seconds' field in DHCP message header

Because it wastes several additional bytes for what I = believe is very little gain.

Perhaps there are some bizarre future applications = where we want to wait for "long" periods of time, but I can't = see any value in this. What this is to be used for is failover type = support (either failover protocol or just multiple servers, one which = is to be used unless the other fails).

If we're really concerned about being able to store = long times, why don't we just make this seconds? I can't see any need = to make the resolution 100ths of seconds and with seconds we can store = many hours worth of time.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Sunday, August 26, 2001 10:44 PM
To: DHCPv6 discussion list
Subject: Re: Change to 'seconds' field in DHCP = message header



> I think 16-bits is enough (with the counter = maxing out). If an attempt goes
> on that long, no server is probably available = and the relays (or servers)
> will likely long have taken alternative actions = (which probably failed as
> well). So, I see little need to make this more = than 16-bits.

That's a pretty set of suppositions, but you may well = be wrong.   Why
not make sure that it works if you are?

        =         =                _MelloN_

------_=_NextPart_001_01C12EFD.EEC7A730-- From dhcwg-admin@ietf.org Mon Aug 27 09:47:25 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18257; Mon, 27 Aug 2001 09:47:19 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20190; Mon, 27 Aug 2001 09:46:44 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA20161 for ; Mon, 27 Aug 2001 09:46:42 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18188 for ; Mon, 27 Aug 2001 09:45:22 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7RDkgp18047 for ; Mon, 27 Aug 2001 08:46:42 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7RDkga20407 for ; Mon, 27 Aug 2001 08:46:42 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Aug 27 08:46:41 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 08:46:41 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B349C@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: dhcwg@ietf.org Subject: RE: [Dhcwg] Re: Change to 'seconds' field in DHCP message header Date: Mon, 27 Aug 2001 08:46:40 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12EFE.B3217610" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12EFE.B3217610 Content-Type: text/plain; charset="iso-8859-1" I supported the change to 1/10th of a second (would even support a change to 1 second as mentioned previously). I agree with Ralph. I don't see the need to waste the additional bytes. -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, August 27, 2001 9:12 AM To: dhcwg@ietf.org Subject: [Dhcwg] Re: Change to 'seconds' field in DHCP message header (Please note that this message has been sent to the new dhc WG mailing list, dhcwg@ietf.org. The current mailing lists, dhcp-v4@bucknell.edu and dhcp-v6@bucknell.edu, will be taken off line tomorrow, Aug 28, around 4PM. I will arrange for e-mail to the old lists to be forwarded to dhcwg@ietf.org for a couple of months. I will also save the archives from the old lists and make them available on line as soon as possible. - RD) Another alternative for greater range would be to define the units of the data value to be tenths of a second. My intuition is that tenths of a second should be sufficiently precise... Can anyone give us the benefit of experience with the 'secs' field in DHCPv4? There hasn't been any interest in defining a new option with greater range or precision than the current 0-255 seconds measured in seconds. Has the range or precision in DHCPv4 been inadequate in any specific instance? - Ralph At 10:44 PM 8/26/2001 -0400, you wrote: >> I think 16-bits is enough (with the counter maxing out). If an attempt goes >> on that long, no server is probably available and the relays (or servers) >> will likely long have taken alternative actions (which probably failed as >> well). So, I see little need to make this more than 16-bits. > >That's a pretty set of suppositions, but you may well be wrong. Why >not make sure that it works if you are? > > _MelloN_ _______________________________________________ Dhcwg mailing list Dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C12EFE.B3217610 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Dhcwg] Re: Change to 'seconds' field in DHCP message = header

I supported the change to 1/10th of a second (would = even support a change to 1 second as mentioned previously).

I agree with Ralph. I don't see the need to waste the = additional bytes.

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Monday, August 27, 2001 9:12 AM
To: dhcwg@ietf.org
Subject: [Dhcwg] Re: Change to 'seconds' field in = DHCP message header


(Please note that this message has been sent to the = new dhc WG mailing list, dhcwg@ietf.org.  The current mailing = lists, dhcp-v4@bucknell.edu and dhcp-v6@bucknell.edu, will be taken off = line tomorrow, Aug 28, around 4PM.  I will arrange for e-mail to = the old lists to be forwarded to dhcwg@ietf.org for a couple of = months.  I will also save the archives from the old lists and make = them available on line as soon as possible. - RD)

Another alternative for greater range would be to = define the units of the data value to be tenths of a second.  My = intuition is that tenths of a second should be sufficiently = precise...

Can anyone give us the benefit of experience with the = 'secs' field in DHCPv4?  There hasn't been any interest in = defining a new option with greater range or precision than the current = 0-255 seconds measured in seconds.  Has the range or precision in = DHCPv4 been inadequate in any specific instance?

- Ralph

At 10:44 PM 8/26/2001 -0400, you wrote:

>> I think 16-bits is enough (with the counter = maxing out). If an attempt goes
>> on that long, no server is probably = available and the relays (or servers)
>> will likely long have taken alternative = actions (which probably failed as
>> well). So, I see little need to make this = more than 16-bits.
>
>That's a pretty set of suppositions, but you may = well be wrong.   Why
>not make sure that it works if you are?
>
>          = ;            = ;         _MelloN_


_______________________________________________
Dhcwg mailing list
Dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg=

------_=_NextPart_001_01C12EFE.B3217610-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 10:06:18 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19074; Mon, 27 Aug 2001 10:06:18 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20991; Mon, 27 Aug 2001 10:05:15 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA20965 for ; Mon, 27 Aug 2001 10:05:13 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18991 for ; Mon, 27 Aug 2001 10:03:52 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA25589 for ; Mon, 27 Aug 2001 10:04:42 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827100306.00b649f8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 10:04:38 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] RE: Change to 'seconds' field in DHCP message header Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org (All - please respond through dhcwg@ietf.org. - RD) >From: "Bernie Volz (EUD)" >To: DHCPv6 discussion list >Subject: RE: Change to 'seconds' field in DHCP message header >Date: Mon, 27 Aug 2001 08:41:11 -0500 >X-Mailer: Internet Mail Service (5.5.2653.19) >Reply-To: dhcp-v6@bucknell.edu >Sender: owner-dhcp-v6@bucknell.edu > >Because it wastes several additional bytes for what I believe is very little gain. > >Perhaps there are some bizarre future applications where we want to wait for "long" periods of time, but I can't see any value in this. What this is to be used for is failover type support (either failover protocol or just multiple servers, one which is to be used unless the other fails). > >If we're really concerned about being able to store long times, why don't we just make this seconds? I can't see any need to make the resolution 100ths of seconds and with seconds we can store many hours worth of time. > >- Bernie > >-----Original Message----- >From: Ted Lemon [mailto:mellon@nominum.com] >Sent: Sunday, August 26, 2001 10:44 PM >To: DHCPv6 discussion list >Subject: Re: Change to 'seconds' field in DHCP message header > > >> I think 16-bits is enough (with the counter maxing out). If an attempt goes >> on that long, no server is probably available and the relays (or servers) >> will likely long have taken alternative actions (which probably failed as >> well). So, I see little need to make this more than 16-bits. > >That's a pretty set of suppositions, but you may well be wrong. Why >not make sure that it works if you are? > > _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 10:17:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19603; Mon, 27 Aug 2001 10:17:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21426; Mon, 27 Aug 2001 10:16:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA21397 for ; Mon, 27 Aug 2001 10:16:41 -0400 (EDT) Received: from telutil12a.ml.com (telutil12a-v.ml.com [199.43.34.196]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19567 for ; Mon, 27 Aug 2001 10:15:21 -0400 (EDT) Received: from telutil13a.ml.com (telutil13a [146.125.226.11]) by telutil12a.ml.com (8.11.3/8.11.3/telutil12a-1.1) with ESMTP id f7REGf316731 for ; Mon, 27 Aug 2001 10:16:41 -0400 (EDT) Received: from ehudwt02.exchange.ml.com (ehudwt02.exchange.ml.com [199.201.37.23]) by telutil13a.ml.com (8.11.3/8.11.3/telutil13a-1.0) with SMTP id f7REGfM16275 for ; Mon, 27 Aug 2001 10:16:41 -0400 (EDT) Received: from 146.125.56.74 by ehudwt02.exchange.ml.com with SMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Mon, 27 Aug 2001 10:16:41 -0400 X-Server-Uuid: 3789b954-9c4e-11d3-af68-0008c73b0911 Received: from dtsiwks3a.ml.com by everest.etsol.ml.com ( SMI-8.6/ML54SMX-1.05) id KAA03205; Mon, 27 Aug 2001 10:15:41 -0400 Received: from dtsiwks3a by dtsiwks3a.ml.com (SMI-8.6/SMI-SVR4) id KAA05634; Mon, 27 Aug 2001 10:16:40 -0400 Message-ID: <200108271416.KAA05634@dtsiwks3a.ml.com> Date: Mon, 27 Aug 2001 10:16:40 -0400 (EDT) From: "Thomas Holz" Reply-to: "Thomas Holz" To: dhcwg@ietf.org MIME-Version: 1.0 X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc X-WSS-ID: 179489C3332405-01-01 Content-Type: text/plain; charset=us-ascii Content-MD5: jQUjRPptSZpjEZqrXhWb9w== Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] remove from list Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit please remove from DHCP mailing list _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From owner-dhcp-v4@bucknell.edu Mon Aug 27 10:25:07 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19933 for ; Mon, 27 Aug 2001 10:25:07 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7REJHq16101; Mon, 27 Aug 2001 10:19:18 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7REINq19741 for ; Mon, 27 Aug 2001 10:18:23 -0400 (EDT) Received: from mjs-nt.cisco.com ([172.27.181.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA27220; Mon, 27 Aug 2001 10:18:03 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827085127.02de6960@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 10:16:58 -0400 To: DHCPv4 discussion list From: Mark Stapp Subject: Re: Last call for Cc: DHCPv4 discussion list In-Reply-To: <200108250504.f7P54Kw12906@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Reply-To: mjs@cisco.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN Gosh, this is a bit of a deja vu. I thought we'd gotten language into these drafts that was clear about the role of administrative domains, and that allowed outs for hosts like yours, which run processes that perform updates to zones outside the administrative control of the DHCP admins. There's nothing in these drafts that prohibits a process on your laptop from attempting to update a zone that the DHCP server will not be updating. The drafts only talk about the zones that are administered in parallel with the DHCP servers. There's no intention that servers will blindly perform updates to zones that they aren't configured to update. The general server model is usually that some domain or domains are associated with ip subnets, or with the entire server configuration. That association might also include credentials that the server would use to perform the dns updates. Clients who receive a lease will get a PTR record that points at some name in the domains that the server is configured to update. Either the client is interested in maintaining that name, or the server may maintain it on the client's behalf. Furthermore, the admins may believe that the DHCP clients have sufficient credentials to update A RRs in the admins' domains. If so, they may configure the DHCP servers to tell the clients what name they should update, and trust that the DHCP clients will behave. It may be that the admins choose not to distribute credentials to the clients, and may prefer to have the servers perform updates into the local zones. The servers are easier to control, can remove records as leases expire since they are up all the time, and might be able to offer extra services like configured names for each known client. Your case is exactly the one that caused the words about "other processes" to emerge: a couple of years ago, someone wrote an email hotly complaining that I was trying to take control of all dns updates everywhere on the internet. All that this draft does is to describe a way for a DHCP client and server to exchange some information about the administrative domain where the client is booting. The client gets to tell the server some things that it knows, and the server tells the client some things that it knows. If a host wants to be known by a domain name that the DHCP server doesn't have the authority to update, then that's the host's business: that just means that the client knows about some other administrative domain too. There's nothing in these dhcp drafts that is intended to restrict dns updates on the internet or the kinds of processes that might perform them. The DHCP server is under the control of its administrators, who may have established policies like: "Always give each client matching A and PTR records in a zone we control, in case someone cares to compare those records." If the DHCP client doesn't care to maintain those records, or if it doesn't have the credentials to do so, the DHCP server can do it. At the London meeting, your client did not have credentials (I'm betting) that would have allowed it to update "ietf.org" or "meetings.ietf.org", and the DNS primary for ietf.org probably would not have accepted unauthenticated updates from your laptop. That's the zone that was under the same administrative control as the dhcp servers: there's no reason to expect them to have credentials to update dyndns.org for you! The roving case that concerns you so much is something that the servers could potentially help with. We could define a new option, the "home domain name" option, say, that would allow the client to specify a domain name in its home zone. The server might be willing to add and manage a PTR RR pointing at that name, either in addition to or instead of a PTR pointing to some name in a locally-controlled zone. I've made some more specific replies inline: At 10:04 PM 8/24/01 -0700, Stuart Cheshire wrote: >A bunch of comments on draft-ietf-dhc-fqdn-option-02.txt: > >I agree that it may be useful to have a way to request the DHCP server to >update the PTR record for the address it assigned to you. The DHCP server >has authority to hand out addresses in a certain range; therefore it >makes sense for it to also control the PTR records for addresses in that >range. > >Where I am less convinced is in the vague security arguments about why it >is desirable to have the DHCP server update the hosts "A" record too: > >At the London IETF meeting, my laptop was always reachable at the name >"stu.dyndns.org.", because my DynDNS client updated my "A" record every >time my address changed. > >Having the IETF DHCP server try to update that record would have been >futile, because it doesn't have the credentials to update it. > > > if the server sets both the "S" > > and the "O" bits (the two least-significant bits) in the option's > > flags field, the DHCP client MUST NOT initiate an update > >Having the IETF DHCP server set the "S" and "O" bits to try to prohibit >my DynDNS client from updating its own "A" record would also have been >futile, because the DynDNS client currently ignores those bits, and I >expect it will continue to do so, because it has nothing to gain by >deliberately not working in certain situations. > >The draft even acknowledges this: > > > Furthermore, this specification applies only to DHCP client and > > server processes: it does not apply to other processes which > > initiate DNS updates. > >How do you define the "client process"? Is the Dynamic DNS client >exempted from honoring the "S" and "O" bits if it is in a separate >address space? In a separate library? Compiled from a separate "C" file? >Implemented in a separate function in the same "C" file that also holds >the DHCP code? > >You could say that any code that does Dynamic DNS updates is, by >definition, a Dynamic DNS client, not a DHCP client, so by definition >none of this document applies to any code that does DNS updates. I'm sure >that's not what you intended. > >When most people read "DHCP client", they are going to assume it means >"the machine acquiring the DHCP address." When they observe a DHCP client >acquiring a DHCP address and then promptly update its DNS record, in >violation of the "S" and "O" bits, they are probably going to conclude >that the client is violating this specification. They are probably not >going to conclude that this is perfectly correct, because the DNS update >was done by a piece of DNS update code, not by DHCP code. You downloaded a separate application that performs dns updates for you. Your dhcp client did not initiate these updates to the dyndns.org domain. Furthermore - see above - the server and its admins don't really care about your host's updates to a zone that they don't know anything about. What your dhcp client must not do is initiate updates for the name in the fqdn option if the server tells it not to. > > A DHCP client may be given authority over mapping its own A > > RRs, or that authority may be restricted to a server to > > prevent the client from listing arbitrary addresses or > > associating its address with arbitrary domain names. > >What's the point of "restricted authority to prevent the client >associating its address with arbitrary domain names" if you then provide >a way for an unauthenticated DHCP client to ask the DHCP server on its >behalf to associate its address with arbitrary domain names? Either you >have a secure way of knowing the identity of the client, or you don't, >and if you don't, the extra layer of indirection doesn't make it any more >secure. See above: no one is interested in 'arbitrary domain names'. The name the server is interested is the one in the fqdn option, not the one configured into some other dns update software. > > This document describes a new DHCP option which a client can use to > > convey all or part of its domain name to a DHCP server. > >Why not use the existing Host Name Option (code 12) to carry a fully >qualified host name, as described in RFC 2132? The host name option already has deployed behavior, can't exchange information about who should perform the update, and specifies an ascii encoding. > > The data in the Domain Name field may appear in one of two formats: > > ASCII, or DNS-style binary encoding > >What's the benefit of providing this choice? It just makes the lives of >server writers harder because now they have to support both. Because the option has already been widely deployed using the ascii encoding, which has some significant limitations. That encoding is deprecated, but not invalidated. > > Implementors should note that EDNS0 describes a mechanism for > > extending the length of a DNS RCODE to 12 bits. EDNS0 is specified > > in RFC2671[8]. Only the least-significant 8 bits of the RCODE from a > > DNS update will be carried in the Client FQDN DHCP Option. This > > provides enough number space to accomodate the RCODEs defined in the > > DNS update specification. > >Why provide RCODE fields that are known to be too small to hold the >possible range of RCODE values? Isn't this just setting us up for later >problems? Why not just make the fields large enough? Same historical problem: these have little or no value, but a widely-deployed implementation contains them. It didn't seem to make sense to break a large body of clients. > > If a client that owns/maintains its own FQDN wants to be responsible > > for updating the FQDN to IP address mapping for the FQDN and > > address(es) used by the client, then the client MUST include the > > Client FQDN option in the DHCPREQUEST message originated by the > > client. > >The DHCP client on my Mac cannot comply with this "MUST", because there >is no way for it to know that some time later in the day I might choose >to run my DynDNS client. > >If when you say, "If a client ... wants to be responsible for updating >... then the client MUST ..." you're not talking about my machine as the >"client", but specifically only the DHCP code on the machine, then the >"if" clause is trivially false. My DHCP code only ever sends and receives >DHCP packets. Any code on my machine that sends and receives DNS Update >packets is by definition DNS Update code, not DHCP code. The DHCP client and server are exchanging information about the local administrative domain, the one where the host is booting. If your DHCP client wanted to maintain the name in the fqdn option, a name in a local zone, it would have to comply with this requirement. Since it doesn't, it doesn't. > > A client that delegates the responsibility for updating the FQDN to > > IP address mapping to a server might not receive any indication > > (either positive or negative) from the server whether the server was > > able to perform the update. In this case the client MAY use a DNS > > query to check whether the mapping is updated. > >And do what if it finds it failed? It might inform a user, or its administrator. Someone at some point asked that this check be explicitly permitted, I think. > > The server MAY complete the update before the server sends the > > DHCPACK message to the client. In this case the RCODE from the > > update MUST be carried to the client in the RCODE1 field of the > > Client FQDN option in the DHCPACK message. Alternatively, the server > > MAY send the DHCPACK message to the client without waiting for the > > update to be completed. In this case the RCODE1 field of the Client > > FQDN option in the DHCPACK message MUST be set to 255. The choice > > between the two alternatives is entirely determined by the > > configuration of the DHCP server. Servers SHOULD support both > > configuration options. > >What's the benefit of providing this choice? It just makes the lives of >client writers harder because now they have to support both. As I said earlier, there's not much that clients can do with this rcode information even if it's present. I don't think there's much client difference, actually. > > If a server terminates a lease on an address prior to the lease's > > expiration time, for instance by sending a DHCPNAK to a client, > >Servers can never terminate a lease. Once a client has a lease, it can >use it until it expires, without ever having to talk to the server again. >That's one of the basic principles of DHCP (unless something has changed >recently that I don't know about). Ummm, if a server NAKs your client, you must stop using the address, no? That's why the words 'for instance by sending a DHCPNAK...' are in the sentence you quoted. > > Unauthenticated updates to the DNS can lead to tremendous confusion, > > through malicious attack or through inadvertent misconfiguration. > > Administrators should be wary of permitting unsecured DNS updates > >But this draft specifies a way for unauthenticated clients to have a >trusted DHCP server do inadvertent or malicious DNS updates on their >behalf. How is that better? This draft specifies a way for clients and servers to exchange information about the local network, including an fqdn that the client may be associated with locally. That doesn't make the need for security go away. The warning about unauthenticated dns updates is just that: a warning. It's not a comparison between a 'worse' case and a 'better' one. It's included in a sentence that says 'use tsig, for pity's sake', and be aware that DHCP exchanges are still largely unsecured. It may be that we'll develop a BCP about deploying dns updates or dns updates in dhcp environments at some point as we develop more experience with the authentication mechanism. -- Mark From owner-dhcp-v4@bucknell.edu Mon Aug 27 10:58:23 2001 Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20906 for ; Mon, 27 Aug 2001 10:58:13 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by mail.bucknell.edu (8.11.4/8.11.4) with SMTP id f7RErMq21325; Mon, 27 Aug 2001 10:53:22 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7REr9q06391 for ; Mon, 27 Aug 2001 10:53:10 -0400 (EDT) Received: from grosse.bisbee.fugue.com (1Cust24.tnt2.nyc3.da.uu.net [63.28.109.24]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7RElCf09626; Mon, 27 Aug 2001 07:47:12 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7REqUi00426; Mon, 27 Aug 2001 10:52:30 -0400 (EDT) Message-Id: <200108271452.f7REqUi00426@grosse.bisbee.fugue.com> To: DHCPv4 discussion list cc: DHCPv4 discussion list Subject: Re: Last call for In-Reply-To: Message from Mark Stapp of "Mon, 27 Aug 2001 10:16:58 EDT." <4.3.2.7.2.20010827085127.02de6960@funnel.cisco.com> Date: Mon, 27 Aug 2001 10:52:30 -0400 From: Ted Lemon Reply-To: mellon@nominum.com Sender: owner-dhcp-v4@bucknell.edu X-Listprocessor-Version: 8.2.10/991025/16:55 -- ListProc(tm) by CREN > >If when you say, "If a client ... wants to be responsible for updating > >... then the client MUST ..." you're not talking about my machine as the > >"client", but specifically only the DHCP code on the machine, then the > >"if" clause is trivially false. My DHCP code only ever sends and receives > >DHCP packets. Any code on my machine that sends and receives DNS Update > >packets is by definition DNS Update code, not DHCP code. > > The DHCP client and server are exchanging information about the local > administrative domain, the one where the host is booting. If your DHCP > client wanted to maintain the name in the fqdn option, a name in a local > zone, it would have to comply with this requirement. Since it doesn't, it > doesn't. My client _always_ sends grosse.fugue.com in the FQDN option. I thought that was how the FQDN option was supposed to be used. It also always updates my DNS server. It would be wrong for the DHCP server to tell me not to update grosse.fugue.com, unless it was administered by me (I own the fugue.com domain). However, it's quite possible that it might do this anyway. It could do this because it can't be configured to selectively permit or deny updates based on whether or not the client sent an FQDN, and the administrator wants to prevent the latter case (Microsoft Win2k clients will otherwise attempt to do the update in the local domain, causing errors to be logged by the local name server). It might also be the case that the server administrator is not willing to let you set up a working PTR/A pair, and is trying to signify that by saying you shouldn't do an update. I don't think I am out of conformance with the spec if I ignore the no-client-update bit in the FQDN option - if I am, then you should probably change the relevant MUST to a SHOULD. I have a feeling that that would address Stuart's objections... :'} _MelloN_ From dhcwg-admin@ietf.org Mon Aug 27 11:07:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21114; Mon, 27 Aug 2001 11:07:34 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23343; Mon, 27 Aug 2001 11:04:09 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23320 for ; Mon, 27 Aug 2001 11:04:06 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20995 for ; Mon, 27 Aug 2001 11:02:33 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA04190 for ; Mon, 27 Aug 2001 11:03:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827110130.00b94da8@mail.bucknell.edu> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 11:03:20 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org (Please follow up to dhcwg@ietf.org mailing list. - RD) >Subject: Re: Last call for >Date: Mon, 27 Aug 2001 10:52:30 -0400 >From: Ted Lemon > > >> >If when you say, "If a client ... wants to be responsible for updating >> >... then the client MUST ..." you're not talking about my machine as the >> >"client", but specifically only the DHCP code on the machine, then the >> >"if" clause is trivially false. My DHCP code only ever sends and receives >> >DHCP packets. Any code on my machine that sends and receives DNS Update >> >packets is by definition DNS Update code, not DHCP code. >> >> The DHCP client and server are exchanging information about the local >> administrative domain, the one where the host is booting. If your DHCP >> client wanted to maintain the name in the fqdn option, a name in a local >> zone, it would have to comply with this requirement. Since it doesn't, it >> doesn't. > >My client _always_ sends grosse.fugue.com in the FQDN option. I >thought that was how the FQDN option was supposed to be used. It also >always updates my DNS server. It would be wrong for the DHCP server >to tell me not to update grosse.fugue.com, unless it was administered >by me (I own the fugue.com domain). However, it's quite possible that >it might do this anyway. It could do this because it can't be >configured to selectively permit or deny updates based on whether or >not the client sent an FQDN, and the administrator wants to prevent >the latter case (Microsoft Win2k clients will otherwise attempt to do >the update in the local domain, causing errors to be logged by the >local name server). It might also be the case that the server >administrator is not willing to let you set up a working PTR/A pair, >and is trying to signify that by saying you shouldn't do an update. > >I don't think I am out of conformance with the spec if I ignore the >no-client-update bit in the FQDN option - if I am, then you should >probably change the relevant MUST to a SHOULD. I have a feeling that >that would address Stuart's objections... :'} > > _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 11:21:02 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21411; Mon, 27 Aug 2001 11:21:02 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23700; Mon, 27 Aug 2001 11:19:32 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA23673 for ; Mon, 27 Aug 2001 11:19:30 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21363 for ; Mon, 27 Aug 2001 11:18:08 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA06484 for ; Mon, 27 Aug 2001 11:18:59 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827111658.00ba4ee0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 11:18:59 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Admin requests Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Please do not post requests to unsubscribe to dhcwg@ietf.org. For admin requests - to unsubscribe from the new list - please go to http://www1.ietf.org/mailman/subscribe/dhcwg (look to the bottom of the page for existing subscriptions) or send e-mail containing the message "help" to dhcwg-request@ietf.org - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 12:50:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24232; Mon, 27 Aug 2001 12:50:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26611; Mon, 27 Aug 2001 12:49:17 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26586 for ; Mon, 27 Aug 2001 12:49:15 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24127 for ; Mon, 27 Aug 2001 12:47:51 -0400 (EDT) Received: from mjs-nt.cisco.com ([172.27.181.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA17656; Mon, 27 Aug 2001 12:48:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827104131.031063b0@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 12:48:27 -0400 To: cheshire@apple.com From: Mark Stapp Cc: dhcwg@ietf.org In-Reply-To: <200108250531.f7P5Vlw17510@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Stuart, At 10:31 PM 8/24/01 -0700, Stuart Cheshire wrote: > > Furthermore, this specification > > applies only to DHCP client and server processes: it does not apply > > to other processes which initiate DNS updates. > >Same comment as for draft-ietf-dhc-fqdn-option: Protocol specifications >need to specify what packets are valid on the wire -- how the code is >implemented shouldn't matter. If two hosts send identical packet >sequences, it makes no sense to say that one is legal and the other is >not because one host used different "processes" to send the packets and >the other host did it using a single "process". The motivation for the sentence you quote is pretty simple: the rr and the MUSTs and SHOULDs for noticing and using it are designed to address the needs of the DHCP community. The rr is not a general-purpose 'identifier rr'. The method for computing its data is explicitly tied to DHCP message data. It seemed more direct to say that up-front rather than leave it as an implication of the specification. Other situations involving other updaters of DNS are outside the scope of the DHC WG. > > At many sites, the difficulties with distributing DNS update > > credentials to all of the DHCP clients lead to the desire for the > > DHCP servers to perform A RR updates on behalf of their clients. > >If the clients don't have any credentials to prove they are not rogue >clients, how secure is it to allow rogue clients to ask a middleman to do >updates for them? There is certainly a level of administrative control that can be exercised by limiting dns update credentials to the DHCP servers. The sentence you quote is about distributing DNS update credentials, based on the observation that it may be more practical to distribute them to a few servers rather than to very many clients. The alternative is also, of course, valid: clients may be assigned credentials that allow them to update some name or names. Both of these specifications say explicitly that there's no DHCP security right now, and that unsecured DNS updates are a bad idea. But DHCP works acceptably in some places in spite of its security flaws. > > FOr this purpose, a DHCID RR, described in [6], is used to associate > > client identification information with a DNS name and the A or PTR > > RR associated with that name. When either a client or server adds an > > A or PTR RR for a client, it also adds a DHCID RR which specifies a > > unique client identity (based on a "client specifier" created from > > the data in the client's DHCPREQUEST message). In this model, only > > one A RR is associated with a given DNS name at a time. > >I don't think this works. > >The purpose of the DHCID RR is to protect against two clients that are >accidentally configured to think they have the same host name. > >Adding the DHCID RR is just another level of indirection to the same >problem: what do you do if two clients are accidentally configured to >think they have the same DHCID? > >If the DHCID RR is derived from the Client Identifier Option (code 61) >then there's no protection against two clients being accidentally >configured with the same value, so this option hasn't solved the "unique >identifier" problem. Absolutely - this method does not prevent accidental or malicious misconfigurations. But from the perspective of the dhcp servers, two hosts presenting the same CID are the same client, so there are several problems that this particular misconfiguration will cause, and which aren't addressed by the existing DHCP specification. >If the DHCID RR is derived from the client's link-layer network address, >then it is harder to have accidental collisions because user's don't >normally manually set their link-layer address, but now you have the >opposite problem: false negatives, as described below: > >What about the user who uses a laptop on Ethernet in the office, and then >uses 802.11 wireless in the conference room, and then uses PPP over a >modem when dialing in from home? > >When they leave their office Ethernet try to access the network from the >conference room using wireless, the DNS update will fail because they are >accessing the network from a different link-layer address, so they appear >to be a different client trying to steal a DNS name that's already in use. > >When they dial in from home in the evening, their modem doesn't even have >a link-layer address to use to derive the DHCID. Quite correct. This is an issue with DHCP in general. This single host with multiple CIDs is seen as more than one client by most DHCP servers: that's the way the protocol works. This is the problem with CIDs that vary with the link-layer: it would be useful if clients allowed a stable identifier to be configured, or could generate and remember one. >Even supposing that they are connecting from home using a 802.11 wireless >and a DSL line, so they do have a link-layer address, what chance is >there that the Cisco DNS servers are going to let Pacific Bell's DHCP >servers do unauthenticated DNS updates? None at all: see my explanation of administrative domains in the previous email. I'd expect that the pacbell dhcp servers might update some zones that pb controls, not that they'd arbitrarily initiate updates to zones that they have no credentials to update. >I think the main benefit of Dynamic DNS updates is to allow mobile >clients to be reached using a constant name, no matter where they are. I >think a mobility solution that only works as long as users don't leave >their office Ethernet has limited applicability. That assertion is really about mobility and the dns protocols, though it may valid for some portion of the dhcp clients in the world. You've addressed your needs by obtaining DNS service that is independent of your DHCP service (and even of whether or not you're using DHCP.) Personally, I don't particularly care whether my laptop can be 'reached' using a stable dns name when I'm roaming. Most of the time, I'm behind someone's firewall or on a VPN where my host couldn't accept an incoming smtp, ftp, or http connection anyway. It works much better for me to use other servers to hold my mail and serve my public data. When I'm roaming, I don't really need to be 'pingable', and my IP reachability is often so restricted that a 'constant' dns name wouldn't matter. I don't think that the configuration you use is prohibited by the specifications under discussion. If you think that it is, would you please send me some examples of specific clarifications that would help you? Or is there something that should be added to the introduction section somewhere that would better delineate where this specification applies and where it doesn't? I think that the sentences about non-DHCP client processes pretty much address your case, but if they're not adequate, I'd like to improve them. Thanks, Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 12:57:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24544; Mon, 27 Aug 2001 12:57:40 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26824; Mon, 27 Aug 2001 12:56:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA26796 for ; Mon, 27 Aug 2001 12:56:40 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24365 for ; Mon, 27 Aug 2001 12:55:20 -0400 (EDT) Received: from mjs-nt.cisco.com ([172.27.181.73]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id MAA18601; Mon, 27 Aug 2001 12:56:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827124938.03034960@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 12:56:07 -0400 To: mellon@nominum.com From: Mark Stapp Cc: dhcwg@ietf.org In-Reply-To: <200108271452.f7REqUi00426@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010827085127.02de6960@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ted, I agree with you about the purpose of the bit, but I'm a little confused by your last paragraph. Do you mean that even if the server was configured by you, and it asked your client not to update grosse.fugue.com, you'd like your client to update that zone anyway? I guess I don't see the point of that: if the dns and dhcp share administration, the 'don't update' bit tells the client that the administrators don't want the client to do the update for the fqdn in the option. If you get to ignore that bit, why don't the win2k clients get to ignore it too, and fire updates into your zone? -- Mark At 10:52 AM 8/27/01 -0400, Ted Lemon wrote: > > >If when you say, "If a client ... wants to be responsible for updating > > >... then the client MUST ..." you're not talking about my machine as the > > >"client", but specifically only the DHCP code on the machine, then the > > >"if" clause is trivially false. My DHCP code only ever sends and receives > > >DHCP packets. Any code on my machine that sends and receives DNS Update > > >packets is by definition DNS Update code, not DHCP code. > > > > The DHCP client and server are exchanging information about the local > > administrative domain, the one where the host is booting. If your DHCP > > client wanted to maintain the name in the fqdn option, a name in a local > > zone, it would have to comply with this requirement. Since it doesn't, it > > doesn't. > >My client _always_ sends grosse.fugue.com in the FQDN option. I >thought that was how the FQDN option was supposed to be used. It also >always updates my DNS server. It would be wrong for the DHCP server >to tell me not to update grosse.fugue.com, unless it was administered >by me (I own the fugue.com domain). However, it's quite possible that >it might do this anyway. It could do this because it can't be >configured to selectively permit or deny updates based on whether or >not the client sent an FQDN, and the administrator wants to prevent >the latter case (Microsoft Win2k clients will otherwise attempt to do >the update in the local domain, causing errors to be logged by the >local name server). It might also be the case that the server >administrator is not willing to let you set up a working PTR/A pair, >and is trying to signify that by saying you shouldn't do an update. > >I don't think I am out of conformance with the spec if I ignore the >no-client-update bit in the FQDN option - if I am, then you should >probably change the relevant MUST to a SHOULD. I have a feeling that >that would address Stuart's objections... :'} > > _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 16:59:12 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00159; Mon, 27 Aug 2001 16:59:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04110; Mon, 27 Aug 2001 16:56:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04086 for ; Mon, 27 Aug 2001 16:56:02 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00049 for ; Mon, 27 Aug 2001 16:54:41 -0400 (EDT) Received: from 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 NAA19019 for ; Mon, 27 Aug 2001 13:56:01 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 27 Aug 2001 13:55:58 -0700 Received: from [206.111.147.149] (vpn-gh-1056.apple.com [17.254.140.31]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id NAA08040; Mon, 27 Aug 2001 13:55:57 -0700 (PDT) Message-Id: <200108272055.NAA08040@scv3.apple.com> Date: Mon, 27 Aug 2001 13:55:56 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Ted Lemon" , "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [dhcwg] Re: Several reminders Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >Actually, this is not true, and is a dangerous idea. If I define the >format of something that's authoritatively defined elsewhere in my own >draft, and I make a mistake in transcribing or paraphrasing the >authoritative source, this is likely to create interoperability >problems when someone doesn't refer to the source. So I _must_ refer >to the authoritative source, and _must not_ paraphrase it. Ted, I'm not understanding your point. I didn't say that you shouldn't have references. What I said was that writing a number in little square brackets doesn't exempt the writer from the normal rules of English grammar. Footnotes and endnotes are not the English language equivalent of "#include". If the text is necessary for the basic understanding of the sentence, then it should be in the sentence. Footnotes and endnotes can provide additional clarification, but the sentence should still be grammatically correct if you ignore them. This seems to be a modern trend in writing, particularly in documents like RFCs which not academic research papers, but are written somewhat in that style. If you look at research publications from fifty years ago, no one would ever have thought of using a sprinking of footnote and endnote references as a substitute for a grammatically correct sentence. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 17:05:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00381; Mon, 27 Aug 2001 17:05:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04747; Mon, 27 Aug 2001 17:05:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04721 for ; Mon, 27 Aug 2001 17:05:01 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00330 for ; Mon, 27 Aug 2001 17:03:40 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id OAA21075 for ; Mon, 27 Aug 2001 14:05:01 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 27 Aug 2001 14:03:07 +0100 Received: from [206.111.147.149] (vpn-gh-1056.apple.com [17.254.140.31]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id OAA01850; Mon, 27 Aug 2001 14:05:00 -0700 (PDT) Message-Id: <200108272105.OAA01850@scv1.apple.com> Date: Mon, 27 Aug 2001 14:04:58 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Mark Stapp" , "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >At the London meeting, your client did not have credentials >(I'm betting) that would have allowed it to update "ietf.org" or >"meetings.ietf.org", and the DNS primary for ietf.org probably >would not have accepted unauthenticated updates from your laptop. Why would that have been useful? What's the point of having a constant well-know host name if that host name keep changing every time you move? If my laptop is called "something.ietf.org." when I'm at an IETF meeting, and "something.apple.com." when I'm at work, and "something.stanford.edu." when I'm at Stanford, what use is that? My host *did* have various names of the form "host217-33-141-85.ietf.ignite.net" while I was at the meeting, which had both valid forward and reverse mappings. If my host is going to have some name which it cannot control and which no one else knows, then who cares whether it was dynamically updated or not? >You downloaded a separate application that performs dns updates for you. A protocol specification should specify packets on the wire, not how the software is packaged. >What your dhcp client must not do is initiate updates for the name >in the fqdn option if the server tells it not to. If the DNS administrator doesn't want me to initiate updates, then that's achieved simply by not giving my client the cryptographic credentials necessary to do the updates. If I don't have the credentials, then I can't do the update, and the question of whether my client obey's the DHCP server or not becomes a moot point. >no one is interested in 'arbitrary domain names'. That text about 'arbitrary domain names' was quoted from your draft. >The host name option already has deployed behavior, Which works fine. >and specifies an ascii encoding. Which works fine. >can't exchange information about who should perform the update, Then perhaps the draft should be specifying a "who wants to do the dynamic DNS update?" option, not an Fully Qualified Domain Name option. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 17:05:52 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00410; Mon, 27 Aug 2001 17:05:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04792; Mon, 27 Aug 2001 17:05:14 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04762 for ; Mon, 27 Aug 2001 17:05:12 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00333 for ; Mon, 27 Aug 2001 17:03:52 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id OAA21126 for ; Mon, 27 Aug 2001 14:05:12 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 27 Aug 2001 14:03:19 +0100 Received: from [206.111.147.149] (vpn-gh-1056.apple.com [17.254.140.31]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id OAA01923; Mon, 27 Aug 2001 14:05:12 -0700 (PDT) Message-Id: <200108272105.OAA01923@scv1.apple.com> Subject: Re: [dhcwg] Re: Last call for Date: Mon, 27 Aug 2001 14:05:11 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Mark Stapp" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >Personally, I don't particularly care whether my laptop can be 'reached' >using a stable dns name Now I'm really confused about why you're writing this draft. What is the point of doing dynamic DNS updates, if not so that your machine has a constant DNS name by which other hosts can refer to it? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 17:07:32 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00459; Mon, 27 Aug 2001 17:07:28 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04245; Mon, 27 Aug 2001 16:59:18 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA04217 for ; Mon, 27 Aug 2001 16:59:16 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00142 for ; Mon, 27 Aug 2001 16:57:55 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id NAA16978 for ; Mon, 27 Aug 2001 13:59:16 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 27 Aug 2001 13:59:14 -0700 Received: from [206.111.147.149] (vpn-gh-1056.apple.com [17.254.140.31]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f7RKxEw00418; Mon, 27 Aug 2001 13:59:14 -0700 (PDT) Message-Id: <200108272059.f7RKxEw00418@scv2.apple.com> Date: Mon, 27 Aug 2001 13:59:13 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Ted Lemon" , "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >I find it difficult to believe that any existing, deployed network >depends on the correct operation of the existing static routes option. >Do you know of such a network, or are you speaking hypothetically? >CIDR is close to a decade old now, and I find it difficult to believe >that there exists a network where the static routes option is needed >and where it can correctly represent the routing table that one would >need to send to the client. Ted, I'm not trying to impede progress on this document. On the contrary, I want to get it published ASAP so I can include it in the next Mac OS release, but I can't if it is written in such as way as to prevent me from doing that. Apple ships millions of copies of Mac OS. If we change *anything*, there's always a non-zero number of people who will complain about it. The most common use of static routes I know is to tell a host with a global address and a default gateway that Net 10/8 is local and reachable via a different route. I can't ship an update that breaks that. >kludging this draft to support the old static routes option >side-by-side CSR *would* break new clients. Why would this break new clients? Clients can request all three options, but only use "routers" and "static routes" when there's no "classless static routes" data in the packet. The draft already suggests exactly this mechanism for the "routers" option. Why not the same mechanism for "static routes" too? >The reason for the exclusion is that these options are huge, and if >the server is asked to send both, it is likely that one of them won't >fit, or that some other important option won't be sent. You've said yourself that most sites are not even using "static routes", so why is this going to be a problem? Once CSR support is widespread in clients, sites that are currently using (or abusing) "static routes" can simply switch over to CSR instead. I expect most servers won't send both -- but the client has to ask for both because it doesn't know what the server is going to send. >I would like to get these drafts done, >and revising them as you have proposed will then require another long >review period, and may introduce mistakes that actually damage the >draft. There is no such thing as a draft that cannot be meaningfully >clarified - the question is, does it *need* to be clarified. I also don't want to delay it, but the "MUST NOT request the Static Routes option" wasn't in the first few drafts I read, and I apologize for not noticing it sooner. As it is, the draft mandates that I have to break existing functionality if I want to support CSR. I can't do that. I proposed new text to try to help this go smoothly. If the WG members agree with the proposed new text, then we have consensus. Question for the Working Group: *********************************************************** * * * Can anyone give any technical reason why it is * * necessary for *this* document to prohibit clients * * from requesting DHCP option number 6 (static routes)? * * * *********************************************************** Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 17:07:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00500; Mon, 27 Aug 2001 17:07:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04963; Mon, 27 Aug 2001 17:06:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04931 for ; Mon, 27 Aug 2001 17:06:46 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00365 for ; Mon, 27 Aug 2001 17:05:25 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.9.3/8.9.3) with ESMTP id OAA21545 for ; Mon, 27 Aug 2001 14:06:46 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 27 Aug 2001 14:04:53 +0100 Received: from [206.111.147.149] (vpn-gh-1056.apple.com [17.254.140.31]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id OAA02524; Mon, 27 Aug 2001 14:06:45 -0700 (PDT) Message-Id: <200108272106.OAA02524@scv1.apple.com> Subject: Re: [dhcwg] Re: Last call for Date: Mon, 27 Aug 2001 14:06:44 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Mark Stapp" , Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >I agree with you about the purpose of the bit, but I'm a little confused by >your last paragraph. Do you mean that even if the server was configured by >you, and it asked your client not to update grosse.fugue.com, you'd like >your client to update that zone anyway? How would Ted's DHCP client *know* that the server was configured by Ted? When Ted's sitting in Starbucks with his laptop and the Starbucks DHCP server tells it not to update "grosse.fugue.com.", how can Ted's DHCP client distinguish that case from Ted's own DHCP server telling it not to update "grosse.fugue.com."? Furthermore, if Ted's laptop has the software and the credentials to safely update "grosse.fugue.com.", why would Ted *ever* set his DHCP server to tell his client not to? Surely Ted will want his laptop to *always* ignore the "don't update" bit, because he knows that if the bit is ever set, it will be from a DHCP server that has no authority to tell him not to update his own domain? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 17:10:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00601; Mon, 27 Aug 2001 17:10:07 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA05004; Mon, 27 Aug 2001 17:07:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA04981 for ; Mon, 27 Aug 2001 17:07:23 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00440 for ; Mon, 27 Aug 2001 17:06:02 -0400 (EDT) Received: from apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id OAA18859 for ; Mon, 27 Aug 2001 14:07:21 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 27 Aug 2001 14:07:20 -0700 Received: from [206.111.147.149] (vpn-gh-1056.apple.com [17.254.140.31]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id f7RL7Kw03215; Mon, 27 Aug 2001 14:07:20 -0700 (PDT) Message-Id: <200108272107.f7RL7Kw03215@scv2.apple.com> Date: Mon, 27 Aug 2001 14:07:19 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Mark Stapp" , "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >the [FQDN] option has already been widely deployed This I think is the real issue. The purpose of WG discussion is to discuss protocol design, not to rubber-stamp an existing implementation, warts and all. An Informational RFC is the right place to document an existing implementation, warts and all. Mark, don't misunderstand this. I don't have any objection to you shipping products. I do object to a Standards-Track RFC published after-the-fact to give the impression that the design of the previously mentioned shipping products was the result of IETF Working Group Consensus. If you want this to be a Working Group publication, you have to be able to update your deployed products to comply with the eventual Working Group Consensus. If you can't update your deployed products to comply, then this whole process is a waste of time. Just publish it as Informational. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 17:57:38 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01892; Mon, 27 Aug 2001 17:57:38 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06497; Mon, 27 Aug 2001 17:56:52 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA06431 for ; Mon, 27 Aug 2001 17:56:49 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01664 for ; Mon, 27 Aug 2001 17:55:27 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7RLujp13776 for ; Mon, 27 Aug 2001 16:56:45 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7RLujT10327 for ; Mon, 27 Aug 2001 16:56:45 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Aug 27 16:56:04 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 16:56:03 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34A6@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Mark Stapp'" , mellon@nominum.com Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Re: Last call for Date: Mon, 27 Aug 2001 16:56:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12F43.10076940" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12F43.10076940 Content-Type: text/plain; charset="iso-8859-1" I think in Ted's case the server would not return the same FQDN option if it wasn't a fugue.com server. Ted's saying that his client would always send the FQDN with grosse.fugue.com, but that's not necessarily what the server would send back. Hence, if the server sends back some other domain (such as blah.ietf.org if he was at an IETF meeting), his client will go ahead and update the grosse.fugue.com domain anyway. I think that is OK. The client must just do what the server wants it to do about the FQDN supplied by the server, it can't say what to do about the FQDN supplied by the client. Or, am I wrong about this? - Bernie -----Original Message----- From: Mark Stapp [mailto:mjs@cisco.com] Sent: Monday, August 27, 2001 12:56 PM To: mellon@nominum.com Cc: dhcwg@ietf.org Subject: [dhcwg] Re: Last call for Ted, I agree with you about the purpose of the bit, but I'm a little confused by your last paragraph. Do you mean that even if the server was configured by you, and it asked your client not to update grosse.fugue.com, you'd like your client to update that zone anyway? I guess I don't see the point of that: if the dns and dhcp share administration, the 'don't update' bit tells the client that the administrators don't want the client to do the update for the fqdn in the option. If you get to ignore that bit, why don't the win2k clients get to ignore it too, and fire updates into your zone? -- Mark At 10:52 AM 8/27/01 -0400, Ted Lemon wrote: > > >If when you say, "If a client ... wants to be responsible for updating > > >... then the client MUST ..." you're not talking about my machine as the > > >"client", but specifically only the DHCP code on the machine, then the > > >"if" clause is trivially false. My DHCP code only ever sends and receives > > >DHCP packets. Any code on my machine that sends and receives DNS Update > > >packets is by definition DNS Update code, not DHCP code. > > > > The DHCP client and server are exchanging information about the local > > administrative domain, the one where the host is booting. If your DHCP > > client wanted to maintain the name in the fqdn option, a name in a local > > zone, it would have to comply with this requirement. Since it doesn't, it > > doesn't. > >My client _always_ sends grosse.fugue.com in the FQDN option. I >thought that was how the FQDN option was supposed to be used. It also >always updates my DNS server. It would be wrong for the DHCP server >to tell me not to update grosse.fugue.com, unless it was administered >by me (I own the fugue.com domain). However, it's quite possible that >it might do this anyway. It could do this because it can't be >configured to selectively permit or deny updates based on whether or >not the client sent an FQDN, and the administrator wants to prevent >the latter case (Microsoft Win2k clients will otherwise attempt to do >the update in the local domain, causing errors to be logged by the >local name server). It might also be the case that the server >administrator is not willing to let you set up a working PTR/A pair, >and is trying to signify that by saying you shouldn't do an update. > >I don't think I am out of conformance with the spec if I ignore the >no-client-update bit in the FQDN option - if I am, then you should >probably change the relevant MUST to a SHOULD. I have a feeling that >that would address Stuart's objections... :'} > > _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C12F43.10076940 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>

I think in Ted's case the server would not return the same FQDN option if it wasn't
a fugue.com server. Ted's saying that his client would always send the FQDN with
grosse.fugue.com, but that's not necessarily what the server would send back. Hence,
if the server sends back some other domain (such as blah.ietf.org if he was at an
IETF meeting), his client will go ahead and update the grosse.fugue.com domain anyway.
I think that is OK. The client must just do what the server wants it to do about the
FQDN supplied by the server, it can't say what to do about the FQDN supplied by the
client.

Or, am I wrong about this?

- Bernie

-----Original Message-----
From: Mark Stapp [mailto:mjs@cisco.com]
Sent: Monday, August 27, 2001 12:56 PM
To: mellon@nominum.com
Cc: dhcwg@ietf.org
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-fqdn-option-02.txt>


Ted,
I agree with you about the purpose of the bit, but I'm a little confused by
your last paragraph. Do you mean that even if the server was configured by
you, and it asked your client not to update grosse.fugue.com, you'd like
your client to update that zone anyway? I guess I don't see the point of
that: if the dns and dhcp share administration, the 'don't update' bit
tells the client that the administrators don't want the client to do the
update for the fqdn in the option. If you get to ignore that bit, why don't
the win2k clients get to ignore it too, and fire updates into your zone?

-- Mark

At 10:52 AM 8/27/01 -0400, Ted Lemon wrote:

> > >If when you say, "If a client ... wants to be responsible for updating
> > >... then the client MUST ..." you're not talking about my machine as the
> > >"client", but specifically only the DHCP code on the machine, then the
> > >"if" clause is trivially false. My DHCP code only ever sends and receives
> > >DHCP packets. Any code on my machine that sends and receives DNS Update
> > >packets is by definition DNS Update code, not DHCP code.
> >
> > The DHCP client and server are exchanging information about the local
> > administrative domain, the one where the host is booting. If your DHCP
> > client wanted to maintain the name in the fqdn option, a name in a local
> > zone, it would have to comply with this requirement. Since it doesn't, it
> > doesn't.
>
>My client _always_ sends grosse.fugue.com in the FQDN option.  I
>thought that was how the FQDN option was supposed to be used.  It also
>always updates my DNS server.  It would be wrong for the DHCP server
>to tell me not to update grosse.fugue.com, unless it was administered
>by me (I own the fugue.com domain).  However, it's quite possible that
>it might do this anyway.  It could do this because it can't be
>configured to selectively permit or deny updates based on whether or
>not the client sent an FQDN, and the administrator wants to prevent
>the latter case (Microsoft Win2k clients will otherwise attempt to do
>the update in the local domain, causing errors to be logged by the
>local name server).   It might also be the case that the server
>administrator is not willing to let you set up a working PTR/A pair,
>and is trying to signify that by saying you shouldn't do an update.
>
>I don't think I am out of conformance with the spec if I ignore the
>no-client-update bit in the FQDN option - if I am, then you should
>probably change the relevant MUST to a SHOULD.   I have a feeling that
>that would address Stuart's objections... :'}
>
>                                _MelloN_


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C12F43.10076940-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 18:13:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02414; Mon, 27 Aug 2001 18:13:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07731; Mon, 27 Aug 2001 18:08:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07700 for ; Mon, 27 Aug 2001 18:08:02 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02101 for ; Mon, 27 Aug 2001 18:06:39 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7RM80p19097 for ; Mon, 27 Aug 2001 17:08:00 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7RM80T16032 for ; Mon, 27 Aug 2001 17:08:00 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Mon Aug 27 17:07:59 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 17:07:58 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34A7@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Stuart Cheshire'" , Ted Lemon , DHCP discussion list Subject: RE: [dhcwg] Re: Several reminders Date: Mon, 27 Aug 2001 17:07:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12F44.BAA3C0A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12F44.BAA3C0A0 Content-Type: text/plain; charset="iso-8859-1" Stuart, I think Ted misunderstood what you requested ... I did too until I looked at your examples. Just to be clear, Ted he wasn't asking you to describe what the document said. He was just saying that you should put in full sentences. Look at the examples Stuart gave of the changes. I do think they are good changes because, as Stuart pointed out, you do not need to look up the reference to understand the sentence. The different is sutble but significant. A very simple example is rather than to use " ... the Transmission Control Protocol [RFC 793]" instead of " ... [5]" where [5] is a reference to RFC 793. I think this change is minor enough that it should be allowable during the final editing process (perhaps the RFC-Editor would do it anyway)? - Bernie -----Original Message----- From: Stuart Cheshire [mailto:cheshire@apple.com] Sent: Monday, August 27, 2001 4:56 PM To: Ted Lemon; DHCP discussion list Subject: [dhcwg] Re: Several reminders >Actually, this is not true, and is a dangerous idea. If I define the >format of something that's authoritatively defined elsewhere in my own >draft, and I make a mistake in transcribing or paraphrasing the >authoritative source, this is likely to create interoperability >problems when someone doesn't refer to the source. So I _must_ refer >to the authoritative source, and _must not_ paraphrase it. Ted, I'm not understanding your point. I didn't say that you shouldn't have references. What I said was that writing a number in little square brackets doesn't exempt the writer from the normal rules of English grammar. Footnotes and endnotes are not the English language equivalent of "#include". If the text is necessary for the basic understanding of the sentence, then it should be in the sentence. Footnotes and endnotes can provide additional clarification, but the sentence should still be grammatically correct if you ignore them. This seems to be a modern trend in writing, particularly in documents like RFCs which not academic research papers, but are written somewhat in that style. If you look at research publications from fifty years ago, no one would ever have thought of using a sprinking of footnote and endnote references as a substitute for a grammatically correct sentence. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C12F44.BAA3C0A0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Re: Several reminders

Stuart, I think Ted misunderstood what you requested ... I did too until I
looked at your examples.

Just to be clear, Ted he wasn't asking you to describe what the document said.
He was just saying that you should put in full sentences.

Look at the examples Stuart gave of the changes. I do think they are good changes
because, as Stuart pointed out, you do not need to look up the reference to
understand the sentence. The different is sutble but significant. A very
simple example is rather than to use " ... the Transmission Control Protocol [RFC 793]"
instead of " ... [5]" where [5] is a reference to RFC 793.

I think this change is minor enough that it should be allowable during the final
editing process (perhaps the RFC-Editor would do it anyway)?

- Bernie

-----Original Message-----
From: Stuart Cheshire [mailto:cheshire@apple.com]
Sent: Monday, August 27, 2001 4:56 PM
To: Ted Lemon; DHCP discussion list
Subject: [dhcwg] Re: Several reminders


>Actually, this is not true, and is a dangerous idea.   If I define the
>format of something that's authoritatively defined elsewhere in my own
>draft, and I make a mistake in transcribing or paraphrasing the
>authoritative source, this is likely to create interoperability
>problems when someone doesn't refer to the source.   So I _must_ refer
>to the authoritative source, and _must not_ paraphrase it.

Ted,

I'm not understanding your point.

I didn't say that you shouldn't have references. What I said was that
writing a number in little square brackets doesn't exempt the writer from
the normal rules of English grammar. Footnotes and endnotes are not the
English language equivalent of "#include". If the text is necessary for
the basic understanding of the sentence, then it should be in the
sentence. Footnotes and endnotes can provide additional clarification,
but the sentence should still be grammatically correct if you ignore them.

This seems to be a modern trend in writing, particularly in documents
like RFCs which not academic research papers, but are written somewhat in
that style. If you look at research publications from fifty years ago, no
one would ever have thought of using a sprinking of footnote and endnote
references as a substitute for a grammatically correct sentence.

Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C12F44.BAA3C0A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 18:13:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02419; Mon, 27 Aug 2001 18:13:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07768; Mon, 27 Aug 2001 18:08:07 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA07696 for ; Mon, 27 Aug 2001 18:08:02 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02088 for ; Mon, 27 Aug 2001 18:06:35 -0400 (EDT) Received: from MJS-W2K.cisco.com (dhcp-161-44-149-89.cisco.com [161.44.149.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA28936; Mon, 27 Aug 2001 18:07:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827175744.037dc870@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 18:08:23 -0400 To: Stuart Cheshire From: Mark Stapp Subject: Re: [dhcwg] Re: Last call for Cc: In-Reply-To: <200108272106.OAA02524@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Stuart, You misunderstood. A server that doesn't know about Ted's domain shouldn't try to prevent his client from updating it. On the contrary, the only server that should tell him *not* to update that zone would be a server configured both to update the zone, and to tell clients not to update it themselves. That's why I asked Ted the question: the only time his client should see the 'don't update' bit is the time that he *should* pay attention to it. He shouldn't see it from dhcp servers that he's visiting, servers who aren't configured to update his zone. Do both you and Ted think that the default behavior for servers should be to tell all clients not to perform updates, regardless of the domain names that the clients present? I don't agree with that. The specification is about exchanging configuration information, and the server who has no information about the administrative policy in a zone shouldn't make up a policy and tell clients about it. A server which does know a zone's policy about updates should tell clients about it, and the clients should pay attention to it. -- Mark At 02:06 PM 8/27/2001 -0700, Stuart Cheshire wrote: > >I agree with you about the purpose of the bit, but I'm a little confused by > >your last paragraph. Do you mean that even if the server was configured by > >you, and it asked your client not to update grosse.fugue.com, you'd like > >your client to update that zone anyway? > >How would Ted's DHCP client *know* that the server was configured by Ted? > >When Ted's sitting in Starbucks with his laptop and the Starbucks DHCP >server tells it not to update "grosse.fugue.com.", how can Ted's DHCP >client distinguish that case from Ted's own DHCP server telling it not to >update "grosse.fugue.com."? > >Furthermore, if Ted's laptop has the software and the credentials to >safely update "grosse.fugue.com.", why would Ted *ever* set his DHCP >server to tell his client not to? > >Surely Ted will want his laptop to *always* ignore the "don't update" >bit, because he knows that if the bit is ever set, it will be from a DHCP >server that has no authority to tell him not to update his own domain? > >Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 18:19:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02617; Mon, 27 Aug 2001 18:19:41 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08774; Mon, 27 Aug 2001 18:15:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA08746 for ; Mon, 27 Aug 2001 18:15:15 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02416 for ; Mon, 27 Aug 2001 18:13:53 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7RMFEp22122 for ; Mon, 27 Aug 2001 17:15:14 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7RMFET19233 for ; Mon, 27 Aug 2001 17:15:14 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Mon Aug 27 17:15:13 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Mon, 27 Aug 2001 17:15:13 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34A8@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Stuart Cheshire'" , Ted Lemon , DHCP discussion list Subject: RE: [dhcwg] Re: Last call for Date: Mon, 27 Aug 2001 17:15:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C12F45.BD396A30" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C12F45.BD396A30 Content-Type: text/plain; charset="iso-8859-1" I was always wondering why it was MUST NOT. Seems to me that asking for both options MIGHT be a good thing during the transition period. Especially since hand encoding the CSR option is a bit tricky so without some special server configuration support, it likely won't be widely used - or worse yet, encoded incorrectly!. Certainly hand encoding 20 or 30 routes, especially if they could change from time to time won't be fun very long and likely to be wrong. As the existing static route option likely isn't used for much, having both is not going to make packets too big. If that does happen, then I guess a site would need to use an updated server that does not send both or they'd need to stop using one. Using static routes these days is kind of questionable anyway, isn't it? So, I can't give you a technical reason for using MUST NOT and would support changing this. I would really like to see this draft get published!!!!!!! It seemed like such an easy exercise! - Bernie Volz -----Original Message----- From: Stuart Cheshire [mailto:cheshire@apple.com] Sent: Monday, August 27, 2001 4:59 PM To: Ted Lemon; DHCP discussion list Subject: [dhcwg] Re: Last call for >I find it difficult to believe that any existing, deployed network >depends on the correct operation of the existing static routes option. >Do you know of such a network, or are you speaking hypothetically? >CIDR is close to a decade old now, and I find it difficult to believe >that there exists a network where the static routes option is needed >and where it can correctly represent the routing table that one would >need to send to the client. Ted, I'm not trying to impede progress on this document. On the contrary, I want to get it published ASAP so I can include it in the next Mac OS release, but I can't if it is written in such as way as to prevent me from doing that. Apple ships millions of copies of Mac OS. If we change *anything*, there's always a non-zero number of people who will complain about it. The most common use of static routes I know is to tell a host with a global address and a default gateway that Net 10/8 is local and reachable via a different route. I can't ship an update that breaks that. >kludging this draft to support the old static routes option >side-by-side CSR *would* break new clients. Why would this break new clients? Clients can request all three options, but only use "routers" and "static routes" when there's no "classless static routes" data in the packet. The draft already suggests exactly this mechanism for the "routers" option. Why not the same mechanism for "static routes" too? >The reason for the exclusion is that these options are huge, and if >the server is asked to send both, it is likely that one of them won't >fit, or that some other important option won't be sent. You've said yourself that most sites are not even using "static routes", so why is this going to be a problem? Once CSR support is widespread in clients, sites that are currently using (or abusing) "static routes" can simply switch over to CSR instead. I expect most servers won't send both -- but the client has to ask for both because it doesn't know what the server is going to send. >I would like to get these drafts done, >and revising them as you have proposed will then require another long >review period, and may introduce mistakes that actually damage the >draft. There is no such thing as a draft that cannot be meaningfully >clarified - the question is, does it *need* to be clarified. I also don't want to delay it, but the "MUST NOT request the Static Routes option" wasn't in the first few drafts I read, and I apologize for not noticing it sooner. As it is, the draft mandates that I have to break existing functionality if I want to support CSR. I can't do that. I proposed new text to try to help this go smoothly. If the WG members agree with the proposed new text, then we have consensus. Question for the Working Group: *********************************************************** * * * Can anyone give any technical reason why it is * * necessary for *this* document to prohibit clients * * from requesting DHCP option number 6 (static routes)? * * * *********************************************************** Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C12F45.BD396A30 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Re: Last call for <draft-ietf-dhc-csr-05.txt>

I was always wondering why it was MUST NOT. Seems to me that asking for
both options MIGHT be a good thing during the transition period. Especially
since hand encoding the CSR option is a bit tricky so without some special
server configuration support, it likely won't be widely used - or worse yet,
encoded incorrectly!. Certainly hand encoding 20 or 30 routes, especially if
they could change from time to time won't be fun very long and likely to be
wrong.

As the existing static route option likely isn't used for much, having both
is not going to make packets too big. If that does happen, then I guess
a site would need to use an updated server that does not send both or they'd
need to stop using one.

Using static routes these days is kind of questionable anyway, isn't it?

So, I can't give you a technical reason for using MUST NOT and would support
changing this.

I would really like to see this draft get published!!!!!!! It seemed like such
an easy exercise!

- Bernie Volz

-----Original Message-----
From: Stuart Cheshire [mailto:cheshire@apple.com]
Sent: Monday, August 27, 2001 4:59 PM
To: Ted Lemon; DHCP discussion list
Subject: [dhcwg] Re: Last call for <draft-ietf-dhc-csr-05.txt>


>I find it difficult to believe that any existing, deployed network
>depends on the correct operation of the existing static routes option.
>Do you know of such a network, or are you speaking hypothetically?
>CIDR is close to a decade old now, and I find it difficult to believe
>that there exists a network where the static routes option is needed
>and where it can correctly represent the routing table that one would
>need to send to the client.

Ted,

I'm not trying to impede progress on this document. On the contrary, I
want to get it published ASAP so I can include it in the next Mac OS
release, but I can't if it is written in such as way as to prevent me
from doing that.

Apple ships millions of copies of Mac OS. If we change *anything*,
there's always a non-zero number of people who will complain about it.

The most common use of static routes I know is to tell a host with a
global address and a default gateway that Net 10/8 is local and reachable
via a different route.

I can't ship an update that breaks that.

>kludging this draft to support the old static routes option
>side-by-side CSR *would* break new clients.

Why would this break new clients?

Clients can request all three options, but only use "routers" and "static
routes" when there's no "classless static routes" data in the packet.

The draft already suggests exactly this mechanism for the "routers"
option. Why not the same mechanism for "static routes" too?

>The reason for the exclusion is that these options are huge, and if
>the server is asked to send both, it is likely that one of them won't
>fit, or that some other important option won't be sent.

You've said yourself that most sites are not even using "static routes",
so why is this going to be a problem?

Once CSR support is widespread in clients, sites that are currently using
(or abusing) "static routes" can simply switch over to CSR instead. I
expect most servers won't send both -- but the client has to ask for both
because it doesn't know what the server is going to send.

>I would like to get these drafts done,
>and revising them as you have proposed will then require another long
>review period, and may introduce mistakes that actually damage the
>draft.  There is no such thing as a draft that cannot be meaningfully
>clarified - the question is, does it *need* to be clarified.

I also don't want to delay it, but the "MUST NOT request the Static
Routes option" wasn't in the first few drafts I read, and I apologize for
not noticing it sooner. As it is, the draft mandates that I have to break
existing functionality if I want to support CSR. I can't do that.

I proposed new text to try to help this go smoothly. If the WG members
agree with the proposed new text, then we have consensus.

Question for the Working Group:

    ***********************************************************
    *                                                         *
    * Can anyone give any technical reason why it is          *
    * necessary for *this* document to prohibit clients       *
    * from requesting DHCP option number 6 (static routes)?   *
    *                                                         *
    ***********************************************************


Stuart Cheshire <cheshire@apple.com>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org



_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C12F45.BD396A30-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 18:30:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03101; Mon, 27 Aug 2001 18:29:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10107; Mon, 27 Aug 2001 18:27:00 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10081 for ; Mon, 27 Aug 2001 18:26:59 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02989 for ; Mon, 27 Aug 2001 18:25:37 -0400 (EDT) Received: from MJS-W2K.cisco.com (dhcp-161-44-149-89.cisco.com [161.44.149.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id SAA00704; Mon, 27 Aug 2001 18:26:25 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827181455.03837030@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 18:27:03 -0400 To: Stuart Cheshire From: Mark Stapp Subject: Re: [dhcwg] Re: Last call for Cc: In-Reply-To: <200108272105.OAA01923@scv1.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Stuart, My anecdotal needs aren't the motivation for this specification. It is a common practice in many organizations to provide matching A and PTR RRs for each active host. Manually configuring those RRs and keeping them up to date is inefficient in DHCP environments. Dns updates are a very good solution to that problem. That's a different problem in some ways from your 'roving host' situation, but it's a common problem. As you may know, Win 2k deployments for example don't work well without dns updates. In many networks, hosts don't go a-roving much, but administrators still derive a significant benefit from dns updates that are integrated into the dhcp exchange. Some form of that integration is offered by all the DHCP server vendors that I know of. A number of issues have arisen over time as DHCP and DNS updates have been deployed together, and those issues are the ones that motivated these specifications. As I've written repeatedly, what's specified isn't intended to and doesn't prevent you from configuring your host as you have. -- Mark At 02:05 PM 8/27/2001 -0700, Stuart Cheshire wrote: > >Personally, I don't particularly care whether my laptop can be 'reached' > >using a stable dns name > >Now I'm really confused about why you're writing this draft. > >What is the point of doing dynamic DNS updates, if not so that your >machine has a constant DNS name by which other hosts can refer to it? > >Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 18:33:56 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03214; Mon, 27 Aug 2001 18:33:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10532; Mon, 27 Aug 2001 18:33:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA10504 for ; Mon, 27 Aug 2001 18:33:23 -0400 (EDT) Received: from inet-vrs-03.redmond.corp.microsoft.com (mail3.microsoft.com [131.107.3.123]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03187 for ; Mon, 27 Aug 2001 18:31:58 -0400 (EDT) Received: from 157.54.9.100 by inet-vrs-03.redmond.corp.microsoft.com (InterScan E-Mail VirusWall NT); Mon, 27 Aug 2001 15:32:41 -0700 Received: from red-imc-01.redmond.corp.microsoft.com ([157.54.9.102]) by inet-imc-03.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:32:41 -0700 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.39]) by red-imc-01.redmond.corp.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:32:42 -0700 Received: from win-msg-02.wingroup.windeploy.ntdev.microsoft.com ([157.54.0.134]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(5.0.2195.2966); Mon, 27 Aug 2001 15:32:20 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: RE: [dhcwg] Re: Last call for Date: Mon, 27 Aug 2001 15:32:20 -0700 Message-ID: Thread-Topic: [dhcwg] Re: Last call for Thread-Index: AcEvQ7u1TaHbSD0uRqyCIa8dCTYH5QAA3dSA From: "Christian Huitema" To: "Stuart Cheshire" , "Mark Stapp" , "DHCP discussion list" X-OriginalArrivalTime: 27 Aug 2001 22:32:20.0737 (UTC) FILETIME=[22942710:01C12F48] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id SAA10505 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit > My host *did* have various names of the form > "host217-33-141-85.ietf.ignite.net" while I was at the meeting, which > had > both valid forward and reverse mappings. If my host is going to have > some > name which it cannot control and which no one else knows, then who > cares > whether it was dynamically updated or not? In this scenario, what is the tradeoff between: laptop.example.com IN CNAME host217-33-141-85.ietf.ignite.net and laptop.example.com IN A 217.33.141.85 ? Also, what are the consequences of the 6to4 address: laptop.example.com IN AAAA 2002:D921:8D55:0001:1234:5678:90AB:CDEF ? (This address being derived from 217.33.141.85.) -- Christian Huitema _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 19:02:50 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03757; Mon, 27 Aug 2001 19:02:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11368; Mon, 27 Aug 2001 19:00:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA11311 for ; Mon, 27 Aug 2001 19:00:55 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03652 for ; Mon, 27 Aug 2001 18:59:35 -0400 (EDT) Received: from MJS-W2K.cisco.com (dhcp-161-44-149-89.cisco.com [161.44.149.89]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA02939; Mon, 27 Aug 2001 19:00:21 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827182735.01b1f8c8@funnel.cisco.com> X-Sender: mjs@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 19:00:06 -0400 To: Stuart Cheshire From: Mark Stapp Subject: Re: [dhcwg] Re: Last call for Cc: "DHCP discussion list" In-Reply-To: <200108272107.f7RL7Kw03215@scv2.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Stuart, I have identified three technical objections in your messages. First, you object to the presence of the RCODE fields, which you do not find useful. Second, you wish there were a single domain-name encoding in the fqdn option. Third, there is some lack of clarity about what servers' default behavior should be when presented with client fqdns that are in zones outside the servers' administration. I've tried to respond to the third issue in the other email threads. As you observed in your reply to a question about the csr option, there are many millions of deployed clients with dependencies on parts of some existing options. In some cases, the presence of running implementations is worth considering when developing a new protocol feature. In my opinion, that is the case with both of your other objections. If we retain some backwards compatibility, new functionality is introduced with a minimum of disruption. The name encoding cost is born largely by the server implementations, who must be prepared for clients who only understand the deprecated ascii encoding. Everyone bears the burden of the additional two bytes per option for the RCODEs. But that seems to me to be a smaller burden than having to support both the existing option as deployed in many millions of clients, as well as the time and cost to define, approve, implement, and deploy a brand-new option that saves the two bytes. It has been some time since those issues were last addressed by the working group. I think that the compromise has been a very practical and reasonable one. I don't think it's worth the time to reopen such a fundamental issue as the value of fqdn option compatibility with every shipping MS client since win98. I'd prefer that we make the best engineering tradeoff that's available, account for the deployed clients, and add additional capabilities that can be supported by future clients. If others feel that this tradeoff is not worth making, we need to hear from them. I feel that the purpose of the wg is to identify problems, reach consensus on solutions, implement, and then refine based on operational experience. We have some operational experience integrating DHCP and DNS, and that motivates these specifications. I'm not quite certain what you're getting at when you refer to our server implementation. We update the server quite frequently, like many vendors. If you have specific issues or integration problems with the cisco server, feel free to contact me or Kim directly. -- Mark At 02:07 PM 8/27/2001 -0700, Stuart Cheshire wrote: > >the [FQDN] option has already been widely deployed > >This I think is the real issue. > >The purpose of WG discussion is to discuss protocol design, not to >rubber-stamp an existing implementation, warts and all. > >An Informational RFC is the right place to document an existing >implementation, warts and all. > >Mark, don't misunderstand this. I don't have any objection to you >shipping products. I do object to a Standards-Track RFC published >after-the-fact to give the impression that the design of the previously >mentioned shipping products was the result of IETF Working Group >Consensus. > >If you want this to be a Working Group publication, you have to be able >to update your deployed products to comply with the eventual Working >Group Consensus. If you can't update your deployed products to comply, >then this whole process is a waste of time. Just publish it as >Informational. > >Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 20:54:58 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05409; Mon, 27 Aug 2001 20:54:58 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14329; Mon, 27 Aug 2001 20:54:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14307 for ; Mon, 27 Aug 2001 20:54:06 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05384 for ; Mon, 27 Aug 2001 20:52:45 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com [165.121.48.213]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S0mGf10246; Mon, 27 Aug 2001 17:48:16 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7REZNi00390; Mon, 27 Aug 2001 10:35:23 -0400 (EDT) Message-Id: <200108271435.f7REZNi00390@grosse.bisbee.fugue.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from Ralph Droms of "Mon, 27 Aug 2001 09:11:35 EDT." <4.3.2.7.2.20010827091121.00b648b0@funnel.cisco.com> Date: Mon, 27 Aug 2001 10:35:23 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Can anyone give us the benefit of experience with the 'secs' field > in DHCPv4? There hasn't been any interest in defining a new option > with greater range or precision than the current 0-255 seconds > measured in seconds. Has the range or precision in DHCPv4 been > inadequate in any specific instance? A millisecond is a thousandth of a second. So the range with 16 bits is 65.536 seconds, not 655.36 seconds as Bernie said. I think this is too short to represent a reasonable set of cases. There may be devices, e.g. low power scientific devices that might want to probe the network from time to time, but can't afford the power cost of probing it frequently, where the desirable retry interval may be much longer than that. I do not know of any such devices that are in use right now, but it seems plausible to me that someone might want to deploy one, and I would like to account for that possibility. > Another alternative for greater range would be to define the units > of the data value to be tenths of a second. My intuition is that > tenths of a second should be sufficiently precise... I think it's good to have better granularity than that. We specify the retry timeout in milliseconds, so the retry interval should also be computed in milliseconds. This is an option that will only be present in exceptional cases, and we are discussing a difference in space consumption of 33%. I am all in favor of saving space in frequently-transmitted packets, but this is not much space, and will not be in the most frequently-transmitted packets. I may be wrong that we need this extra breathing room, but the cost is low, and I'd really appreciate it if we could stop arguing about this and just take the risk that we might be being a little bit generous in our allocation of bits. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 21:04:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05547; Mon, 27 Aug 2001 21:04:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14796; Mon, 27 Aug 2001 21:04:06 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14770 for ; Mon, 27 Aug 2001 21:04:04 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05511 for ; Mon, 27 Aug 2001 21:02:42 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-39.cisco.com [10.82.240.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA10091; Mon, 27 Aug 2001 21:03:29 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827205720.03901be0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 21:03:24 -0400 To: Ted Lemon From: Ralph Droms Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header Cc: dhcwg@ietf.org In-Reply-To: <200108271435.f7REZNi00390@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010827091121.00b648b0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Comments in line; anyone have specific examples of the use of the 'secs' field in DHCPv4? If it hasn't been used at all in DHCPv4 perhaps we don't need to define it at this point in DHCPv6. - Ralph At 10:35 AM 8/27/2001 -0400, Ted Lemon wrote: >> Can anyone give us the benefit of experience with the 'secs' field >> in DHCPv4? There hasn't been any interest in defining a new option >> with greater range or precision than the current 0-255 seconds >> measured in seconds. Has the range or precision in DHCPv4 been >> inadequate in any specific instance? > >A millisecond is a thousandth of a second. The original definition I sent out defined the value in the option field to be expressed in hundredths of a second (10^-2 seconds), giving the range of 0-655.36 seconds, >> Another alternative for greater range would be to define the units >> of the data value to be tenths of a second. My intuition is that >> tenths of a second should be sufficiently precise... > >I think it's good to have better granularity than that. We specify >the retry timeout in milliseconds, so the retry interval should also >be computed in milliseconds. Are there specific examples of when millisecond granularity is needed? >This is an option that will only be present in exceptional cases, and >we are discussing a difference in space consumption of 33%. I am all >in favor of saving space in frequently-transmitted packets, but this >is not much space, and will not be in the most frequently-transmitted >packets. > >I may be wrong that we need this extra breathing room, but the cost is >low, and I'd really appreciate it if we could stop arguing about this >and just take the risk that we might be being a little bit generous in >our allocation of bits. > > _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 21:15:28 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05711; Mon, 27 Aug 2001 21:15:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14922; Mon, 27 Aug 2001 21:12:25 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA14901 for ; Mon, 27 Aug 2001 21:12:24 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05644 for ; Mon, 27 Aug 2001 21:11:03 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com [165.121.48.213]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S16Wf10282; Mon, 27 Aug 2001 18:06:33 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7S1C6T00354; Mon, 27 Aug 2001 21:12:06 -0400 (EDT) Message-Id: <200108280112.f7S1C6T00354@grosse.bisbee.fugue.com> To: Mark Stapp cc: dhcwg@ietf.org In-Reply-To: Message from Mark Stapp of "Mon, 27 Aug 2001 12:56:07 EDT." <4.3.2.7.2.20010827124938.03034960@funnel.cisco.com> Date: Mon, 27 Aug 2001 21:12:05 -0400 From: Ted Lemon Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Do you mean that even if the server was configured by > you, and it asked your client not to update grosse.fugue.com, you'd like > your client to update that zone anyway? No, I mean that there's really no way for the client to know that this is the case, so I want my client to always update the zone, because I explicitly told it to. But I don't want the draft to recommend this - my case is weird, and so is Stuart's, at least for now. I just want the draft to not forbid this. > I guess I don't see the point of that: if the dns and dhcp share > administration This is a semantically null statement in the present context, which is why this isn't making sense. If there were some way for the DHCP server to be able to say "I am authoritative for the domain you specified, and please don't update it," then that would be fine, but that's not really possible with the present draft, and I am _not_ proposing that you fix this! :'} > If you get to ignore that bit, why don't > the win2k clients get to ignore it too, and fire updates into your zone? They just happen not to, because (I presume) that is what the spec recommends. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 21:39:47 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06990; Mon, 27 Aug 2001 21:39:47 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15658; Mon, 27 Aug 2001 21:38:08 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15628 for ; Mon, 27 Aug 2001 21:38:06 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA06961 for ; Mon, 27 Aug 2001 21:36:45 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com [165.121.48.213]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S1WFf10317; Mon, 27 Aug 2001 18:32:17 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7S1bmT00401; Mon, 27 Aug 2001 21:37:48 -0400 (EDT) Message-Id: <200108280137.f7S1bmT00401@grosse.bisbee.fugue.com> To: Stuart Cheshire cc: "DHCP discussion list" In-Reply-To: Message from Stuart Cheshire of "Mon, 27 Aug 2001 13:55:56 PDT." <200108272055.NAA08040@scv3.apple.com> Date: Mon, 27 Aug 2001 21:37:48 -0400 From: Ted Lemon Subject: [dhcwg] Re: Several reminders Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > I didn't say that you shouldn't have references. What I said was that > writing a number in little square brackets doesn't exempt the writer from > the normal rules of English grammar. Footnotes and endnotes are not the > English language equivalent of "#include". Ah, I see. So is what I did misleading or confusing, or do you just think it's bad style? If it is the latter, I don't disagree, and I will follow your recommendations in the next draft I write, but I do not want to have to change this draft now. The usage about which you are complaining was cribbed, IIRC, from a draft that is now an RFC. :'} _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 21:50:54 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07235; Mon, 27 Aug 2001 21:50:54 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15912; Mon, 27 Aug 2001 21:49:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA15890 for ; Mon, 27 Aug 2001 21:49:15 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07133 for ; Mon, 27 Aug 2001 21:47:53 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com [165.121.48.213]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S1hOf10324; Mon, 27 Aug 2001 18:43:25 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7S1mtT00420; Mon, 27 Aug 2001 21:48:55 -0400 (EDT) Message-Id: <200108280148.f7S1mtT00420@grosse.bisbee.fugue.com> To: Stuart Cheshire cc: "DHCP discussion list" In-Reply-To: Message from Stuart Cheshire of "Mon, 27 Aug 2001 13:59:13 PDT." <200108272059.f7RKxEw00418@scv2.apple.com> Date: Mon, 27 Aug 2001 21:48:55 -0400 From: Ted Lemon Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > The most common use of static routes I know is to tell a host with a > global address and a default gateway that Net 10/8 is local and reachable > via a different route. But you can't specify that with the static routes option! This is why we need the CSR option - because you can't specify a CIDR route such as the one you just mentioned using the existing static routes option. > Clients can request all three options, but only use "routers" and "static > routes" when there's no "classless static routes" data in the packet. The client probably won't *get* all three options! The server will likely leave one out due to lack of space, and there is no reason to believe that the one it will drop will be the static routes option. We could make it the server's responsibility to notice that both options are requested and exclude one, but this is fairly expensive, and servers have to handle the aggregate workload rather than the individual workload, which is why I didn't solve the problem that way. > * Can anyone give any technical reason why it is * > * necessary for *this* document to prohibit clients * > * from requesting DHCP option number 6 (static routes)? * Because both options are likely not to fit in a packet. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 21:55:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07338; Mon, 27 Aug 2001 21:55:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16089; Mon, 27 Aug 2001 21:52:51 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA16064 for ; Mon, 27 Aug 2001 21:52:50 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07277 for ; Mon, 27 Aug 2001 21:51:28 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-39.cisco.com [10.82.240.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id VAA12881 for ; Mon, 27 Aug 2001 21:52:18 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827215130.03906db0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 21:52:15 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Option 150 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Does anyone know of a well-known use of option 150? Is it coded into any known client or clients? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 22:19:08 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07603; Mon, 27 Aug 2001 22:19:08 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16785; Mon, 27 Aug 2001 22:18:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16765 for ; Mon, 27 Aug 2001 22:18:01 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07551 for ; Mon, 27 Aug 2001 22:16:39 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com [165.121.48.213]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S2C7f10390; Mon, 27 Aug 2001 19:12:11 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7S2HaT00474; Mon, 27 Aug 2001 22:17:36 -0400 (EDT) Message-Id: <200108280217.f7S2HaT00474@grosse.bisbee.fugue.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from Ralph Droms of "Mon, 27 Aug 2001 21:03:24 EDT." <4.3.2.7.2.20010827205720.03901be0@funnel.cisco.com> Date: Mon, 27 Aug 2001 22:17:36 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Are there specific examples of when millisecond granularity is needed? I have definitely found that 1s granularity is too coarse for DHCPv4, at least in the ISC DHCP server, and I have been meaning to make it more fine-grained, but have not yet done so. I think it violates the principle of least surprise to call an option milliseconds when it's not - if it's centiseconds, call it that. WRT granularity, if we are specifying millisecond granularity, people are likely to do their math in millisecond granularity, and I think it's confusing to specify a variety of different granularities. I will not respond to any further questions about this. I think I've made my reasoning clear. I can't prove that we need 32 bits. I think we do. I am not without experience in these matters, so I think that my gut feeling on this is worth something, but I can't prove it, and it's pointless for you to ask me to try. Do what you will. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 22:20:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07652; Mon, 27 Aug 2001 22:20:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16847; Mon, 27 Aug 2001 22:19:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16824 for ; Mon, 27 Aug 2001 22:19:14 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07585 for ; Mon, 27 Aug 2001 22:17:52 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com [165.121.48.213]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S2DOf10394; Mon, 27 Aug 2001 19:13:25 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7S2IsT00484; Mon, 27 Aug 2001 22:18:54 -0400 (EDT) Message-Id: <200108280218.f7S2IsT00484@grosse.bisbee.fugue.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from Ralph Droms of "Mon, 27 Aug 2001 21:03:24 EDT." <4.3.2.7.2.20010827205720.03901be0@funnel.cisco.com> Date: Mon, 27 Aug 2001 22:18:54 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Comments in line; anyone have specific examples of the use of the > 'secs' field in DHCPv4? If it hasn't been used at all in DHCPv4 > perhaps we don't need to define it at this point in DHCPv6. The ISC DHCP server uses it to bypass load balancing at a user-specified threshhold. The Microsoft DHCP relay can be configured to relay based on a user-specified threshhold. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 22:24:30 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07730; Mon, 27 Aug 2001 22:24:29 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16939; Mon, 27 Aug 2001 22:22:45 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA16910 for ; Mon, 27 Aug 2001 22:22:43 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07691 for ; Mon, 27 Aug 2001 22:21:21 -0400 (EDT) Received: from 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 TAA02242 for ; Mon, 27 Aug 2001 19:22:42 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 27 Aug 2001 19:22:41 -0700 Received: from [206.111.147.149] (vpn-gh-1077.apple.com [17.254.140.52]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id TAA04426; Mon, 27 Aug 2001 19:22:40 -0700 (PDT) Message-Id: <200108280222.TAA04426@scv3.apple.com> Date: Mon, 27 Aug 2001 19:22:40 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Ted Lemon" cc: "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >But you can't specify that with the static routes option! This is >why we need the CSR option - because you can't specify a CIDR route >such as the one you just mentioned using the existing static routes >option. 10/8 is NOT a CIDR route. Net 10 is a common private network, and 10/8 is the standard classful interpretation. >The client probably won't *get* all three options! The server will >likely leave one out due to lack of space, and there is no reason to >believe that the one it will drop will be the static routes option. I didn't say I expected the server to send all three options. I said the client has to *ask* for all three options, because it doesn't know what the server is configured for. A typical server will most often be configured to send either (a) only CSR, or (b) only Router and Static Routes. The problem is that the client doesn't know which until it asks. >> * Can anyone give any technical reason why it is * >> * necessary for *this* document to prohibit clients * >> * from requesting DHCP option number 6 (static routes)? * > >Because both options are likely not to fit in a packet. The Mac OS DHCP client sets the DHCP Maximum Message Size Option to 1500 bytes. The Static Routes option for a single Net 10/8 entry is ten bytes. The CSR option for a single Net 10/8 entry is eight bytes. I think a 1500-byte packet has space for eighteen bytes, even if the server were configured to send both, which as I said above, it probably won't. Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 22:30:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08212; Mon, 27 Aug 2001 22:30:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17097; Mon, 27 Aug 2001 22:29:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17072 for ; Mon, 27 Aug 2001 22:29:44 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07816 for ; Mon, 27 Aug 2001 22:28:20 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-39.cisco.com [10.82.240.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA14741; Mon, 27 Aug 2001 22:29:08 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827222005.038fa050@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 22:29:05 -0400 To: Ted Lemon From: Ralph Droms Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header Cc: dhcwg@ietf.org In-Reply-To: <200108280217.f7S2HaT00474@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010827205720.03901be0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Ted - I specifically titled this new option "Elapsed Time" (see the original text I sent out) to be more descriptive (rather than 'secs' or 'milliseconds') and to allow for other units in the expression of the data value. I'm not asking for proof of the requirement for milliseconds or 32 bits. We have a difference of opinion, and I'd like to find out if there's any operational experience that would give us something more than opinion to base a decision on. If nobody speaks up to say that the 'secs' field in DHCPv4 has actually been used in practice, perhaps we don't need to define an "Elapsed Time" option at all. More comments in line... - Ralph At 10:17 PM 8/27/2001 -0400, Ted Lemon wrote: >> Are there specific examples of when millisecond granularity is needed? > >I have definitely found that 1s granularity is too coarse for DHCPv4, >at least in the ISC DHCP server, and I have been meaning to make it >more fine-grained, but have not yet done so. Are you referring to the granularity of the 'secs' field? How would you make it more fine-grained if the units for the fields are defined as "seconds" in the spec? >I think it violates the principle of least surprise to call an option >milliseconds when it's not - if it's centiseconds, call it that. WRT >granularity, if we are specifying millisecond granularity, people are >likely to do their math in millisecond granularity, and I think it's >confusing to specify a variety of different granularities. > >I will not respond to any further questions about this. I think I've >made my reasoning clear. I can't prove that we need 32 bits. I think >we do. I am not without experience in these matters, so I think that >my gut feeling on this is worth something, but I can't prove it, and >it's pointless for you to ask me to try. Do what you will. > > _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 22:32:45 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08864; Mon, 27 Aug 2001 22:32:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17419; Mon, 27 Aug 2001 22:31:02 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17387 for ; Mon, 27 Aug 2001 22:31:00 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07837 for ; Mon, 27 Aug 2001 22:29:37 -0400 (EDT) Received: from rdroms-w2k.cisco.com (rtp-vpn2-39.cisco.com [10.82.240.39]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id WAA14799; Mon, 27 Aug 2001 22:30:26 -0400 (EDT) Message-Id: <4.3.2.7.2.20010827222935.039a8bb0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 27 Aug 2001 22:30:24 -0400 To: Ted Lemon From: Ralph Droms Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header Cc: dhcwg@ietf.org In-Reply-To: <200108280218.f7S2IsT00484@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010827205720.03901be0@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org My last message crossed with yours in flight; please ignore my previous request for specific examples. Thanks... - Ralph At 10:18 PM 8/27/2001 -0400, Ted Lemon wrote: >> Comments in line; anyone have specific examples of the use of the >> 'secs' field in DHCPv4? If it hasn't been used at all in DHCPv4 >> perhaps we don't need to define it at this point in DHCPv6. > >The ISC DHCP server uses it to bypass load balancing at a >user-specified threshhold. The Microsoft DHCP relay can be >configured to relay based on a user-specified threshhold. > > _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 22:55:14 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09191; Mon, 27 Aug 2001 22:55:14 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17777; Mon, 27 Aug 2001 22:51:40 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17748 for ; Mon, 27 Aug 2001 22:51:38 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09154 for ; Mon, 27 Aug 2001 22:50:18 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com [165.121.48.213]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S2jnf10440; Mon, 27 Aug 2001 19:45:49 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7S2oYT00561; Mon, 27 Aug 2001 22:50:34 -0400 (EDT) Message-Id: <200108280250.f7S2oYT00561@grosse.bisbee.fugue.com> To: Stuart Cheshire cc: "DHCP discussion list" In-Reply-To: Message from Stuart Cheshire of "Mon, 27 Aug 2001 19:22:40 PDT." <200108280222.TAA04426@scv3.apple.com> Date: Mon, 27 Aug 2001 22:50:34 -0400 From: Ted Lemon Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > 10/8 is NOT a CIDR route. Net 10 is a common private network, and 10/8 is > the standard classful interpretation. Oops, sorry - for some reason I was reading 10/8 and thinking 10/16. > A typical server will most often be configured to send either (a) only > CSR, or (b) only Router and Static Routes. If the static routes option is useful, then the server will have to be configured to send both, because a typical site will not be upgrading all of its Windows XP and previous clients at once. > The Static Routes option for a single Net 10/8 entry is ten bytes. > > The CSR option for a single Net 10/8 entry is eight bytes. If I change MUST NOT to SHOULD NOT, will this answer your objection? _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 22:56:06 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09227; Mon, 27 Aug 2001 22:56:06 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17875; Mon, 27 Aug 2001 22:55:12 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA17848 for ; Mon, 27 Aug 2001 22:55:11 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA09167 for ; Mon, 27 Aug 2001 22:53:50 -0400 (EDT) Received: from grosse.bisbee.fugue.com (user-2inic6l.dialup.mindspring.com [165.121.48.213]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7S2nLf10452; Mon, 27 Aug 2001 19:49:22 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7S2smT00572; Mon, 27 Aug 2001 22:54:48 -0400 (EDT) Message-Id: <200108280254.f7S2smT00572@grosse.bisbee.fugue.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [Dhcwg] Re: Change to 'seconds' field in DHCP message header In-Reply-To: Message from Ralph Droms of "Mon, 27 Aug 2001 22:29:05 EDT." <4.3.2.7.2.20010827222005.038fa050@funnel.cisco.com> Date: Mon, 27 Aug 2001 22:54:48 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > >I will not respond to any further questions about this. Promises, promises. :'} I'm sorry for all the mistakes in the previous couple of messages - I'm working from what I remember seeing a while back, when we had decided to call the message milliseconds and represent it in milliseconds, so I apparently didn't read your writeup very carefully. :'( > Are you referring to the granularity of the 'secs' field? How > would you make it more fine-grained if the units for the fields > are defined as "seconds" in the spec? I'm referring to timeout computations. And if timeout computations are more fine-grained, then it would make sense for the secs field to be more fine-grained as well. Otherwise the implementor has to answer the question "if the difference between the last transmission time and the current transmission time is less than one half the granularity, do I specify an interval of zero or one?" I would rather not force the implementor to make this decision, because s/he will get it wrong, probably even if it is carefully specified in the draft. I don't know many junior geeks who have taken courses in numerical methods. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Aug 27 23:52:00 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10238; Mon, 27 Aug 2001 23:51:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19236; Mon, 27 Aug 2001 23:42:21 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA19210 for ; Mon, 27 Aug 2001 23:42:19 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10058 for ; Mon, 27 Aug 2001 23:40:58 -0400 (EDT) Received: from apple.con (A17-128-100-225.apple.com [17.128.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id UAA18240 for ; Mon, 27 Aug 2001 20:40:30 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by apple.con (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 27 Aug 2001 20:38:36 +0100 Received: from [206.111.147.149] (vpn-gh-1077.apple.com [17.254.140.52]) by scv1.apple.com (8.9.3/8.9.3) with SMTP id UAA19954; Mon, 27 Aug 2001 20:40:28 -0700 (PDT) Message-Id: <200108280340.UAA19954@scv1.apple.com> Date: Mon, 27 Aug 2001 20:40:28 -0700 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "Ted Lemon" cc: "DHCP discussion list" Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org >If I change MUST NOT to SHOULD NOT, will this answer your objection? In my original mail, I proposed text using the word "MAY". I still think that's the right wording. I notice an amusing symmetry here: I write a DHCP client, and would like it to request both options, but I expect server administrators will usually configure their servers to return only one or the other, as appropriate for the particular site. Ted writes a DHCP server, and would like it to be configured with data for both options, but expects client administrators to configure their clients to only request one or the other, as appropriate for the particular site. No editorial comment here. I'm just wondering if we're both looking at the same problem from opposite sides, and each wanting the other side to be the one making the decision. (However, if we do pursue this line of reasoning, I'd argue that site-specific configuration belongs in the server, not the client.) Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 28 00:36:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10804; Tue, 28 Aug 2001 00:36:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20767; Tue, 28 Aug 2001 00:33:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA20745 for ; Tue, 28 Aug 2001 00:33:56 -0400 (EDT) Received: from shell.nominum.com (shell.nominum.com [128.177.192.160]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA10766 for ; Tue, 28 Aug 2001 00:32:33 -0400 (EDT) Received: from drc-toshiba.nominum.com (shell.nominum.com [128.177.192.160]) by shell.nominum.com (Postfix) with ESMTP id 82A7E31914; Mon, 27 Aug 2001 21:33:22 -0700 (PDT) Message-Id: <5.0.2.1.2.20010827192520.028b9dd8@localhost> X-Sender: drc@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Mon, 27 Aug 2001 21:33:21 -0700 To: Stuart Cheshire , "Ted Lemon" From: "David R. Conrad" Subject: Re: [dhcwg] Re: Last call for Cc: "DHCP discussion list" In-Reply-To: <200108280222.TAA04426@scv3.apple.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Stuart, Not particularly DHCP related, but: At 07:22 PM 8/27/2001 -0700, Stuart Cheshire wrote: >10/8 is NOT a CIDR route. / is the standard representation of classless routing prefixes. Classful would simply be 10.0.0.0 since there is an implicit assumption of a netmask of 255.0.0.0. As such, 10/8 would indeed be considered CIDR. >Net 10 is a common private network, and 10/8 is >the standard classful interpretation. No. Classful interpretation does not specify the prefix length as it is implied by the first two bits of the address. Classless require the specification of the prefix length. Rgds, -drc _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 28 02:26:42 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28067; Tue, 28 Aug 2001 02:26:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA02012; Tue, 28 Aug 2001 02:21:11 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA01984 for ; Tue, 28 Aug 2001 02:21:09 -0400 (EDT) Received: from internaut.com ([64.38.134.99]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28020 for ; Tue, 28 Aug 2001 02:19:17 -0400 (EDT) Received: from localhost (aboba@localhost) by internaut.com (8.9.3/8.9.3) with ESMTP id XAA31268; Mon, 27 Aug 2001 23:12:47 -0700 (PDT) (envelope-from aboba@internaut.com) Date: Mon, 27 Aug 2001 23:12:47 -0700 (PDT) From: Bernard Aboba To: dhcwg@ietf.org cc: Stuart Cheshire In-Reply-To: <5.0.2.1.2.20010827192520.028b9dd8@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] draft-aboba-dhc-domsearch-06.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I have updated draft-aboba-dhc-domsearch-05.txt as per Stuart Cheshire's suggestions and submitted it to the Internet Drafts directory as draft-aboba-dhc-domsearch-06.txt. If there are any further comments, please post them ASAP. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 28 12:01:10 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13914; Tue, 28 Aug 2001 12:01:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16683; Tue, 28 Aug 2001 11:59:42 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA16663 for ; Tue, 28 Aug 2001 11:59:41 -0400 (EDT) Received: from mailserver.sylantro.com ([65.200.90.207]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13721 for ; Tue, 28 Aug 2001 11:58:21 -0400 (EDT) Received: from 172.16.128.12 by mailserver.sylantro.com with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v4.7)); Tue, 28 Aug 2001 08:56:19 -0700 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2653.19) id ; Tue, 28 Aug 2001 08:56:19 -0700 Message-ID: <79FEAA5FABA7D411BF580001023D1BBDB5A7E1@mailserver.sylantro.com> From: "Joe Aiello" To: "Ralph Droms" , dhcwg@ietf.org Subject: RE: [dhcwg] Option 150 Date: Tue, 28 Aug 2001 08:56:18 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-WSS-ID: 179560A963353-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Yes. Cisco IP phones use Options 150 and 151. -- Joe -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Monday, August 27, 2001 6:52 PM To: dhcwg@ietf.org Subject: [dhcwg] Option 150 Does anyone know of a well-known use of option 150? Is it coded into any known client or clients? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 28 16:12:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20288; Tue, 28 Aug 2001 16:12:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24991; Tue, 28 Aug 2001 16:11:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24716 for ; Tue, 28 Aug 2001 16:06:08 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20128 for ; Tue, 28 Aug 2001 16:04:47 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA10685 for ; Tue, 28 Aug 2001 16:05:36 -0400 (EDT) Message-Id: <4.3.2.7.2.20010828160414.00b6c220@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 28 Aug 2001 16:05:34 -0400 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org I've completed the changes to remove the client-link-local-address field from the DHCP message header. Relay agents and servers will now use the source address from the IP header to reply to client messages. The changes include: * Message format and descriptions in section 8 to remove the client-link-local-address field * Relay agent message format and descriptions in section 9 to accommodate the client-return-address field * Address selection described in section 12 to allow for unicast client messages * The description of client behavior in sections 13 and 14 to remove the use of the client-link-local-address field and to specify that the client must send the message through the interface to be configure, to correctly set the source address in the IP header * The description of server behavior in sections 13 and 14 to remove the use of the client-link-local-address and change the format of the relay agent messages * The description of relay behavior in section 15 based on the new relay agent message format Note that the relay agent message has to include information about: 1. The return address to which the server should send the Relay-reply message 2. A link identifier/subnet selector that the server uses to select configuration information for the client 3. An interface identifier and return address for the client that the relay agent uses to forward the message from the server back to the client In DHCPv4, all of these functions are supplied by 'giaddr'. However, the source address from the IP header isn't sufficient (which we had discussed using for DHCPv6), because it may be awkward or impossible (and, usually suboptimal) to force the message from the relay agent to be sent to the server through the interface on which the message from the client was received. So, I've retained the relay-address field and added a client-return-address field in the Relay-forward for 2. and 3., and specified that the server use the source address from the IP header for 1. The text affected by these changes is included below. Please review and follow up with comments. - Ralph ===== 8. Message Formats Each DHCP message has an identical fixed format header; some messages also allow a variable format area for options. Not all fields in the header are used in every message. In this section, every field is described for every message and fields that are not used in a message are marked as "unused". All unused fields in a message MUST be transmitted as zeroes and ignored by the receiver of the message. The DHCP message header: 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 | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.1. DHCP Solicit Message Format msg-type SOLICIT transaction-ID An unsigned integer generated by the client used to identify this Solicit message. server-address (unused) MUST be 0 options See section 18. 8.2. DHCP Advertise Message Format msg-type ADVERTISE transaction-ID An unsigned integer used to identify this Advertise message. Copied from the client's Solicit message. server-address The IP address of the server that generated this message. If the DHCP domain crosses site boundaries, then this address MUST be globally-scoped. options See section 18. 8.3. DHCP Request Message Format msg-type REQUEST transaction-ID An unsigned integer generated by the client used to identify this Request message. server-address The IP address of the server to which the this message is directed, copied from an Advertise message. options See section 18. 8.4. DHCP Confirm Message Format msg-type CONFIRM transaction-ID An unsigned integer generated by the client used to identify this Confirm message. server-address MUST be zero. options See section 18. 8.5. DHCP Renew Message Format msg-type RENEW transaction-ID An unsigned integer generated by the client used to identify this Renew message. server-address The IP address of the server to which this Renew message is directed, which MUST be the address of the server from which the IAs in this message were originally assigned. options See section 18. 8.6. DHCP Rebind Message Format msg-type REBIND transaction-ID An unsigned integer generated by the client used to identify this Rebind message. server-address MUST be zero. options See section 18. 8.7. DHCP Reply Message Format msg-type REPLY transaction-ID An unsigned integer used to identify this Reply message. Copied from the client's Request, Confirm, Renew or Rebind message. server-address The IP address of the server. If the DHCP domain crosses site boundaries, then this address MUST be globally-scoped. options See section 18. 8.8. DHCP Release Message Format msg-type RELEASE transaction-ID An unsigned integer generated by the client used to identify this Release message. server-address The IP address of the server that assigned the IA. options See section 18. 8.9. DHCP Decline Message Format msg-type DECLINE transaction-ID An unsigned integer generated by the client used to identify this Decline message. server-address The IP address of the server that assigned the addresses. options See section 18. 8.10. DHCP Reconfigure-init Message Format msg-type RECONFIG-INIT transaction-ID (unused) MUST be 0 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. options See section 18. 9. Relay messages Relay agents exchange messages with servers to forward messages between clients and servers that are not connected to the same link. 9.1. Relay-forward 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 | | +-+-+-+-+-+-+-+-+ | | | | relay-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | | | | client-return-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-FORW prefix-length The length of the prefix in the address in the "relay-address" field. relay-address An address assigned to the interface on which the message from the client was received. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Client message option"; see section 18.7. 9.2. Relay-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 | | +-+-+-+-+-+-+-+-+ | | | | relay-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | | | | client-return-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-REPL prefix-length The length of the prefix in the address in the "relay-address" field. relay-address An address identifying the interface on the relay agent through which the message from the server should be forwarded; copied from the "relay-forward" message. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Server message option"; see section 18.8. 12. Selecting addresses for assignment to an IA A server selects addresses to be assigned to an IA according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from the following sources: - The link to which the client is attached: * If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is a link-local address, then the client is on the same link to which the interface over which the message was received is attached * If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is not link-local address, then the client is on the link identified by the source address in the IP datagram * If the server receives the message from a forwarding relay agent, then the client is on the same link as the one to which the interface identified by the relay-address field in the message from the relay is attached - The DUID supplied by the client - Other information in options supplied by the client - Other information in options supplied by the relay agent 13. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. 13.1. Solicit Message Validation Clients MUST silently discard any received Solicit messages. 13.2. Advertise Message Validation Servers MUST discard any received Advertise messages. Clients MUST discard any received Advertise messages in which the "Transaction-ID" field value does not match the value the client used in its Solicit message. 13.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. 13.3.1. Creation and sending of the Solicit message The client sets the "msg-type" field to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. The client sends the Solicit message to the 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. 13.4. Server Behavior A server sends an Advertise message in response to Solicit messages it receives to announce the availability of the server to the client. 13.4.1. Receipt of Solicit messages The server determines the information about the client and its location as described in section 12. If administrative policy permits the server to respond to the client, the server will generate and send an Advertise message to the client. 13.4.2. Creation and sending of Advertise messages The server sets the "msg-type" field to ADVERTISE and copies the values of the transaction-ID field from the client's Solicit to the Advertise message. The server places one of its IP addresses (determined through administrator setting) in the "server-address" field of the Advertise message. The server MAY add a Preference option to carry the preference value for the Advertise message. The server implementation SHOULD allow the setting of a server preference value by the administrator. The server preference value MUST default to zero unless otherwise configured by the server administrator. The server MUST include options to the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MAY choose to send an Advertise message to the client that includes no IA options. The server MAY include other options the server will return to the client in a subsequent Reply message. The information in these options will be used by the client in the selection of a server if the client receives more than one Advertise message. The server SHOULD include options specifying values for options requested by the client in an Option Request Option included in the Solicit message. If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the address in the source address field from the IP datagram in which the Solicit message was received. The Advertise message MUST be unicast through the interface on which the Solicit message was received. If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "server-message" option. The server unicasts the Relay-reply message directly to the relay agent using the address in the source address field from the IP datagram in which the Relay-forward message was received. 14. DHCP Client-Initiated Configuration Exchange A client initiates a message exchange with a server or servers to acquire or update configuration information of interest. The client may initiate the configuration exchange as part of the operating system configuration process or when requested to do so by the application layer. The client uses the following messages to initiate a configuration event: Request Obtain initial configuration information (from a server identified in a previously received Advertise message) when the client has no assigned addresses Confirm Confirm the validity of assigned addresses and other configuration changes through the server from which the configuration information was obtained when the client's assigned addresses may not be valid; for example, when the client reboots or loses its connection to a link Renew Extend the lease on an IA through the server that originally assigned the IA Rebind Extend the lease on an IA through any server willing to extend the lease Release Release the lease on an IA and release all of the addresses contained in the IA, Decline Decline the assignment of one or more addresses in an IA. A client uses the Release/Reply message exchange to indicate to the DHCP server that the client will no longer be using the addresses in the released IA. A client uses the Decline/Reply message exchange to indicate to the DHCP server that the client has detected that one or more addresses assigned by the server is already in use on the client's link. 14.1. Client Message Validation Clients MUST silently discard any received client messages (Request, Confirm, Renew, Rebind, Release or Decline messages). Servers MUST discard any received client messages in which the "options" field contains an authentication option, and the server cannot successfully authenticate the client. Servers MUST discard any received Request, Renew, Release or Decline message in which the "server-address" field value does not match any of the server's addresses. 14.2. Server Message Validation Servers MUST silently discard any received server messages (Advertise, Reply or Reconfigure-init messages). Clients MUST discard any server messages that meet any of the following criteria: o The "transaction-ID" field value in the server message does not match the value the client used in its Request or Release message. o The server message contains an authentication option, and the client's attempt to authenticate the message fails. Relays MUST discard any Relay-reply message in which the "client-link-local-address" field in the Relay-reply message does not contain a valid link-local address. 14.3. Client Behavior A client will use Request, Confirm, Renew and Rebind messages to acquire and confirm the validity of 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 address information from previous Advertise message(s) for use in constructing Request and Renew 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 IAs when the client has been instructed to release the IA prior to the IA expiration time since it is no longer needed. A client uses the Decline message when the client has determined through DAD or some other method that one or more of the addresses assigned by the server in the IA is already in use by a different client. 14.3.1. Creation and sending of Request messages If a client has no valid IPv6 addresses of sufficient scope to communicate with a DHCP server, it may send a Request message to obtain new addresses. The client includes one or more IAs in the Request message, to which the server assigns new addresses. The server then returns IA(s) to the client in a Reply message. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any other appropriate options, including one or more IA options (if the client is requesting that the server assign it some network addresses). The list of addresses in each included IA MUST be empty. If the client is not requesting that the server assign it any addresses, the client omits the IA option. The client sends the Request message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. The server will respond to the Request message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 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 7.5. 14.3.2. Creation and sending of Confirm messages Whenever a client may have moved to a new link, its IPv6 addresses may no longer be valid. Examples of times when a client may have moved to a new link include: o The client reboots o The client is physically disconnected from a wired connection o The client returns from sleep mode o The client using a wireless technology changes cells In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. The client includes any IAs, along with the addresses associated with those IAs, in its Confirm message. Any responding servers will indicate the acceptability of the addresses with the status in the IA it returns to the client. The client sets the "msg-type" field to CONFIRM. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server confirm the validity of some network addresses). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Confirm message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. Servers will respond to the Confirm message with a Reply message. If no Confirm message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Confirm 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 QRY_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 QRY_MSG_ATTEMPTS are documented in section 7.5. If the client receives no response to its Confirm message, it MAY restart the configuration process by locating a DHCP server with an Advertise message and sending a Request to that server, as described in section 14.3.1. 14.3.3. Creation and sending of Renew messages IPv6 addresses assigned to a client through an IA use the same preferred and valid lifetimes as IPv6 addresses obtained through stateless autoconfiguration. The server assigns preferred and valid lifetimes to the IPv6 addresses it assigns to an IA. To extend those lifetimes, the client sends a Request to the server containing an "IA option" for the IA and its associated addresses. The server determines new lifetimes for the addresses in the IA according to the server's administrative configuration. The server may also add new addresses to the IA. The server remove addresses from the IA by setting the preferred and valid lifetimes of those addresses to zero. The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA. If the server does not assign an explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the shortest preferred lifetime of any address assigned to the IA and T2 defaults to 0.875 times the shortest preferred lifetime of any address assigned to the IA. At time T1 for an IA, the client initiates a Request/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Request message. The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Renew message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. The server will respond to the Renew message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Renew 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 until time T2 is reached (see section 14.3.4). Default and initial values for REP_MSG_TIMEOUT are documented in section 7.5. 14.3.4. Creation and sending of Rebind messages At time T2 for an IA (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange. The client includes an IA option with all addresses currently assigned to the IA in its Rebind message. The client sends this message to the All DHCP Agents multicast address. The client sets the "msg-type" field to REBIND. The client generates a transaction ID inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options. If the client does include any IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions), it MUST include the list of addresses the client currently has associated with that IA. The client sends the Rebind message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. The server will respond to the Rebind message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Rebind 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. Default and initial values for REP_MSG_TIMEOUT are documented in section 7.5. The client has several alternatives to choose from if it receives no response to its Rebind message. - When the lease on the IA expires, the client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server - Some addresses in the IA may have lifetimes that extend beyond the lease of the IA, so the client may choose to continue to use those addresses; once all of the addresses have expired, the client may choose to locate a new DHCP server - The client may have other addresses in other IAs, so the client may choose to discard the expired IA and use the addresses in the other IAs 14.3.5 (omitted) 14.3.6. Creation and sending of Release messages The client sets the "msg-type" field to RELEASE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is releasing in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for the release. If the client is configured to use authentication, the client generates the appropriate authentication option, and adds this option to the "options" field. Note that the authentication option MUST be the last option in the "options" field. See section 18.11 for more details about the authentication option. The client sends the Release message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. 14.3.7. (Omitted) 14.3.8. (Omitted) 14.3.9. Creation and sending of Decline messages The client sets the "msg-type" field to DECLINE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is declining in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for declining the address. If the client is configured to use authentication, the client generates the appropriate authentication option, and adds this option to the "options" field. Note that the authentication option MUST be the last option in the "options" field. See section 18.11 for more details about the authentication option. The client sends the Decline message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. 14.3.10. (Omitted) If no Reply message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Decline, 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 attempt to decline the address. 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 7.5. 14.3.11. Receipt of Reply message in response to a Release message 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. 14.4. Server Behavior For this discussion, the Server is assumed to have been configured in an implementation specific manner with configuration of interest to clients. 14.4.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 options field. The server then constructs a Reply message and sends it to the client. The server SHOULD process each option for the client in an implementation-specific manner. The server MUST construct a Reply message containing the following values: msg-type REPLY transaction-ID The transaction-ID from the Request message. server address One of the IP addresses assigned to the interface through which the server received the message from the client. When the server receives a Request and IA option is included the client is requesting the configuration of a new IA by the server. The server MUST take the clients IA and associate a binding for that client in an implementation-specific manner within the server's configuration parameter database for DHCP clients. If the server cannot provide addresses to the client it SHOULD send back an empty IA to the client with the status field set to Unavail. If the server can provide addresses to the client it MUST send back the IA to the client with all fields entered and a status of Success, and add the IA as a new client binding. The server adds options to the Reply message for any other configuration information to be assigned to the client. 14.4.2. Receipt of Confirm messages Upon the receipt of a valid Confirm message from a client the server can respond to, (implementation-specific administrative policy satisfied) the server scans the options field. The server then constructs a Reply message and sends it to the client. The server SHOULD process each option for the client in an implementation-specific manner. The server MUST construct a Reply message containing the following values: msg-type REPLY transaction-ID The transaction-ID from the Confirm message. server address One of the IP addresses assigned to the interface through which the server received the message from the client. When the server receives a Confirm and an IA option is included the client is requesting confirmation that the addresses in the IA are valid. The server SHOULD locate the clients binding and verify the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for this IA the server SHOULD return an empty IA with status set to NoBinding. If the server finds that the information for the client does not match what is in the server's records for that client the server should send back an empty IA with status set to Conf_NoMatch. If the server finds a match to the Confirm then the server should send back the IA to the client with status set to success. 14.4.3. Receipt of Renew messages Upon the receipt of a valid Renew message from a client the server can respond to, (implementation-specific administrative policy satisfied) the server scans the options field. The server then constructs a Reply message and sends it to the client. The server SHOULD process each option for the client in an implementation-specific manner. The server MUST construct a Reply message containing the following values: msg-type REPLY transaction-ID The transaction-ID from the Confirm message. server address One of the IP addresses assigned to the interface through which the server received the message from the client. When the server receives a Renew and IA option from a client it SHOULD locate the clients binding and verify the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for this IA the server SHOULD return an empty IA with status set to NoBinding. If the server finds that the addresses in the IA for the client do not match the clients binding the server should return an empty IA with status set to Renw_NoMatch. If the server cannot Renew addresses for the client it SHOULD send back an empty IA to the client with the status field set to Unavail. If the server finds the addresses in the IA for the client then the server SHOULD send back the IA to the client with new lease times and T1/T2 times if the default is not being used, and set status to Success. 14.4.4. Receipt of Rebind messages Upon the receipt of a valid Rebind message from a client the server can respond to, (implementation-specific administrative policy satisfied) the server scans the options field. The server then constructs a Reply message and sends it to the client. The server SHOULD process each option for the client in an implementation-specific manner. The server MUST construct a Reply message containing the following values: msg-type REPLY transaction-ID The transaction-ID from the Confirm message. server address One of the IP addresses assigned to the interface through which the server received the message from the client. When the server receives a Rebind and IA option from a client it SHOULD locate the clients binding and verify the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for this IA the server SHOULD return an empty IA with status set to NoBinding. If the server finds that the addresses in the IA for the client do not match the clients binding the server should return an empty IA with status set to Rebd_NoMatch. If the server cannot Rebind addresses for the client it SHOULD send back an empty IA to the client with the status field set to Unavail. If the server finds the addresses in the IA for the client then the server SHOULD send back the IA to the client with new lease times and T1/T2 times if the default is not being used, and set status to Success. There is a significant difference between Renew and Rebind messages: Because the Rebind message is processed by a single server, the responding server can actually change the addresses in the IA. However, because multiple servers may respond to a Rebind, all they can safely do is update T1, T2 (for the IA) and lifetimes (for individual addresses). 14.4.5. Receipt of Release messages Upon the receipt of a valid Release message, the server examines the IAs and the addresses in the IAs for validity. If the IAs in the message are in a binding for the client and the addresses in the IAs have been assigned by the server to those IA, the server deletes the addresses from the IAs and makes the addresses available for assignment to other clients. The server then generates a Reply message. If all of the IAs were valid and the addresses successfully released,, the server sets the "status" field to "Success". If any of the IAs were invalid or if any of the addresses were not successfully released, the server releases none of the addresses in the message and sets the "status" field to "NoBinding"(section 7.4). If the client successfully releases some but not all of the addresses in an IA, the IA continues to exist and holds the remaining, unreleased addresses. A client can send an option containing an IA with no listed addresses to release implicitly all of the addresses in the IA. A server is not required to (but may choose to as an implementation strategy) retain any record of an IA from which all of the addresses have been released. 14.4.6. Sending of Reply messages If the Request, Confirm, Renew, Rebind or Release message from the client was originally received was originally received in a Relay-forward message from a relay, the server places the Reply message in the options field of a Relay-response message and copies the relay-address and client-link-local-address fields from the Relay-forward message into the Relay-response message. The server then unicasts the Reply or Relay-reply to the source address from the IP datagram in which the original message was received. 16. Relay Behavior For this discussion, the Relay may be configured to use a list of server destination addresses, which may include unicast addresses, the All DHCP Servers multicast address, or other multicast addresses selected by the network administrator. If the Relay has not been explicitly configured, it MUST use the All DHCP Servers multicast address as the default. 16.1. Relaying of client messages When a Relay receives a valid client message, it constructs a Relay-forward message. The relay places an address from the interface on which the client message was received in the "relay-address" field. This address will be used by the server to identify the link to which the client is connected and will be used by the relay to forward the Advertise message from the server back to the client. The relay copies the source address from the IP datagram in which the message was received from the client into the client-link-local-address field in the Relay-forward message. The relay constructs a "client-message" option 18.7 that contains the entire message from the client in the data field of the option. The relay places the "relay-message" option along with any "relay-specific" options in the options field of the Relay-forward message. The Relay then sends the Relay-forward message to the list of server destination addresses that it has been configured with. 16.2. Relaying of server messages When the relay receives a Relay-reply message, it extracts the server message from the "server-message" option and forwards the message to the address in the client-link-local-address field in the Relay-reply message. The relay forwards the server message through the interface identified in the "relay-address" field in the Relay-reply message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Aug 28 20:04:23 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA24243; Tue, 28 Aug 2001 20:04:23 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03592; Tue, 28 Aug 2001 20:00:48 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA03568 for ; Tue, 28 Aug 2001 20:00:46 -0400 (EDT) Received: from e33.bld.us.ibm.com (e33.co.us.ibm.com [32.97.110.131]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA24191 for ; Tue, 28 Aug 2001 19:59:22 -0400 (EDT) Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e33.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id SAA29968 for ; Tue, 28 Aug 2001 18:58:30 -0500 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7SNxQH132218 for ; Tue, 28 Aug 2001 17:59:26 -0600 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.99.140.23]) by e34.bld.us.ibm.com (8.9.3/8.9.3) with ESMTP id TAA20584 for ; Tue, 28 Aug 2001 19:27:44 -0400 Received: from d03nm042.boulder.ibm.com (d03nm042.boulder.ibm.com [9.99.140.42]) by westrelay02.boulder.ibm.com (8.11.1m3/NCO v4.97.1) with ESMTP id f7SNSdH95314 for ; Tue, 28 Aug 2001 17:28:39 -0600 X-Mailer: Lotus Notes Release 5.0.7 March 21, 2001 MIME-Version: 1.0 To: Message-ID: From: "Prasenjit Sarkar" Date: Tue, 28 Aug 2001 16:59:25 -0700 X-MIMETrack: Serialize by Router on D03NM042/03/M/IBM(Release 5.0.8 |June 18, 2001) at 08/28/2001 04:59:25 PM Content-type: text/plain; charset=us-ascii Subject: [dhcwg] (dhcpwg) RootPath option for iSCSI boot Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Hi, I am primarily a member of the ip storage working group working on iscsi boot. The goal is for an iscsi boot client to locate the iscsi boot server using dhcp. For that purpose, we propose to reuse the rootpath option [recognizing that root is different from boot]. To that end, I have submitted a private draft "draft-sarkar-dhc-iscsi-boot-00.txt". Comments welcome, Prasenjit Prasenjit Sarkar Research Staff Member IBM Almaden Research San Jose _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 05:42:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18883; Wed, 29 Aug 2001 05:42:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26877; Wed, 29 Aug 2001 05:41:24 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA26852 for ; Wed, 29 Aug 2001 05:41:22 -0400 (EDT) Received: from mail.span.ch (mail.span.ch [144.85.10.50]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA18830; Wed, 29 Aug 2001 05:39:59 -0400 (EDT) Received: from is-production.com (unknown [144.85.4.122]) by mail.span.ch (Postfix) with ESMTP id 18E42388C5; Wed, 29 Aug 2001 11:41:05 +0200 (MEST) Message-ID: <3B8CB6A1.FA7237D7@is-production.com> Date: Wed, 29 Aug 2001 11:32:17 +0200 From: Bernard Dugas Organization: Originale X-Mailer: Mozilla 4.75 [fr] (WinNT; U) X-Accept-Language: fr,en MIME-Version: 1.0 To: ietf-web@ietf.org, Ralph Droms , michael.patrick@motorola.com, dhcwg@ietf.org References: <3B8659B5.59E7AD2@is-production.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [dhcwg] Re: DHCP behind NAT Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 8bit Hello, I've had no comment on that. Is it the right procedure ? The patch is loadable at http://www.is-pronet.com/download/, with the original version and the patched version of ISC dhcpd we were using. Best regards, and thanks for help of mailing lists and open source process ! Bernard Dugas a écrit : > > Hi, > > I have a comment to do on both RFC : > - Dynamic Host Configuration Protocol (RFC 2131); > - DHCP Relay Agent Information Option (RFC 3046). > > I couldn't find in these RFC's any mention of the possibility of a DHCP > client being on a subnet behind some NAT device like a router. > > NAT is used quite often, specially in the kind of network represented in > RFC3046 Figure 1 page 3, with network clients behind modems. > > Even more, it seems that the behaviour described by RFC2131 > is preventing a dhcp server to answer to a client behind a NAT. > > 3 problems have been identified : > - PB1) In the case of a unicast DISCOVER, with a relay involved, the > DHCP > server is answering to the ip address of the relay (giaddr field). In a > non-NAT context, the giaddr is the same that the source ip address of > the DISCOVER packet. But with NAT, the DHCP server MUST answer to the IP > source address of the DISCOVER packet. This problem may happen also in > other requests. > > cf. " 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'. " > in : > " Droms Standards Track [Page > 23] > RFC 2131 Dynamic Host Configuration Protocol March 1997 > " > > - PB2) The same apply for to UDP port of the OFFER packet : it should be > the udp port of the IP source address of the DISCOVER packet, because > NAT may have changed the port too ; > > - PB3) The DHCP server is issuing a ICMP echo on client address before > answering with the OFFER. In a NAT context, the echo can't go on the > client subnet. The RELAY should do the ping before relaying the OFFER. > > To illustrate the PB1, I can send you a patch on ISC dhcp 3.0.RC11, > which allow our DHCP server to answer to clients behind NAT. > > I would be very grateful to have an answer on these problems. Thanks a > lot. -- __________ Bernard DUGAS ________________________________________ | | | Technoparc Pays de Gex mailto:bernard.dugas@is-production.com | | 30 Rue Auguste Piccard Tel.: +33 450 205 105 | | FR 01630 St Genis Pouilly Fax : +33 450 205 106 | |_________________________________________________________________| _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 10:58:09 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00057; Wed, 29 Aug 2001 10:58:09 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04986; Wed, 29 Aug 2001 10:55:59 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04892 for ; Wed, 29 Aug 2001 10:53:47 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29867 for ; Wed, 29 Aug 2001 10:52:26 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7TErkq32211; Wed, 29 Aug 2001 10:53:46 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-196.cisco.com [161.44.149.196]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA22209; Wed, 29 Aug 2001 10:53:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20010829103638.00b6e7f0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Aug 2001 10:47:19 -0400 To: dhcp-v4@bucknell.edu, dhcp-v6@bucknell.edu From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Termination of dhcp-v4 and dhcp-v6 mailing lists Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The dhcp-v4@bucknell.edu and dhcp-v6@bucknell.edu mailing lists have been terminated. The folks at Bucknell have graciously agreed to leave an alias in place that will forward e-mail addressed to the old lists to the new DHC WG mailing list, dhcwg@ietf.org. This message is an announcement of the change and a test of the new aliases. Thanks to the staff at Bucknell for hosting the DHC WG mailing lists over the past several years and for making this transition so painless... - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 11:50:15 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01737; Wed, 29 Aug 2001 11:50:15 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06841; Wed, 29 Aug 2001 11:49:26 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA06816 for ; Wed, 29 Aug 2001 11:49:25 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01688 for ; Wed, 29 Aug 2001 11:48:03 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7TFhXf13493; Wed, 29 Aug 2001 08:43:33 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7TFn6F00436; Wed, 29 Aug 2001 11:49:06 -0400 (EDT) Message-Id: <200108291549.f7TFn6F00436@grosse.bisbee.fugue.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header In-Reply-To: Message from Ralph Droms of "Tue, 28 Aug 2001 16:05:34 EDT." <4.3.2.7.2.20010828160414.00b6c220@funnel.cisco.com> Date: Wed, 29 Aug 2001 11:49:05 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org How about making relay-address an option? I don't think it will be useful in most cases, so it seems like a drag to have it part of the fixed header. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 12:27:31 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02549; Wed, 29 Aug 2001 12:27:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08309; Wed, 29 Aug 2001 12:21:43 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08280 for ; Wed, 29 Aug 2001 12:21:41 -0400 (EDT) Received: from imr2.ericy.com (imr2.ericy.com [12.34.240.68]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02393 for ; Wed, 29 Aug 2001 12:20:20 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.92.15]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id f7TGLA507637 for ; Wed, 29 Aug 2001 11:21:10 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7TGLAF05164 for ; Wed, 29 Aug 2001 11:21:10 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Wed Aug 29 11:20:15 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 11:20:15 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34BE@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Date: Wed, 29 Aug 2001 11:20:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C130A6.7B3F60A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C130A6.7B3F60A0 Content-Type: text/plain; charset="iso-8859-1" I am working through this document, but I had the same thought as I was reviewing it. If the relay-address and source IP address of the relay are the same, there is no reason to have both. Most relays should be able to do this, so it will hopefully be the exception to the rule that this information is needed. This will require changes to section 12 and likely other places. Also, while I'm at it, 9.1 and 9.2 still have the "prefix-length" field defined by this field no longer exists within the Relay-Forw and Relay-Repl messages. In 13.4.2, it says "and copies the values of the transaction-ID field ...". All that is now copied is the transaction-id so just say "value". Perhaps best to just say "copies the transaction-id field". In 13.4.2, as "The server MAY include other options", do these other options include IA IDs (and related suboptions that are still being worked out) that the server might know about for the client? In other words, might we allow a server to send back all of the IA IDs (and addresses) it knows about a client in the Solicit. (Perhaps best to wait to answer this based on what Mark, Ted, and I work out!) I haven't finished the rest of the document so I may have more comments later. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Wednesday, August 29, 2001 11:49 AM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header How about making relay-address an option? I don't think it will be useful in most cases, so it seems like a drag to have it part of the fixed header. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C130A6.7B3F60A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Changes to remove = "client-link-local-address" from the DHCPv6 header

I am working through this document, but I had the = same thought as I was reviewing it.

If the relay-address and source IP address of the = relay are the same, there is no reason
to have both. Most relays should be able to do this, = so it will hopefully be the exception
to the rule that this information is needed. This = will require changes to section 12 and
likely other places.

Also, while I'm at it, 9.1 and 9.2 still have the = "prefix-length" field defined by this
field no longer exists within the Relay-Forw and = Relay-Repl messages.

In 13.4.2, it says "and copies the values of the = transaction-ID field ...". All that is
now copied is the transaction-id so just say = "value". Perhaps best to just say "copies
the transaction-id field".

In 13.4.2, as "The server MAY include other = options", do these other options include
IA IDs (and related suboptions that are still being = worked out) that the server might
know about for the client? In other words, might we = allow a server to send back all
of the IA IDs (and addresses) it knows about a = client in the Solicit. (Perhaps best to
wait to answer this based on what Mark, Ted, and I = work out!)

I haven't finished the rest of the document so I may = have more comments later.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Wednesday, August 29, 2001 11:49 AM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Changes to remove = "client-link-local-address" from
the DHCPv6 header



How about making relay-address an option?   = I don't think it will be
useful in most cases, so it seems like a drag to = have it part of the
fixed header.

        =         =                _MelloN_

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg=

------_=_NextPart_001_01C130A6.7B3F60A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 13:23:51 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03755; Wed, 29 Aug 2001 13:23:51 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09813; Wed, 29 Aug 2001 13:23:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA09787 for ; Wed, 29 Aug 2001 13:23:17 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA03686 for ; Wed, 29 Aug 2001 13:21:57 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-196.cisco.com [161.44.149.196]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id NAA10911 for ; Wed, 29 Aug 2001 13:22:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20010829131820.00b6c520@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Aug 2001 13:22:40 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header In-Reply-To: <200108291549.f7TFn6F00436@grosse.bisbee.fugue.com> References: <4.3.2.7.2.20010828160414.00b6c220@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Before I make the change, let me make sure I understand your proposal. If the relay agent does not include the relay-address, the relay agent has to cause the forwarded message to have a source address - an address with the widest scope possible; e.g., a link-local address isn't useful - that is assigned to the interface on which the message was received by the agent from the client. - Ralph At 11:49 AM 8/29/2001 -0400, Ted Lemon wrote: >How about making relay-address an option? I don't think it will be >useful in most cases, so it seems like a drag to have it part of the >fixed header. > > _MelloN_ > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 14:10:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04875; Wed, 29 Aug 2001 14:10:30 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11223; Wed, 29 Aug 2001 14:09:31 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11201 for ; Wed, 29 Aug 2001 14:09:30 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04786 for ; Wed, 29 Aug 2001 14:08:09 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7TI9Sp29409 for ; Wed, 29 Aug 2001 13:09:28 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7TI9S711383 for ; Wed, 29 Aug 2001 13:09:28 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Aug 29 13:09:27 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 13:09:27 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34C3@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Date: Wed, 29 Aug 2001 13:09:27 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C130B5.BDA49BE0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C130B5.BDA49BE0 Content-Type: text/plain; charset="iso-8859-1" Please see my other message just sent a few moments ago before making this change. To answer your specific question, correct. In many cases this probably won't be an issue (at least if you consider the IPv4 case as all we have there is giaddr). Sure, there are some cases where this would be a problem (relay has no global address or address of sufficient scope for the interface) and in those the relay uses the option to carry this information. But, again, we need to look at the RETURN path and that's why I now think making this an option is a bad idea. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, August 29, 2001 1:23 PM To: dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header Before I make the change, let me make sure I understand your proposal. If the relay agent does not include the relay-address, the relay agent has to cause the forwarded message to have a source address - an address with the widest scope possible; e.g., a link-local address isn't useful - that is assigned to the interface on which the message was received by the agent from the client. - Ralph At 11:49 AM 8/29/2001 -0400, Ted Lemon wrote: >How about making relay-address an option? I don't think it will be >useful in most cases, so it seems like a drag to have it part of the >fixed header. > > _MelloN_ > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >http://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C130B5.BDA49BE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Changes to remove = "client-link-local-address" from the DHCPv6 header

Please see my other message just sent a few moments = ago before making this change.

To answer your specific question, correct. In many = cases this probably won't be an issue (at least if you consider the = IPv4 case as all we have there is giaddr). Sure, there are some cases = where this would be a problem (relay has no global address or address = of sufficient scope for the interface) and in those the relay uses the = option to carry this information.

But, again, we need to look at the RETURN path and = that's why I now think making this an option is a bad idea.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, August 29, 2001 1:23 PM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Changes to remove = "client-link-local-address" from
the DHCPv6 header


Before I make the change, let me make sure I = understand your proposal.  If the relay agent does not include the = relay-address, the relay agent has to cause the forwarded message to = have a source address - an address with the widest scope possible; = e.g., a link-local address isn't useful - that is assigned to the = interface on which the message was received by the agent from the = client.

- Ralph

At 11:49 AM 8/29/2001 -0400, Ted Lemon wrote:

>How about making relay-address an = option?   I don't think it will be
>useful in most cases, so it seems like a drag to = have it part of the
>fixed header.
>
>          = ;            = ;         _MelloN_
>
>_______________________________________________
>dhcwg mailing list
>dhcwg@ietf.org
>http://www1.ietf.org/mailman/listinfo/dhcwg=


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg=

------_=_NextPart_001_01C130B5.BDA49BE0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 14:16:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05036; Wed, 29 Aug 2001 14:16:42 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11475; Wed, 29 Aug 2001 14:15:27 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA11133 for ; Wed, 29 Aug 2001 14:07:14 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04754 for ; Wed, 29 Aug 2001 14:05:52 -0400 (EDT) Received: from mr7.exu.ericsson.se (mr7u3.ericy.com [208.237.135.122]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7TI7Bp27978 for ; Wed, 29 Aug 2001 13:07:11 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr7.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7TI7BA22986 for ; Wed, 29 Aug 2001 13:07:11 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Wed Aug 29 13:06:36 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Wed, 29 Aug 2001 13:06:36 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34C2@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Date: Wed, 29 Aug 2001 13:06:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C130B5.55CF5730" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C130B5.55CF5730 Content-Type: text/plain; charset="iso-8859-1" See my comments below (prefixed by BV>). But, let me make a few general comments. I assume that the changes to centralize the sending of messages and retransmissions discussions have not yet been applied and hence I will refrain from commenting about those sections of text. Let me also suggest that the previous suggestion by Ted (which I also was suggested) to move the "relay-address" into an option is probably not so good. Consider ... how does the relay know on which interface to send the client the Reply? The only way it could get this without the option is by getting the destination address from the IPv6 header of the Relay-Reply. While this is likely much more possible with the IPv6 socket API, it really isn't that easy if one considers the more restrictive IPv4 socket API (recvfrom only returns source info, not destination info). I ran into this issue when I received the end of Ralph's text (section 16.2). I have no problem if we want to gamble on this feature being available on all IPv6 stacks (to obtain the IPv6 destination address). I added this comment after making many of the comments about the changes needed to make this an option below. So, depending on what we decide, the comments below regarding making this an option may need to be ignored. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Tuesday, August 28, 2001 4:06 PM To: dhcwg@ietf.org Subject: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header I've completed the changes to remove the client-link-local-address field from the DHCP message header. Relay agents and servers will now use the source address from the IP header to reply to client messages. The changes include: * Message format and descriptions in section 8 to remove the client-link-local-address field * Relay agent message format and descriptions in section 9 to accommodate the client-return-address field * Address selection described in section 12 to allow for unicast client messages * The description of client behavior in sections 13 and 14 to remove the use of the client-link-local-address field and to specify that the client must send the message through the interface to be configure, to correctly set the source address in the IP header * The description of server behavior in sections 13 and 14 to remove the use of the client-link-local-address and change the format of the relay agent messages * The description of relay behavior in section 15 based on the new relay agent message format Note that the relay agent message has to include information about: 1. The return address to which the server should send the Relay-reply message 2. A link identifier/subnet selector that the server uses to select configuration information for the client 3. An interface identifier and return address for the client that the relay agent uses to forward the message from the server back to the client In DHCPv4, all of these functions are supplied by 'giaddr'. However, the source address from the IP header isn't sufficient (which we had discussed using for DHCPv6), because it may be awkward or impossible (and, usually suboptimal) to force the message from the relay agent to be sent to the server through the interface on which the message from the client was received. So, I've retained the relay-address field and added a client-return-address field in the Relay-forward for 2. and 3., and specified that the server use the source address from the IP header for 1. The text affected by these changes is included below. Please review and follow up with comments. - Ralph ===== 8. Message Formats Each DHCP message has an identical fixed format header; some messages also allow a variable format area for options. Not all fields in the header are used in every message. In this section, every field is described for every message and fields that are not used in a message are marked as "unused". All unused fields in a message MUST be transmitted as zeroes and ignored by the receiver of the message. The DHCP message header: 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 | transaction-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | server-address | | (16 octets) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . options . . (variable) . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8.1. DHCP Solicit Message Format msg-type SOLICIT transaction-ID An unsigned integer generated by the client used to identify this Solicit message. server-address (unused) MUST be 0 options See section 18. 8.2. DHCP Advertise Message Format msg-type ADVERTISE transaction-ID An unsigned integer used to identify this Advertise message. Copied from the client's Solicit message. server-address The IP address of the server that generated this message. If the DHCP domain crosses site boundaries, then this address MUST be globally-scoped. options See section 18. 8.3. DHCP Request Message Format msg-type REQUEST transaction-ID An unsigned integer generated by the client used to identify this Request message. server-address The IP address of the server to which the this message is directed, copied from an Advertise message. options See section 18. 8.4. DHCP Confirm Message Format msg-type CONFIRM transaction-ID An unsigned integer generated by the client used to identify this Confirm message. server-address MUST be zero. options See section 18. 8.5. DHCP Renew Message Format msg-type RENEW transaction-ID An unsigned integer generated by the client used to identify this Renew message. server-address The IP address of the server to which this Renew message is directed, which MUST be the address of the server from which the IAs in this message were originally assigned. options See section 18. 8.6. DHCP Rebind Message Format msg-type REBIND transaction-ID An unsigned integer generated by the client used to identify this Rebind message. server-address MUST be zero. options See section 18. 8.7. DHCP Reply Message Format msg-type REPLY transaction-ID An unsigned integer used to identify this Reply message. Copied from the client's Request, Confirm, Renew or Rebind message. server-address The IP address of the server. If the DHCP domain crosses site boundaries, then this address MUST be globally-scoped. options See section 18. 8.8. DHCP Release Message Format msg-type RELEASE transaction-ID An unsigned integer generated by the client used to identify this Release message. server-address The IP address of the server that assigned the IA. options See section 18. 8.9. DHCP Decline Message Format msg-type DECLINE transaction-ID An unsigned integer generated by the client used to identify this Decline message. server-address The IP address of the server that assigned the addresses. options See section 18. 8.10. DHCP Reconfigure-init Message Format msg-type RECONFIG-INIT transaction-ID (unused) MUST be 0 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. options See section 18. 9. Relay messages Relay agents exchange messages with servers to forward messages between clients and servers that are not connected to the same link. 9.1. Relay-forward 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 | | +-+-+-+-+-+-+-+-+ | | | | relay-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | | | | client-return-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-FORW prefix-length The length of the prefix in the address in the "relay-address" field. BV> Drop prefix-length as not used. relay-address An address assigned to the interface on which the message from the client was received. BV> See previous email from Ted and myself regarding the relay-address; BV> we should make it an option since it won't always be needed (as the BV> source IPv6 header address can be used in most cases). ALSO, see BV> my intro to this message before making this change.) client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Client message option"; see section 18.7. 9.2. Relay-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 | | +-+-+-+-+-+-+-+-+ | | | | relay-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | | | | client-return-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-REPL prefix-length The length of the prefix in the address in the "relay-address" field. BV> Drop prefix-length as not used. relay-address An address identifying the interface on the relay agent through which the message from the server should be forwarded; copied from the "relay-forward" message. BV> See above (make an option). Note that the server MUST send this BV> option back in the relay sent it in Relay-Forw. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Server message option"; see section 18.8. 12. Selecting addresses for assignment to an IA A server selects addresses to be assigned to an IA according to the address assignment policies determined by the server administrator and the specific information the server determines about the client from the following sources: - The link to which the client is attached: * If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is a link-local address, then the client is on the same link to which the interface over which the message was received is attached * If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is not link-local address, then the client is on the link identified by the source address in the IP datagram * If the server receives the message from a forwarding relay agent, then the client is on the same link as the one to which the interface identified by the relay-address field in the message from the relay is attached BV> This will need to be updated to reflect relay-address option (if no BV> option, use source address else use relay-address option value). - The DUID supplied by the client - Other information in options supplied by the client - Other information in options supplied by the relay agent 13. DHCP Server Solicitation This section describes how a client locates servers. The behavior of client and server implementations is discussed, along with the messages they use. 13.1. Solicit Message Validation Clients MUST silently discard any received Solicit messages. 13.2. Advertise Message Validation Servers MUST discard any received Advertise messages. Clients MUST discard any received Advertise messages in which the "Transaction-ID" field value does not match the value the client used in its Solicit message. 13.3. Client Behavior A client uses the Solicit message to discover DHCP servers configured to serve addresses on the link to which the client is attached. 13.3.1. Creation and sending of the Solicit message The client sets the "msg-type" field to SOLICIT. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client includes a DUID option to identify itself to the server. The client MUST include options for any IAs to which it wants the server to assign addresses. The client may include addresses in the IAs as a hint to the server about addresses for which the client may have a preference. The client MAY include an Option Request Option in the Solicit message. The client MUST NOT include any other options except those specifically allowed as defined by specific options. The client sends the Solicit message to the 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. 13.4. Server Behavior A server sends an Advertise message in response to Solicit messages it receives to announce the availability of the server to the client. 13.4.1. Receipt of Solicit messages The server determines the information about the client and its location as described in section 12. If administrative policy permits the server to respond to the client, the server will generate and send an Advertise message to the client. 13.4.2. Creation and sending of Advertise messages The server sets the "msg-type" field to ADVERTISE and copies the values of the transaction-ID field from the client's Solicit to the BV> Drop "the values of" Advertise message. The server places one of its IP addresses (determined through administrator setting) in the "server-address" field of the Advertise message. The server MAY add a Preference option to carry the preference value for the Advertise message. The server implementation SHOULD allow the setting of a server preference value by the administrator. The server preference value MUST default to zero unless otherwise configured by the server administrator. The server MUST include options to the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. If the server will not assign any addresses to IAs in a subsequent Request from the client, the server MAY choose to send an Advertise message to the client that includes no IA options. The server MAY include other options the server will return to the client in a subsequent Reply message. The information in these options will be used by the client in the selection of a server if the client receives more than one Advertise message. The server SHOULD include options specifying values for options requested by the client in an Option Request Option included in the Solicit message. If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the address in the source address field from the IP datagram in which the Solicit message was received. The Advertise message MUST be unicast through the interface on which the Solicit message was received. If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "server-message" option. The server unicasts the Relay-reply message directly to the relay agent using the address in the source address field from the IP datagram in which the Relay-forward message was received. 14. DHCP Client-Initiated Configuration Exchange A client initiates a message exchange with a server or servers to acquire or update configuration information of interest. The client may initiate the configuration exchange as part of the operating system configuration process or when requested to do so by the application layer. The client uses the following messages to initiate a configuration event: Request Obtain initial configuration information (from a server identified in a previously received Advertise message) when the client has no assigned addresses BV> Request may also be used at any time, not just "initial" configuration BV> information ... when the client has no assigned addresses. Confirm Confirm the validity of assigned addresses and other configuration changes through the server from which the BV> "configuration changes"? how about "configuration information". configuration information was obtained when the client's assigned addresses may not be valid; for example, when the client reboots or loses its connection to a link BV> also, this isn't just from the server from the info was obtained? Renew Extend the lease on an IA through the server that originally assigned the IA Rebind Extend the lease on an IA through any server willing to extend the lease Release Release the lease on an IA and release all of the addresses contained in the IA, BV> I think we still have open whether all or some address can be released. Decline Decline the assignment of one or more addresses in an IA. A client uses the Release/Reply message exchange to indicate to the DHCP server that the client will no longer be using the addresses in the released IA. BV> Why have this? Isn't this already covered by the above entry for Release? A client uses the Decline/Reply message exchange to indicate to the DHCP server that the client has detected that one or more addresses assigned by the server is already in use on the client's link. BV> Why have this? Same as release. 14.1. Client Message Validation Clients MUST silently discard any received client messages (Request, Confirm, Renew, Rebind, Release or Decline messages). Servers MUST discard any received client messages in which the "options" field contains an authentication option, and the server cannot successfully authenticate the client. Servers MUST discard any received Request, Renew, Release or Decline message in which the "server-address" field value does not match any of the server's addresses. 14.2. Server Message Validation Servers MUST silently discard any received server messages (Advertise, Reply or Reconfigure-init messages). Clients MUST discard any server messages that meet any of the following criteria: o The "transaction-ID" field value in the server message does not match the value the client used in its Request or Release message. BV> This should apply to all client messages, not just Request/Release. o The server message contains an authentication option, and the client's attempt to authenticate the message fails. Relays MUST discard any Relay-reply message in which the "client-link-local-address" field in the Relay-reply message does not contain a valid link-local address. BV> This is now the "client-return-address" and does it really need to BV> only be a link-local address? I don't think so (though it likely will BV> mostly be link-local). 14.3. Client Behavior A client will use Request, Confirm, Renew and Rebind messages to acquire and confirm the validity of 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 address information from previous Advertise message(s) for use in constructing Request and Renew 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 IAs when the client has been instructed to release the IA prior to the IA expiration time since it is no longer needed. A client uses the Decline message when the client has determined through DAD or some other method that one or more of the addresses assigned by the server in the IA is already in use by a different client. 14.3.1. Creation and sending of Request messages If a client has no valid IPv6 addresses of sufficient scope to communicate with a DHCP server, it may send a Request message to BV> Why "communicate with a DHCP server"? And the client could well BV> have many addresses of sufficient scope - that's not the point BV> of the request. We really should just say that "If the client BV> is using stateful address configuration and either needs an BV> initial set of address or additional addresses, it MUST send a BV> Request message to obtain new addresses." (or something like that) obtain new addresses. The client includes one or more IAs in the Request message, to which the server assigns new addresses. The server then returns IA(s) to the client in a Reply message. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. BV> How about "The client copies the "server-address" field as received in BV> the selected Advertise message to the "server-address" field of the BV> Request." The client adds a DUID option to identify itself to the server. The client adds any other appropriate options, including one or more IA options (if the client is requesting that the server assign it some network addresses). The list of addresses in each included IA MUST be empty. If the client is not requesting that the server assign it BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't BV> it that people wanted the addresses received in the Advertise to be BV> used here? any addresses, the client omits the IA option. The client sends the Request message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. The server will respond to the Request message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 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 7.5. 14.3.2. Creation and sending of Confirm messages Whenever a client may have moved to a new link, its IPv6 addresses may no longer be valid. Examples of times when a client may have moved to a new link include: o The client reboots o The client is physically disconnected from a wired connection o The client returns from sleep mode o The client using a wireless technology changes cells In any situation when a client may have moved to a new link, the client MUST initiate a Confirm/Reply message exchange. The client includes any IAs, along with the addresses associated with those IAs, in its Confirm message. Any responding servers will indicate the acceptability of the addresses with the status in the IA it returns to the client. The client sets the "msg-type" field to CONFIRM. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server confirm the validity of some network addresses). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Confirm message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. Servers will respond to the Confirm message with a Reply message. If no Confirm message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Confirm 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 QRY_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 QRY_MSG_ATTEMPTS are documented in section 7.5. If the client receives no response to its Confirm message, it MAY restart the configuration process by locating a DHCP server with an Advertise message and sending a Request to that server, as described in section 14.3.1. 14.3.3. Creation and sending of Renew messages IPv6 addresses assigned to a client through an IA use the same preferred and valid lifetimes as IPv6 addresses obtained through stateless autoconfiguration. The server assigns preferred and valid lifetimes to the IPv6 addresses it assigns to an IA. To extend those lifetimes, the client sends a Request to the server containing an "IA option" for the IA and its associated addresses. The server determines new lifetimes for the addresses in the IA according to the server's administrative configuration. The server may also add new addresses to the IA. The server remove addresses from the IA by BV> The server [may] remove addresses from the IA by ... setting the preferred and valid lifetimes of those addresses to zero. The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA. If the server does not assign an explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the shortest preferred lifetime of any address assigned to the IA and T2 defaults to 0.875 times the shortest preferred lifetime of any address assigned to the IA. BV> The above will be reworked in new material Mark, Ted, and I should be BV> providing. At time T1 for an IA, the client initiates a Request/Reply message exchange to extend the lifetimes on any addresses in the IA. The client includes an IA option with all addresses currently assigned to the IA in its Request message. The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions). If the client does include any IA options, it MUST include the list of addresses the client currently has associated with that IA. The client sends the Renew message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. The server will respond to the Renew message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Renew 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 until time T2 is reached (see section 14.3.4). Default and initial values for REP_MSG_TIMEOUT are documented in section 7.5. 14.3.4. Creation and sending of Rebind messages At time T2 for an IA (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange. The client includes an IA option with all addresses currently assigned to the IA in its Rebind message. The client sends this message to the All DHCP Agents multicast address. The client sets the "msg-type" field to REBIND. The client generates a transaction ID inserts this value in the "transaction-ID" field. The client sets the "server-address" field to 0. The client adds a DUID option to identify itself to the server. The client adds any appropriate options, including one or more IA options. If the client does include any IA options (if the client is requesting that the server extend the lease on some IAs; note that the client may check the status of other configuration parameters without asking for lease extensions), it MUST include the list of addresses the client currently has associated with that IA. The client sends the Rebind message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. The server will respond to the Rebind message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Rebind 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. Default and initial values for REP_MSG_TIMEOUT are documented in section 7.5. The client has several alternatives to choose from if it receives no response to its Rebind message. - When the lease on the IA expires, the client may choose to use a Solicit message to locate a new DHCP server and send a Request for the expired IA to the new server - Some addresses in the IA may have lifetimes that extend beyond the lease of the IA, so the client may choose to continue to use those addresses; once all of the addresses have expired, the client may choose to locate a new DHCP server - The client may have other addresses in other IAs, so the client may choose to discard the expired IA and use the addresses in the other IAs 14.3.5 (omitted) 14.3.6. Creation and sending of Release messages The client sets the "msg-type" field to RELEASE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is releasing in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for the release. If the client is configured to use authentication, the client generates the appropriate authentication option, and adds this option to the "options" field. Note that the authentication option MUST be the last option in the "options" field. See section 18.11 for more details about the authentication option. The client sends the Release message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. 14.3.7. (Omitted) 14.3.8. (Omitted) 14.3.9. Creation and sending of Decline messages The client sets the "msg-type" field to DECLINE. The client generates a transaction ID and places this value in the "transaction-ID" field. The client places the IP address of the server that allocated the address(es) in the "server-address" field. The client adds a DUID option to identify itself to the server. The client includes options containing the IAs it is declining in the "options" field. The addresses to be released MUST be included in the IAs. The appropriate "status" field in the options MUST be set to indicate the reason for declining the address. If the client is configured to use authentication, the client generates the appropriate authentication option, and adds this option to the "options" field. Note that the authentication option MUST be the last option in the "options" field. See section 18.11 for more details about the authentication option. The client sends the Decline message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. 14.3.10. (Omitted) If no Reply message is received within REP_MSG_TIMEOUT milliseconds, the client retransmits the Decline, 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 attempt to decline the address. 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 7.5. 14.3.11. Receipt of Reply message in response to a Release message 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. BV> This section should replace Release with Decline (Section 14.3.8 BV> covers the Release case). No need for application layer to be told BV> about Declines? 14.4. Server Behavior For this discussion, the Server is assumed to have been configured in an implementation specific manner with configuration of interest to clients. 14.4.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 options field. The server then constructs a Reply message and sends it to the client. The server SHOULD process each option for the client in an implementation-specific manner. The server MUST construct a Reply message containing the following values: msg-type REPLY transaction-ID The transaction-ID from the Request message. server address One of the IP addresses assigned to the interface through which the server received the message from the client. When the server receives a Request and IA option is included the client is requesting the configuration of a new IA by the server. BV> We need to clarify this behavoir and what "new" means (may be cases BV> where client thinks it is new, but server already knows about it). The server MUST take the clients IA and associate a binding for that client in an implementation-specific manner within the server's configuration parameter database for DHCP clients. If the server cannot provide addresses to the client it SHOULD send back an empty IA to the client with the status field set to Unavail. If the server can provide addresses to the client it MUST send back the IA to the client with all fields entered and a status of Success, and add the IA as a new client binding. The server adds options to the Reply message for any other configuration information to be assigned to the client. 14.4.2. Receipt of Confirm messages Upon the receipt of a valid Confirm message from a client the server can respond to, (implementation-specific administrative policy satisfied) the server scans the options field. The server then constructs a Reply message and sends it to the client. The server SHOULD process each option for the client in an implementation-specific manner. The server MUST construct a Reply message containing the following values: msg-type REPLY transaction-ID The transaction-ID from the Confirm message. server address One of the IP addresses assigned to the interface through which the server received the message from the client. When the server receives a Confirm and an IA option is included the client is requesting confirmation that the addresses in the IA are valid. The server SHOULD locate the clients binding and verify the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for this IA the server SHOULD return an empty IA with status set to NoBinding. If the server finds that the information for the client does not match what is in the server's records for that client the server should send back an empty IA with status set to Conf_NoMatch. If the server finds a match to the Confirm then the server should send back the IA to the client with status set to success. 14.4.3. Receipt of Renew messages Upon the receipt of a valid Renew message from a client the server can respond to, (implementation-specific administrative policy satisfied) the server scans the options field. The server then constructs a Reply message and sends it to the client. The server SHOULD process each option for the client in an implementation-specific manner. The server MUST construct a Reply message containing the following values: msg-type REPLY transaction-ID The transaction-ID from the Confirm message. server address One of the IP addresses assigned to the interface through which the server received the message from the client. When the server receives a Renew and IA option from a client it SHOULD locate the clients binding and verify the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for this IA the server SHOULD return an empty IA with status set to NoBinding. If the server finds that the addresses in the IA for the client do not match the clients binding the server should return an empty IA with status set to Renw_NoMatch. If the server cannot Renew addresses for the client it SHOULD send back an empty IA to the client with the status field set to Unavail. If the server finds the addresses in the IA for the client then the server SHOULD send back the IA to the client with new lease times and T1/T2 times if the default is not being used, and set status to Success. 14.4.4. Receipt of Rebind messages Upon the receipt of a valid Rebind message from a client the server can respond to, (implementation-specific administrative policy satisfied) the server scans the options field. The server then constructs a Reply message and sends it to the client. The server SHOULD process each option for the client in an implementation-specific manner. The server MUST construct a Reply message containing the following values: msg-type REPLY transaction-ID The transaction-ID from the Confirm message. server address One of the IP addresses assigned to the interface through which the server received the message from the client. When the server receives a Rebind and IA option from a client it SHOULD locate the clients binding and verify the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for this IA the server SHOULD return an empty IA with status set to NoBinding. If the server finds that the addresses in the IA for the client do not match the clients binding the server should return an empty IA with status set to Rebd_NoMatch. If the server cannot Rebind addresses for the client it SHOULD send back an empty IA to the client with the status field set to Unavail. If the server finds the addresses in the IA for the client then the server SHOULD send back the IA to the client with new lease times and T1/T2 times if the default is not being used, and set status to Success. There is a significant difference between Renew and Rebind messages: Because the Rebind message is processed by a single server, the responding server can actually change the addresses in the IA. However, because multiple servers may respond to a Rebind, all they can safely do is update T1, T2 (for the IA) and lifetimes (for individual addresses). 14.4.5. Receipt of Release messages Upon the receipt of a valid Release message, the server examines the IAs and the addresses in the IAs for validity. If the IAs in the message are in a binding for the client and the addresses in the IAs have been assigned by the server to those IA, the server deletes the addresses from the IAs and makes the addresses available for assignment to other clients. The server then generates a Reply message. If all of the IAs were valid and the addresses successfully released,, the server sets the "status" field to "Success". If any of the IAs were invalid or if any of the addresses were not successfully released, the server releases none of the addresses in the message and sets the "status" field to "NoBinding"(section 7.4). If the client successfully releases some but not all of the addresses in an IA, the IA continues to exist and holds the remaining, unreleased addresses. A client can send an option containing an IA with no listed addresses to release implicitly all of the addresses in the IA. A server is not required to (but may choose to as an implementation strategy) retain any record of an IA from which all of the addresses have been released. 14.4.6. Sending of Reply messages If the Request, Confirm, Renew, Rebind or Release message from BV> What about Decline messages (add to list). the client was originally received was originally received in a BV> typo - duplicated "was originally received". Relay-forward message from a relay, the server places the Reply message in the options field of a Relay-response message and copies the relay-address and client-link-local-address fields from the BV> client-return-address Relay-forward message into the Relay-response message. The server then unicasts the Reply or Relay-reply to the source address from the IP datagram in which the original message was received. 16. Relay Behavior For this discussion, the Relay may be configured to use a list of server destination addresses, which may include unicast addresses, the All DHCP Servers multicast address, or other multicast addresses selected by the network administrator. If the Relay has not been explicitly configured, it MUST use the All DHCP Servers multicast address as the default. 16.1. Relaying of client messages When a Relay receives a valid client message, it constructs a Relay-forward message. The relay places an address from the interface on which the client message was received in the "relay-address" field. This address will be used by the server to identify the link to which the client is connected and will be used by the relay to forward the Advertise message from the server back to the client. The relay copies the source address from the IP datagram in which the message was received from the client into the client-link-local-address field in the Relay-forward message. BV> client-return-address The relay constructs a "client-message" option 18.7 that contains the entire message from the client in the data field of the option. The relay places the "relay-message" option along with any "relay-specific" options in the options field of the Relay-forward message. The Relay then sends the Relay-forward message to the list of server destination addresses that it has been configured with. 16.2. Relaying of server messages When the relay receives a Relay-reply message, it extracts the server message from the "server-message" option and forwards the message to the address in the client-link-local-address field in the Relay-reply BV> client-returnn-address message. The relay forwards the server message through the interface identified in the "relay-address" field in the Relay-reply message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C130B5.55CF5730 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header

See my comments below (prefixed by BV>).

But, let me make a few general comments. I assume that the changes to centralize
the sending of messages and retransmissions discussions have not yet been applied
and hence I will refrain from commenting about those sections of text.

Let me also suggest that the previous suggestion by Ted (which I also was
suggested) to move the "relay-address" into an option is probably not so good.
Consider ... how does the relay know on which interface to send the client the
Reply? The only way it could get this without the option is by getting the
destination address from the IPv6 header of the Relay-Reply. While this is likely
much more possible with the IPv6 socket API, it really isn't that easy if one
considers the more restrictive IPv4 socket API (recvfrom only returns source
info, not destination info). I ran into this issue when I received the end of
Ralph's text (section 16.2). I have no problem if we want to gamble on this feature
being available on all IPv6 stacks (to obtain the IPv6 destination address).
I added this comment after making many of the comments about the changes needed to
make this an option below. So, depending on what we decide, the comments below
regarding making this an option may need to be ignored.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Tuesday, August 28, 2001 4:06 PM
To: dhcwg@ietf.org
Subject: [dhcwg] Changes to remove "client-link-local-address" from the
DHCPv6 header


I've completed the changes to remove the client-link-local-address
field from the DHCP message header.  Relay agents and servers will now
use the source address from the IP header to reply to client messages.

The changes include:

* Message format and descriptions in section 8 to remove the
  client-link-local-address field 
* Relay agent message format and descriptions in section 9 to
  accommodate the client-return-address field
* Address selection described in section 12 to allow for unicast
  client messages
* The description of client behavior in sections 13 and 14
  to remove the use of the client-link-local-address field and to
  specify that the client must send the message through the interface
  to be configure, to correctly set the source address in the IP
  header
* The description of server behavior in sections 13 and 14 to remove
  the use of the client-link-local-address and change the format of
  the relay agent messages
* The description of relay behavior in section 15 based on the new
  relay agent message format

Note that the relay agent message has to include information about:

1. The return address to which the server should send the Relay-reply
   message
2. A link identifier/subnet selector that the server uses to select
   configuration information for the client
3. An interface identifier and return address for the client that the
   relay agent uses to forward the message from the server back to the
   client

In DHCPv4, all of these functions are supplied by 'giaddr'.  However,
the source address from the IP header isn't sufficient (which we had
discussed using for DHCPv6), because it may be awkward or impossible
(and, usually suboptimal) to force the message from the relay agent to
be sent to the server through the interface on which the message from
the client was received.  So, I've retained the relay-address field
and added a client-return-address field in the Relay-forward for
2. and 3., and specified that the server use the source address from
the IP header for 1.

The text affected by these changes is included below.  Please review
and follow up with comments.

- Ralph

=====

8. Message Formats

   Each DHCP message has an identical fixed format header; some messages
   also allow a variable format area for options.  Not all fields in
   the header are used in every message.  In this section, every field
   is described for every message and fields that are not used in a
   message are marked as "unused".  All unused fields in a message MUST
   be transmitted as zeroes and ignored by the receiver of the message.

   The DHCP message header:
      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   |               transaction-ID                  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                         server-address                        |
     |                          (16 octets)                          |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                            options                            .
     .                          (variable)                           .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+




8.1. DHCP Solicit Message Format

      msg-type         SOLICIT

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Solicit message.

      server-address   (unused) MUST be 0

      options          See section 18.


8.2. DHCP Advertise Message Format

      msg-type         ADVERTISE

      transaction-ID   An unsigned integer used to identify this
                       Advertise message.  Copied from the client's
                       Solicit message.

      server-address   The IP address of the server that generated
                       this message.  If the DHCP domain crosses
                       site boundaries, then this address MUST be
                       globally-scoped.

      options          See section 18.


8.3. DHCP Request Message Format

      msg-type         REQUEST

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Request message.

      server-address   The IP address of the server to which the this
                       message is directed, copied from an Advertise
                       message.

      options          See section 18.


8.4. DHCP Confirm Message Format

      msg-type         CONFIRM

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Confirm message.

      server-address   MUST be zero.

      options          See section 18.


8.5. DHCP Renew Message Format

      msg-type         RENEW

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Renew message.

      server-address   The IP address of the server to which this Renew
                       message is directed, which MUST be the address
                       of the server from which the IAs in this message
                       were originally assigned.

      options          See section 18.


8.6. DHCP Rebind Message Format

      msg-type         REBIND

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Rebind message.

      server-address   MUST be zero.

      options          See section 18.


8.7. DHCP Reply Message Format

      msg-type         REPLY

      transaction-ID   An unsigned integer used to identify this Reply
                       message.  Copied from the client's Request,
                       Confirm, Renew or Rebind message.

      server-address   The IP address of the server.  If the DHCP domain
                       crosses site boundaries, then this address MUST
                       be globally-scoped.

      options          See section 18.


8.8. DHCP Release Message Format

      msg-type         RELEASE

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Release message.

      server-address   The IP address of the server that assigned the
                       IA.

      options          See section 18.


8.9. DHCP Decline Message Format

      msg-type         DECLINE

      transaction-ID   An unsigned integer generated by the client used
                       to identify this Decline message.

      server-address   The IP address of the server that assigned the
                       addresses.

      options          See section 18.


8.10. DHCP Reconfigure-init Message Format

      msg-type         RECONFIG-INIT

      transaction-ID   (unused) MUST be 0

      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.

      options          See section 18.


9. Relay messages

   Relay agents exchange messages with servers to forward messages
   between clients and servers that are not connected to the same link.


9.1. Relay-forward 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   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                     client-return-address                     |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     .                                                               .
     .            options (variable number and length)   ....        .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      msg-type                    RELAY-FORW

      prefix-length               The length of the prefix in the
                                  address in the "relay-address" field.
BV> Drop prefix-length as not used.

      relay-address               An address assigned to the interface
                                  on which the message from the client
                                  was received.
BV> See previous email from Ted and myself regarding the relay-address;
BV> we should make it an option since it won't always be needed (as the
BV> source IPv6 header address can be used in most cases). ALSO, see
BV> my intro to this message before making this change.)

      client-return-address       The source address from the IP
                                  datagram in which the message from the
                                  client was received by the relay agent

      options                     MUST include a "Client message
                                  option"; see section 18.7.


9.2. Relay-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   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                         relay-address                         |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                     client-return-address                     |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     .                                                               .
     .            options (variable number and length)   ....        .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      msg-type        RELAY-REPL

      prefix-length   The length of the prefix in the address in the
                      "relay-address" field.
BV> Drop prefix-length as not used.

      relay-address   An address identifying the interface on the
                      relay agent through which the message from the
                      server should be forwarded; copied from the
                      "relay-forward" message.
BV> See above (make an option). Note that the server MUST send this
BV> option back in the relay sent it in Relay-Forw.

      client-return-address       The source address from the IP
                                  datagram in which the message from the
                                  client was received by the relay agent

      options         MUST include a "Server message option"; see
                      section 18.8.



12. Selecting addresses for assignment to an IA

   A server selects addresses to be assigned to an IA according to the
   address assignment policies determined by the server administrator
   and the specific information the server determines about the client
   from the following sources:

    -  The link to which the client is attached:

        *  If the server receives the message directly from the client
           and the source address in the IP datagram in which the
           message was received is a link-local address, then the client
           is on the same link to which the interface over which the
           message was received is attached

        *  If the server receives the message directly from the client
           and the source address in the IP datagram in which the
           message was received is not link-local address, then the
           client is on the link identified by the source address in the
           IP datagram

        *  If the server receives the message from a forwarding relay
           agent, then the client is on the same link as the one to
           which the interface identified by the relay-address field in
           the message from the relay is attached
BV> This will need to be updated to reflect relay-address option (if no
BV> option, use source address else use relay-address option value).

    -  The DUID supplied by the client

    -  Other information in options supplied by the client

    -  Other information in options supplied by the relay agent


13. DHCP Server Solicitation

   This section describes how a client locates servers.  The behavior
   of client and server implementations is discussed, along with the
   messages they use.


13.1. Solicit Message Validation

   Clients MUST silently discard any received Solicit messages.


13.2. Advertise Message Validation

   Servers MUST discard any received Advertise messages.

   Clients MUST discard any received Advertise messages in which the
   "Transaction-ID" field value does not match the value the client used
   in its Solicit message.


13.3. Client Behavior

   A client uses the Solicit message to discover DHCP servers configured
   to serve addresses on the link to which the client is attached.


13.3.1. Creation and sending of the Solicit message

   The client sets the "msg-type" field to SOLICIT. The client generates
   a transaction ID and inserts this value in the "transaction-ID"
   field.

   The client includes a DUID option to identify itself to the server.
   The client MUST include options for any IAs to which it wants the
   server to assign addresses.  The client may include addresses in the
   IAs as a hint to the server about addresses for which the client
   may have a preference.  The client MAY include an Option Request
   Option in the Solicit message.  The client MUST NOT include any other
   options except those specifically allowed as defined by specific
   options.

   The client sends the Solicit message to the 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.



13.4. Server Behavior

   A server sends an Advertise message in response to Solicit messages
   it receives to announce the availability of the server to the client.


13.4.1. Receipt of Solicit messages

   The server determines the information about the client and its
   location as described in section 12.  If administrative policy
   permits the server to respond to the client, the server will generate
   and send an Advertise message to the client.


13.4.2. Creation and sending of Advertise messages

   The server sets the "msg-type" field to ADVERTISE and copies the
   values of the transaction-ID field from the client's Solicit to the
BV> Drop "the values of"
   Advertise message.

   The server places one of its IP addresses (determined through
   administrator setting) in the "server-address" field of the Advertise
   message.  The server MAY add a Preference option to carry the
   preference value for the Advertise message.

   The server implementation SHOULD allow the setting of a server
   preference value by the administrator.  The server preference value
   MUST default to zero unless otherwise configured by the server
   administrator.

   The server MUST include options to the Advertise message containing
   any addresses that would be assigned to IAs contained in the Solicit
   message from the client.  If the server will not assign any addresses
   to IAs in a subsequent Request from the client, the server MAY choose
   to send an Advertise message to the client that includes no IA
   options.  The server MAY include other options the server will return
   to the client in a subsequent Reply message.  The information in
   these options will be used by the client in the selection of a server
   if the client receives more than one Advertise message.  The server
   SHOULD include options specifying values for options requested by the
   client in an Option Request Option included in the Solicit message.

   If the Solicit message was received directly by the server, the
   server unicasts the Advertise message directly to the client using
   the address in the source address field from the IP datagram in
   which the Solicit message was received.  The Advertise message MUST
   be unicast through the interface on which the Solicit message was
   received.

   If the Solicit message was received in a Relay-forward message,
   the server constructs a Relay-reply message with the Advertise
   message in the payload of a "server-message" option.  The server
   unicasts the Relay-reply message directly to the relay agent using
   the address in the source address field from the IP datagram in which
   the Relay-forward message was received.


14. DHCP Client-Initiated Configuration Exchange

   A client initiates a message exchange with a server or servers to
   acquire or update configuration information of interest.  The client
   may initiate the configuration exchange as part of the operating
   system configuration process or when requested to do so by the
   application layer.

   The client uses the following messages to initiate a configuration
   event:

      Request   Obtain initial configuration information (from a server
                identified in a previously received Advertise message)
                when the client has no assigned addresses
BV> Request may also be used at any time, not just "initial" configuration
BV> information ... when the client has no assigned addresses.

      Confirm   Confirm the validity of assigned addresses and other
                configuration changes through the server from which the
BV> "configuration changes"? how about "configuration information".
                configuration information was obtained when the client's
                assigned addresses may not be valid; for example, when
                the client reboots or loses its connection to a link
BV> also, this isn't just from the server from the info was obtained?

      Renew     Extend the lease on an IA through the server that
                originally assigned the IA

      Rebind    Extend the lease on an IA through any server willing to
                extend the lease

      Release   Release the lease on an IA and release all of the
                addresses contained in the IA,
BV> I think we still have open whether all or some address can be released.

      Decline   Decline the assignment of one or more addresses in an
                IA.

   A client uses the Release/Reply message exchange to indicate to the
   DHCP server that the client will no longer be using the addresses in
   the released IA.
BV> Why have this? Isn't this already covered by the above entry for Release?

   A client uses the Decline/Reply message exchange to indicate to the
   DHCP server that the client has detected that one or more addresses
   assigned by the server is already in use on the client's link.
BV> Why have this? Same as release.


14.1. Client Message Validation

   Clients MUST silently discard any received client messages (Request,
   Confirm, Renew, Rebind, Release or Decline messages).

   Servers MUST discard any received client messages in which the
   "options" field contains an authentication option, and the server
   cannot successfully authenticate the client.

   Servers MUST discard any received Request, Renew, Release or Decline
   message in which the "server-address" field value does not match any
   of the server's addresses.


14.2. Server Message Validation

   Servers MUST silently discard any received server messages
   (Advertise, Reply or Reconfigure-init messages).

   Clients MUST discard any server messages that meet any of the
   following criteria:

     o The "transaction-ID" field value in the server message does
       not match the value the client used in its Request or Release
       message.
BV> This should apply to all client messages, not just Request/Release.

     o The server message contains an authentication option, and the
       client's attempt to authenticate the message fails.

   Relays MUST discard any Relay-reply message in which the
   "client-link-local-address" field in the Relay-reply message does not
   contain a valid link-local address.
BV> This is now the "client-return-address" and does it really need to
BV> only be a link-local address? I don't think so (though it likely will
BV> mostly be link-local).

14.3. Client Behavior

   A client will use Request, Confirm, Renew and Rebind messages to
   acquire and confirm the validity of 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 address information from
   previous Advertise message(s) for use in constructing Request and
   Renew 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 IAs when
   the client has been instructed to release the IA prior to the IA
   expiration time since it is no longer needed.

   A client uses the Decline message when the client has determined
   through DAD or some other method that one or more of the addresses
   assigned by the server in the IA is already in use by a different
   client.


14.3.1. Creation and sending of Request messages

   If a client has no valid IPv6 addresses of sufficient scope to
   communicate with a DHCP server, it may send a Request message to
BV> Why "communicate with a DHCP server"? And the client could well
BV> have many addresses of sufficient scope - that's not the point
BV> of the request. We really should just say that "If the client
BV> is using stateful address configuration and either needs an
BV> initial set of address or additional addresses, it MUST send a
BV> Request message to obtain new addresses." (or something like that)
   obtain new addresses.  The client includes one or more IAs in the
   Request message, to which the server assigns new addresses.  The
   server then returns IA(s) to the client in a Reply message.

   The client generates a transaction ID and inserts this value in the
   "transaction-ID" field.

   The client places the address of the destination server in the
   "server-address" field.
BV> How about "The client copies the "server-address" field as received in
BV> the selected Advertise message to the "server-address" field of the
BV> Request."

   The client adds a DUID option to identify itself to the server.  The
   client adds any other appropriate options, including one or more IA
   options (if the client is requesting that the server assign it some
   network addresses).  The list of addresses in each included IA MUST
   be empty.  If the client is not requesting that the server assign it
BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't
BV> it that people wanted the addresses received in the Advertise to be
BV> used here?
   any addresses, the client omits the IA option.

   The client sends the Request message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, with the destination port set
   to 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.

   The server will respond to the Request message with a Reply
   message.  If no Reply message is received within REP_MSG_TIMEOUT
   milliseconds, 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 7.5.


14.3.2. Creation and sending of Confirm messages

   Whenever a client may have moved to a new link, its IPv6 addresses
   may no longer be valid.  Examples of times when a client may have
   moved to a new link include:

     o The client reboots

     o The client is physically disconnected from a wired connection

     o The client returns from sleep mode

     o The client using a wireless technology changes cells

   In any situation when a client may have moved to a new link, the
   client MUST initiate a Confirm/Reply message exchange.  The client
   includes any IAs, along with the addresses associated with those IAs,
   in its Confirm message.  Any responding servers will indicate the
   acceptability of the addresses with the status in the IA it returns
   to the client.

   The client sets the "msg-type" field to CONFIRM. The client generates
   a transaction ID and inserts this value in the "transaction-ID"
   field.

   The client sets the "server-address" field to 0.

   The client adds a DUID option to identify itself to the server.  The
   client adds any appropriate options, including one or more IA options
   (if the client is requesting that the server confirm the validity of
   some network addresses).  If the client does include any IA options,
   it MUST include the list of addresses the client currently has
   associated with that IA.

   The client sends the Confirm message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, with the destination port set
   to 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.

   Servers will respond to the Confirm message with a Reply message.  If
   no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Confirm 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 QRY_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 QRY_MSG_ATTEMPTS
   are documented in section 7.5.

   If the client receives no response to its Confirm message, it MAY
   restart the configuration process by locating a DHCP server with an
   Advertise message and sending a Request to that server, as described
   in section 14.3.1.


14.3.3. Creation and sending of Renew messages

   IPv6 addresses assigned to a client through an IA use the same
   preferred and valid lifetimes as IPv6 addresses obtained through
   stateless autoconfiguration.  The server assigns preferred and valid
   lifetimes to the IPv6 addresses it assigns to an IA. To extend those
   lifetimes, the client sends a Request to the server containing an
   "IA option" for the IA and its associated addresses.  The server
   determines new lifetimes for the addresses in the IA according to
   the server's administrative configuration.  The server may also add
   new addresses to the IA. The server remove addresses from the IA by
BV> The server [may] remove addresses from the IA by ...
   setting the preferred and valid lifetimes of those addresses to zero.

   The server controls the time at which the client contacts the server
   to extend the lifetimes on assigned addresses through the T1 and
   T2 parameters assigned to an IA. If the server does not assign an
   explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the
   shortest preferred lifetime of any address assigned to the IA and
   T2 defaults to 0.875 times the shortest preferred lifetime of any
   address assigned to the IA.
BV> The above will be reworked in new material Mark, Ted, and I should be
BV> providing.

   At time T1 for an IA, the client initiates a Request/Reply message
   exchange to extend the lifetimes on any addresses in the IA. The
   client includes an IA option with all addresses currently assigned to
   the IA in its Request message.

   The client sets the "msg-type" field to RENEW. The client generates a
   transaction ID and inserts this value in the "transaction-ID" field.

   The client places the address of the destination server in the
   "server-address" field.

   The client adds a DUID option to identify itself to the server.  The
   client adds any appropriate options, including one or more IA options
   (if the client is requesting that the server extend the lease on some
   IAs; note that the client may check the status of other configuration
   parameters without asking for lease extensions).  If the client does
   include any IA options, it MUST include the list of addresses the
   client currently has associated with that IA.

   The client sends the Renew message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, with the destination port set
   to 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.

   The server will respond to the Renew message with a Reply message.
   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Renew 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 until time T2 is
   reached (see section 14.3.4).

   Default and initial values for REP_MSG_TIMEOUT are documented in
   section 7.5.


14.3.4. Creation and sending of Rebind messages

   At time T2 for an IA (which will only be reached if the server to
   which the Renew message was sent at time T1 has not responded),
   the client initiates a Rebind/Reply message exchange.  The client
   includes an IA option with all addresses currently assigned to the IA
   in its Rebind message.  The client sends this message to the All DHCP
   Agents multicast address.

   The client sets the "msg-type" field to REBIND. The client generates
   a transaction ID inserts this value in the "transaction-ID" field.

   The client sets the "server-address" field to 0.

   The client adds a DUID option to identify itself to the server.
   The client adds any appropriate options, including one or more IA
   options.  If the client does include any IA options (if the client is
   requesting that the server extend the lease on some IAs; note that
   the client may check the status of other configuration parameters
   without asking for lease extensions), it MUST include the list of
   addresses the client currently has associated with that IA.

   The client sends the Rebind message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, with the destination port set
   to 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.

   The server will respond to the Rebind message with a Reply message.
   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Rebind 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.

   Default and initial values for REP_MSG_TIMEOUT are documented in
   section 7.5.

   The client has several alternatives to choose from if it receives no
   response to its Rebind message.

    -  When the lease on the IA expires, the client may choose to use a
       Solicit message to locate a new DHCP server and send a Request
       for the expired IA to the new server

    -  Some addresses in the IA may have lifetimes that extend beyond
       the lease of the IA, so the client may choose to continue to use
       those addresses; once all of the addresses have expired, the
       client may choose to locate a new DHCP server

    -  The client may have other addresses in other IAs, so the client
       may choose to discard the expired IA and use the addresses in the
       other IAs

14.3.5 (omitted)

14.3.6. Creation and sending of Release messages

   The client sets the "msg-type" field to RELEASE. The client generates
   a transaction ID and places this value in the "transaction-ID" field.

   The client places the IP address of the server that allocated the
   address(es) in the "server-address" field.

   The client adds a DUID option to identify itself to the server.  The
   client includes options containing the IAs it is releasing in the
   "options" field.  The addresses to be released MUST be included in
   the IAs.  The appropriate "status" field in the options MUST be set
   to indicate the reason for the release.

   If the client is configured to use authentication, the client
   generates the appropriate authentication option, and adds this option
   to the "options" field.  Note that the authentication option MUST be
   the last option in the "options" field.  See section  18.11 for more
   details about the authentication option.

   The client sends the Release message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, with the destination port set
   to 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.


14.3.7. (Omitted)


14.3.8. (Omitted)


14.3.9. Creation and sending of Decline messages

   The client sets the "msg-type" field to DECLINE. The client generates
   a transaction ID and places this value in the "transaction-ID" field.

   The client places the IP address of the server that allocated the
   address(es) in the "server-address" field.

   The client adds a DUID option to identify itself to the server.  The
   client includes options containing the IAs it is declining in the
   "options" field.  The addresses to be released MUST be included in
   the IAs.  The appropriate "status" field in the options MUST be set
   to indicate the reason for declining the address.

   If the client is configured to use authentication, the client
   generates the appropriate authentication option, and adds this option
   to the "options" field.  Note that the authentication option MUST be
   the last option in the "options" field.  See section  18.11 for more
   details about the authentication option.

   The client sends the Decline message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, with the destination port set
   to 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.

14.3.10. (Omitted)

   If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
   the client retransmits the Decline, 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 attempt to
   decline the address.  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 7.5.


14.3.11. Receipt of Reply message in response to a Release message

   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.
BV> This section should replace Release with Decline (Section 14.3.8
BV> covers the Release case). No need for application layer to be told
BV> about Declines?


14.4. Server Behavior

   For this discussion, the Server is assumed to have been configured in
   an implementation specific manner with configuration of interest to
   clients.


14.4.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 options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type         REPLY

      transaction-ID   The transaction-ID from the Request message.

      server address   One of the IP addresses assigned to the interface
                       through which the server received the message
                       from the client.

   When the server receives a Request and IA option is included the
   client is requesting the configuration of a new IA by the server.
BV> We need to clarify this behavoir and what "new" means (may be cases
BV> where client thinks it is new, but server already knows about it).
   The server MUST take the clients IA and associate a binding for that
   client in an implementation-specific manner within the server's
   configuration parameter database for DHCP clients.

   If the server cannot provide addresses to the client it SHOULD send
   back an empty IA to the client with the status field set to Unavail.

   If the server can provide addresses to the client it MUST send back
   the IA to the client with all fields entered and a status of Success,
   and add the IA as a new client binding.

   The server adds options to the Reply message for any other
   configuration information to be assigned to the client.


14.4.2. Receipt of Confirm messages

   Upon the receipt of a valid Confirm message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type         REPLY

      transaction-ID   The transaction-ID from the Confirm message.

      server address   One of the IP addresses assigned to the interface
                       through which the server received the message
                       from the client.

   When the server receives a Confirm and an IA option is included the
   client is requesting confirmation that the addresses in the IA are
   valid.  The server SHOULD locate the clients binding and verify the
   information in the IA from the client matches the information stored
   for that client.

   If the server cannot find a client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server finds that the information for the client does not
   match what is in the server's records for that client the server
   should send back an empty IA with status set to Conf_NoMatch.

   If the server finds a match to the Confirm then the server should
   send back the IA to the client with status set to success.


14.4.3. Receipt of Renew messages

   Upon the receipt of a valid Renew message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type         REPLY

      transaction-ID   The transaction-ID from the Confirm message.

      server address   One of the IP addresses assigned to the interface
                       through which the server received the message
                       from the client.

   When the server receives a Renew and IA option from a client it
   SHOULD locate the clients binding and verify the information in the
   IA from the client matches the information stored for that client.

   If the server cannot find a client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server finds that the addresses in the IA for the client do
   not match the clients binding the server should return an empty IA
   with status set to Renw_NoMatch.

   If the server cannot Renew addresses for the client it SHOULD send
   back an empty IA to the client with the status field set to Unavail.

   If the server finds the addresses in the IA for the client then the
   server SHOULD send back the IA to the client with new lease times
   and T1/T2 times if the default is not being used, and set status to
   Success.


14.4.4. Receipt of Rebind messages

   Upon the receipt of a valid Rebind message from a client the server
   can respond to, (implementation-specific administrative policy
   satisfied) the server scans the options field.

   The server then constructs a Reply message and sends it to the
   client.

   The server SHOULD process each option for the client in an
   implementation-specific manner.  The server MUST construct a Reply
   message containing the following values:

      msg-type         REPLY

      transaction-ID   The transaction-ID from the Confirm message.

      server address   One of the IP addresses assigned to the interface
                       through which the server received the message
                       from the client.

   When the server receives a Rebind and IA option from a client it
   SHOULD locate the clients binding and verify the information in the
   IA from the client matches the information stored for that client.

   If the server cannot find a client entry for this IA the server
   SHOULD return an empty IA with status set to NoBinding.

   If the server finds that the addresses in the IA for the client do
   not match the clients binding the server should return an empty IA
   with status set to Rebd_NoMatch.

   If the server cannot Rebind addresses for the client it SHOULD send
   back an empty IA to the client with the status field set to Unavail.

   If the server finds the addresses in the IA for the client then the
   server SHOULD send back the IA to the client with new lease times
   and T1/T2 times if the default is not being used, and set status to
   Success.

   There is a significant difference between Renew and Rebind messages:
   Because the Rebind message is processed by a single server, the
   responding server can actually change the addresses in the IA.
   However, because multiple servers may respond to a Rebind, all they
   can safely do is update T1, T2 (for the IA) and lifetimes (for
   individual addresses).


14.4.5. Receipt of Release messages

   Upon the receipt of a valid Release message, the server examines the
   IAs and the addresses in the IAs for validity.  If the IAs in the
   message are in a binding for the client and the addresses in the IAs
   have been assigned by the server to those IA, the server deletes
   the addresses from the IAs and makes the addresses available for
   assignment to other clients.

   The server then generates a Reply message.  If all of the IAs were
   valid and the addresses successfully released,, the server sets the
   "status" field to "Success".  If any of the IAs were invalid or if
   any of the addresses were not successfully released, the server
   releases none of the addresses in the message and sets the "status"
   field to "NoBinding"(section 7.4).

   If the client successfully releases some but not all of the addresses
   in an IA, the IA continues to exist and holds the remaining,
   unreleased addresses.

   A client can send an option containing an IA with no listed addresses
   to release implicitly all of the addresses in the IA.

   A server is not required to (but may choose to as an implementation
   strategy) retain any record of an IA from which all of the addresses
   have been released.


14.4.6. Sending of Reply messages

   If the Request, Confirm, Renew, Rebind or Release message from
BV> What about Decline messages (add to list).
   the client was originally received was originally received in a
BV> typo - duplicated "was originally received".
   Relay-forward message from a relay, the server places the Reply
   message in the options field of a Relay-response message and copies
   the relay-address and client-link-local-address fields from the
BV> client-return-address
   Relay-forward message into the Relay-response message.

   The server then unicasts the Reply or Relay-reply to the source
   address from the IP datagram in which the original message was
   received.


16. Relay Behavior

   For this discussion, the Relay may be configured to use a list of
   server destination addresses, which may include unicast addresses,
   the All DHCP Servers multicast address, or other multicast addresses
   selected by the network administrator.  If the Relay has not been
   explicitly configured, it MUST use the All DHCP Servers multicast
   address as the default.

16.1. Relaying of client messages

   When a Relay receives a valid client message, it constructs
   a Relay-forward message.  The relay places an address from
   the interface on which the client message was received in the
   "relay-address" field.  This address will be used by the server to
   identify the link to which the client is connected and will be used
   by the relay to forward the Advertise message from the server back to
   the client.

   The relay copies the source address from the IP datagram
   in which the message was received from the client into the
   client-link-local-address field in the Relay-forward message.
BV> client-return-address

   The relay constructs a "client-message" option 18.7 that contains
   the entire message from the client in the data field of the
   option.  The relay places the "relay-message" option along with any
   "relay-specific" options in the options field of the Relay-forward
   message.  The Relay then sends the Relay-forward message to the list
   of server destination addresses that it has been configured with.


16.2. Relaying of server messages

   When the relay receives a Relay-reply message, it extracts the server
   message from the "server-message" option and forwards the message to
   the address in the client-link-local-address field in the Relay-reply
BV> client-returnn-address
   message.  The relay forwards the server message through the interface
   identified in the "relay-address" field in the Relay-reply message.


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C130B5.55CF5730-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 16:52:19 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09310; Wed, 29 Aug 2001 16:52:10 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA16361; Wed, 29 Aug 2001 16:50:33 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA15245 for ; Wed, 29 Aug 2001 16:32:59 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08572 for ; Wed, 29 Aug 2001 16:31:36 -0400 (EDT) Received: from cisco.com (dhcp-161-44-149-95.cisco.com [161.44.149.95]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA06583; Wed, 29 Aug 2001 16:31:09 -0400 (EDT) Message-ID: <3B8D50D9.D86E9BF7@cisco.com> Date: Wed, 29 Aug 2001 16:30:17 -0400 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bernie Volz (EUD)" CC: "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header References: <66F66129A77AD411B76200508B65AC697B34C2@eambunt705.ena-east.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit Bernie, I agree with your conclusion, but differ with your reasoning. Comments inline: > "Bernie Volz (EUD)" wrote: > > See my comments below (prefixed by BV>). > > Let me also suggest that the previous suggestion by Ted (which I also was > suggested) to move the "relay-address" into an option is probably not so > good. > Consider ... how does the relay know on which interface to send the client > the > Reply? The only way it could get this without the option is by getting the > > destination address from the IPv6 header of the Relay-Reply. I believe if the relay is using the simple API and it must specify the right source address, then the relay will need to send through a socket which is bound to the desired local address. I believe it will also receive its response through that bound socket, so learning the responses packet's destination address is accomplished by noticing the socket through which it arrived. So, its doable with the simple API, though I think its a bit more complexity than you'd want relays to have to implement. As you note below, if using the advanced API, then specifying the source address on sending and learning the destination address on receiving is easier, and is almost as easy as writing a the relay's local address into a fixed place in the packet, but not quite. I think the explicit specification of a relay-address is needed in cases where either the relay has no global address on the proper interface (and thus needs to indicate a prefix-only address, which should work just fine), or where specifying the source address may complicate the packet's route out of the relay (this is speculation). If a relay must detect one of these conditions, then it complicates the relay, or encourages relay authors to opt for the safer solution and always use the option (in which case it isn't optional in a practical sense). I think those are the technical considerations. I think I'd have the relay-address always present (not move it to an option) for relay agent implementation simplicity. > While this is > likely > much more possible with the IPv6 socket API, it really isn't that easy if > one > considers the more restrictive IPv4 socket API (recvfrom only returns > source > info, not destination info). I ran into this issue when I received the end > of > Ralph's text (section 16.2). I have no problem if we want to gamble on > this feature > being available on all IPv6 stacks (to obtain the IPv6 destination > address). > I added this comment after making many of the comments about the changes > needed to > make this an option below. So, depending on what we decide, the comments > below > regarding making this an option may need to be ignored. > > - Bernie > > -----Original Message----- > From: Ralph Droms [mailto:rdroms@cisco.com] > Sent: Tuesday, August 28, 2001 4:06 PM > To: dhcwg@ietf.org > Subject: [dhcwg] Changes to remove "client-link-local-address" from the > DHCPv6 header > > I've completed the changes to remove the client-link-local-address > field from the DHCP message header. Relay agents and servers will now > use the source address from the IP header to reply to client messages. > > The changes include: > > * Message format and descriptions in section 8 to remove the > client-link-local-address field > * Relay agent message format and descriptions in section 9 to > accommodate the client-return-address field > * Address selection described in section 12 to allow for unicast > client messages > * The description of client behavior in sections 13 and 14 > to remove the use of the client-link-local-address field and to > specify that the client must send the message through the interface > to be configure, to correctly set the source address in the IP > header > * The description of server behavior in sections 13 and 14 to remove > the use of the client-link-local-address and change the format of > the relay agent messages > * The description of relay behavior in section 15 based on the new > relay agent message format > > Note that the relay agent message has to include information about: > > 1. The return address to which the server should send the Relay-reply > message > 2. A link identifier/subnet selector that the server uses to select > configuration information for the client > 3. An interface identifier and return address for the client that the > relay agent uses to forward the message from the server back to the > client > > In DHCPv4, all of these functions are supplied by 'giaddr'. However, > the source address from the IP header isn't sufficient (which we had > discussed using for DHCPv6), because it may be awkward or impossible > (and, usually suboptimal) to force the message from the relay agent to > be sent to the server through the interface on which the message from > the client was received. So, I've retained the relay-address field > and added a client-return-address field in the Relay-forward for > 2. and 3., and specified that the server use the source address from > the IP header for 1. > > The text affected by these changes is included below. Please review > and follow up with comments. > > - Ralph > > ===== > > 8. Message Formats > > Each DHCP message has an identical fixed format header; some messages > also allow a variable format area for options. Not all fields in > the header are used in every message. In this section, every field > is described for every message and fields that are not used in a > message are marked as "unused". All unused fields in a message MUST > be transmitted as zeroes and ignored by the receiver of the message. > > The DHCP message header: > 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 | transaction-ID | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | server-address | > | (16 octets) | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > . options . > . (variable) . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > 8.1. DHCP Solicit Message Format > > msg-type SOLICIT > > transaction-ID An unsigned integer generated by the client used > to identify this Solicit message. > > server-address (unused) MUST be 0 > > options See section 18. > > 8.2. DHCP Advertise Message Format > > msg-type ADVERTISE > > transaction-ID An unsigned integer used to identify this > Advertise message. Copied from the client's > Solicit message. > > server-address The IP address of the server that generated > this message. If the DHCP domain crosses > site boundaries, then this address MUST be > globally-scoped. > > options See section 18. > > 8.3. DHCP Request Message Format > > msg-type REQUEST > > transaction-ID An unsigned integer generated by the client used > to identify this Request message. > > server-address The IP address of the server to which the this > message is directed, copied from an Advertise > message. > > options See section 18. > > 8.4. DHCP Confirm Message Format > > msg-type CONFIRM > > transaction-ID An unsigned integer generated by the client used > to identify this Confirm message. > > server-address MUST be zero. > > options See section 18. > > 8.5. DHCP Renew Message Format > > msg-type RENEW > > transaction-ID An unsigned integer generated by the client used > to identify this Renew message. > > server-address The IP address of the server to which this Renew > message is directed, which MUST be the address > of the server from which the IAs in this message > were originally assigned. > > options See section 18. > > 8.6. DHCP Rebind Message Format > > msg-type REBIND > > transaction-ID An unsigned integer generated by the client used > to identify this Rebind message. > > server-address MUST be zero. > > options See section 18. > > 8.7. DHCP Reply Message Format > > msg-type REPLY > > transaction-ID An unsigned integer used to identify this Reply > message. Copied from the client's Request, > Confirm, Renew or Rebind message. > > server-address The IP address of the server. If the DHCP domain > crosses site boundaries, then this address MUST > be globally-scoped. > > options See section 18. > > 8.8. DHCP Release Message Format > > msg-type RELEASE > > transaction-ID An unsigned integer generated by the client used > to identify this Release message. > > server-address The IP address of the server that assigned the > IA. > > options See section 18. > > 8.9. DHCP Decline Message Format > > msg-type DECLINE > > transaction-ID An unsigned integer generated by the client used > to identify this Decline message. > > server-address The IP address of the server that assigned the > addresses. > > options See section 18. > > 8.10. DHCP Reconfigure-init Message Format > > msg-type RECONFIG-INIT > > transaction-ID (unused) MUST be 0 > > 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. > > options See section 18. > > 9. Relay messages > > Relay agents exchange messages with servers to forward messages > between clients and servers that are not connected to the same link. > > 9.1. Relay-forward 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 | | > +-+-+-+-+-+-+-+-+ | > | | > | relay-address | > | | > | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > +-+-+-+-+-+-+-+-+ | > | | > | client-return-address | > | | > | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > +-+-+-+-+-+-+-+-+ | > . . > . options (variable number and length) .... . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > msg-type RELAY-FORW > > prefix-length The length of the prefix in the > address in the "relay-address" field. > BV> Drop prefix-length as not used. > > relay-address An address assigned to the interface > on which the message from the client > was received. > BV> See previous email from Ted and myself regarding the relay-address; > BV> we should make it an option since it won't always be needed (as the > BV> source IPv6 header address can be used in most cases). ALSO, see > BV> my intro to this message before making this change.) > > client-return-address The source address from the IP > datagram in which the message from the > client was received by the relay agent > > options MUST include a "Client message > option"; see section 18.7. > > 9.2. Relay-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 | | > +-+-+-+-+-+-+-+-+ | > | | > | relay-address | > | | > | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > +-+-+-+-+-+-+-+-+ | > | | > | client-return-address | > | | > | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| > +-+-+-+-+-+-+-+-+ | > . . > . options (variable number and length) .... . > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > msg-type RELAY-REPL > > prefix-length The length of the prefix in the address in the > "relay-address" field. > BV> Drop prefix-length as not used. > > relay-address An address identifying the interface on the > relay agent through which the message from the > server should be forwarded; copied from the > "relay-forward" message. > BV> See above (make an option). Note that the server MUST send this > BV> option back in the relay sent it in Relay-Forw. > > client-return-address The source address from the IP > datagram in which the message from the > client was received by the relay agent > > options MUST include a "Server message option"; see > section 18.8. > > 12. Selecting addresses for assignment to an IA > > A server selects addresses to be assigned to an IA according to the > address assignment policies determined by the server administrator > and the specific information the server determines about the client > from the following sources: > > - The link to which the client is attached: > > * If the server receives the message directly from the client > and the source address in the IP datagram in which the > message was received is a link-local address, then the client > is on the same link to which the interface over which the > message was received is attached > > * If the server receives the message directly from the client > and the source address in the IP datagram in which the > message was received is not link-local address, then the > client is on the link identified by the source address in the > IP datagram > > * If the server receives the message from a forwarding relay > agent, then the client is on the same link as the one to > which the interface identified by the relay-address field in > the message from the relay is attached > BV> This will need to be updated to reflect relay-address option (if no > BV> option, use source address else use relay-address option value). > > - The DUID supplied by the client > > - Other information in options supplied by the client > > - Other information in options supplied by the relay agent > > 13. DHCP Server Solicitation > > This section describes how a client locates servers. The behavior > of client and server implementations is discussed, along with the > messages they use. > > 13.1. Solicit Message Validation > > Clients MUST silently discard any received Solicit messages. > > 13.2. Advertise Message Validation > > Servers MUST discard any received Advertise messages. > > Clients MUST discard any received Advertise messages in which the > "Transaction-ID" field value does not match the value the client used > in its Solicit message. > > 13.3. Client Behavior > > A client uses the Solicit message to discover DHCP servers configured > to serve addresses on the link to which the client is attached. > > 13.3.1. Creation and sending of the Solicit message > > The client sets the "msg-type" field to SOLICIT. The client generates > a transaction ID and inserts this value in the "transaction-ID" > field. > > The client includes a DUID option to identify itself to the server. > The client MUST include options for any IAs to which it wants the > server to assign addresses. The client may include addresses in the > IAs as a hint to the server about addresses for which the client > may have a preference. The client MAY include an Option Request > Option in the Solicit message. The client MUST NOT include any other > options except those specifically allowed as defined by specific > options. > > The client sends the Solicit message to the 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. > > 13.4. Server Behavior > > A server sends an Advertise message in response to Solicit messages > it receives to announce the availability of the server to the client. > > 13.4.1. Receipt of Solicit messages > > The server determines the information about the client and its > location as described in section 12. If administrative policy > permits the server to respond to the client, the server will generate > and send an Advertise message to the client. > > 13.4.2. Creation and sending of Advertise messages > > The server sets the "msg-type" field to ADVERTISE and copies the > values of the transaction-ID field from the client's Solicit to the > BV> Drop "the values of" > Advertise message. > > The server places one of its IP addresses (determined through > administrator setting) in the "server-address" field of the Advertise > message. The server MAY add a Preference option to carry the > preference value for the Advertise message. > > The server implementation SHOULD allow the setting of a server > preference value by the administrator. The server preference value > MUST default to zero unless otherwise configured by the server > administrator. > > The server MUST include options to the Advertise message containing > any addresses that would be assigned to IAs contained in the Solicit > message from the client. If the server will not assign any addresses > to IAs in a subsequent Request from the client, the server MAY choose > to send an Advertise message to the client that includes no IA > options. The server MAY include other options the server will return > to the client in a subsequent Reply message. The information in > these options will be used by the client in the selection of a server > if the client receives more than one Advertise message. The server > SHOULD include options specifying values for options requested by the > client in an Option Request Option included in the Solicit message. > > If the Solicit message was received directly by the server, the > server unicasts the Advertise message directly to the client using > the address in the source address field from the IP datagram in > which the Solicit message was received. The Advertise message MUST > be unicast through the interface on which the Solicit message was > received. > > If the Solicit message was received in a Relay-forward message, > the server constructs a Relay-reply message with the Advertise > message in the payload of a "server-message" option. The server > unicasts the Relay-reply message directly to the relay agent using > the address in the source address field from the IP datagram in which > the Relay-forward message was received. > > 14. DHCP Client-Initiated Configuration Exchange > > A client initiates a message exchange with a server or servers to > acquire or update configuration information of interest. The client > may initiate the configuration exchange as part of the operating > system configuration process or when requested to do so by the > application layer. > > The client uses the following messages to initiate a configuration > event: > > Request Obtain initial configuration information (from a server > identified in a previously received Advertise message) > when the client has no assigned addresses > BV> Request may also be used at any time, not just "initial" configuration > > BV> information ... when the client has no assigned addresses. > > Confirm Confirm the validity of assigned addresses and other > configuration changes through the server from which the > BV> "configuration changes"? how about "configuration information". > configuration information was obtained when the client's > assigned addresses may not be valid; for example, when > the client reboots or loses its connection to a link > BV> also, this isn't just from the server from the info was obtained? > > Renew Extend the lease on an IA through the server that > originally assigned the IA > > Rebind Extend the lease on an IA through any server willing to > extend the lease > > Release Release the lease on an IA and release all of the > addresses contained in the IA, > BV> I think we still have open whether all or some address can be > released. > > Decline Decline the assignment of one or more addresses in an > IA. > > A client uses the Release/Reply message exchange to indicate to the > DHCP server that the client will no longer be using the addresses in > the released IA. > BV> Why have this? Isn't this already covered by the above entry for > Release? > > A client uses the Decline/Reply message exchange to indicate to the > DHCP server that the client has detected that one or more addresses > assigned by the server is already in use on the client's link. > BV> Why have this? Same as release. > > 14.1. Client Message Validation > > Clients MUST silently discard any received client messages (Request, > Confirm, Renew, Rebind, Release or Decline messages). > > Servers MUST discard any received client messages in which the > "options" field contains an authentication option, and the server > cannot successfully authenticate the client. > > Servers MUST discard any received Request, Renew, Release or Decline > message in which the "server-address" field value does not match any > of the server's addresses. > > 14.2. Server Message Validation > > Servers MUST silently discard any received server messages > (Advertise, Reply or Reconfigure-init messages). > > Clients MUST discard any server messages that meet any of the > following criteria: > > o The "transaction-ID" field value in the server message does > not match the value the client used in its Request or Release > message. > BV> This should apply to all client messages, not just Request/Release. > > o The server message contains an authentication option, and the > client's attempt to authenticate the message fails. > > Relays MUST discard any Relay-reply message in which the > "client-link-local-address" field in the Relay-reply message does not > contain a valid link-local address. > BV> This is now the "client-return-address" and does it really need to > BV> only be a link-local address? I don't think so (though it likely will > BV> mostly be link-local). > > 14.3. Client Behavior > > A client will use Request, Confirm, Renew and Rebind messages to > acquire and confirm the validity of 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 address information from > previous Advertise message(s) for use in constructing Request and > Renew 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 IAs when > the client has been instructed to release the IA prior to the IA > expiration time since it is no longer needed. > > A client uses the Decline message when the client has determined > through DAD or some other method that one or more of the addresses > assigned by the server in the IA is already in use by a different > client. > > 14.3.1. Creation and sending of Request messages > > If a client has no valid IPv6 addresses of sufficient scope to > communicate with a DHCP server, it may send a Request message to > BV> Why "communicate with a DHCP server"? And the client could well > BV> have many addresses of sufficient scope - that's not the point > BV> of the request. We really should just say that "If the client > BV> is using stateful address configuration and either needs an > BV> initial set of address or additional addresses, it MUST send a > BV> Request message to obtain new addresses." (or something like that) > obtain new addresses. The client includes one or more IAs in the > Request message, to which the server assigns new addresses. The > server then returns IA(s) to the client in a Reply message. > > The client generates a transaction ID and inserts this value in the > "transaction-ID" field. > > The client places the address of the destination server in the > "server-address" field. > BV> How about "The client copies the "server-address" field as received in > > BV> the selected Advertise message to the "server-address" field of the > BV> Request." > > The client adds a DUID option to identify itself to the server. The > client adds any other appropriate options, including one or more IA > options (if the client is requesting that the server assign it some > network addresses). The list of addresses in each included IA MUST > be empty. If the client is not requesting that the server assign it > BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't > BV> it that people wanted the addresses received in the Advertise to be > BV> used here? > any addresses, the client omits the IA option. > > The client sends the Request message to the All DHCP Agents multicast > address through the interface for which the client is interested in > obtaining configuration information, with the destination port set > to 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. > > The server will respond to the Request message with a Reply > message. If no Reply message is received within REP_MSG_TIMEOUT > milliseconds, 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 7.5. > > 14.3.2. Creation and sending of Confirm messages > > Whenever a client may have moved to a new link, its IPv6 addresses > may no longer be valid. Examples of times when a client may have > moved to a new link include: > > o The client reboots > > o The client is physically disconnected from a wired connection > > o The client returns from sleep mode > > o The client using a wireless technology changes cells > > In any situation when a client may have moved to a new link, the > client MUST initiate a Confirm/Reply message exchange. The client > includes any IAs, along with the addresses associated with those IAs, > in its Confirm message. Any responding servers will indicate the > acceptability of the addresses with the status in the IA it returns > to the client. > > The client sets the "msg-type" field to CONFIRM. The client generates > a transaction ID and inserts this value in the "transaction-ID" > field. > > The client sets the "server-address" field to 0. > > The client adds a DUID option to identify itself to the server. The > client adds any appropriate options, including one or more IA options > (if the client is requesting that the server confirm the validity of > some network addresses). If the client does include any IA options, > it MUST include the list of addresses the client currently has > associated with that IA. > > The client sends the Confirm message to the All DHCP Agents multicast > address through the interface for which the client is interested in > obtaining configuration information, with the destination port set > to 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. > > Servers will respond to the Confirm message with a Reply message. If > no Confirm message is received within REP_MSG_TIMEOUT milliseconds, > the client retransmits the Confirm 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 QRY_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 QRY_MSG_ATTEMPTS > are documented in section 7.5. > > If the client receives no response to its Confirm message, it MAY > restart the configuration process by locating a DHCP server with an > Advertise message and sending a Request to that server, as described > in section 14.3.1. > > 14.3.3. Creation and sending of Renew messages > > IPv6 addresses assigned to a client through an IA use the same > preferred and valid lifetimes as IPv6 addresses obtained through > stateless autoconfiguration. The server assigns preferred and valid > lifetimes to the IPv6 addresses it assigns to an IA. To extend those > lifetimes, the client sends a Request to the server containing an > "IA option" for the IA and its associated addresses. The server > determines new lifetimes for the addresses in the IA according to > the server's administrative configuration. The server may also add > new addresses to the IA. The server remove addresses from the IA by > BV> The server [may] remove addresses from the IA by ... > setting the preferred and valid lifetimes of those addresses to zero. > > The server controls the time at which the client contacts the server > to extend the lifetimes on assigned addresses through the T1 and > T2 parameters assigned to an IA. If the server does not assign an > explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the > shortest preferred lifetime of any address assigned to the IA and > T2 defaults to 0.875 times the shortest preferred lifetime of any > address assigned to the IA. > BV> The above will be reworked in new material Mark, Ted, and I should be > BV> providing. > > At time T1 for an IA, the client initiates a Request/Reply message > exchange to extend the lifetimes on any addresses in the IA. The > client includes an IA option with all addresses currently assigned to > the IA in its Request message. > > The client sets the "msg-type" field to RENEW. The client generates a > transaction ID and inserts this value in the "transaction-ID" field. > > The client places the address of the destination server in the > "server-address" field. > > The client adds a DUID option to identify itself to the server. The > client adds any appropriate options, including one or more IA options > (if the client is requesting that the server extend the lease on some > IAs; note that the client may check the status of other configuration > parameters without asking for lease extensions). If the client does > include any IA options, it MUST include the list of addresses the > client currently has associated with that IA. > > The client sends the Renew message to the All DHCP Agents multicast > address through the interface for which the client is interested in > obtaining configuration information, with the destination port set > to 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. > > The server will respond to the Renew message with a Reply message. > If no Reply message is received within REP_MSG_TIMEOUT milliseconds, > the client retransmits the Renew 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 until time T2 is > reached (see section 14.3.4). > > Default and initial values for REP_MSG_TIMEOUT are documented in > section 7.5. > > 14.3.4. Creation and sending of Rebind messages > > At time T2 for an IA (which will only be reached if the server to > which the Renew message was sent at time T1 has not responded), > the client initiates a Rebind/Reply message exchange. The client > includes an IA option with all addresses currently assigned to the IA > in its Rebind message. The client sends this message to the All DHCP > Agents multicast address. > > The client sets the "msg-type" field to REBIND. The client generates > a transaction ID inserts this value in the "transaction-ID" field. > > The client sets the "server-address" field to 0. > > The client adds a DUID option to identify itself to the server. > The client adds any appropriate options, including one or more IA > options. If the client does include any IA options (if the client is > requesting that the server extend the lease on some IAs; note that > the client may check the status of other configuration parameters > without asking for lease extensions), it MUST include the list of > addresses the client currently has associated with that IA. > > The client sends the Rebind message to the All DHCP Agents multicast > address through the interface for which the client is interested in > obtaining configuration information, with the destination port set > to 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. > > The server will respond to the Rebind message with a Reply message. > If no Reply message is received within REP_MSG_TIMEOUT milliseconds, > the client retransmits the Rebind 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. > > Default and initial values for REP_MSG_TIMEOUT are documented in > section 7.5. > > The client has several alternatives to choose from if it receives no > response to its Rebind message. > > - When the lease on the IA expires, the client may choose to use a > Solicit message to locate a new DHCP server and send a Request > for the expired IA to the new server > > - Some addresses in the IA may have lifetimes that extend beyond > the lease of the IA, so the client may choose to continue to use > those addresses; once all of the addresses have expired, the > client may choose to locate a new DHCP server > > - The client may have other addresses in other IAs, so the client > may choose to discard the expired IA and use the addresses in the > other IAs > > 14.3.5 (omitted) > > 14.3.6. Creation and sending of Release messages > > The client sets the "msg-type" field to RELEASE. The client generates > a transaction ID and places this value in the "transaction-ID" field. > > The client places the IP address of the server that allocated the > address(es) in the "server-address" field. > > The client adds a DUID option to identify itself to the server. The > client includes options containing the IAs it is releasing in the > "options" field. The addresses to be released MUST be included in > the IAs. The appropriate "status" field in the options MUST be set > to indicate the reason for the release. > > If the client is configured to use authentication, the client > generates the appropriate authentication option, and adds this option > to the "options" field. Note that the authentication option MUST be > the last option in the "options" field. See section 18.11 for more > details about the authentication option. > > The client sends the Release message to the All DHCP Agents multicast > address through the interface for which the client is interested in > obtaining configuration information, with the destination port set > to 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. > > 14.3.7. (Omitted) > > 14.3.8. (Omitted) > > 14.3.9. Creation and sending of Decline messages > > The client sets the "msg-type" field to DECLINE. The client generates > a transaction ID and places this value in the "transaction-ID" field. > > The client places the IP address of the server that allocated the > address(es) in the "server-address" field. > > The client adds a DUID option to identify itself to the server. The > client includes options containing the IAs it is declining in the > "options" field. The addresses to be released MUST be included in > the IAs. The appropriate "status" field in the options MUST be set > to indicate the reason for declining the address. > > If the client is configured to use authentication, the client > generates the appropriate authentication option, and adds this option > to the "options" field. Note that the authentication option MUST be > the last option in the "options" field. See section 18.11 for more > details about the authentication option. > > The client sends the Decline message to the All DHCP Agents multicast > address through the interface for which the client is interested in > obtaining configuration information, with the destination port set > to 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. > > 14.3.10. (Omitted) > > If no Reply message is received within REP_MSG_TIMEOUT milliseconds, > the client retransmits the Decline, 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 attempt to > decline the address. 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 7.5. > > 14.3.11. Receipt of Reply message in response to a Release message > > 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. > BV> This section should replace Release with Decline (Section 14.3.8 > BV> covers the Release case). No need for application layer to be told > BV> about Declines? > > 14.4. Server Behavior > > For this discussion, the Server is assumed to have been configured in > an implementation specific manner with configuration of interest to > clients. > > 14.4.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 options field. > > The server then constructs a Reply message and sends it to the > client. > > The server SHOULD process each option for the client in an > implementation-specific manner. The server MUST construct a Reply > message containing the following values: > > msg-type REPLY > > transaction-ID The transaction-ID from the Request message. > > server address One of the IP addresses assigned to the interface > through which the server received the message > from the client. > > When the server receives a Request and IA option is included the > client is requesting the configuration of a new IA by the server. > BV> We need to clarify this behavoir and what "new" means (may be cases > BV> where client thinks it is new, but server already knows about it). > The server MUST take the clients IA and associate a binding for that > client in an implementation-specific manner within the server's > configuration parameter database for DHCP clients. > > If the server cannot provide addresses to the client it SHOULD send > back an empty IA to the client with the status field set to Unavail. > > If the server can provide addresses to the client it MUST send back > the IA to the client with all fields entered and a status of Success, > and add the IA as a new client binding. > > The server adds options to the Reply message for any other > configuration information to be assigned to the client. > > 14.4.2. Receipt of Confirm messages > > Upon the receipt of a valid Confirm message from a client the server > can respond to, (implementation-specific administrative policy > satisfied) the server scans the options field. > > The server then constructs a Reply message and sends it to the > client. > > The server SHOULD process each option for the client in an > implementation-specific manner. The server MUST construct a Reply > message containing the following values: > > msg-type REPLY > > transaction-ID The transaction-ID from the Confirm message. > > server address One of the IP addresses assigned to the interface > through which the server received the message > from the client. > > When the server receives a Confirm and an IA option is included the > client is requesting confirmation that the addresses in the IA are > valid. The server SHOULD locate the clients binding and verify the > information in the IA from the client matches the information stored > for that client. > > If the server cannot find a client entry for this IA the server > SHOULD return an empty IA with status set to NoBinding. > > If the server finds that the information for the client does not > match what is in the server's records for that client the server > should send back an empty IA with status set to Conf_NoMatch. > > If the server finds a match to the Confirm then the server should > send back the IA to the client with status set to success. > > 14.4.3. Receipt of Renew messages > > Upon the receipt of a valid Renew message from a client the server > can respond to, (implementation-specific administrative policy > satisfied) the server scans the options field. > > The server then constructs a Reply message and sends it to the > client. > > The server SHOULD process each option for the client in an > implementation-specific manner. The server MUST construct a Reply > message containing the following values: > > msg-type REPLY > > transaction-ID The transaction-ID from the Confirm message. > > server address One of the IP addresses assigned to the interface > through which the server received the message > from the client. > > When the server receives a Renew and IA option from a client it > SHOULD locate the clients binding and verify the information in the > IA from the client matches the information stored for that client. > > If the server cannot find a client entry for this IA the server > SHOULD return an empty IA with status set to NoBinding. > > If the server finds that the addresses in the IA for the client do > not match the clients binding the server should return an empty IA > with status set to Renw_NoMatch. > > If the server cannot Renew addresses for the client it SHOULD send > back an empty IA to the client with the status field set to Unavail. > > If the server finds the addresses in the IA for the client then the > server SHOULD send back the IA to the client with new lease times > and T1/T2 times if the default is not being used, and set status to > Success. > > 14.4.4. Receipt of Rebind messages > > Upon the receipt of a valid Rebind message from a client the server > can respond to, (implementation-specific administrative policy > satisfied) the server scans the options field. > > The server then constructs a Reply message and sends it to the > client. > > The server SHOULD process each option for the client in an > implementation-specific manner. The server MUST construct a Reply > message containing the following values: > > msg-type REPLY > > transaction-ID The transaction-ID from the Confirm message. > > server address One of the IP addresses assigned to the interface > through which the server received the message > from the client. > > When the server receives a Rebind and IA option from a client it > SHOULD locate the clients binding and verify the information in the > IA from the client matches the information stored for that client. > > If the server cannot find a client entry for this IA the server > SHOULD return an empty IA with status set to NoBinding. > > If the server finds that the addresses in the IA for the client do > not match the clients binding the server should return an empty IA > with status set to Rebd_NoMatch. > > If the server cannot Rebind addresses for the client it SHOULD send > back an empty IA to the client with the status field set to Unavail. > > If the server finds the addresses in the IA for the client then the > server SHOULD send back the IA to the client with new lease times > and T1/T2 times if the default is not being used, and set status to > Success. > > There is a significant difference between Renew and Rebind messages: > Because the Rebind message is processed by a single server, the > responding server can actually change the addresses in the IA. > However, because multiple servers may respond to a Rebind, all they > can safely do is update T1, T2 (for the IA) and lifetimes (for > individual addresses). > > 14.4.5. Receipt of Release messages > > Upon the receipt of a valid Release message, the server examines the > IAs and the addresses in the IAs for validity. If the IAs in the > message are in a binding for the client and the addresses in the IAs > have been assigned by the server to those IA, the server deletes > the addresses from the IAs and makes the addresses available for > assignment to other clients. > > The server then generates a Reply message. If all of the IAs were > valid and the addresses successfully released,, the server sets the > "status" field to "Success". If any of the IAs were invalid or if > any of the addresses were not successfully released, the server > releases none of the addresses in the message and sets the "status" > field to "NoBinding"(section 7.4). > > If the client successfully releases some but not all of the addresses > in an IA, the IA continues to exist and holds the remaining, > unreleased addresses. > > A client can send an option containing an IA with no listed addresses > to release implicitly all of the addresses in the IA. > > A server is not required to (but may choose to as an implementation > strategy) retain any record of an IA from which all of the addresses > have been released. > > 14.4.6. Sending of Reply messages > > If the Request, Confirm, Renew, Rebind or Release message from > BV> What about Decline messages (add to list). > the client was originally received was originally received in a > BV> typo - duplicated "was originally received". > Relay-forward message from a relay, the server places the Reply > message in the options field of a Relay-response message and copies > the relay-address and client-link-local-address fields from the > BV> client-return-address > Relay-forward message into the Relay-response message. > > The server then unicasts the Reply or Relay-reply to the source > address from the IP datagram in which the original message was > received. > > 16. Relay Behavior > > For this discussion, the Relay may be configured to use a list of > server destination addresses, which may include unicast addresses, > the All DHCP Servers multicast address, or other multicast addresses > selected by the network administrator. If the Relay has not been > explicitly configured, it MUST use the All DHCP Servers multicast > address as the default. > > 16.1. Relaying of client messages > > When a Relay receives a valid client message, it constructs > a Relay-forward message. The relay places an address from > the interface on which the client message was received in the > "relay-address" field. This address will be used by the server to > identify the link to which the client is connected and will be used > by the relay to forward the Advertise message from the server back to > the client. > > The relay copies the source address from the IP datagram > in which the message was received from the client into the > client-link-local-address field in the Relay-forward message. > BV> client-return-address > > The relay constructs a "client-message" option 18.7 that contains > the entire message from the client in the data field of the > option. The relay places the "relay-message" option along with any > "relay-specific" options in the options field of the Relay-forward > message. The Relay then sends the Relay-forward message to the list > of server destination addresses that it has been configured with. > > 16.2. Relaying of server messages > > When the relay receives a Relay-reply message, it extracts the server > message from the "server-message" option and forwards the message to > the address in the client-link-local-address field in the Relay-reply > BV> client-returnn-address > message. The relay forwards the server message through the interface > identified in the "relay-address" field in the Relay-reply message. > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > http://www1.ietf.org/mailman/listinfo/dhcwg -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Aug 29 19:50:17 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13574; Wed, 29 Aug 2001 19:50:17 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00054; Wed, 29 Aug 2001 19:49:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA00032 for ; Wed, 29 Aug 2001 19:49:01 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13558 for ; Wed, 29 Aug 2001 19:47:41 -0400 (EDT) Received: from rdroms-w2k.cisco.com (sjc-vpn2-178.cisco.com [10.21.112.178]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA24060; Wed, 29 Aug 2001 19:48:27 -0400 (EDT) Message-Id: <4.3.2.7.2.20010829194352.01ce3008@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 29 Aug 2001 19:45:29 -0400 To: "Bernie Volz (EUD)" From: Ralph Droms Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Cc: dhcwg@ietf.org In-Reply-To: <66F66129A77AD411B76200508B65AC697B34C2@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie, Thanks for you careful review of the new text. I made all of the changes you suggested, except as noted below (RD>) - Ralph 14.3.1. Creation and sending of Request messages If a client has no valid IPv6 addresses of sufficient scope to communicate with a DHCP server, it may send a Request message to BV> Why "communicate with a DHCP server"? And the client could well BV> have many addresses of sufficient scope - that's not the point BV> of the request. We really should just say that "If the client BV> is using stateful address configuration and either needs an BV> initial set of address or additional addresses, it MUST send a BV> Request message to obtain new addresses." (or something like that) obtain new addresses. The client includes one or more IAs in the Request message, to which the server assigns new addresses. The server then returns IA(s) to the client in a Reply message. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. BV> How about "The client copies the "server-address" field as received in BV> the selected Advertise message to the "server-address" field of the BV> Request." RD> Why the change? The client adds a DUID option to identify itself to the server. The client adds any other appropriate options, including one or more IA options (if the client is requesting that the server assign it some network addresses). The list of addresses in each included IA MUST be empty. If the client is not requesting that the server assign it BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't BV> it that people wanted the addresses received in the Advertise to be BV> used here? RD> I leave this for the IA option and semantics design. any addresses, the client omits the IA option. The client sends the Request message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. The server will respond to the Request message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 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 7.5. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 09:19:55 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15671; Thu, 30 Aug 2001 09:19:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27517; Thu, 30 Aug 2001 09:17:05 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA27497 for ; Thu, 30 Aug 2001 09:17:04 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15500 for ; Thu, 30 Aug 2001 09:15:43 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7UDH4p03097 for ; Thu, 30 Aug 2001 08:17:04 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7UDH4O20530 for ; Thu, 30 Aug 2001 08:17:04 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Aug 30 08:17:03 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 08:17:03 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34CC@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , "Bernie Volz (EUD)" Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Date: Thu, 30 Aug 2001 08:17:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13156.0ED086A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13156.0ED086A0 Content-Type: text/plain; charset="iso-8859-1" Ralph: RD> Why the change? Just thought it was clearer where the server address comes from. RD> I leave this for the IA option and semantics design. No problem. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Wednesday, August 29, 2001 7:45 PM To: Bernie Volz (EUD) Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Bernie, Thanks for you careful review of the new text. I made all of the changes you suggested, except as noted below (RD>) - Ralph 14.3.1. Creation and sending of Request messages If a client has no valid IPv6 addresses of sufficient scope to communicate with a DHCP server, it may send a Request message to BV> Why "communicate with a DHCP server"? And the client could well BV> have many addresses of sufficient scope - that's not the point BV> of the request. We really should just say that "If the client BV> is using stateful address configuration and either needs an BV> initial set of address or additional addresses, it MUST send a BV> Request message to obtain new addresses." (or something like that) obtain new addresses. The client includes one or more IAs in the Request message, to which the server assigns new addresses. The server then returns IA(s) to the client in a Reply message. The client generates a transaction ID and inserts this value in the "transaction-ID" field. The client places the address of the destination server in the "server-address" field. BV> How about "The client copies the "server-address" field as received in BV> the selected Advertise message to the "server-address" field of the BV> Request." RD> Why the change? The client adds a DUID option to identify itself to the server. The client adds any other appropriate options, including one or more IA options (if the client is requesting that the server assign it some network addresses). The list of addresses in each included IA MUST be empty. If the client is not requesting that the server assign it BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't BV> it that people wanted the addresses received in the Advertise to be BV> used here? RD> I leave this for the IA option and semantics design. any addresses, the client omits the IA option. The client sends the Request message to the All DHCP Agents multicast address through the interface for which the client is interested in obtaining configuration information, with the destination port set to 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. The server will respond to the Request message with a Reply message. If no Reply message is received within REP_MSG_TIMEOUT milliseconds, 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 7.5. ------_=_NextPart_001_01C13156.0ED086A0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header

Ralph:

RD> Why the change?

Just thought it was clearer where the server address comes from.

RD> I leave this for the IA option and semantics design.

No problem.

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Wednesday, August 29, 2001 7:45 PM
To: Bernie Volz (EUD)
Cc: dhcwg@ietf.org
Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from
th e DHCPv6 header


Bernie,

Thanks for you careful review of the new text.  I made all
of the changes you suggested, except as noted below (RD>)

- Ralph

14.3.1. Creation and sending of Request messages

   If a client has no valid IPv6 addresses of sufficient scope to
   communicate with a DHCP server, it may send a Request message to
BV> Why "communicate with a DHCP server"? And the client could well
BV> have many addresses of sufficient scope - that's not the point
BV> of the request. We really should just say that "If the client
BV> is using stateful address configuration and either needs an
BV> initial set of address or additional addresses, it MUST send a
BV> Request message to obtain new addresses." (or something like that)
   obtain new addresses.  The client includes one or more IAs in the
   Request message, to which the server assigns new addresses.  The
   server then returns IA(s) to the client in a Reply message.

   The client generates a transaction ID and inserts this value in the
   "transaction-ID" field.

   The client places the address of the destination server in the
   "server-address" field.
BV> How about "The client copies the "server-address" field as received in
BV> the selected Advertise message to the "server-address" field of the
BV> Request."

RD> Why the change?

   The client adds a DUID option to identify itself to the server.  The
   client adds any other appropriate options, including one or more IA
   options (if the client is requesting that the server assign it some
   network addresses).  The list of addresses in each included IA MUST
   be empty.  If the client is not requesting that the server assign it
BV> IA MUST be empty? This wasn't what we had been discussing?? Wasn't
BV> it that people wanted the addresses received in the Advertise to be
BV> used here?

RD> I leave this for the IA option and semantics design.

   any addresses, the client omits the IA option.

   The client sends the Request message to the All DHCP Agents multicast
   address through the interface for which the client is interested in
   obtaining configuration information, with the destination port set
   to 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.

   The server will respond to the Request message with a Reply
   message.  If no Reply message is received within REP_MSG_TIMEOUT
   milliseconds, 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 7.5.

------_=_NextPart_001_01C13156.0ED086A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 09:47:46 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA16874; Thu, 30 Aug 2001 09:47:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA28166; Thu, 30 Aug 2001 09:43:22 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA24004 for ; Thu, 30 Aug 2001 07:22:33 -0400 (EDT) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10209 for ; Thu, 30 Aug 2001 07:21:14 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by mail.bucknell.edu (8.11.4/8.11.4) with ESMTP id f7UBMWq01094 for ; Thu, 30 Aug 2001 07:22: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 HAA10196; Thu, 30 Aug 2001 07:21:09 -0400 (EDT) Message-Id: <200108301121.HAA10196@ietf.org> To: IETF-Announce: ; Cc: RFC Editor Cc: Internet Architecture Board Cc: dhcp-v4@bucknell.edu From: The IESG Date: Thu, 30 Aug 2001 07:21:09 -0400 Subject: [dhcwg] Protocol Action: DHCP reconfigure extension to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org The IESG has approved the Internet-Draft 'DHCP reconfigure extension' as a Proposed Standard. This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This draft defines extensions to DHCP [RFC 2131] to allow dynamic reconfiguration of a single host triggered by the DHCP server (e.g., a new IP address). This is achieved by introducing a unicast FORCERENEW message that forces the client into the RENEW state. The behaviour for hosts using the DHCP INFORM message to obtain configuration information is also described. Working Group Summary There has been support for this document in the WG for sometime, and the document has been waiting for the DHCP authentication document to complete, as the FORCERENEW messages is ignored unless authenticated. No issues were raised during the IETF Last Call. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 10:37:59 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18560; Thu, 30 Aug 2001 10:37:55 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29564; Thu, 30 Aug 2001 10:36:19 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29545 for ; Thu, 30 Aug 2001 10:36:18 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18445 for ; Thu, 30 Aug 2001 10:34:57 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7UEUPf15495; Thu, 30 Aug 2001 07:30:25 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7UEaEl00456; Thu, 30 Aug 2001 10:36:14 -0400 (EDT) Message-Id: <200108301436.f7UEaEl00456@grosse.bisbee.fugue.com> To: Josh Littlefield cc: "Bernie Volz (EUD)" , "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header In-Reply-To: Message from Josh Littlefield of "Wed, 29 Aug 2001 16:30:17 EDT." <3B8D50D9.D86E9BF7@cisco.com> Date: Thu, 30 Aug 2001 10:36:14 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > I believe if the relay is using the simple API and it must specify the right > source address, then the relay will need to send through a socket which is > bound to the desired local address. I believe it will also receive its > response through that bound socket, so learning the responses packet's > destination address is accomplished by noticing the socket through which it > arrived. So, its doable with the simple API, though I think its a bit more > complexity than you'd want relays to have to implement. > > As you note below, if using the advanced API, then specifying the source > address on sending and learning the destination address on receiving is > easier, and is almost as easy as writing a the relay's local address into a > fixed place in the packet, but not quite. This is kind of a strange thing. If you need the functionality of the advanced API, why not use the advanced API? > I think the explicit specification of a relay-address is needed in cases > where either the relay has no global address on the proper interface (and > thus needs to indicate a prefix-only address, which should work just fine), > or where specifying the source address may complicate the packet's route out > of the relay (this is speculation). If a relay must detect one of these > conditions, then it complicates the relay, or encourages relay authors to > opt for the safer solution and always use the option (in which case it isn't > optional in a practical sense). I think the DHCP server should be using the prefix that the relay reports when doing address assignments, not the IP address that the relay reports. Maybe I'm missing something here - are we back to overloading these two functions? _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 11:00:16 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18953; Thu, 30 Aug 2001 11:00:12 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29981; Thu, 30 Aug 2001 10:58:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA29955 for ; Thu, 30 Aug 2001 10:58:52 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18899 for ; Thu, 30 Aug 2001 10:57:32 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id KAA15392 for ; Thu, 30 Aug 2001 10:58:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20010830104633.03d33f08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Aug 2001 10:58:18 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header In-Reply-To: <200108301436.f7UEaEl00456@grosse.bisbee.fugue.com> References: <3B8D50D9.D86E9BF7@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org At 10:36 AM 8/30/2001 -0400, Ted Lemon wrote: >> I think the explicit specification of a relay-address is needed in cases >> where either the relay has no global address on the proper interface (and >> thus needs to indicate a prefix-only address, which should work just fine), >> or where specifying the source address may complicate the packet's route out >> of the relay (this is speculation). If a relay must detect one of these >> conditions, then it complicates the relay, or encourages relay authors to >> opt for the safer solution and always use the option (in which case it isn't >> optional in a practical sense). > >I think the DHCP server should be using the prefix that the relay >reports when doing address assignments, not the IP address that the >relay reports. Maybe I'm missing something here - are we back to >overloading these two functions? > > _MelloN_ Suppose the field name and definition are changed as in the figure below, and: * The server chooses an address for the client based on the link-prefix (details TBD; could use 0s to indicate prefix length or include explicit prefix length or ???) * The server sends the Relay-reply message to the source address in the IP header of the Relay-forward message * The relay forwards the Reply message to the client on the link identified by the link-prefix This proposal still overloads the identification of the link on which the relay forward the Reply to the client with the selection of an address for the client by the server. We could either add a separate field for specifying a prefix for address selection or define an option (like the DHCPv4 subnet selection option). I would be inclined to define an option that might be used by either a client or a relay (or both?). - Ralph ===== 9.1. Relay-forward 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 | | +-+-+-+-+-+-+-+-+ | | link-prefix | | | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | | | | client-return-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-FORW link-prefix A prefix assigned to the link from which the client message was received. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Client message option"; see section 18.7. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 11:18:35 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19395; Thu, 30 Aug 2001 11:18:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00574; Thu, 30 Aug 2001 11:16:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA00555 for ; Thu, 30 Aug 2001 11:16:11 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19337 for ; Thu, 30 Aug 2001 11:14:51 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7UFAKf15565; Thu, 30 Aug 2001 08:10:20 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7UFG6l00557; Thu, 30 Aug 2001 11:16:06 -0400 (EDT) Message-Id: <200108301516.f7UFG6l00557@grosse.bisbee.fugue.com> To: Ralph Droms cc: dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header In-Reply-To: Message from Ralph Droms of "Thu, 30 Aug 2001 10:58:18 EDT." <4.3.2.7.2.20010830104633.03d33f08@funnel.cisco.com> Date: Thu, 30 Aug 2001 11:16:06 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > This proposal still overloads the identification of the link > on which the relay forward the Reply to the client with the > selection of an address for the client by the server. We > could either add a separate field for specifying a prefix > for address selection or define an option (like the DHCPv4 > subnet selection option). I would be inclined to define > an option that might be used by either a client or a > relay (or both?). Sounds reasonable. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 11:37:57 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19818; Thu, 30 Aug 2001 11:37:56 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01274; Thu, 30 Aug 2001 11:37:03 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA01202 for ; Thu, 30 Aug 2001 11:36:59 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19749 for ; Thu, 30 Aug 2001 11:35:39 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7UFb0p15979 for ; Thu, 30 Aug 2001 10:37:01 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7UFb0O22372 for ; Thu, 30 Aug 2001 10:37:00 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Aug 30 10:37:00 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 10:37:00 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34D3@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Date: Thu, 30 Aug 2001 10:36:57 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13169.9A6B60A0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13169.9A6B60A0 Content-Type: text/plain; charset="iso-8859-1" Just to be clear, there are three pieces of information: 1. The address used to communicate with the relay. 2. The link on which the client's packet was received. 3. The prefix to be used for address assignment for the client. I think 1 is easy and it should just be the IPv6 source address of the Relay-Forw. In many cases 2 and 3 are the same but they need not be. I would suggest we solve this by doing the following: For 3, the relay should send a prefix and prefix-length. For 2, the relay can either use 3 or provide some other means of identifying this information. It may not be an address - it could just be an interface id or some other opaque info. So, I suggest that for 2, we simply have an "Interface-ID" option which is whatever the relay wants it to be. The server should treat it as opaque and simply echo it back to the relay. If the relay doesn't need it (because the info in (3) is sufficient), it need not provide this option. Relay-Interface-ID Option: 2-byte option id 2-byte option length data - interface ID - whatever the relay wants For example, a relay could simply send 1 byte of data which is the interface number. Or, it could send 16 bytes to represent an address of the interface. - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, August 30, 2001 10:58 AM To: dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header At 10:36 AM 8/30/2001 -0400, Ted Lemon wrote: >> I think the explicit specification of a relay-address is needed in cases >> where either the relay has no global address on the proper interface (and >> thus needs to indicate a prefix-only address, which should work just fine), >> or where specifying the source address may complicate the packet's route out >> of the relay (this is speculation). If a relay must detect one of these >> conditions, then it complicates the relay, or encourages relay authors to >> opt for the safer solution and always use the option (in which case it isn't >> optional in a practical sense). > >I think the DHCP server should be using the prefix that the relay >reports when doing address assignments, not the IP address that the >relay reports. Maybe I'm missing something here - are we back to >overloading these two functions? > > _MelloN_ Suppose the field name and definition are changed as in the figure below, and: * The server chooses an address for the client based on the link-prefix (details TBD; could use 0s to indicate prefix length or include explicit prefix length or ???) * The server sends the Relay-reply message to the source address in the IP header of the Relay-forward message * The relay forwards the Reply message to the client on the link identified by the link-prefix This proposal still overloads the identification of the link on which the relay forward the Reply to the client with the selection of an address for the client by the server. We could either add a separate field for specifying a prefix for address selection or define an option (like the DHCPv4 subnet selection option). I would be inclined to define an option that might be used by either a client or a relay (or both?). - Ralph ===== 9.1. Relay-forward 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 | | +-+-+-+-+-+-+-+-+ | | link-prefix | | | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | | | | client-return-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-FORW link-prefix A prefix assigned to the link from which the client message was received. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Client message option"; see section 18.7. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C13169.9A6B60A0 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header

Just to be clear, there are three pieces of information:

1. The address used to communicate with the relay.
2. The link on which the client's packet was received.
3. The prefix to be used for address assignment for the client.

I think 1 is easy and it should just be the IPv6 source address of the Relay-Forw.

In many cases 2 and 3 are the same but they need not be. I would suggest we solve
this by doing the following:

For 3, the relay should send a prefix and prefix-length.

For 2, the relay can either use 3 or provide some other means of identifying this
information. It may not be an address - it could just be an interface id or some
other opaque info. So, I suggest that for 2, we simply have an "Interface-ID" option
which is whatever the relay wants it to be. The server should treat it as opaque
and simply echo it back to the relay. If the relay doesn't need it (because the
info in (3) is sufficient), it need not provide this option.

Relay-Interface-ID Option:

        2-byte option id
        2-byte option length
        data - interface ID - whatever the relay wants

For example, a relay could simply send 1 byte of data which is the interface number.
Or, it could send 16 bytes to represent an address of the interface.


- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, August 30, 2001 10:58 AM
To: dhcwg@ietf.org
Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from
the DHCPv6 header


At 10:36 AM 8/30/2001 -0400, Ted Lemon wrote:
>> I think the explicit specification of a relay-address is needed in cases
>> where either the relay has no global address on the proper interface (and
>> thus needs to indicate a prefix-only address, which should work just fine),
>> or where specifying the source address may complicate the packet's route out
>> of the relay (this is speculation).  If a relay must detect one of these
>> conditions, then it complicates the relay, or encourages relay authors to
>> opt for the safer solution and always use the option (in which case it isn't
>> optional in a practical sense).
>
>I think the DHCP server should be using the prefix that the relay
>reports when doing address assignments, not the IP address that the
>relay reports.   Maybe I'm missing something here - are we back to
>overloading these two functions?
>
>                               _MelloN_


Suppose the field name and definition are changed as in the figure below,
and:

* The server chooses an address for the client
  based on the link-prefix (details TBD; could
  use 0s to indicate prefix length or include
  explicit prefix length or ???)
* The server sends the Relay-reply message to
  the source address in the IP header of the
  Relay-forward message
* The relay forwards the Reply message to the
  client on the link identified by the
  link-prefix

This proposal still overloads the identification of the link
on which the relay forward the Reply to the client with the
selection of an address for the client by the server.  We
could either add a separate field for specifying a prefix
for address selection or define an option (like the DHCPv4
subnet selection option).  I would be inclined to define
an option that might be used by either a client or a
relay (or both?).

- Ralph

=====
9.1. Relay-forward 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   |                                               |
     +-+-+-+-+-+-+-+-+                                               |
     |                          link-prefix                          |
     |                                                               |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     |                                                               |
     |                     client-return-address                     |
     |                                                               |
     |               |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     +-+-+-+-+-+-+-+-+                                               |
     .                                                               .
     .            options (variable number and length)   ....        .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


      msg-type                    RELAY-FORW

      link-prefix                 A prefix assigned to the link from
                                  which the client message was received.

      client-return-address       The source address from the IP
                                  datagram in which the message from the
                                  client was received by the relay agent

      options                     MUST include a "Client message
                                  option"; see section 18.7.





_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C13169.9A6B60A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 12:23:27 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20961; Thu, 30 Aug 2001 12:23:27 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02906; Thu, 30 Aug 2001 12:22:23 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA02876 for ; Thu, 30 Aug 2001 12:22:17 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20862 for ; Thu, 30 Aug 2001 12:20:57 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7UGGPf15654; Thu, 30 Aug 2001 09:16:25 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7UGM8l00649; Thu, 30 Aug 2001 12:22:08 -0400 (EDT) Message-Id: <200108301622.f7UGM8l00649@grosse.bisbee.fugue.com> To: "Bernie Volz (EUD)" cc: "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 30 Aug 2001 10:36:57 CDT." <66F66129A77AD411B76200508B65AC697B34D3@eambunt705.ena-east.ericsson.se> Date: Thu, 30 Aug 2001 12:22:08 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > For 2, the relay can either use 3 or provide some other means of > identifying this information. It may not be an address - it could > just be an interface id or some other opaque info. So, I suggest > that for 2, we simply have an "Interface-ID" option which is > whatever the relay wants it to be. The server should treat it as > opaque and simply echo it back to the relay. If the relay doesn't > need it (because the info in (3) is sufficient), it need not provide > this option. We've already got two options that handle this - the circuit ID and the remote ID. Do we need a third, or is the circuit ID already serving this purpose? _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 12:57:07 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21786; Thu, 30 Aug 2001 12:57:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03645; Thu, 30 Aug 2001 12:56:10 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA03626 for ; Thu, 30 Aug 2001 12:56:08 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21751 for ; Thu, 30 Aug 2001 12:54:49 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7UGu9p08449 for ; Thu, 30 Aug 2001 11:56:09 -0500 (CDT) Received: from eamrcnt747.exu.ericsson.se (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7UGu9O14804 for ; Thu, 30 Aug 2001 11:56:09 -0500 (CDT) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Thu Aug 30 11:56:08 2001 -0500 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 11:56:08 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34DA@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ted Lemon'" Cc: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Date: Thu, 30 Aug 2001 11:56:07 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13174.A99339D0" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13174.A99339D0 Content-Type: text/plain; charset="iso-8859-1" It does seem to me, based on the DHCPv4 RFC3046 description, that a circuit ID option would work just fine. - Bernie -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: Thursday, August 30, 2001 12:22 PM To: Bernie Volz (EUD) Cc: 'Ralph Droms'; dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header > For 2, the relay can either use 3 or provide some other means of > identifying this information. It may not be an address - it could > just be an interface id or some other opaque info. So, I suggest > that for 2, we simply have an "Interface-ID" option which is > whatever the relay wants it to be. The server should treat it as > opaque and simply echo it back to the relay. If the relay doesn't > need it (because the info in (3) is sufficient), it need not provide > this option. We've already got two options that handle this - the circuit ID and the remote ID. Do we need a third, or is the circuit ID already serving this purpose? _MelloN_ ------_=_NextPart_001_01C13174.A99339D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Changes to remove = "client-link-local-address" from th e DHCPv6 header

It does seem to me, based on the DHCPv4 RFC3046 = description, that a circuit ID
option would work just fine.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:mellon@nominum.com]=
Sent: Thursday, August 30, 2001 12:22 PM
To: Bernie Volz (EUD)
Cc: 'Ralph Droms'; dhcwg@ietf.org
Subject: Re: [dhcwg] Changes to remove = "client-link-local-address" from
th e DHCPv6 header



> For 2, the relay can either use 3 or provide = some other means of
> identifying this information. It may not be an = address - it could
> just be an interface id or some other opaque = info. So, I suggest
> that for 2, we simply have an = "Interface-ID" option which is
> whatever the relay wants it to be. The server = should treat it as
> opaque and simply echo it back to the relay. If = the relay doesn't
> need it (because the info in (3) is = sufficient), it need not provide
> this option.

We've already got two options that handle this - the = circuit ID and
the remote ID.   Do we need a third, or is = the circuit ID already
serving this purpose?

        =         =                _MelloN_

------_=_NextPart_001_01C13174.A99339D0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 14:06:49 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23959; Thu, 30 Aug 2001 14:06:49 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05745; Thu, 30 Aug 2001 14:05:54 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA05722 for ; Thu, 30 Aug 2001 14:05:52 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23774 for ; Thu, 30 Aug 2001 14:04:32 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id OAA10607 for ; Thu, 30 Aug 2001 14:05:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20010830135626.03920b88@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 30 Aug 2001 14:04:35 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header In-Reply-To: <66F66129A77AD411B76200508B65AC697B34D3@eambunt705.ena-east .ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Bernie opined: >Just to be clear, there are three pieces of information: > >1. The address used to communicate with the relay. >2. The link on which the client's packet was received. >3. The prefix to be used for address assignment for the client. > >I think 1 is easy and it should just be the IPv6 source address of the Relay-Forw. > >In many cases 2 and 3 are the same but they need not be. I would suggest we solve >this by doing the following: > >For 3, the relay should send a prefix and prefix-length. For 3, we can either do a variable length length+prefix field or send a prefix with 0's in the interface-id or just send an address from the appropriate link and let the server deduce the prefix (which is what we do in DHCPv4, right?). I've written up the third alternative, which is as easy as any. I'll rewrite it as soon as someone expresses a preference for one of the other alternatives or comes up with a different plan. - Ralph ===== 9.1. Relay-forward 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 | | +-+-+-+-+-+-+-+-+ | | link-prefix | | | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | | | | client-return-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-FORW link-prefix An address with a prefix that is assigned to the link from which the client should be assigned an address. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Client message option"; see section 18.7. The relay MUST include a "circuit-ID option" if it needs to explicitly identify the link on which the client message should be forwarded to the client _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 15:15:41 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25921; Thu, 30 Aug 2001 15:15:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08109; Thu, 30 Aug 2001 15:10:47 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA08073 for ; Thu, 30 Aug 2001 15:10:44 -0400 (EDT) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25774 for ; Thu, 30 Aug 2001 15:09:24 -0400 (EDT) Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id f7UJAjp01569 for ; Thu, 30 Aug 2001 14:10:45 -0500 (CDT) Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id f7UJAjZ14294 for ; Thu, 30 Aug 2001 14:10:45 -0500 (CDT) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Thu Aug 30 14:10:45 2001 -0500 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Thu, 30 Aug 2001 14:10:44 -0500 Message-ID: <66F66129A77AD411B76200508B65AC697B34DE@eambunt705.ena-east.ericsson.se> From: "Bernie Volz (EUD)" To: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header Date: Thu, 30 Aug 2001 14:10:42 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C13187.76FEA370" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C13187.76FEA370 Content-Type: text/plain; charset="iso-8859-1" Yeah, in thinking some more about this, perhaps it is better that the relay doesn't know about prefix lengths (it doesn't really need to) - though it likely will anyway (because of Router Advertisements, etc). It also is one more thing that could get misconfigured in some way between the relay and server, so perhaps best to just let the server deal with it. Therefore, I would suggest it can either be the prefix (with 0's in the interface id) or just an address. Since the server knows the prefix lengths, it can find the appropriate "network" by doing the checks only against the prefix-length bits. Essentially, only the prefix bits are significant and the remaining bits are don't care. But, I have no major issue if we want to force it to be just the prefix (with 0's in the other bits). - Bernie -----Original Message----- From: Ralph Droms [mailto:rdroms@cisco.com] Sent: Thursday, August 30, 2001 2:05 PM To: dhcwg@ietf.org Subject: RE: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header Bernie opined: >Just to be clear, there are three pieces of information: > >1. The address used to communicate with the relay. >2. The link on which the client's packet was received. >3. The prefix to be used for address assignment for the client. > >I think 1 is easy and it should just be the IPv6 source address of the Relay-Forw. > >In many cases 2 and 3 are the same but they need not be. I would suggest we solve >this by doing the following: > >For 3, the relay should send a prefix and prefix-length. For 3, we can either do a variable length length+prefix field or send a prefix with 0's in the interface-id or just send an address from the appropriate link and let the server deduce the prefix (which is what we do in DHCPv4, right?). I've written up the third alternative, which is as easy as any. I'll rewrite it as soon as someone expresses a preference for one of the other alternatives or comes up with a different plan. - Ralph ===== 9.1. Relay-forward 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 | | +-+-+-+-+-+-+-+-+ | | link-prefix | | | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | | | | client-return-address | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-FORW link-prefix An address with a prefix that is assigned to the link from which the client should be assigned an address. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Client message option"; see section 18.7. The relay MUST include a "circuit-ID option" if it needs to explicitly identify the link on which the client message should be forwarded to the client _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C13187.76FEA370 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Changes to remove = "client-link-local-address" from the DHCPv6 header

Yeah, in thinking some more about this, perhaps it is = better that the relay
doesn't know about prefix lengths (it doesn't really = need to) - though it
likely will anyway (because of Router = Advertisements, etc).

It also is one more thing that could get = misconfigured in some way between
the relay and server, so perhaps best to just let = the server deal with it.

Therefore, I would suggest it can either be the = prefix (with 0's in the interface
id) or just an address. Since the server knows the = prefix lengths, it can find
the appropriate "network" by doing the = checks only against the prefix-length
bits. Essentially, only the prefix bits are = significant and the remaining bits
are don't care. But, I have no major issue if we = want to force it to be just
the prefix (with 0's in the other bits).

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:rdroms@cisco.com]
Sent: Thursday, August 30, 2001 2:05 PM
To: dhcwg@ietf.org
Subject: RE: [dhcwg] Changes to remove = "client-link-local-address" from
the DHCPv6 header


Bernie opined:

>Just to be clear, there are three pieces of = information:
>
>1. The address used to communicate with the = relay.
>2. The link on which the client's packet was = received.
>3. The prefix to be used for address assignment = for the client.
>
>I think 1 is easy and it should just be the IPv6 = source address of the Relay-Forw.
>
>In many cases 2 and 3 are the same but they need = not be. I would suggest we solve
>this by doing the following:
>
>For 3, the relay should send a prefix and = prefix-length.


For 3, we can either do a variable length = length+prefix field or send
a prefix with 0's in the interface-id or just send = an address
from the appropriate link and let the server deduce = the
prefix (which is what we do in DHCPv4, = right?).  I've written up
the third alternative, which is as easy as = any.  I'll rewrite
it as soon as someone expresses a preference for one = of the
other alternatives or comes up with a different = plan.

- Ralph

=3D=3D=3D=3D=3D
9.1. Relay-forward 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   = |            = ;            = ;            = ;           |
     = +-+-+-+-+-+-+-+-+         &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp; |
     = |            = ;            = ;  = link-prefix          &= nbsp;           &= nbsp;   |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     = +-+-+-+-+-+-+-+-+         &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp; |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;         = client-return-address        &nb= sp;            = |
     = |            = ;            = ;            = ;            = ;            = ;   |
     = |            = ;   |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
     = +-+-+-+-+-+-+-+-+         &= nbsp;           &= nbsp;           &= nbsp;           &= nbsp; |
     = .           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;           &nbs= p;   .
     = .            = options (variable number and length)   = ....        .
     = |            = ;            = ;            = ;            = ;            = ;   |
     = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=


      = msg-type          &nbs= p;         RELAY-FORW

      = link-prefix          &= nbsp;      An address with a prefix that = is
          &nb= sp;           &nb= sp;           = assigned to the link from
          &nb= sp;           &nb= sp;           which = the client should be assigned
          &nb= sp;           &nb= sp;           an = address.

      = client-return-address       The source = address from the IP
          &nb= sp;           &nb= sp;           = datagram in which the message from the
          &nb= sp;           &nb= sp;           client = was received by the relay agent

      = options           = ;          MUST include a = "Client message
          &nb= sp;           &nb= sp;           = option"; see section 18.7.  The relay
          &nb= sp;           &nb= sp;           MUST = include a "circuit-ID option" if
          &nb= sp;           &nb= sp;           it = needs to explicitly identify the
          &nb= sp;           &nb= sp;           link on = which the client message should
          &nb= sp;           &nb= sp;           be = forwarded to the client


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg=

------_=_NextPart_001_01C13187.76FEA370-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 16:06:03 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26813; Thu, 30 Aug 2001 16:06:03 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09449; Thu, 30 Aug 2001 16:05:20 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09426 for ; Thu, 30 Aug 2001 16:05:18 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26771 for ; Thu, 30 Aug 2001 16:03:57 -0400 (EDT) Received: from cisco.com (dhcp-161-44-149-95.cisco.com [161.44.149.95]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA28093; Thu, 30 Aug 2001 16:04:45 -0400 (EDT) Message-ID: <3B8E9C27.209B08B4@cisco.com> Date: Thu, 30 Aug 2001 16:03:51 -0400 From: Josh Littlefield Organization: Cisco Systems X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bernie Volz (EUD)" CC: "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header References: <66F66129A77AD411B76200508B65AC697B34DE@eambunt705.ena-east.ericsson.se> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Content-Transfer-Encoding: 7bit > "Bernie Volz (EUD)" wrote: > > Yeah, in thinking some more about this, perhaps it is better that the > relay > doesn't know about prefix lengths (it doesn't really need to) - though it > likely will anyway (because of Router Advertisements, etc). > > It also is one more thing that could get misconfigured in some way between > > the relay and server, so perhaps best to just let the server deal with it. I agree. I think having the relay include the prefix length is almost over-specifying the subnet to the server. The server had its configuration of subnets, and the relay needs only to provide an address within a subnet. Then the address either maps to a subnet, or it doesn't. But it won't run the risk of mapping to more than one if the relay-communicated prefix length is smaller than expected). > Therefore, I would suggest it can either be the prefix (with 0's in the > interface > id) or just an address. Since the server knows the prefix lengths, it can > find > the appropriate "network" by doing the checks only against the > prefix-length > bits. Essentially, only the prefix bits are significant and the remaining > bits > are don't care. But, I have no major issue if we want to force it to be > just > the prefix (with 0's in the other bits). This is what I was trying to get at before. The relay-address can be a full address, or a "prefix-only" address (0's in the other bits) and the server shouldn't care one way or the other as long as it maps to a subnet and isn't used to address packets. I see no reason to force the relay-address to be prefix-only, or to disallow it. -- ===================================================================== Josh Littlefield Cisco Systems, Inc. joshl@cisco.com 250 Apollo Drive tel: 978-244-8378 fax: same Chelmsford, MA 01824-3627 _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Aug 30 19:12:37 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29946; Thu, 30 Aug 2001 19:12:37 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14116; Thu, 30 Aug 2001 19:12:04 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA14053 for ; Thu, 30 Aug 2001 19:12:01 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29853 for ; Thu, 30 Aug 2001 19:10:41 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f7UN65f16138; Thu, 30 Aug 2001 16:06:05 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7UNBlf00374; Thu, 30 Aug 2001 19:11:47 -0400 (EDT) Message-Id: <200108302311.f7UNBlf00374@grosse.bisbee.fugue.com> To: "Bernie Volz (EUD)" cc: "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from th e DHCPv6 header In-Reply-To: Message from "Bernie Volz (EUD)" of "Thu, 30 Aug 2001 14:10:42 CDT." <66F66129A77AD411B76200508B65AC697B34DE@eambunt705.ena-east.ericsson.se> Date: Thu, 30 Aug 2001 19:11:47 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > Therefore, I would suggest it can either be the prefix (with 0's in > the interface id) or just an address. Since the server knows the > prefix lengths, it can find the appropriate "network" by doing the > checks only against the prefix-length bits. Essentially, only the > prefix bits are significant and the remaining bits are don't > care. But, I have no major issue if we want to force it to be just > the prefix (with 0's in the other bits). If we force it to be just the prefix, the relay has to know the length of the prefix in order to figure out what it is, right? :') Anyway, I think your loose interpretation is fine - any address in the subnet's range should be fine, including the prefix+all zeros address. The point is that it is semantically *not* the address to which the reply goes. _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 31 11:41:26 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08092; Fri, 31 Aug 2001 11:41:22 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15384; Fri, 31 Aug 2001 11:38:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA15356 for ; Fri, 31 Aug 2001 11:38:53 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08037 for ; Fri, 31 Aug 2001 11:37:30 -0400 (EDT) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-183.cisco.com [161.44.149.183]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12980 for ; Fri, 31 Aug 2001 11:38:22 -0400 (EDT) Message-Id: <4.3.2.7.2.20010831113644.01ca7ef8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 31 Aug 2001 11:38:19 -0400 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header In-Reply-To: <200108302311.f7UNBlf00374@grosse.bisbee.fugue.com> References: <66F66129A77AD411B76200508B65AC697B34DE@eambunt705.ena-east.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Here's the final text on this issue (extracted from the revved draft): 9. Relay messages Relay agents exchange messages with servers to forward messages between clients and servers that are not connected to the same link. 9.1. Relay-forward 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 | | +-+-+-+-+-+-+-+-+ | | link-prefix | | | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+ | | client-return-address | | | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-FORW link-prefix An address with a prefix that is assigned to the link from which the client should be assigned an address. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Client message option"; see section 18.7. 9.2. Relay-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 | | +-+-+-+-+-+-+-+-+ | | link-prefix | | | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+ | | client-return-address | | | | | | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | | | +-+-+-+-+-+-+-+-+ | . . . options (variable number and length) .... . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ msg-type RELAY-REPL link-prefix An address with a prefix that is assigned to the link from which the client should be assigned an address. client-return-address The source address from the IP datagram in which the message from the client was received by the relay agent options MUST include a "Server message option"; see section 18.8. 16. Relay Behavior For this discussion, the Relay may be configured to use a list of server destination addresses, which may include unicast addresses, the All DHCP Servers multicast address, or other multicast addresses selected by the network administrator. If the Relay has not been explicitly configured, it MUST use the All DHCP Servers multicast address as the default. 16.1. Relaying of client messages When a Relay receives a valid client message, it constructs a Relay-forward message. The relay places an address with a prefix assigned to the link on which the client should be assigned an address in the link-prefix field. This address will be used by the server to determine the link from which the client should be assigned an address and other configuration information. If the relay cannot use the address in the link-prefix field to identify the interface through which the response to the client will be forwarded, the relay MUST include a circuit-id option (see section TBD)in the Relay-forward message. The server will include the circuit-id option in its Relay-reply message. The relay copies the source address from the IP datagram in which the message was received from the client into the client-return-address field in the Relay-forward message. The relay constructs a "client-message" option 18.7 that contains the entire message from the client in the data field of the option. The relay places the "relay-message" option along with any "relay-specific" options in the options field of the Relay-forward message. The Relay then sends the Relay-forward message to the list of server destination addresses that it has been configured with. 16.2. Relaying of server messages When the relay receives a Relay-reply message, it extracts the server message from the "server-message" option. If the Relay-reply message includes a circuit-id option, the relay forwards the message from the server to the client on the link identified by the circuit-id option. Otherwise, the relay forwards the message on the link identified by the link-prefix option. In either case, the relay forwards the message to the address in the client-return-address field in the Relay-reply message. _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 31 15:18:11 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14496; Fri, 31 Aug 2001 15:18:11 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22566; Fri, 31 Aug 2001 15:17:13 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA22541 for ; Fri, 31 Aug 2001 15:17:11 -0400 (EDT) Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14482 for ; Fri, 31 Aug 2001 15:15:48 -0400 (EDT) Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id f7VJGi828888 for ; Fri, 31 Aug 2001 12:16:44 -0700 (PDT) Date: Fri, 31 Aug 2001 15:16:39 -0400 (EDT) From: Ralph Droms To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Progress on DHCPv6 spec Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org Looks like we are not going to make our goal of completing the -20 rev of the DHCPv6 spec by 8/31. We still have several issues from the London WG meeting to address in the spec. My current best estimate for completion of the next rev is next Friday, 9/7. We will continue to publish text for sepcific issues as we finish that text. The -20 rev may not be published for a few days after 9/7 so the authors can make a last review of the text. - Ralph Droms _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 31 23:08:39 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22512; Fri, 31 Aug 2001 23:08:39 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02801; Fri, 31 Aug 2001 23:07:55 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02771 for ; Fri, 31 Aug 2001 23:07:53 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22493 for ; Fri, 31 Aug 2001 23:06:29 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8131tf18293 for ; Fri, 31 Aug 2001 20:01:55 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7VHODj00362 for ; Fri, 31 Aug 2001 13:24:13 -0400 (EDT) Message-Id: <200108311724.f7VHODj00362@grosse.bisbee.fugue.com> To: dhcwg@ietf.org In-Reply-To: Message from Stuart Cheshire of "Fri, 24 Aug 2001 18:17:41 PDT." <200108250117.SAA13998@scv1.apple.com> Date: Fri, 31 Aug 2001 13:24:13 -0400 From: Ted Lemon Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org After arguing at length so as to avoid making major changes to the draft, I reread your message, and I think that all your proposed changes are actually good ones. So I will be putting them in a new version of the draft and submitting it to the RFC editor. Sorry for being stubborn - I'm just paranoid about delaying this draft any further. Thanks very much for your careful read of the draft, and for your well-thought-out suggestions for improving it. I'll try to be less churlish next time. :'} _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 31 23:08:40 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22510; Fri, 31 Aug 2001 23:08:35 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02832; Fri, 31 Aug 2001 23:07:58 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02805 for ; Fri, 31 Aug 2001 23:07:55 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22496 for ; Fri, 31 Aug 2001 23:06:32 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f8131wf18302; Fri, 31 Aug 2001 20:01:58 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7VHWfj00376; Fri, 31 Aug 2001 13:32:41 -0400 (EDT) Message-Id: <200108311732.f7VHWfj00376@grosse.bisbee.fugue.com> To: Stuart Cheshire cc: "DHCP discussion list" In-Reply-To: Message from Stuart Cheshire of "Mon, 27 Aug 2001 20:40:28 PDT." <200108280340.UAA19954@scv1.apple.com> Date: Fri, 31 Aug 2001 13:32:41 -0400 From: Ted Lemon Subject: [dhcwg] Re: Last call for Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org > I write a DHCP client, and would like it to request both options, but I > expect server administrators will usually configure their servers to > return only one or the other, as appropriate for the particular site. > > Ted writes a DHCP server, and would like it to be configured with data > for both options, but expects client administrators to configure their > clients to only request one or the other, as appropriate for the > particular site. There is actually a good reason to put complexity in the client - it distributes the work more fairly. If you do the work on the server, the workload increases by O(n), where n is the number of clients. If you do it on the client, each client's workload increases by O(1). I think in this case, with your proposed changes, there is no additional workload for the server, so I'm happy to leave it that way. But as a general rule, when we are making decisions like this, I think if we *can* push the work to the client, we should. BTW, I am both a client and a server implementor - I am very fond of the ISC DHCP client, which I use constantly as I roam from network to network. :') _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Aug 31 23:08:43 2001 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22564; Fri, 31 Aug 2001 23:08:43 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02864; Fri, 31 Aug 2001 23:08:01 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA02838 for ; Fri, 31 Aug 2001 23:07:58 -0400 (EDT) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22499 for ; Fri, 31 Aug 2001 23:06:34 -0400 (EDT) Received: from grosse.bisbee.fugue.com (dsl081-147-128.chi1.dsl.speakeasy.net [64.81.147.128]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id f81320f18308; Fri, 31 Aug 2001 20:02:01 -0700 (PDT) Received: from grosse.bisbee.fugue.com (localhost [127.0.0.1]) by grosse.bisbee.fugue.com (8.11.3/8.6.11) with ESMTP id f7VGslj00311; Fri, 31 Aug 2001 12:54:47 -0400 (EDT) Message-Id: <200108311654.f7VGslj00311@grosse.bisbee.fugue.com> To: Bernard Dugas cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: DHCP behind NAT In-Reply-To: Message from Bernard Dugas of "Wed, 29 Aug 2001 11:32:17 +0200." <3B8CB6A1.FA7237D7@is-production.com> Date: Fri, 31 Aug 2001 12:54:47 -0400 From: Ted Lemon Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: X-BeenThere: dhcwg@ietf.org There's no way to make your proposed change RFC2131 at this late date. Too many devices have been deployed that follow the current protocol specification. In order to do what you need, you have to come up with a different method. I would recommend that you investigate the subnet selection option. Send the address to which you want the reply sent in giaddr, and use the subnet-selection-option to store the address you would otherwise have stored in giaddr. I agree with you, by the way, that your proposed way of doing this is better than the way that RFC2131 does it. The problem is not that you're wrong, but that you're too late - this behavior was canonicalized in RFC951, and that's the last time it was possible to fix this the way you propose. :'} _MelloN_ _______________________________________________ dhcwg mailing list dhcwg@ietf.org http://www1.ietf.org/mailman/listinfo/dhcwg