From dhcwg-admin@ietf.org Fri Feb 1 04:03:11 2002 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 EAA05813; Fri, 1 Feb 2002 04:03:10 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02719; Fri, 1 Feb 2002 03:53:16 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA02693 for ; Fri, 1 Feb 2002 03:53:15 -0500 (EST) Received: from u533-015.cradle.com ([66.52.184.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04905 for ; Fri, 1 Feb 2002 03:53:07 -0500 (EST) Received: from alka ([192.168.1.50]) by u533-015.cradle.com (8.8.8+Sun/8.8.8) with SMTP id AAA00086 for ; Fri, 1 Feb 2002 00:52:43 -0800 (PST) Message-ID: <00b901c1aaff$3118b610$3201a8c0@cradle.com> From: "Alka Mohite" To: Date: Fri, 1 Feb 2002 14:32:32 +0530 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B6_01C1AB2D.486F3450" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [dhcwg] DHCP DNS 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 is a multi-part message in MIME format. ------=_NextPart_000_00B6_01C1AB2D.486F3450 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Can you please guide me towards an RFC detailing about DHCP server and = DNS server communication for updates in DNS data bases. regards, Alka ------=_NextPart_000_00B6_01C1AB2D.486F3450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

Can you please guide me towards an RFC = detailing=20 about DHCP server and DNS server communication for updates in DNS data=20 bases.

regards,
Alka

------=_NextPart_000_00B6_01C1AB2D.486F3450-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From mailman-owner@ietf.org Fri Feb 1 06:00:42 2002 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 GAA15336 for ; Fri, 1 Feb 2002 06:00:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA08201 for ; Fri, 1 Feb 2002 06:00:45 -0500 (EST) Date: Fri, 1 Feb 2002 06:00:45 -0500 (EST) Message-Id: <200202011100.GAA08201@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: dhc-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhc-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive@lists.ietf.org From dhcwg-admin@ietf.org Fri Feb 1 11:29:39 2002 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 LAA02212; Fri, 1 Feb 2002 11:29:39 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24100; Fri, 1 Feb 2002 11:28:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA24075 for ; Fri, 1 Feb 2002 11:28:26 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02190 for ; Fri, 1 Feb 2002 11:28:23 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA67406 for ; Fri, 1 Feb 2002 10:23:49 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g11GSNb281614 for ; Fri, 1 Feb 2002 11:28:23 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g11GShQ01490 for ; Fri, 1 Feb 2002 11:28:43 -0500 Message-Id: <200202011628.g11GShQ01490@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Fri, 01 Feb 2002 11:28:43 -0500 From: Thomas Narten Subject: [dhcwg] IESG feedback on draft-ietf-dhc-csr-05.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 The authors have seen most of these already, but I thought it appropriate for the WG to see them as well. The first one, in particular, we should have caught ourselves! Once these issues are addressed, I expect the IESG will approve the document in short order. (The next IESG telechat is next Thursday, so it would be nice to have a new ID in place by then!) > Security Considerations > > DHCP currently provides no authentication or security mechanisms. What about RFC 3118? > 1. The document uses "classed" to refer to non-classless addresses. > In my experience, "Classful" is a much more common term (e.g. RFC 1817's > title, and a grep for "classed" in all RFCs vs. a grep for "classful".) > > 2. It's not completely clear what "supersedes" in the abstract means. > Does this document obsolete option 33? It should probably say "Updates > RFC2132"? Also, mentioning Classless vs. Classful in the abstract > would probably be appropriate, and I always think that "new" or "old" > in abstracts end up out of date too quickly - how about this replacement > wording: > > This document defines a DHCP option which is passed from the DHCP > Server to the DHCP Client to configure a list of classless static > routes in the client. This option should be used instead of the > classful Static Route option (option 33) defined in RFC2132. > > 3. The IANA Considerations section is missing an "of" in "..the list DHCP > option codes.." Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 1 11:43:06 2002 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 LAA02660; Fri, 1 Feb 2002 11:43:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25141; Fri, 1 Feb 2002 11:42:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA25115 for ; Fri, 1 Feb 2002 11:42:33 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02656 for ; Fri, 1 Feb 2002 11:42:28 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id KAA83974 for ; Fri, 1 Feb 2002 10:37:55 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g11GgTb204040 for ; Fri, 1 Feb 2002 11:42:29 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g11GgmT01529 for ; Fri, 1 Feb 2002 11:42:48 -0500 Message-Id: <200202011642.g11GgmT01529@rotala.raleigh.ibm.com> To: dhcwg@ietf.org Date: Fri, 01 Feb 2002 11:42:48 -0500 From: Thomas Narten Subject: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.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 The authors have seen most of these already, but there is one question in particular I think the WG should have a chance to comment on. Once these issues are addressed, I expect the IESG will approve the document in short order. (The next IESG telechat is next Thursday, so it would be nice to have a new ID in place by then!) 1) General question. Does this document update RFC 2131? If so, the introduction should have a sentence that says this explicitely. More background: > The applicability section seems to say that an encoding agent can > use the Option Overload option and the concat at any time. > > Isn't this likely to cause interoperability problems until all DHCP decoding > agents support the concat specification? > It would seem more conservative to only allow concat for specific option > codes (such as the classless route one and others that explicitly say they > will use concat). 2) A minor complaint about the abstract: This draft specifies how DHCP options in a DHCP packet can be aggregated so that DHCP protocol agents can send options that are more than 255 bytes in length. I'd rather see "split and combined" (or similar) rather than "aggregated". The document also talks about using this feature in order to split options across packet fields, but that's not mentioned in the abstract. I'm not as worried about that. The technical summary in the draft announcement might actually be a much better abstract than what's there now. It is: This document specifies the processing rules for DHCP options that appear multiple times in the same message. The need to send multiple instances of the same option occurs when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be broken up into smaller pieces in order that the pieces can be placed in the DHC packet in non-contiguous locations (e.g., within the "file" or "sname" field). When multiple instances of the same option appear in a packet, the contents of the option are concatenated together prior to processing. 3) Should the security considerations section refer to RFC 3118? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 1 12:05:29 2002 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 MAA03816; Fri, 1 Feb 2002 12:05:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27375; Fri, 1 Feb 2002 12:04:44 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27354 for ; Fri, 1 Feb 2002 12:04:42 -0500 (EST) Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03739 for ; Fri, 1 Feb 2002 12:04:39 -0500 (EST) 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 g11H4bh18800 for ; Fri, 1 Feb 2002 11:04:38 -0600 (CST) 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 g11H4bg27190 for ; Fri, 1 Feb 2002 11:04:37 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Feb 01 11:04:37 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 11:04:37 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CE75@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , dhcwg@ietf.org Subject: RE: [dhcwg] IESG feedback on draft-ietf-dhc-csr-05.txt Date: Fri, 1 Feb 2002 11:04:36 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB42.86E4D720" 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_01C1AB42.86E4D720 Content-Type: text/plain; charset="iso-8859-1" >> Security Considerations >> >> DHCP currently provides no authentication or security mechanisms. > >What about RFC 3118? Yeah, we should have caught that ... but then this (and several other drafts) have been in process for a long while (before RFC 3118). And, one must be careful about referencing I-Ds since that can sometimes cause issues as well. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Friday, February 01, 2002 11:29 AM To: dhcwg@ietf.org Subject: [dhcwg] IESG feedback on draft-ietf-dhc-csr-05.txt The authors have seen most of these already, but I thought it appropriate for the WG to see them as well. The first one, in particular, we should have caught ourselves! Once these issues are addressed, I expect the IESG will approve the document in short order. (The next IESG telechat is next Thursday, so it would be nice to have a new ID in place by then!) > Security Considerations > > DHCP currently provides no authentication or security mechanisms. What about RFC 3118? > 1. The document uses "classed" to refer to non-classless addresses. > In my experience, "Classful" is a much more common term (e.g. RFC 1817's > title, and a grep for "classed" in all RFCs vs. a grep for "classful".) > > 2. It's not completely clear what "supersedes" in the abstract means. > Does this document obsolete option 33? It should probably say "Updates > RFC2132"? Also, mentioning Classless vs. Classful in the abstract > would probably be appropriate, and I always think that "new" or "old" > in abstracts end up out of date too quickly - how about this replacement > wording: > > This document defines a DHCP option which is passed from the DHCP > Server to the DHCP Client to configure a list of classless static > routes in the client. This option should be used instead of the > classful Static Route option (option 33) defined in RFC2132. > > 3. The IANA Considerations section is missing an "of" in "..the list DHCP > option codes.." Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1AB42.86E4D720 Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] IESG feedback on draft-ietf-dhc-csr-05.txt

>> Security Considerations
>>
>> DHCP currently provides no authentication or security mechanisms.
>
>What about RFC 3118?

Yeah, we should have caught that ... but then this (and several other drafts) have
been in process for a long while (before RFC 3118). And, one must be careful about
referencing I-Ds since that can sometimes cause issues as well.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Friday, February 01, 2002 11:29 AM
To: dhcwg@ietf.org
Subject: [dhcwg] IESG feedback on draft-ietf-dhc-csr-05.txt

The authors have seen most of these already, but I thought it
appropriate for the WG to see them as well. The first one, in
particular, we should have caught ourselves!

Once these issues are addressed, I expect the IESG will approve the
document in short order. (The next IESG telechat is next Thursday, so
it would be nice to have a new ID in place by then!)

> Security Considerations
>
> DHCP currently provides no authentication or security mechanisms.

What about RFC 3118?

> 1. The document uses "classed" to refer to non-classless addresses.
> In my experience, "Classful" is a much more common term (e.g. RFC 1817's
> title, and a grep for "classed" in all RFCs vs. a grep for "classful".)
>
> 2. It's not completely clear what "supersedes" in the abstract means.
> Does this document obsolete option 33? It should probably say "Updates
> RFC2132"? Also, mentioning Classless vs. Classful in the abstract
> would probably be appropriate, and I always think that "new" or "old"
> in abstracts end up out of date too quickly - how about this replacement
> wording:
>
>    This document defines a DHCP option which is passed from the DHCP
>    Server to the DHCP Client to configure a list of classless static
>    routes in the client. This option should be used instead of the
>    classful Static Route option (option 33) defined in RFC2132.
>
> 3. The IANA Considerations section is missing an "of" in "..the list DHCP
> option codes.."

Thomas

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

------_=_NextPart_001_01C1AB42.86E4D720-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 1 12:09:04 2002 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 MAA04039; Fri, 1 Feb 2002 12:09:04 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27726; Fri, 1 Feb 2002 12:07:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA27687 for ; Fri, 1 Feb 2002 12:07:47 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03929 for ; Fri, 1 Feb 2002 12:07:44 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g11H4Sm25769; Fri, 1 Feb 2002 09:04:28 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g11H7cl01495; Fri, 1 Feb 2002 11:07:38 -0600 (CST) Date: Fri, 1 Feb 2002 11:07:38 -0600 Subject: Re: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org To: Thomas Narten From: Ted Lemon In-Reply-To: <200202011642.g11GgmT01529@rotala.raleigh.ibm.com> Message-Id: <31D01AE8-1736-11D6-8A91-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 I would like to avoid having these two drafts require the implementation of RFC3118, since RFC3118 by itself isn't very deployable. But you're right that RFC3118 does address the security issue, and ought to be mentioned. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 1 12:32:42 2002 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 MAA05139; Fri, 1 Feb 2002 12:32:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29571; Fri, 1 Feb 2002 12:32:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA29540 for ; Fri, 1 Feb 2002 12:31:58 -0500 (EST) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05129 for ; Fri, 1 Feb 2002 12:31:54 -0500 (EST) Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id LAA98956; Fri, 1 Feb 2002 11:27:21 -0600 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.9.21]) by southrelay02.raleigh.ibm.com (8.11.1m3/NCO v5.01) with ESMTP id g11HVtb31342; Fri, 1 Feb 2002 12:31:55 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id g11HWEF01880; Fri, 1 Feb 2002 12:32:15 -0500 Message-Id: <200202011732.g11HWEF01880@rotala.raleigh.ibm.com> To: Ted Lemon cc: dhcwg@ietf.org Subject: Re: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt In-Reply-To: Message from "Fri, 01 Feb 2002 11:07:38 CST." <31D01AE8-1736-11D6-8A91-00039317663C@nominum.com> Date: Fri, 01 Feb 2002 12:32:14 -0500 From: Thomas Narten 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 would like to avoid having these two drafts require the implementation of > RFC3118, since RFC3118 by itself isn't very deployable. Plus, has anyone even implemented it yet? Please? On the point of 3118 deployability, there has been some private discussion that what would be useful to have is a DHC authentication mechanism that can use certificates, and that only authenticates the server to the client. This would seem to be a useful deployment scenario. Thoughts? Also, note that the final wording in draft-aboba-dhc-domsearch-09.txt on this point didn't require the use of 3118, but did point out its existance. That made it through the IESG (but it also prompted the above discussion about the desirability of a more useful/deployable authentication mechanism). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 1 13:40:30 2002 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 NAA07298; Fri, 1 Feb 2002 13:40:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02901; Fri, 1 Feb 2002 13:36:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA02877 for ; Fri, 1 Feb 2002 13:36:39 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07051 for ; Fri, 1 Feb 2002 13:36:35 -0500 (EST) Received: from mr6.exu.ericsson.se (mr6att.ericy.com [138.85.224.157]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g11Ia8S09484 for ; Fri, 1 Feb 2002 12:36:08 -0600 (CST) 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 g11Ia8O21809 for ; Fri, 1 Feb 2002 12:36:08 -0600 (CST) Received: FROM eamrcnt760.exu.ericsson.se BY eamrcnt749 ; Fri Feb 01 12:36:07 2002 -0600 Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 1 Feb 2002 12:36:07 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CE79@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'Thomas Narten'" , Ted Lemon Cc: dhcwg@ietf.org Subject: RE: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt Date: Fri, 1 Feb 2002 12:36:06 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AB4F.4F351710" 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_01C1AB4F.4F351710 Content-Type: text/plain; charset="iso-8859-1" >there has been some private >discussion that what would be useful to have is a DHC authentication >mechanism that can use certificates, and that only authenticates the >server to the client. Sounds good to me. Isn't this something that 3118 supports since the server can just send back an Authentication Option with this information? We might need to define a new authentication type. RE CSR draft, yes, I had assumed we would not require Auth. Just mention its existence and suggest those concerned with security issues use it. -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Friday, February 01, 2002 12:32 PM To: Ted Lemon Cc: dhcwg@ietf.org Subject: Re: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt > I would like to avoid having these two drafts require the implementation of > RFC3118, since RFC3118 by itself isn't very deployable. Plus, has anyone even implemented it yet? Please? On the point of 3118 deployability, there has been some private discussion that what would be useful to have is a DHC authentication mechanism that can use certificates, and that only authenticates the server to the client. This would seem to be a useful deployment scenario. Thoughts? Also, note that the final wording in draft-aboba-dhc-domsearch-09.txt on this point didn't require the use of 3118, but did point out its existance. That made it through the IESG (but it also prompted the above discussion about the desirability of a more useful/deployable authentication mechanism). Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1AB4F.4F351710 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt =

>there has been some private
>discussion that what would be useful to have is = a DHC authentication
>mechanism that can use certificates, and that = only authenticates the
>server to the client.

Sounds good to me. Isn't this something that 3118 = supports since the server
can just send back an Authentication Option with = this information? We might
need to define a new authentication type.

RE CSR draft, yes, I had assumed we would not require = Auth. Just mention its
existence and suggest those concerned with security = issues use it.

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Friday, February 01, 2002 12:32 PM
To: Ted Lemon
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] IESG feedback on = draft-ietf-dhc-concat-01.txt

> I would like to avoid having these two drafts = require the implementation of
> RFC3118, since RFC3118 by itself isn't very = deployable.

Plus, has anyone even implemented it yet? = Please?

On the point of 3118 deployability, there has been = some private
discussion that what would be useful to have is a = DHC authentication
mechanism that can use certificates, and that only = authenticates the
server to the client. This would seem to be a useful = deployment
scenario. Thoughts?

Also, note that the final wording in = draft-aboba-dhc-domsearch-09.txt
on this point didn't require the use of 3118, but = did point out its
existance. That made it through the IESG (but it = also prompted the
above discussion about the desirability of a more = useful/deployable
authentication mechanism).

Thomas

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

------_=_NextPart_001_01C1AB4F.4F351710-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 1 16:04:30 2002 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 QAA12024; Fri, 1 Feb 2002 16:04:30 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09955; Fri, 1 Feb 2002 16:03:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA09935 for ; Fri, 1 Feb 2002 16:03:41 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12006 for ; Fri, 1 Feb 2002 16:03:37 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-314.cisco.com [10.82.225.58]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA28227 for ; Fri, 1 Feb 2002 16:03:08 -0500 (EST) Message-Id: <4.3.2.7.2.20020201160127.03826c38@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Feb 2002 16:03:29 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHCPv6 spec (-23) and associated drafts 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 made some final edits and submitted DHCPv6 (-23) to the IETF for publication this afternoon. Until it appears at www.ietf.org, you can get a copy at www.dhcp.org/dhcpv6-23 This rev of the spec will be submitted to the IESG for acceptance as a Proposed Standard. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 1 18:51:48 2002 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 SAA14343; Fri, 1 Feb 2002 18:51:48 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17751; Fri, 1 Feb 2002 18:51:05 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id SAA17729 for ; Fri, 1 Feb 2002 18:51:03 -0500 (EST) Received: from mercury.netopia.com (mail.netopia.com [163.176.4.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14335 for ; Fri, 1 Feb 2002 18:51:00 -0500 (EST) Received: from netopia.com ([163.176.45.190]) by mercury.netopia.com (Netscape Messaging Server 4.15) with ESMTP id GQVOW800.EHH for ; Fri, 1 Feb 2002 15:50:32 -0800 Message-ID: <3C5B29B6.BB41CFF4@netopia.com> Date: Fri, 01 Feb 2002 15:50:15 -0800 From: "Matt Frick" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Confusion on RFC 3011 subnet selection option 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 After re-reading RFC 3011 many times, I'm still a bit confused, and hopefully there are some talented indivuals out there on the email list that can help me out. From what I understand, (other than the obvious subnet-related parts) the subnet selection option overrides the current usage of giaddr which is used by relay agents to specify: 1) the address to which the server is to send it's reply, and 2) the subnet from which to allocate the address. It seems that the option is designed to be used / necessary only when a relay agent needs the server to reply to an address on a subnet that is different than the subnet on which the address should be allocated, since "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)." [RFC 3011, page 4] Since the RAS device in the motivational example is connected to the internal network on which the DHCP server is located, does that mean that the RAS device is the "client" in the above quote? If it is, then that would explain why it has an address on which it can receive DHCP packets to put in the giaddr when sending a discover or request (ie. when it's not bound) -- perhaps the address sent in the giaddr field is not a DHCP obtained address, but a statically defined address on the internal network. Can this option be sent by a end client (host) directly to a server, or must it pass through a relay agent? The reason it seems likely that a relay agent is required, is that when the giaddr is nonzero, the server will repond to the server port, not the client port: "The server SHOULD next check the 'giaddr' field. If this field is non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to the IP address identified in the 'giaddr' field. The UDP destination port MUST be set to BOOTPS (67)." [RFC 1542, page 20] especially since: "This option does not require changes to operations or features of the DHCP server other than to select the subnet on which to allocate on address." [RFC 3011, page 3] So, I guess the big mystery (atleast for me,) is this: can an end client send a subnet selection option? When the client doesn't have a binding (and it's sending a subnet selection option,) can / should the giaddr be set to zero? Or, is this option reserved for situations more complicated than a simple scenario where a DHCP server has several subnets and a directly connected client wants to request an address on a specific subnet? Thanks for reading this far, hopefully this RFC can be clarified. -Matt Frick _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 1 21:36:52 2002 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 VAA17592; Fri, 1 Feb 2002 21:36:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24819; Fri, 1 Feb 2002 21:36:23 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id VAA24794 for ; Fri, 1 Feb 2002 21:36:22 -0500 (EST) Received: from localhost ([211.208.32.189]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA17585 for ; Fri, 1 Feb 2002 21:36:15 -0500 (EST) Message-Id: <200202020236.VAA17585@ietf.org> Reply-To: office7000@yahoo.co.kr From: �� To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 2 Feb 2002 11:36:51 +0900 Subject: [dhcwg] [��] ��� ̵�� [�̼��Ա��] 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 �� Ͻø� �� ǻ縦 ��ϰڽ��ϴ�.

�� ּҴ� ��, http://www.xxxxxxxx.com/
�� ˰� �Ȱ��̸�, E-Mail �ּ� �ܿ�, �ٸ� �� ʽ��ϴ�.
�� ǰ��׿� �ǰ� �� [��]�� ǥ�� Դϴ�.��Űź�� ּ��

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 2 05:11:58 2002 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 FAA01453; Sat, 2 Feb 2002 05:11:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20309; Sat, 2 Feb 2002 05:11:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20286 for ; Sat, 2 Feb 2002 05:11:33 -0500 (EST) Received: from localhost ([211.183.238.87]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01446 for ; Sat, 2 Feb 2002 05:11:28 -0500 (EST) Message-Id: <200202021011.FAA01446@ietf.org> Reply-To: office700@yahoo.co.kr From: �� To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 2 Feb 2002 19:09:15 +0900 Subject: [dhcwg] [��[ ��� ̵�� [�̼��ѱ��] 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 �� Ͻø� �� ǻ縦 ��ϰڽ��ϴ�.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 4 00:54:59 2002 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 AAA06291; Mon, 4 Feb 2002 00:54:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28834; Mon, 4 Feb 2002 00:53:42 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28816 for ; Mon, 4 Feb 2002 00:53:41 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA06275 for ; Mon, 4 Feb 2002 00:53:39 -0500 (EST) Received: from BarrH63p601 ([64.170.117.6]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GQZ003YEV1G82@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Sun, 03 Feb 2002 21:53:40 -0800 (PST) Date: Sun, 03 Feb 2002 21:52:43 -0800 From: Richard Barr Hibbs In-reply-to: To: Erik Guttman Cc: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Content-Transfer-Encoding: 7BIT Subject: [dhcwg] RE: SLPv2 DHCPv6 options (was: additional option for dhcpv6) 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 Erik-- Thanks for the clarification! --Barr > -----Original Message----- > From: Erik Guttman > Sent: Monday, January 28, 2002 09:54 > > I can briefly clarify the SLP DHC options. These are being > revised from RFC 2610 in draft-guttman-svrloc-rfc2610bis-01.txt > I will add text to specify DHCPv6 options in the next revision. > [Snip!] > > Please note that it is possible for the DA option to be sent > without sending the SLP scope option. When an SLP agent is > configured with the DA option, it will request a SLPv2 DAAdvert > from the DA whose address is listed, in order to obtain information > about the DA, including which scopes the DA is configured with. > This is described in detail in draft-guttman-svrloc-rfc2608bis-02.txt > > The analogy to v4 option 78, SLP Directory Agent Option, will be > > 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_SLPDA | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > | DA Address #1 | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > . . . . > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > | | > | DA Address #N | > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > One or more DA addresses are supplied. The minimum length of the > option will be 36 bytes. The interpretation of this is field is > exactly the same as for option 78, except that it is used to > configure a SLP v2 agent with the IPv6 address of a SLPv2 DA. > [Snip!] > > Only one SLP Service Scope Option is sent to configure an SLP > agent. > > The analogy to v4 option 79, SLP Service Scope Option, will be > > 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_SLPSCOPES | option-len | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | ... > +-------------------- > > This option includes zero or more bytes of UTF-8 string. Its > minimum length is 4 bytes. The interpretation of this field > is exactly as per DHCP option 79. > > I have no doubt that these options will eventually assigned > DHCPv6 option IDs as the rfc2610bis document proceeds. > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 4 01:38:14 2002 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 BAA06717; Mon, 4 Feb 2002 01:38:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09823; Mon, 4 Feb 2002 01:37:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA09803 for ; Mon, 4 Feb 2002 01:37:13 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06694 for ; Mon, 4 Feb 2002 01:37:11 -0500 (EST) Received: from BarrH63p601 ([64.170.117.6]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GQZ005J0X20MO@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Sun, 03 Feb 2002 22:37:13 -0800 (PST) Date: Sun, 03 Feb 2002 22:36:15 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] Security Issue about DHCP In-reply-to: <35DE082769ACD311A9AE009027C3CBC902F76466@aints2.asiainfo.com> To: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=gb2312 Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 -----Original Message----- From: Hai Xu Sent: Thursday, January 31, 2002 01:31 I'd like to know whether there are some mechanism to acchieve the following issues with DHCP: 1. If illegal person set up another DHCP server. Clients will only select the DHCP server who respond quickly. How to avoid the legal DHCP from being disturbed by illegal server? ...while it is most common for DHCP clients to select the first server that responds to a DHCPDISCOVER message, that behavior is not required by RFC 2132: the client may use any method at its disposal to determine which server to select. For example, a client could insist that a DHCP server not be on the same subnet as the client itself (useful if it is known that legitimate DHCP servers are on a separate subnet accessible through a router or relay agent). RFC3118 specifies the client-server authentication protocol for DHCP: one of the stated purposes of this protocol is to prevent illegal DHCP servers from interfering with the operation of clients. I'll leave it to vendors to identify products that implement RFC3118. 2. In an DHCP domain, clients can also configure themselves with static IP. Can switches refuse those clients to work? ...if I understand your question correctly, to mean can various pieces of network equipment be prevented from servicing clients who've statically configured themselves with an IP address, the answer is no: there is no means to generally distinguish whether a client has been configured by a DHCP server. 3. I've been told that DHCP could work with RADIUS to acchieve authentication before allocating IP address. Are there any mature products then? ...RADIUS could be used successfully to validate a user (its most common application) and probably validate a client as well, but I'll leave it to vendors to reply to this question. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 4 10:02:29 2002 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 KAA24694; Mon, 4 Feb 2002 10:02:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07034; Mon, 4 Feb 2002 10:00:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA07008 for ; Mon, 4 Feb 2002 10:00:08 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24473 for ; Mon, 4 Feb 2002 10:00:06 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14ExaH07259; Mon, 4 Feb 2002 09:59:37 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g14ExZ328282; Mon, 4 Feb 2002 09:59:35 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id ; Mon, 4 Feb 2002 09:59:34 -0500 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E60136F72A@zcard0ke.ca.nortel.com> From: "Glenn Waters" To: Matt Frick , dhcwg@ietf.org Subject: RE: [dhcwg] Confusion on RFC 3011 subnet selection option Date: Mon, 4 Feb 2002 09:59:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AD8C.8D43EBF0" 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_01C1AD8C.8D43EBF0 Content-Type: text/plain This option is intended for use by a device that is requesting address on behalf of another device. The word client in this case implies that you already have an IP address (static or dynamic). This option is not intended to allocate an address on a specific subnet on devices that are connected to multiple subnets. The correct way to allocate an address on a specific subnet is to send the DHCP request out on the subnet for which you wish to have an address allocated. /gww -----Original Message----- From: Matt Frick [mailto:mfrick@netopia.com] Sent: Friday, February 01, 2002 18:50 To: dhcwg@ietf.org Subject: [dhcwg] Confusion on RFC 3011 subnet selection option After re-reading RFC 3011 many times, I'm still a bit confused, and hopefully there are some talented indivuals out there on the email list that can help me out. From what I understand, (other than the obvious subnet-related parts) the subnet selection option overrides the current usage of giaddr which is used by relay agents to specify: 1) the address to which the server is to send it's reply, and 2) the subnet from which to allocate the address. It seems that the option is designed to be used / necessary only when a relay agent needs the server to reply to an address on a subnet that is different than the subnet on which the address should be allocated, since "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)." [RFC 3011, page 4] Since the RAS device in the motivational example is connected to the internal network on which the DHCP server is located, does that mean that the RAS device is the "client" in the above quote? If it is, then that would explain why it has an address on which it can receive DHCP packets to put in the giaddr when sending a discover or request (ie. when it's not bound) -- perhaps the address sent in the giaddr field is not a DHCP obtained address, but a statically defined address on the internal network. Can this option be sent by a end client (host) directly to a server, or must it pass through a relay agent? The reason it seems likely that a relay agent is required, is that when the giaddr is nonzero, the server will repond to the server port, not the client port: "The server SHOULD next check the 'giaddr' field. If this field is non-zero, the server SHOULD send the BOOTREPLY as an IP unicast to the IP address identified in the 'giaddr' field. The UDP destination port MUST be set to BOOTPS (67)." [RFC 1542, page 20] especially since: "This option does not require changes to operations or features of the DHCP server other than to select the subnet on which to allocate on address." [RFC 3011, page 3] So, I guess the big mystery (atleast for me,) is this: can an end client send a subnet selection option? When the client doesn't have a binding (and it's sending a subnet selection option,) can / should the giaddr be set to zero? Or, is this option reserved for situations more complicated than a simple scenario where a DHCP server has several subnets and a directly connected client wants to request an address on a specific subnet? Thanks for reading this far, hopefully this RFC can be clarified. -Matt Frick _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1AD8C.8D43EBF0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Confusion on RFC 3011 subnet selection = option

This option is intended for use by a device that is = requesting address on behalf of another device. The word client in this = case implies that you already have an IP address (static or = dynamic).

This option is not intended to allocate an address on = a specific subnet on devices that are connected to multiple subnets. = The correct way to allocate an address on a specific subnet is to send = the DHCP request out on the subnet for which you wish to have an = address allocated.

/gww

-----Original Message-----
From: Matt Frick [mailto:mfrick@netopia.com] =
Sent: Friday, February 01, 2002 18:50
To: dhcwg@ietf.org
Subject: [dhcwg] Confusion on RFC 3011 subnet = selection option

After re-reading RFC 3011 many times, I'm still a bit = confused, and
hopefully there are some talented indivuals out = there on the email list
that can help me out.

From what I understand, (other than the obvious = subnet-related parts)
the subnet selection option overrides the current = usage of giaddr which
is used by relay agents to specify:
1) the address to which the server is to send it's = reply, and
2) the subnet from which to allocate the = address.
It seems that the option is designed to be used / = necessary only when a
relay agent needs the server to reply to an address = on a subnet that is
different than the subnet on which the address = should be allocated,
since

        "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)." [RFC 3011, page 4]

Since the RAS device in the motivational example is = connected to the
internal network on which the DHCP server is = located, does that mean
that the RAS device is the "client" in the = above quote? If it is, then
that would explain why it has an address on which it = can receive DHCP
packets to put in the giaddr when sending a discover = or request (ie.
when it's not bound) -- perhaps the address sent in = the giaddr field is
not a DHCP obtained address, but a statically = defined address on the
internal network.

Can this option be sent by a end client (host) = directly to a server, or
must it pass through a relay agent? The reason = it seems likely that a
relay agent is required, is that when the giaddr is = nonzero, the server
will repond to the server port, not the client = port:

       "The server = SHOULD next check the 'giaddr' field. If this field
is
        non-zero, = the server SHOULD send the BOOTREPLY as an IP unicast
        to the IP = address identified in the 'giaddr' field. The UDP
        = destination port MUST be set to BOOTPS (67)." [RFC 1542, = page
20]

especially since:

        "This = option does not require changes to operations or features
of the
        DHCP = server other than to select the subnet on which to allocate
on
        = address." [RFC 3011, page 3]

So, I guess the big mystery (atleast for me,) is = this: can an end client
send a subnet selection option? When the = client doesn't have a binding
(and it's sending a subnet selection option,) can / = should the giaddr be
set to zero?
Or, is this option reserved for situations more = complicated than a
simple scenario where a DHCP server has several = subnets and a directly
connected client wants to request an address on a = specific subnet?

Thanks for reading this far, hopefully this RFC can = be clarified.
-Matt Frick

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

------_=_NextPart_001_01C1AD8C.8D43EBF0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 4 14:47:58 2002 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 OAA04279; Mon, 4 Feb 2002 14:47:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26876; Mon, 4 Feb 2002 14:44:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA26857 for ; Mon, 4 Feb 2002 14:44:40 -0500 (EST) 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 OAA04183 for ; Mon, 4 Feb 2002 14:44:35 -0500 (EST) Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g14JiaQ14760 for ; Mon, 4 Feb 2002 11:44:36 -0800 (PST) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id ; Mon, 4 Feb 2002 11:44:34 -0800 Received: from [17.202.44.113] (chesh1.apple.com [17.202.44.113]) by scv2.apple.com (8.11.3/8.11.3) with SMTP id g14JiY026372; Mon, 4 Feb 2002 11:44:34 -0800 (PST) Message-Id: <200202041944.g14JiY026372@scv2.apple.com> Date: Mon, 4 Feb 2002 11:44:34 -0800 x-sender: cheshire@mail.apple.com x-mailer: Claris Emailer 2.0v3, January 22, 1998 From: Stuart Cheshire To: "DHCP discussion list" cc: Mime-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Subject: [dhcwg] IPv4 Address Conflict Detection 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 DHC WG meeting in Salt Lake City we briefly talked about address conflict detection. The feedback I got was that while it is definitely useful to nail down a clear specification of how do do address conflict detection properly, it doesn't have an obvious natural "home" in any current IETF WG, so I should just solicit feedback and then send it in as an individual submission. The two working groups we felt had expertise in this area are DHC and MOBILEIP, hence this email: ---------------- From time to time people ask how Mac OS, Windows, and other OSs do that thing they do where they give an error message if two hosts are accidentally configured with the same IP address. Detecting address conflicts is not difficult, but to date there has been no IETF Standard specifying how to do it. The only RFC I could find that even mentions IPv4 address conflict detection is RFC 2131, where it says things like: If the client detects that the address is already in use (e.g., through the use of ARP), the client MUST send a DHCPDECLINE message to the server Unfortunately, RFC 2131 doesn't go into much detail about trivia like how many ARP packets to send, how long to wait, etc. This is not a criticism of RFC 2131, because defining IPv4 address conflict detection is rightly outside the scope of RFC 2131. Ideally, there should have been an existing specification for RFC 2131 to reference, like this: If the client detects that the address is already in use [RFC xxxx], the client MUST send a DHCPDECLINE message to the server Sadly, that specification did not exist when RFC 2131 was written. To remedy this, I have written a short draft specifying how to detect address conflicts. I'm sending this email not because I think that DHC or MOBILEIP ought to take on this work, but because I think that if it eventually becomes an RFC then DHC and MOBILEIP may want to reference it in their own standards, so I want to give everyone a chance to take a look and see if they like what it says. DHCP depends on a conflict detection mechanism in order to trigger a DHCP DECLINE packet. My hope is that this draft is a clear specification of how to perform that conflict detection, so that if/when RFC 2131 is updated, it can reference this specification instead of again saying, "e.g., through the use of ARP." I think it makes sense to publish IPv4 Address Conflict Detection as a separate standard, because while address conflict detection is important for a DHCP client, it is useful no matter how a host is configured. If a host is configured manually, then address conflict detection allows the host to display an error message if two hosts are accidentally given the same address. If a host is using a Zeroconf self-assigned link-local address, then address conflict detection is the mechanism that tells the host it needs to select a different address. Right now, as written, draft-00 specifies that a host probe the network for 8-10 seconds before beginning to use an IP address. For a desktop machine using DHCP, this is probably fine. For a small mobile device, it may not be fine. A small mobile device may want to be allowed to access the network much quicker than that. For this reason, feedback from MOBILEIP would be good. One of the problems on today's networks is that Ethernet switches that implement spanning tree often silently discard all packets for many seconds, which makes it hard to say how long a host should probe before using an address. One possibility is that we could revise the draft to say that on networks where successful connectivity can be determined by the hardware with some acceptable degree of certainty, all the timeouts can be ten times shorter than currently specified: i.e. 0-200ms initial delay, four packets 200ms apart, for a total probing time of 800-1000ms. Thoughts? Stuart Cheshire * Wizard Without Portfolio, Apple Computer * Chairman, IETF ZEROCONF * www.stuartcheshire.org _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 4 16:22:21 2002 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 QAA06198; Mon, 4 Feb 2002 16:22:21 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01098; Mon, 4 Feb 2002 16:21:25 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA01067 for ; Mon, 4 Feb 2002 16:21:13 -0500 (EST) Received: from mercury.netopia.com (mail.netopia.com [163.176.4.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06189 for ; Mon, 4 Feb 2002 16:21:10 -0500 (EST) Received: from netopia.com ([163.176.45.190]) by mercury.netopia.com (Netscape Messaging Server 4.15) with ESMTP id GR11YI00.MQV; Mon, 4 Feb 2002 13:20:42 -0800 Message-ID: <3C5EFAE5.B85DBFD7@netopia.com> Date: Mon, 04 Feb 2002 13:19:33 -0800 From: "Matt Frick" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Waters CC: dhcwg@ietf.org Subject: Re: [dhcwg] Confusion on RFC 3011 subnet selection option References: <0D7FC1D8D861D511AEA70002A52CE5E60136F72A@zcard0ke.ca.nortel.com> 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 In the case where a server is serving addresses from multiple logical subnets on the same network segment, how does the server know which subnet the DHCP client is sending the DHCP discover/request out on when it's broadcast to all 1s? It seems like this would be the most appropriate option for selecting the subnet in the above scenario, but requiring the giaddr to be set prevents it from being usable in the above scenario. Is there any way it could have been written so that the option would work directly from a DHCP client to a DHCP server such as the above scenario? It seems like requiring the giaddr is only useful when there's no routing between the two interfaces, but by forcing it to be required, doesn't that make this option only usable in that specific circumstance? -Matt Frick Glenn Waters wrote: > > > This option is intended for use by a device that is requesting address > on behalf of another device. The word client in this case implies that > you already have an IP address (static or dynamic). > > This option is not intended to allocate an address on a specific > subnet on devices that are connected to multiple subnets. The correct > way to allocate an address on a specific subnet is to send the DHCP > request out on the subnet for which you wish to have an address > allocated. > > /gww > > -----Original Message----- > From: Matt Frick [mailto:mfrick@netopia.com] > Sent: Friday, February 01, 2002 18:50 > To: dhcwg@ietf.org > Subject: [dhcwg] Confusion on RFC 3011 subnet selection option > > After re-reading RFC 3011 many times, I'm still a bit confused, and > hopefully there are some talented indivuals out there on the email > list > that can help me out. > > From what I understand, (other than the obvious subnet-related parts) > the subnet selection option overrides the current usage of giaddr > which > is used by relay agents to specify: > 1) the address to which the server is to send it's reply, and > 2) the subnet from which to allocate the address. > It seems that the option is designed to be used / necessary only when > a > relay agent needs the server to reply to an address on a subnet that > is > different than the subnet on which the address should be allocated, > since > > "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)." [RFC 3011, page 4] > > Since the RAS device in the motivational example is connected to the > internal network on which the DHCP server is located, does that mean > that the RAS device is the "client" in the above quote? If it is, > then > that would explain why it has an address on which it can receive DHCP > packets to put in the giaddr when sending a discover or request (ie. > when it's not bound) -- perhaps the address sent in the giaddr field > is > not a DHCP obtained address, but a statically defined address on the > internal network. > > Can this option be sent by a end client (host) directly to a server, > or > must it pass through a relay agent? The reason it seems likely that a > > relay agent is required, is that when the giaddr is nonzero, the > server > will repond to the server port, not the client port: > > "The server SHOULD next check the 'giaddr' field. If this > field > is > non-zero, the server SHOULD send the BOOTREPLY as an IP > unicast > to the IP address identified in the 'giaddr' field. The UDP > destination port MUST be set to BOOTPS (67)." [RFC 1542, page > 20] > > especially since: > > "This option does not require changes to operations or > features > of the > DHCP server other than to select the subnet on which to > allocate > on > address." [RFC 3011, page 3] > > So, I guess the big mystery (atleast for me,) is this: can an end > client > send a subnet selection option? When the client doesn't have a > binding > (and it's sending a subnet selection option,) can / should the giaddr > be > set to zero? > Or, is this option reserved for situations more complicated than a > simple scenario where a DHCP server has several subnets and a directly > > connected client wants to request an address on a specific subnet? > > Thanks for reading this far, hopefully this RFC can be clarified. > -Matt Frick > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 4 19:22:06 2002 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 TAA09050; Mon, 4 Feb 2002 19:22:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10599; Mon, 4 Feb 2002 19:21:12 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10568 for ; Mon, 4 Feb 2002 19:21:10 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09042 for ; Mon, 4 Feb 2002 19:21:08 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-128-107-131-58.cisco.com [128.107.131.58]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id TAA21645 for ; Mon, 4 Feb 2002 19:20:39 -0500 (EST) Message-Id: <4.3.2.7.2.20020204113352.01d95008@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Feb 2002 11:47:45 -0500 To: dhcwg@ietf.org From: Ralph Droms Subject: Re: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt In-Reply-To: <200202011732.g11HWEF01880@rotala.raleigh.ibm.com> References: 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 Mentioning 3118 (rather than requiring its use) seems right to me. As Thomas points out, the text from Security Considerations of draft-aboba-dhc-domsearch-09.txt would provide a starting point. Bill Arbaugh may know of an experimental implementation. I don't know of any commercial implementations. A new protocol that only authenticates servers to clients would likely be useful - I'd like to get feedback from anyone on the list who would deploy such a system if it were available. - Ralph At 12:32 PM 2/1/2002 -0500, Thomas Narten wrote: > > I would like to avoid having these two drafts require the > implementation of > > RFC3118, since RFC3118 by itself isn't very deployable. > >Plus, has anyone even implemented it yet? Please? > >On the point of 3118 deployability, there has been some private >discussion that what would be useful to have is a DHC authentication >mechanism that can use certificates, and that only authenticates the >server to the client. This would seem to be a useful deployment >scenario. Thoughts? > >Also, note that the final wording in draft-aboba-dhc-domsearch-09.txt >on this point didn't require the use of 3118, but did point out its >existance. That made it through the IESG (but it also prompted the >above discussion about the desirability of a more useful/deployable >authentication mechanism). > >Thomas > > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 4 20:06:19 2002 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 UAA09517; Mon, 4 Feb 2002 20:06:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12061; Mon, 4 Feb 2002 19:57:43 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA12031 for ; Mon, 4 Feb 2002 19:57:41 -0500 (EST) Received: from mta6.snfc21.pbi.net (mta6.snfc21.pbi.net [206.13.28.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09430 for ; Mon, 4 Feb 2002 19:57:38 -0500 (EST) Received: from BarrH63p601 ([64.170.117.6]) by mta6.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0GR100H1LC03GC@mta6.snfc21.pbi.net> for dhcwg@ietf.org; Mon, 04 Feb 2002 16:57:40 -0800 (PST) Date: Mon, 04 Feb 2002 16:57:34 -0800 From: Richard Barr Hibbs Subject: RE: [dhcwg] IESG feedback on draft-ietf-dhc-concat-01.txt In-reply-to: <4.3.2.7.2.20020204113352.01d95008@funnel.cisco.com> To: Ralph Droms , dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal 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 > -----Original Message----- > From: Ralph Droms > Sent: Monday, February 04, 2002 08:48 > > A new protocol that only authenticates servers to clients would likely be > useful - I'd like to get feedback from anyone on the list who > would deploy > such a system if it were available. > Ralph-- see the earlier message from Hai Ku about security issues and my reply: he seems to be seeking a way to authenticate servers to clients. --Barr _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 01:10:56 2002 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 BAA15311; Tue, 5 Feb 2002 01:10:56 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24220; Tue, 5 Feb 2002 00:32:20 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24197 for ; Tue, 5 Feb 2002 00:32:18 -0500 (EST) Received: from dumburken.it.kth.se (dumburken.it.kth.se [130.237.212.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA14952 for ; Tue, 5 Feb 2002 00:32:17 -0500 (EST) Received: (from maguire@localhost) by dumburken.it.kth.se (8.9.3/8.9.3) id GAA08761; Tue, 5 Feb 2002 06:32:14 +0100 (MET) Date: Tue, 5 Feb 2002 06:32:14 +0100 (MET) Message-Id: <200202050532.GAA08761@dumburken.it.kth.se> X-Authentication-Warning: dumburken.it.kth.se: maguire set sender to maguire@dumburken.it.kth.se using -f From: Gerald Maguire To: mobile-ip@sunroof.eng.sun.com CC: dhcwg@ietf.org, mobile-ip@sunroof.eng.sun.com In-reply-to: <200202041944.g14JiY026372@scv2.apple.com> (message from Stuart Cheshire on Mon, 4 Feb 2002 11:44:34 -0800) References: <200202041944.g14JiY026372@scv2.apple.com> Subject: [dhcwg] Re: [mobile-ip] IPv4 Address Conflict Detection 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 think the idea of probing and waiting _before_ using an address is completely wrong. Since it involves waiting for something _not_ to happen. The better approach is to detect the conflict -- if there is one. See: @misc{ vatn-effect, author = "Jon-Olov Vatn and Gerald Q. Maguire Jr.", title = "The effect of using co-located care-of addresses on macro handover latency", url = "http://citeseer.nj.nec.com/264743.html" } ftp://ftp.it.kth.se/Reports/ts/1998/nts14-coloc.pdf This paper shows that the DHCP server can be doing testing of addresses in advance and this significantly reduce the time required to assign and address. This is critical if you are going to give a mobile device an IP address on a new segment when it arrive and avoid having to drop packets for it (for example from an audio stream). See also: Jon-Olov Vatn, "Long Random Wait Times for Getting a Care-of Address are a Danger to Mobile Multimedia", 1999 IEEE International Workshop on Mobile Multimedia Communications (MoMuC'99), 15-17 November 1999, San Diego, CA USA. http://www.it.kth.se/~vatn/research/momuc-copyright.pdf For his licentiate thesis which includes the above and more see: http://www.it.kth.se/~vatn/mac/lic_prop.fm5.ps Chip _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 01:17:23 2002 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 BAA15379; Tue, 5 Feb 2002 01:17:23 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24477; Tue, 5 Feb 2002 00:41:46 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA24449 for ; Tue, 5 Feb 2002 00:41:44 -0500 (EST) Received: from odin.ietf.org ([218.17.120.252]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15034 for ; Tue, 5 Feb 2002 00:41:42 -0500 (EST) Date: Tue, 5 Feb 2002 00:41:42 -0500 (EST) From: jackywong001@hotmail.com Message-Id: <200202050541.AAA15034@ietf.org> To: dhcwg@ietf.org X-Mailer: WC Mail __ty__ MIME-Version: 1.0 Content-Type: multipart/mixed;boundary= "Z_MULTI_PART_MAIL_BOUNDAEY_S" Subject: [dhcwg] ��̥��I��ڰ�W+��H�s 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 is a multi-part message in MIME format. --Z_MULTI_PART_MAIL_BOUNDAEY_S Content-Type: text/html Content-Transfer-Encoding: base64 PEhUTUw+PEhFQUQ+PE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVudD0idGV4 dC9odG1sOyBjaGFyc2V0PWJpZzUiPg0KPHRpdGxlPqX+tOSzzKWtoUmw6rvasOymVyu69K22 sUimczwvdGl0bGU+DQo8L0hFQUQ+DQo8Qk9EWSBiZ0NvbG9yPSNmZmZmZmYgbGVmdG1hcmdp bj0iMiIgdG9wbWFyZ2luPSIyIj4NCjxESVY+PEZPTlQgZmFjZT2nuspeIHNpemU9Mj4NCiAg PFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBhZGRpbmc9MCB3aWR0aD00NjEgYm9yZGVyPTA+ DQogICAgPFRCT0RZPiANCiAgICA8VFIgYmdDb2xvcj0jZmZmZmNjPg0KICAgICAgPFRIIHZB bGlnbj10b3AgaGVpZ2h0PTI0NiBiZ2NvbG9yPSIjZmFkMDAwIj4gDQogICAgICAgICA8VEFC TEUgY2VsbFNwYWNpbmc9MCBjZWxsUGFkZGluZz0wIHdpZHRoPSI4OCUiIGJvcmRlcj0xPg0K ICAgICAgICAgIDxUQk9EWT4gDQogICAgICAgICAgPFRSIGJnQ29sb3I9IzMzOTljYz4NCiAg ICAgICAgICAgIDxURCBhbGlnbj0iY2VudGVyIiBoZWlnaHQ9IjUzIiBiZ2NvbG9yPSI0Mjg0 Y2Uic3R5bGU9ImxpbmUtaGVpZ2h0OjE4cHQiPiANCiAgICAgICAgICAgICAgPFA+PEZPTlQg Y29sb3I9I2ZmZmZmZiANCiAgICAgICAgICAgIHNpemU9Mz48Qj48YSBocmVmPSJodHRwOi8v d3d3LnNhbGUuY29tLmhrIj48aW1nIHNyYz0iaHR0cDovL3d3dy4xMjMzMjEuY29tL0hLLVNa L2Jhbm5lci9iYW5uZXI3LmdpZiIgd2lkdGg9IjQ2OCIgaGVpZ2h0PSI2MCIgYm9yZGVyPSIw Ij48L2E+PC9CPjwvRk9OVD48L1A+DQogICAgICAgICAgICA8L1REPjwvVFI+PC9UQk9EWT48 L1RBQkxFPg0KICAgICAgICANCiAgICAgICAgPFRBQkxFIGNlbGxTcGFjaW5nPTAgY2VsbFBh ZGRpbmc9MCB3aWR0aD00NjggYm9yZGVyPTE+DQogICAgICAgICAgPFRCT0RZPiANCiAgICAg ICAgICA8VFIgYWxpZ249ImNlbnRlciI+IA0KICAgICAgICAgICAgPFREIGNvbHNwYW49IjIi IGhlaWdodD0zNSA+IA0KICAgICAgICAgICAgICA8cD48YSBocmVmPSJodHRwOi8vd3d3LnNh bGUuY29tLmhrIj48Zm9udCBzaXplPTM+PGI+PGZvbnQgDQogICAgICAgICAgICBzaXplPTM+ saGkSLhgsGWkV7PMprOk36vkqrrCp6qrtbmk36RXpEghIKRApn6ldbvdPC9mb250PjwvYj48 L2ZvbnQ+PGZvbnQgY29sb3I9IzMzMzMzMyBzaXplPTM+PGI+PGZvbnQgY29sb3I9I2ZmMDAz MyBzaXplPTQ+IA0KICAgICAgICAgICAgICAgICQzNjg8L2ZvbnQ+IDwvYj48L2ZvbnQ+PC9h PjwvcD4NCiAgICAgICAgICAgIDwvVEQ+DQogICAgICAgICAgPC9UUj4NCiAgICAgICAgICA8 VFI+IA0KICAgICAgICAgICAgPFREIHdpZHRoPTI3NiBoZWlnaHQ9MzI+Jm5ic3A7PEZPTlQg Y29sb3I9IzY2NjZmZiBzaXplPTM+PEEgDQogICAgICAgICAgICBocmVmPSJodHRwOi8vd3d3 LnNhbGUuY29tLmhrLyI+PEZPTlQgY29sb3I9I2ZmMDAzMz48Qj6nS7ZPPC9CPjwvRk9OVD4g DQogICAgICAgICAgICAgIDxGT05UIA0KY29sb3I9IzAwMDBmZj6w6rvasOymVyh5b3VyZG9t YWluLmNvbS9uZXQvb3JnKTwvRk9OVD48L0E+PC9GT05UPjwvVEQ+DQogICAgICAgICAgICA8 VEQgd2lkdGg9MTg2IGhlaWdodD0zMj4mbmJzcDs8Rk9OVCBjb2xvcj0jNjY2NmZmIHNpemU9 Mz48QSANCiAgICAgICAgICAgIGhyZWY9Imh0dHA6Ly93d3cuc2FsZS5jb20uaGsvIj48Rk9O VCBjb2xvcj0jZmYwMDMzPjxCPqdLPC9CPiA8L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDBmZj6m d7jLtk88L0ZPTlQ+PC9BPjwvRk9OVD48L1REPg0KICAgICAgICAgIDwvVFI+DQogICAgICAg ICAgPFRSPiANCiAgICAgICAgICAgIDxURCB3aWR0aD0yNzYgaGVpZ2h0PTI2PiZuYnNwOzxG T05UIGNvbG9yPSM2NjY2ZmYgc2l6ZT0zPjxBIA0KICAgICAgICAgICAgaHJlZj0iaHR0cDov L3d3dy5zYWxlLmNvbS5oay8iPjxGT05UIGNvbG9yPSNmZjAwMzM+PEI+MTA8L0I+PC9GT05U PiANCiAgICAgICAgICAgICAgPEZPTlQgY29sb3I9IzAwMDBmZj65caRstmy9YzwvRk9OVD48 L0E+PC9GT05UPjwvVEQ+DQogICAgICAgICAgICA8VEQgd2lkdGg9MTg2IGhlaWdodD0yNj4m bmJzcDs8Rk9OVCBjb2xvcj0jNjY2NmZmIHNpemU9Mz48QSANCiAgICAgICAgICAgIGhyZWY9 Imh0dHA6Ly93d3cuc2FsZS5jb20uaGsvIj48Rk9OVCANCiAgICAgICAgICAgIGNvbG9yPSNm ZjAwMzM+PEI+NDBNQjwvQj48L0ZPTlQ+PEZPTlQgY29sb3I9IzAwMDBmZj4gwHimc6rFtqE8 L0ZPTlQ+PC9BPjwvRk9OVD48L1REPg0KICAgICAgICAgIDwvVFI+DQogICAgICAgICAgPFRS PiANCiAgICAgICAgICAgIDxURCB3aWR0aD0yNzYgaGVpZ2h0PTM1PiZuYnNwOzxGT05UIGNv bG9yPSM2NjY2ZmYgc2l6ZT0zPjxBIA0KICAgICAgICAgICAgaHJlZj0iaHR0cDovL3d3dy5z YWxlLmNvbS5oay8iPjxGT05UIA0KICAgICAgICAgICAgY29sb3I9I2ZmMDAzMz48Qj61TK2t PC9CPjwvRk9OVD48Rk9OVCBjb2xvcj0jMDAwMGZmPiBFbWFpbCBGb3J3YXJkaW5nPC9GT05U PjwvQT48L0ZPTlQ+PC9URD4NCiAgICAgICAgICAgIDxURCB3aWR0aD0xODYgaGVpZ2h0PTM1 PiZuYnNwOzxGT05UIGNvbG9yPSM2NjY2ZmYgc2l6ZT0zPjxBIA0KICAgICAgICAgICAgaHJl Zj0iaHR0cDovL3d3dy5zYWxlLmNvbS5oay8iPjxGT05UIGNvbG9yPSNmZjAwMzM+PEI+MjQg PC9CPjwvRk9OVD48Rk9OVCANCiAgICAgIGNvbG9yPSMwMDAwZmY+pHCuyUZUUDwvRk9OVD48 L0E+PC9GT05UPjwvVEQ+DQogICAgICAgICAgPC9UUj4NCiAgICAgICAgICA8L1RCT0RZPiAN CiAgICAgICAgPC9UQUJMRT48YnI+DQogICAgICAgIDxBIGhyZWY9Imh0dHA6Ly93d3cuc2Fs ZS5jb20uaGsvIj48Rk9OVCBzaXplPTM+PEZPTlQgDQogICAgICBjb2xvcj0jMDAwMGZmPr3Q pd+nWaXTvdChQbzGpOmr4atLpWm+1qazptukdrDsplequrr0r7ggoUk8L0ZPTlQ+PC9GT05U PjwvQT48YnI+PGJyPg0KICAgICAgICA8Rk9OVCBmYWNlPae6xekgY29sb3I9IzAwMDBmZj6l 073Qrsm90L/ppEqxTaXOpU64uaGnc2FsZWNvZGWhqDombmJzcDs8Zm9udCBjb2xvcj0iI2Zm MDAwMCIgc2l6ZT0iNCI+c2FsZTwvZm9udD48L0ZPTlQ+PC9USD4NCiAgICA8L1RSPg0KICA8 VFIgYmdDb2xvcj0jMDBjY2NjPg0KICAgICAgPFREIGhlaWdodD0yNCBiZ2NvbG9yPSI0YTg0 Y2UiPiANCiAgICAgICAgPERJViBhbGlnbj1jZW50ZXI+PEZPTlQgY29sb3I9I2ZmZmZmZj48 Rk9OVCBzaXplPTU+PEEgDQogICAgICBocmVmPSJodHRwOi8vd3d3LnNhbGUuY29tLmhrLyI+ PEZPTlQgY29sb3I9I2ZmZmY2Nj48ST48Zm9udCBjb2xvcj0iI0ZGRkZGRiIgc2l6ZT0iNCI+ PGI+dyANCiAgICAgICAgICB3IHcgLiBzIGEgbCBlIC4gYyBvIG0gLiBoIGs8L2I+PC9mb250 PjwvST48L0ZPTlQ+PC9BPjwvRk9OVD48L0ZPTlQ+PC9ESVY+PC9URD4NCiAgICA8L1RSPjwv VEJPRFk+DQo8L1RBQkxFPg0KICA8L0ZPTlQ+PC9ESVY+DQo8L0JPRFk+PC9IVE1MPiAgICA= --Z_MULTI_PART_MAIL_BOUNDAEY_S-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 01:37:01 2002 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 BAA15636; Tue, 5 Feb 2002 01:37:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25122; Tue, 5 Feb 2002 00:58:59 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA25100 for ; Tue, 5 Feb 2002 00:58:58 -0500 (EST) Received: from donkeykong.gpcc.itd.umich.edu (smtp@donkeykong.gpcc.itd.umich.edu [141.211.2.163]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15239 for ; Tue, 5 Feb 2002 00:58:56 -0500 (EST) Received: from robotron.gpcc.itd.umich.edu (robotron.gpcc.itd.umich.edu [141.211.2.207]) by donkeykong.gpcc.itd.umich.edu (8.8.8/4.3-mailhub) with ESMTP id AAA07576 for ; Tue, 5 Feb 2002 00:58:57 -0500 (EST) Received: from localhost (sgoswami@localhost) by robotron.gpcc.itd.umich.edu (8.9.1a/5.1-client) with ESMTP id AAA27504 for ; Tue, 5 Feb 2002 00:58:56 -0500 (EST) Precedence: first-class Date: Tue, 5 Feb 2002 00:58:56 -0500 (EST) From: "s. goswami" X-X-Sender: cc: DHCP discussion list In-Reply-To: <200202041944.g14JiY026372@scv2.apple.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Re: [mobile-ip] IPv4 Address Conflict Detection 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 a DHCP server is used, should not it know what addresses are usuable and what not ? Why should the host's DHCP client be reponsible for figuirng out if the IP addresses is all ready being used ? If DHCP client figures out that the IP address is being us but the DHCP server can not figure that out, would not there be a problem (i.e if a particular MAC address is offered a particular IP adress as is done in many cases) ? On Mon, 4 Feb 2002, Stuart Cheshire wrote: > At the DHC WG meeting in Salt Lake City we briefly talked about address > conflict detection. The feedback I got was that while it is definitely > useful to nail down a clear specification of how do do address conflict > detection properly, it doesn't have an obvious natural "home" in any > current IETF WG, so I should just solicit feedback and then send it in as > an individual submission. The two working groups we felt had expertise in > this area are DHC and MOBILEIP, hence this email: > > ---------------- > > >From time to time people ask how Mac OS, Windows, and other OSs do that > thing they do where they give an error message if two hosts are > accidentally configured with the same IP address. > > Detecting address conflicts is not difficult, but to date there has been > no IETF Standard specifying how to do it. The only RFC I could find that > even mentions IPv4 address conflict detection is RFC 2131, where it says > things like: > > If the client detects that the address is already in use > (e.g., through the use of ARP), the client MUST send > a DHCPDECLINE message to the server > > Unfortunately, RFC 2131 doesn't go into much detail about trivia like how > many ARP packets to send, how long to wait, etc. This is not a criticism > of RFC 2131, because defining IPv4 address conflict detection is rightly > outside the scope of RFC 2131. Ideally, there should have been an > existing specification for RFC 2131 to reference, like this: > > If the client detects that the address is already in use [RFC xxxx], > the client MUST send a DHCPDECLINE message to the server > > Sadly, that specification did not exist when RFC 2131 was written. To > remedy this, I have written a short draft specifying how to detect > address conflicts. > > > > I'm sending this email not because I think that DHC or MOBILEIP ought to > take on this work, but because I think that if it eventually becomes an > RFC then DHC and MOBILEIP may want to reference it in their own > standards, so I want to give everyone a chance to take a look and see if > they like what it says. > > DHCP depends on a conflict detection mechanism in order to trigger a DHCP > DECLINE packet. My hope is that this draft is a clear specification of > how to perform that conflict detection, so that if/when RFC 2131 is > updated, it can reference this specification instead of again saying, > "e.g., through the use of ARP." > > I think it makes sense to publish IPv4 Address Conflict Detection as a > separate standard, because while address conflict detection is important > for a DHCP client, it is useful no matter how a host is configured. If a > host is configured manually, then address conflict detection allows the > host to display an error message if two hosts are accidentally given the > same address. If a host is using a Zeroconf self-assigned link-local > address, then address conflict detection is the mechanism that tells the > host it needs to select a different address. > > Right now, as written, draft-00 specifies that a host probe the network > for 8-10 seconds before beginning to use an IP address. For a desktop > machine using DHCP, this is probably fine. For a small mobile device, it > may not be fine. A small mobile device may want to be allowed to access > the network much quicker than that. For this reason, feedback from > MOBILEIP would be good. One of the problems on today's networks is that > Ethernet switches that implement spanning tree often silently discard all > packets for many seconds, which makes it hard to say how long a host > should probe before using an address. One possibility is that we could > revise the draft to say that on networks where successful connectivity > can be determined by the hardware with some acceptable degree of > certainty, all the timeouts can be ten times shorter than currently > specified: i.e. 0-200ms initial delay, four packets 200ms apart, for a > total probing time of 800-1000ms. Thoughts? > > Stuart Cheshire > * Wizard Without Portfolio, Apple Computer > * Chairman, IETF ZEROCONF > * www.stuartcheshire.org > > _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 02:47:32 2002 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 CAA24873; Tue, 5 Feb 2002 02:47:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09896; Tue, 5 Feb 2002 02:32:50 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA09853 for ; Tue, 5 Feb 2002 02:32:48 -0500 (EST) Received: from localhost ([211.183.238.27]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA24725 for ; Tue, 5 Feb 2002 02:32:44 -0500 (EST) Message-Id: <200202050732.CAA24725@ietf.org> Reply-To: office7000@yahoo.co.kr From: �� To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Tue, 5 Feb 2002 16:33:17 +0900 Subject: [dhcwg] [��] ��� ̵�� [��Űźΰ��մϴ�] 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 �� Ͻø� �� ǻ縦 ��ϰڽ��ϴ�.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 09:51:43 2002 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 JAA01872; Tue, 5 Feb 2002 09:51:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03422; Tue, 5 Feb 2002 09:50:40 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03352 for ; Tue, 5 Feb 2002 09:50:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01629; Tue, 5 Feb 2002 09:50:34 -0500 (EST) Message-Id: <200202051450.JAA01629@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Feb 2002 09:50:33 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-dstm-00.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 --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 : DSTM Options for DHCPv6 Author(s) : J. Bound et al. Filename : draft-ietf-dhc-dhcpv6-opt-dstm-00.txt Pages : 6 Date : 04-Feb-02 The DSTM Global IPv4 Address option and the DSTM Tunnel Endpoint Option provide DSTM (Dual Stack Transition Mechanism) configuration information to DHCPv6 hosts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-dstm-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020204134010.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dstm-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-dstm-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020204134010.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 09:52:11 2002 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 JAA02014; Tue, 5 Feb 2002 09:52:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03346; Tue, 5 Feb 2002 09:50:33 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03316 for ; Tue, 5 Feb 2002 09:50:31 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01613; Tue, 5 Feb 2002 09:50:29 -0500 (EST) Message-Id: <200202051450.JAA01613@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Tue, 05 Feb 2002 09:50:28 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-opt-dnsconfig-00.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 --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 : DNS Configuration Options for DHCPv6 Author(s) : J. Bound et al. Filename : draft-ietf-dhc-dhcpv6-opt-dnsconfig-00.txt Pages : 8 Date : 04-Feb-02 This document describes three options for DNS-related configuration information in DHCPv6: DNS Servers, Domain Name, Domain Search list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-opt-dnsconfig-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020204133958.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-opt-dnsconfig-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-opt-dnsconfig-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020204133958.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 09:56:31 2002 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 JAA02218; Tue, 5 Feb 2002 09:56:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03946; Tue, 5 Feb 2002 09:55:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA03925 for ; Tue, 5 Feb 2002 09:55:36 -0500 (EST) Received: from firewall.agranat.com (agranat.com [198.113.147.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02185 for ; Tue, 5 Feb 2002 09:55:34 -0500 (EST) From: dworley@globespanvirata.com Received: from agranat.com (alice.agranat.com [10.21.0.130]) by firewall.agranat.com (8.9.0/8.9.0) with ESMTP id JAA22180; Tue, 5 Feb 2002 09:54:47 -0500 Received: from dhcp75.ma.virata.com (dhcp75.ma.virata.com [10.21.0.75]) by agranat.com (8.11.6/8.11.6) with ESMTP id g15EskQ30825; Tue, 5 Feb 2002 09:54:46 -0500 Received: (from worley@localhost) by dhcp75.ma.virata.com (8.11.0/8.11.0) id g15Eskg12995; Tue, 5 Feb 2002 09:54:46 -0500 Date: Tue, 5 Feb 2002 09:54:46 -0500 Message-Id: <200202051454.g15Eskg12995@dhcp75.ma.virata.com> X-Authentication-Warning: dhcp75.ma.virata.com: worley set sender to dworley@globespanvirata.com using -f To: mobile-ip@sunroof.eng.sun.com, dhcwg@ietf.org In-reply-to: <200202050532.GAA08761@dumburken.it.kth.se> (message from Gerald Maguire on Tue, 5 Feb 2002 06:32:14 +0100 (MET)) Subject: Re: [dhcwg] Re: [mobile-ip] IPv4 Address Conflict Detection References: <200202041944.g14JiY026372@scv2.apple.com> <200202050532.GAA08761@dumburken.it.kth.se> X-Scanned-By: MIMEDefang 2.2 (www dot roaringpenguin dot com slash mimedefang) 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 From: Gerald Maguire I think the idea of probing and waiting _before_ using an address is completely wrong. Since it involves waiting for something _not_ to happen. The better approach is to detect the conflict -- if there is one. IMHO, detecting address conflicts is not a matter of a single strategy. For instance, if there aren't resource limitations, DHCP clients should check for address conflicts, but DHCP servers should also. Hosts should also continuously monitor their interfaces for evidence of duplicate addresses (e.g., ARPs from other hosts holding the same address). Especially because this is the first attempt to formalize address conflict detection, we should be documenting all methods that are known to be useful, preferably with notes on their costs and benefits, and circumstances in which they are known to be particularly useful. Dale _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 10:03:07 2002 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 KAA02500; Tue, 5 Feb 2002 10:03:07 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04810; Tue, 5 Feb 2002 10:02:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA04773 for ; Tue, 5 Feb 2002 10:02:12 -0500 (EST) Received: from zcars0m9.ca.nortel.com (zcars0m9.nortelnetworks.com [47.129.242.157]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02425 for ; Tue, 5 Feb 2002 10:02:10 -0500 (EST) Received: from zcars04f.ca.nortel.com (zcars04f.ca.nortel.com [47.129.242.57]) by zcars0m9.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15F1bH25380; Tue, 5 Feb 2002 10:01:37 -0500 (EST) Received: from zcard015.ca.nortel.com (zcard015.ca.nortel.com [47.129.30.7]) by zcars04f.ca.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id g15F1Z310261; Tue, 5 Feb 2002 10:01:36 -0500 (EST) Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <1J339F16>; Tue, 5 Feb 2002 10:01:35 -0500 Message-ID: <0D7FC1D8D861D511AEA70002A52CE5E6013703ED@zcard0ke.ca.nortel.com> From: "Glenn Waters" To: Matt Frick Cc: dhcwg@ietf.org Subject: RE: [dhcwg] Confusion on RFC 3011 subnet selection option Date: Tue, 5 Feb 2002 10:01:33 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1AE56.000C4870" 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_01C1AE56.000C4870 Content-Type: text/plain Comments inline... -----Original Message----- From: Matt Frick [mailto:mfrick@netopia.com] Sent: Monday, February 04, 2002 16:20 To: Waters, Glenn [CAR:IO47:EXCH] Cc: dhcwg@ietf.org Subject: Re: [dhcwg] Confusion on RFC 3011 subnet selection option In the case where a server is serving addresses from multiple logical subnets on the same network segment, how does the server know which subnet the DHCP client is sending the DHCP discover/request out on when it's broadcast to all 1s? The server knows which subnet the discover/request are sent on by either receiving the packet on a directly connected subnet or by the giaddr. It seems like this would be the most appropriate option for selecting the subnet in the above scenario, but requiring the giaddr to be set prevents it from being usable in the above scenario. Is there any way it could have been written so that the option would work directly from a DHCP client to a DHCP server such as the above scenario? It seems like requiring the giaddr is only useful when there's no routing between the two interfaces, but by forcing it to be required, doesn't that make this option only usable in that specific circumstance? The subnet selection option is NOT specifically designed for a client to select its own subnet. It is designed for devices that act on behalf of other clients (DHCP or otherwise). -Matt Frick Glenn Waters wrote: > > > This option is intended for use by a device that is requesting address > on behalf of another device. The word client in this case implies that > you already have an IP address (static or dynamic). > > This option is not intended to allocate an address on a specific > subnet on devices that are connected to multiple subnets. The correct > way to allocate an address on a specific subnet is to send the DHCP > request out on the subnet for which you wish to have an address > allocated. > > /gww > > -----Original Message----- > From: Matt Frick [mailto:mfrick@netopia.com] > Sent: Friday, February 01, 2002 18:50 > To: dhcwg@ietf.org > Subject: [dhcwg] Confusion on RFC 3011 subnet selection option > > After re-reading RFC 3011 many times, I'm still a bit confused, and > hopefully there are some talented indivuals out there on the email > list > that can help me out. > > From what I understand, (other than the obvious subnet-related parts) > the subnet selection option overrides the current usage of giaddr > which > is used by relay agents to specify: > 1) the address to which the server is to send it's reply, and > 2) the subnet from which to allocate the address. > It seems that the option is designed to be used / necessary only when > a > relay agent needs the server to reply to an address on a subnet that > is > different than the subnet on which the address should be allocated, > since > > "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)." [RFC 3011, page 4] > > Since the RAS device in the motivational example is connected to the > internal network on which the DHCP server is located, does that mean > that the RAS device is the "client" in the above quote? If it is, > then > that would explain why it has an address on which it can receive DHCP > packets to put in the giaddr when sending a discover or request (ie. > when it's not bound) -- perhaps the address sent in the giaddr field > is > not a DHCP obtained address, but a statically defined address on the > internal network. > > Can this option be sent by a end client (host) directly to a server, > or > must it pass through a relay agent? The reason it seems likely that a > > relay agent is required, is that when the giaddr is nonzero, the > server > will repond to the server port, not the client port: > > "The server SHOULD next check the 'giaddr' field. If this > field > is > non-zero, the server SHOULD send the BOOTREPLY as an IP > unicast > to the IP address identified in the 'giaddr' field. The UDP > destination port MUST be set to BOOTPS (67)." [RFC 1542, page > 20] > > especially since: > > "This option does not require changes to operations or > features > of the > DHCP server other than to select the subnet on which to > allocate > on > address." [RFC 3011, page 3] > > So, I guess the big mystery (atleast for me,) is this: can an end > client > send a subnet selection option? When the client doesn't have a > binding > (and it's sending a subnet selection option,) can / should the giaddr > be > set to zero? > Or, is this option reserved for situations more complicated than a > simple scenario where a DHCP server has several subnets and a directly > > connected client wants to request an address on a specific subnet? > > Thanks for reading this far, hopefully this RFC can be clarified. > -Matt Frick > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C1AE56.000C4870 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Confusion on RFC 3011 subnet selection = option

Comments inline...

-----Original Message-----
From: Matt Frick [mailto:mfrick@netopia.com] =
Sent: Monday, February 04, 2002 16:20
To: Waters, Glenn [CAR:IO47:EXCH]
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] Confusion on RFC 3011 subnet = selection option

In the case where a server is serving addresses from = multiple logical
subnets on the same network segment, how does the = server know which
subnet the DHCP client is sending the DHCP = discover/request out on when
it's broadcast to all 1s?

</gww>
The server knows which subnet the discover/request = are sent on by either receiving the packet on a directly connected = subnet or by the giaddr.

<gww/>

It seems like this would be the most appropriate = option for selecting
the subnet in the above scenario, but requiring the = giaddr to be set
prevents it from being usable in the above = scenario. Is there any way
it could have been written so that the option would = work directly from a
DHCP client to a DHCP server such as the above = scenario? It seems like
requiring the giaddr is only useful when there's no = routing between the
two interfaces, but by forcing it to be required, = doesn't that make this
option only usable in that specific = circumstance?

</gww>
The subnet selection option is NOT specifically = designed for a client to select its own subnet. It is designed for = devices that act on behalf of other clients (DHCP or = otherwise).

<gww/>

-Matt Frick

Glenn Waters wrote:

>
>
> This option is intended for use by a device = that is requesting address
> on behalf of another device. The word client in = this case implies that
> you already have an IP address (static or = dynamic).
>
> This option is not intended to allocate an = address on a specific
> subnet on devices that are connected to = multiple subnets. The correct
> way to allocate an address on a specific subnet = is to send the DHCP
> request out on the subnet for which you wish to = have an address
> allocated.
>
> /gww
>
> -----Original Message-----
> From: Matt Frick [mailto:mfrick@netopia.com]=
> Sent: Friday, February 01, 2002 18:50
> To: dhcwg@ietf.org
> Subject: [dhcwg] Confusion on RFC 3011 subnet = selection option
>
> After re-reading RFC 3011 many times, I'm still = a bit confused, and
> hopefully there are some talented indivuals out = there on the email
> list
> that can help me out.
>
> From what I understand, (other than the obvious = subnet-related parts)
> the subnet selection option overrides the = current usage of giaddr
> which
> is used by relay agents to specify:
> 1) the address to which the server is to send = it's reply, and
> 2) the subnet from which to allocate the = address.
> It seems that the option is designed to be used = / necessary only when
> a
> relay agent needs the server to reply to an = address on a subnet that
> is
> different than the subnet on which the address = should be allocated,
> since
>
>         = "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)." [RFC 3011, page 4]
>
> Since the RAS device in the motivational = example is connected to the
> internal network on which the DHCP server is = located, does that mean
> that the RAS device is the "client" = in the above quote? If it is,
> then
> that would explain why it has an address on = which it can receive DHCP
> packets to put in the giaddr when sending a = discover or request (ie.
> when it's not bound) -- perhaps the address = sent in the giaddr field
> is
> not a DHCP obtained address, but a statically = defined address on the
> internal network.
>
> Can this option be sent by a end client (host) = directly to a server,
> or
> must it pass through a relay agent? The = reason it seems likely that a
>
> relay agent is required, is that when the = giaddr is nonzero, the
> server
> will repond to the server port, not the client = port:
>
>        = "The server SHOULD next check the 'giaddr' field. If = this
> field
> is
>         = non-zero, the server SHOULD send the BOOTREPLY as an IP
> unicast
>         = to the IP address identified in the 'giaddr' field. The = UDP
>         = destination port MUST be set to BOOTPS (67)." [RFC 1542, = page
> 20]
>
> especially since:
>
>         = "This option does not require changes to operations or
> features
> of the
>         = DHCP server other than to select the subnet on which to
> allocate
> on
>         = address." [RFC 3011, page 3]
>
> So, I guess the big mystery (atleast for me,) = is this: can an end
> client
> send a subnet selection option? When the = client doesn't have a
> binding
> (and it's sending a subnet selection option,) = can / should the giaddr
> be
> set to zero?
> Or, is this option reserved for situations more = complicated than a
> simple scenario where a DHCP server has several = subnets and a directly
>
> connected client wants to request an address on = a specific subnet?
>
> Thanks for reading this far, hopefully this RFC = can be clarified.
> -Matt Frick
>
> = _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg

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

------_=_NextPart_001_01C1AE56.000C4870-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 11:17:00 2002 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 LAA06364; Tue, 5 Feb 2002 11:17:00 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10298; Tue, 5 Feb 2002 11:14:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA10277 for ; Tue, 5 Feb 2002 11:14:27 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06268 for ; Tue, 5 Feb 2002 11:14:24 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g15FvIX07413; Tue, 5 Feb 2002 07:57:19 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g15G0bM02743; Tue, 5 Feb 2002 10:00:37 -0600 (CST) Date: Tue, 5 Feb 2002 10:00:37 -0600 Subject: Re: [dhcwg] Confusion on RFC 3011 subnet selection option Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: dhcwg@ietf.org, Matt Frick To: "Glenn Waters" From: Ted Lemon In-Reply-To: <0D7FC1D8D861D511AEA70002A52CE5E6013703ED@zcard0ke.ca.nortel.com> Message-Id: <7EB34DD9-1A51-11D6-ABCA-00039317663C@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 Glenn, I'd just like to point out that DHCP packets are never sent on subnets. They are sent on links. Normally we can get away with confusing subnets for links, but in the case of DHCP, it winds up creating a great deal of confusion. A DHCP server cannot tell on what subnet a client's broadcast was sent - all it can tell is on what link a client's broadcast was sent. So unfortunately there is a natural opportunity to become confused about what the subnet selection option does, which I believe is what happened here. I hate to suggest updating anyhting that's made it to RFC when we have so much other work that's still pending, but it might be worth adding some clarification about this. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 12:07:32 2002 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 MAA08700; Tue, 5 Feb 2002 12:07:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17163; Tue, 5 Feb 2002 12:06:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA17134 for ; Tue, 5 Feb 2002 12:06:30 -0500 (EST) Received: from hoemail1.firewall.lucent.com (hoemail1.lucent.com [192.11.226.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08601 for ; Tue, 5 Feb 2002 12:06:27 -0500 (EST) Received: from sp0002exch001p.wins.lucent.com (h135-88-24-89.lucent.com [135.88.24.89]) by hoemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g15H5xZ06979 for ; Tue, 5 Feb 2002 12:05:59 -0500 (EST) Received: by sp0002exch001p.es.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Feb 2002 18:05:57 +0100 Message-ID: From: "McCullagh, Matthew (Matt)" To: "'dhcwg@ietf.org'" Date: Tue, 5 Feb 2002 18:05:42 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] RFC3004 - User class question. 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 all. RFC 3004 states that "Based on this class, a DHCP server selects the appropriate address pool to assign an address to the client and the appropriate configuration parameters." If I am reading this correctly, any DHCP server which states that it is compliant with RFC 3004 "should" be able to have multiple pools defined using the same private address range - distinguished by user-class. I'll explain a bit more : 1. Company X sells Internet Services to companies A, B, C, D & E. 2. All of these companies have their own private ip@ ranges and refuse to change them. 3. Companies A, C & E all have their networks setup as 192.168.1.x Am I right in assuming that theoretically I could setup a user-class for each company and then define the range of ip@s for each - something like this: dynamic-dhcp range 192.168.1.1 192.168.1.50 class "CompanyA" { option domain-name "CompanyA.com" ; option subnet-mask 255.255.255.0; option dhcp-lease-time 600 } dynamic-dhcp range 192.168.1.1 192.168.1.50 class "CompanyC" { option domain-name "CompanyC.com"; option subnet-mask 255.255.255.0; option dhcp-lease-time 600 } dynamic-dhcp range 192.168.1.1 192.168.1.50 class "CompanyE" { option domain-name "CompanyE.com"; option subnet-mask 255.255.255.0; option dhcp-lease-time 600 } Theoretically each net is distinguished by the user-class so as long as the dhcp clients can send and understand user-class I should have no problem ? Any help at all is more than welcome ! Many thanks in advance and Best Regards, Matt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 12:50:49 2002 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 MAA10741; Tue, 5 Feb 2002 12:50:49 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20609; Tue, 5 Feb 2002 12:42:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA20577 for ; Tue, 5 Feb 2002 12:42:06 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA10389 for ; Tue, 5 Feb 2002 12:42:04 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g15HcdX07617; Tue, 5 Feb 2002 09:38:39 -0800 (PST) Received: from dechen (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g15HfwM02816; Tue, 5 Feb 2002 11:41:58 -0600 (CST) Date: Tue, 5 Feb 2002 11:41:58 -0600 Subject: Re: [dhcwg] RFC3004 - User class question. Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: "'dhcwg@ietf.org'" To: "McCullagh, Matthew (Matt)" From: Ted Lemon In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 > If I am reading this correctly, any DHCP server which states that it is > compliant with RFC 3004 "should" be able to have multiple pools defined > using the same private address range - distinguished by user-class. Yikes! This is a lesson in careful wording of drafts. I am sure that that was not the intention of the authors! It certainly wasn't how I read it during the review. The user class option is just intended to be available to the DHCP server as a way to differentiate between clients based on user-supplied information. How the server uses this is up to the implementor and the server administrator. There is no requirement that servers support the policy you're talking about. Having said that, I'd say it's pretty likely that the server you're using does support address allocation based on user class. The ISC server does, for sure. There's an example of how to configure it in the DHCP Handbook. .. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 13:17:59 2002 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 NAA11868; Tue, 5 Feb 2002 13:17:59 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22641; Tue, 5 Feb 2002 13:12:35 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22612 for ; Tue, 5 Feb 2002 13:12:33 -0500 (EST) Received: from auemail1.firewall.lucent.com (auemail1.lucent.com [192.11.223.161]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11649 for ; Tue, 5 Feb 2002 13:12:31 -0500 (EST) Received: from sp0002exch001p.wins.lucent.com (h135-88-24-89.lucent.com [135.88.24.89]) by auemail1.firewall.lucent.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g15ICUx11116 for ; Tue, 5 Feb 2002 13:12:31 -0500 (EST) Received: by sp0002exch001p.es.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Feb 2002 19:12:29 +0100 Message-ID: From: "McCullagh, Matthew (Matt)" To: "'Ted Lemon'" Cc: "'dhcwg@ietf.org'" Subject: RE: [dhcwg] RFC3004 - User class question. Date: Tue, 5 Feb 2002 19:12:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain 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 Ted, I guess I was reading into it what I wanted/needed to read into it ! I'll certainly look into the ISC option - any ideas how scalable it is. Am checking around to see if we have a copy of your book here ! Many thanks for quick response ! Matt -----Original Message----- From: Ted Lemon [mailto:mellon@nominum.com] Sent: martes, 05 de febrero de 2002 18:42 To: McCullagh, Matthew (Matt) Cc: 'dhcwg@ietf.org' Subject: Re: [dhcwg] RFC3004 - User class question. > If I am reading this correctly, any DHCP server which states that it is > compliant with RFC 3004 "should" be able to have multiple pools defined > using the same private address range - distinguished by user-class. Yikes! This is a lesson in careful wording of drafts. I am sure that that was not the intention of the authors! It certainly wasn't how I read it during the review. The user class option is just intended to be available to the DHCP server as a way to differentiate between clients based on user-supplied information. How the server uses this is up to the implementor and the server administrator. There is no requirement that servers support the policy you're talking about. Having said that, I'd say it's pretty likely that the server you're using does support address allocation based on user class. The ISC server does, for sure. There's an example of how to configure it in the DHCP Handbook. .. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 5 20:22:38 2002 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 UAA26948; Tue, 5 Feb 2002 20:22:38 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14517; Tue, 5 Feb 2002 20:22:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA14498 for ; Tue, 5 Feb 2002 20:22:00 -0500 (EST) Received: from mercury.netopia.com (mail.netopia.com [163.176.4.69]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26938 for ; Tue, 5 Feb 2002 20:21:57 -0500 (EST) Received: from netopia.com ([163.176.45.190]) by mercury.netopia.com (Netscape Messaging Server 4.15) with ESMTP id GR37RL00.H1Z; Tue, 5 Feb 2002 17:21:21 -0800 Message-ID: <3C608477.C98BC49E@netopia.com> Date: Tue, 05 Feb 2002 17:18:47 -0800 From: "Matt Frick" X-Mailer: Mozilla 4.73 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Glenn Waters CC: dhcwg@ietf.org Subject: Re: [dhcwg] Confusion on RFC 3011 subnet selection option References: <0D7FC1D8D861D511AEA70002A52CE5E6013703ED@zcard0ke.ca.nortel.com> 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 OK, one more question (or two,) and I'll stop bothering everyone. ;^) Does "requesting an address on behalf of another device" mean that it's acting as a relay agent, or that it's doing something like obtaining the leases for itself to put in it's available address pool to re-lease to it's clients? Basically, can a relay agent add this option when it realizes that the address that would normally go into the giaddr field cannot be routed to by the DHCP server? -Matt Frick Glenn Waters wrote: > > This option is intended for use by a device that is requesting > address > > on behalf of another device. The word client in this case implies > that > > you already have an IP address (static or dynamic). > > > > This option is not intended to allocate an address on a specific > > subnet on devices that are connected to multiple subnets. The > correct > > way to allocate an address on a specific subnet is to send the DHCP > > request out on the subnet for which you wish to have an address > > allocated. > > > > /gww _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 6 00:45:11 2002 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 AAA04014; Wed, 6 Feb 2002 00:45:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28148; Wed, 6 Feb 2002 00:44:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA28112 for ; Wed, 6 Feb 2002 00:44:12 -0500 (EST) Received: from palrel12.hp.com (palrel12.hp.com [156.153.255.237]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA04007 for ; Wed, 6 Feb 2002 00:44:12 -0500 (EST) Received: from chitha.india.hp.com (chitha.india.hp.com [15.10.43.31]) by palrel12.hp.com (Postfix) with ESMTP id 4A641600850; Tue, 5 Feb 2002 21:43:37 -0800 (PST) Received: (from jitesh@localhost) by chitha.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id KAA02456; Wed, 6 Feb 2002 10:57:19 +0530 (IST) From: Jitesh N Verma Message-Id: <200202060527.KAA02456@chitha.india.hp.com> Subject: Re: [dhcwg] RFC3004 - User class question. To: mm63@lucent.com Date: Wed, 6 Feb 2002 10:57:18 +0530 (IST) Cc: dhcwg@ietf.org In-Reply-To: from "McCullagh, Matthew" at Feb "5," 2002 "06:05:42" pm X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 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 Hi Matt, FYI. HP-UX DHCP server and client has implemented this option/policy. The server identifies the user-class by a tag "class-id". They work well in the situation mentioned in your mail. Cheers, Jitesh > Hi all. > > RFC 3004 states that "Based on this class, a DHCP server selects the > appropriate address pool to assign an address to the client and the > appropriate configuration parameters." > If I am reading this correctly, any DHCP server which states that it is > compliant with RFC 3004 "should" be able to have multiple pools defined > using the same private address range - distinguished by user-class. > > I'll explain a bit more : > 1. Company X sells Internet Services to companies A, B, C, D & E. > 2. All of these companies have their own private ip@ ranges and refuse to > change them. > 3. Companies A, C & E all have their networks setup as 192.168.1.x > > Am I right in assuming that theoretically I could setup a user-class for > each company and then define the range of ip@s for each - something like > this: > > dynamic-dhcp range 192.168.1.1 192.168.1.50 class "CompanyA" { > option domain-name "CompanyA.com" ; > option subnet-mask 255.255.255.0; > option dhcp-lease-time 600 > } > dynamic-dhcp range 192.168.1.1 192.168.1.50 class "CompanyC" { > option domain-name "CompanyC.com"; > option subnet-mask 255.255.255.0; > option dhcp-lease-time 600 > } > dynamic-dhcp range 192.168.1.1 192.168.1.50 class "CompanyE" { > option domain-name "CompanyE.com"; > option subnet-mask 255.255.255.0; > option dhcp-lease-time 600 > } > > Theoretically each net is distinguished by the user-class so as long as the > dhcp clients can send and understand user-class I should have no problem ? > > Any help at all is more than welcome ! > > Many thanks in advance and > > Best Regards, > > Matt > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 6 01:06:03 2002 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 BAA04280; Wed, 6 Feb 2002 01:06:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29775; Wed, 6 Feb 2002 01:05:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA29709 for ; Wed, 6 Feb 2002 01:05:25 -0500 (EST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04266 for ; Wed, 6 Feb 2002 01:05:23 -0500 (EST) Received: from chitha.india.hp.com (chitha.india.hp.com [15.10.43.31]) by palrel10.hp.com (Postfix) with ESMTP id 79EB8C00454; Tue, 5 Feb 2002 22:04:46 -0800 (PST) Received: (from jitesh@localhost) by chitha.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id LAA02496; Wed, 6 Feb 2002 11:18:13 +0530 (IST) From: Jitesh N Verma Message-Id: <200202060548.LAA02496@chitha.india.hp.com> Subject: Re: [dhcwg] Confusion on RFC 3011 subnet selection option To: mellon@nominum.com Date: Wed, 6 Feb 2002 11:18:12 +0530 (IST) Cc: dhcwg@ietf.org, mfrick@netopia.com, gww@nortelnetworks.com In-Reply-To: <7EB34DD9-1A51-11D6-ABCA-00039317663C@nominum.com> from Ted Lemon at Feb "5," 2002 "10:00:37" am X-Mailer: ELM [$Revision: 1.17.214.2 $] MIME-Version: 1.0 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 Hi all, I read the RFC3011 at least 10 times to understand what is written in the document. After so much of effort I did understand the situation the RFC is meant for. But I was not 100% sure either. Because I had to assume several undocumented things to understand. The point I want to raise is why to write RFC documents in such a cryptic/mystic langauge. Why can't the author give an example of the scenario in which the document is applicable. What is the point in coming out with a standard document if normal user can't understand it? The usage of giaddr field has already created lot of confusion in DHCP circle in the past. The complicated topics must be explained properly. Nothing should be left for implementor's assumption. I am not asking for writting whole story. But, at least a hint or guideline should be given. I hope the author of the RFC3011 updates it. If it is not updated, the working group will be getting several such mails from new users and implementors. Cheers, Jitesh > Glenn, I'd just like to point out that DHCP packets are never sent on > subnets. They are sent on links. Normally we can get away with > confusing subnets for links, but in the case of DHCP, it winds up creating > a great deal of confusion. A DHCP server cannot tell on what subnet a > client's broadcast was sent - all it can tell is on what link a client's > broadcast was sent. > > So unfortunately there is a natural opportunity to become confused about > what the subnet selection option does, which I believe is what happened > here. I hate to suggest updating anyhting that's made it to RFC when we > have so much other work that's still pending, but it might be worth adding > some clarification about this. > > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg > -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 6 08:06:36 2002 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 IAA18683; Wed, 6 Feb 2002 08:06:36 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA00016; Wed, 6 Feb 2002 08:05:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA29982 for ; Wed, 6 Feb 2002 08:05:51 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA18663 for ; Wed, 6 Feb 2002 08:05:47 -0500 (EST) Received: from rdroms-w2k.cisco.com (sj-dial-2-165.cisco.com [10.19.226.166]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id IAA21349 for ; Wed, 6 Feb 2002 08:05:17 -0500 (EST) Message-Id: <4.3.2.7.2.20020206075617.00b25428@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Feb 2002 07:58:00 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHC WG meeting at IETF 53 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'm collecting agenda items for the DHC WG meeting in Minneapolis at IETF 53. If you want to get something on the agenda, please send me a request. Here is the scheduling information for the WG meeting: WEDNESDAY, March 20, 2002 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions INT dhc Dynamic Host Configuration WG OPS rmonmib Remote Network Monitoring WG RTG idr Inter-Domain Routing WG TSV avt Audio/Video Transport WG TSV enum Telephone Number Mapping WG - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 6 13:08:14 2002 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 NAA27244; Wed, 6 Feb 2002 13:08:14 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17995; Wed, 6 Feb 2002 13:07:09 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA17970 for ; Wed, 6 Feb 2002 13:07:08 -0500 (EST) Received: from web21209.mail.yahoo.com (web21209.mail.yahoo.com [216.136.175.167]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27231 for ; Wed, 6 Feb 2002 13:07:05 -0500 (EST) Message-ID: <20020206180706.59849.qmail@web21209.mail.yahoo.com> Received: from [12.46.89.4] by web21209.mail.yahoo.com via HTTP; Wed, 06 Feb 2002 10:07:06 PST Date: Wed, 6 Feb 2002 10:07:06 -0800 (PST) From: suzanne andy To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] isc dhcp on windows 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 all , We are planning to have a dhcp Server on windows NT which can provide some apis to configure from a remote location . Can we use ISC DHCP ? Is it available on windows platform ? If not did any one of you try to port the present ISC to windows ? can you please tell me how time it takes to port the whole code to windows ? If there are any pointers for this please forward these to me . thanks in advance Suzanne __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 7 13:23:52 2002 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 NAA04751; Thu, 7 Feb 2002 13:23:51 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06861; Thu, 7 Feb 2002 13:22:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA06835 for ; Thu, 7 Feb 2002 13:22:51 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04567; Thu, 7 Feb 2002 13:22:49 -0500 (EST) Message-Id: <200202071822.NAA04567@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Thu, 07 Feb 2002 13:22:49 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-23.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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Author(s) : J. Bound, M. Carney, C. Perkins, T. Lemon, B. Volz, R. Droms Filename : draft-ietf-dhc-dhcpv6-23.txt Pages : 81 Date : 06-Feb-02 The Dynamic Host Configuration Protocol for IPv6 (DHCP) enables DHCP servers to pass configuration parameters such as IPv6 network addresses to IPv6 nodes. It offers the capability of automatic allocation of reusable network addresses and additional configuration flexibility. This protocol is a stateful counterpart to 'IPv6 Stateless Address Autoconfiguration' [13], and can be used separately or concurrently with the latter to obtain configuration parameters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-23.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-dhcpv6-23.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-dhcpv6-23.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: <20020206132206.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-23.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-23.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020206132206.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 8 10:04:28 2002 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 KAA09833; Fri, 8 Feb 2002 10:04:28 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA11944; Fri, 8 Feb 2002 10:03:49 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA18762 for ; Wed, 6 Feb 2002 13:27:36 -0500 (EST) Received: from mail.bucknell.edu (marge.bucknell.edu [134.82.9.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27675 for ; Wed, 6 Feb 2002 13:27:33 -0500 (EST) Received: from mail01g.rapidsite.net (mail01g.rapidsite.net [207.158.192.232]) by mail.bucknell.edu (8.11.6/8.11.6) with SMTP id g16IRY230911 for ; Wed, 6 Feb 2002 13:27:34 -0500 (EST) Received: from www.ontash.com (209.238.22.8) by mail01g.rapidsite.net (RS ver 1.0.62s) with SMTP id 020481; Wed, 6 Feb 2002 13:27:04 -0500 (EST) Reply-To: From: "Bimal Shah" To: "'Jitesh N Verma'" Cc: Subject: RE: [dhcwg] dhcp question Date: Wed, 6 Feb 2002 13:28:39 -0500 Message-ID: <000601c1af3c$197cc370$7300a8c0@hq.ontash.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <200201240637.MAA19511@chitha.india.hp.com> X-Loop-Detect: 1 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 hi: The way we have an client program on dhcp.org. Do anybody has a server program like that?? Can i have java code of the DHCP server if you have any. that would be really appreciated. Thx bimal -----Original Message----- From: Jitesh N Verma [mailto:jitesh@india.hp.com] Sent: Thursday, January 24, 2002 1:37 AM To: bimal@ontash.com Cc: dhcp-v4@bucknell.edu Subject: Re: [dhcwg] dhcp question Yes. A properly implemented DHCP server assigns appropriate IP addresses to the DHCP client machines without affeting existing machines with static IP addresses. DHCP client also must be intelligent enough to detect dulpicate address offered by the server. ~Jitesh -- ----------------------------------------------------------------------- ~ ~ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* ^ Jitesh N. Verma Tel. 91-80-225 1554 Ext. 1424 ^ ^ HEWLETT PACKARD Fax. 91-80-220 0196 ^ ^ INDIA SOFTWARE OPERATIONS Email. jitesh@india.hp.com ^ ^ 29, CUNNINGHAM ROAD Pager. 9624-263608 ^ ^ BANGALORE 560 052 __ Telnet. 847-1424 ^ ^ / / ^ ^ / /___ _____ ^ ^ / __ // __ / ^ ^ / / / // /_/ / ^ ^ /_/ /_// ____/ ^ ^ / / ^ ^ /_/ ^ *~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~* _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 11 05:14:19 2002 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 FAA27648; Mon, 11 Feb 2002 05:14:19 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28197; Mon, 11 Feb 2002 05:12:17 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA28168 for ; Mon, 11 Feb 2002 05:12:16 -0500 (EST) Received: from mta08.onebox.com (mta08.onebox.com [64.68.76.143]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27589 for ; Mon, 11 Feb 2002 05:12:13 -0500 (EST) Received: from onebox.com ([10.1.101.12]) by mta08.onebox.com (InterMail vM.4.01.03.23 201-229-121-123-20010418) with SMTP id <20020211101139.GIPA16107.mta08.onebox.com@onebox.com> for ; Mon, 11 Feb 2002 02:11:39 -0800 Received: from [194.9.185.75] by onebox.com with HTTP; Mon, 11 Feb 2002 02:11:39 -0800 Date: Mon, 11 Feb 2002 02:11:39 -0800 X-Priority: 1 (Highest) From: "John Darko" To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit MIME-Version: 1.0 Message-Id: <20020211101139.GIPA16107.mta08.onebox.com@onebox.com> Content-Transfer-Encoding: 7bit Subject: [dhcwg] DhCP help!! 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 hi, my dhcp configuration on RH7.1 is posing a problem in my network,it starts the gateway anytime a client tries to pick an address from it(restarts) .It has taken the gateway as it default DNS server since i don't have one set up yet.could this be the problem and if so what should i do. -- John Darko jdarko@onebox.com - email (678) 223-2000 x3602 - voicemail/fax __________________________________________________ FREE voicemail, email, and fax...all in one place. Sign Up Now! http://www.onebox.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 11 11:43:54 2002 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 LAA09133; Mon, 11 Feb 2002 11:43:53 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18894; Mon, 11 Feb 2002 11:43:08 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA18863 for ; Mon, 11 Feb 2002 11:43:06 -0500 (EST) Received: from web20806.mail.yahoo.com (web20806.mail.yahoo.com [216.136.226.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09066 for ; Mon, 11 Feb 2002 11:43:03 -0500 (EST) Message-ID: <20020211164304.57988.qmail@web20806.mail.yahoo.com> Received: from [203.135.50.17] by web20806.mail.yahoo.com via HTTP; Mon, 11 Feb 2002 08:43:04 PST Date: Mon, 11 Feb 2002 08:43:04 -0800 (PST) From: iqtidar khan To: bob@werken.com Cc: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] Sir could you help me 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 Iqtidar ahmed, Rashim gali Larkana(sindh), Pakistan. R/Sir, I am a student and searching information for complex subjects and thair topices so Sir would you help me in that condition because I lose my a lot time in finding that topic on net. May I hopefully find you mail in my mail box. yours sincerely, Iqtdiar Ahmed Mail URL:- khaniqtahmed1@yahoo.com only4friendshipu@yahoo.com __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 11 19:04:22 2002 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 TAA20608; Mon, 11 Feb 2002 19:04:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10519; Mon, 11 Feb 2002 19:03:27 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id TAA10500 for ; Mon, 11 Feb 2002 19:03:26 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20604 for ; Mon, 11 Feb 2002 19:03:24 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate3.mot.com (motgate3 2.1) with ESMTP id QAA23754 for ; Mon, 11 Feb 2002 16:52:47 -0700 (MST)] Received: [from il06exb01.corp.mot.com (il06exb01.corp.mot.com [199.5.78.83]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id RAA10886 for ; Mon, 11 Feb 2002 17:03:24 -0700 (MST)] Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2654.52) id <1P107CD3>; Mon, 11 Feb 2002 18:03:24 -0600 Message-ID: <1B1F9F30D74AD51188C8009027E33B3F26BD1B@il06exm03.corp.mot.com> From: Malek John-AJM240 To: "'dhcwg@ietf.org'" Date: Mon, 11 Feb 2002 18:03:19 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] client get ip not matching giaddr subnet 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 question is, is it possible and if so then how, can A DHCP client going through a proxy (UDPhelp) get an ip address from the DHCP server if the address that I am requesting does not match the subnet of the giaddr field (UDPhelp GW_ip) . I can not get this to work in WIN/NT, maybe WIN/2000 can be configured to do this? Or some 3rd party SW? any help Thank you, John Malek. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 11 22:50:08 2002 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 WAA24854; Mon, 11 Feb 2002 22:50:08 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18640; Mon, 11 Feb 2002 22:49:28 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18617 for ; Mon, 11 Feb 2002 22:49:27 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA24843 for ; Mon, 11 Feb 2002 22:49:25 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g1C3jdX26165; Mon, 11 Feb 2002 19:45:39 -0800 (PST) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g1C3nCK26703; Mon, 11 Feb 2002 21:49:12 -0600 (CST) Date: Mon, 11 Feb 2002 21:49:12 -0600 Subject: Re: [dhcwg] client get ip not matching giaddr subnet Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: "'dhcwg@ietf.org'" To: Malek John-AJM240 From: Ted Lemon In-Reply-To: <1B1F9F30D74AD51188C8009027E33B3F26BD1B@il06exm03.corp.mot.com> Message-Id: <79F2A6DA-1F6B-11D6-BB9C-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 The Windows NT 4.0 and Windows 2000 DHCP server can be configured to do that. Look for superscopes in the menus/documentation. I don't remember the details - sorry. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 12 10:52:31 2002 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 KAA15966; Tue, 12 Feb 2002 10:52:31 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28500; Tue, 12 Feb 2002 10:51:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id KAA28481 for ; Tue, 12 Feb 2002 10:51:31 -0500 (EST) Received: from web13409.mail.yahoo.com (web13409.mail.yahoo.com [216.136.172.17]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA15909 for ; Tue, 12 Feb 2002 10:51:29 -0500 (EST) Message-ID: <20020212155130.51853.qmail@web13409.mail.yahoo.com> Received: from [203.135.50.9] by web13409.mail.yahoo.com via HTTP; Tue, 12 Feb 2002 07:51:30 PST Date: Tue, 12 Feb 2002 07:51:30 -0800 (PST) From: iqtidar khan To: dhcwg@ietf.org Cc: tobin.coziahr@sun.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] Request of help from Iqtidar 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 Iqtidar ahmed, Rashim Gali Larkana(sindh), Pakistan. R/Sir, Thanks for reply Sir, I have problem in the topic of "How Data Transfer from one computer to other computer, in condition of World Wide Web or Wide Area Network, Is there is any difference or not" and " What is the feature of Peer to Peer networking or Server Base networking and Is any other kind of it or not". Sir on which Address, I shall E-mail you. Thanks Again and hopefully again. Yours Sincerely, Iqtidar Ahmed Mail Address:- khaniqtahmed1@yahoo.com only4friendshipu@yahoo.com __________________________________________________ Do You Yahoo!? Send FREE Valentine eCards with Yahoo! Greetings! http://greetings.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 13 22:25:19 2002 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 WAA28366; Wed, 13 Feb 2002 22:25:18 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18755; Wed, 13 Feb 2002 22:18:21 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA18480 for ; Wed, 13 Feb 2002 22:18:10 -0500 (EST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27431 for ; Wed, 13 Feb 2002 22:18:05 -0500 (EST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.3.2.7.2.20020109133527.0369add0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 09 Jan 2002 13:38:35 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk Status: RO X-UID: 325 Subject: [dhcwg] DHC WG last call for DHCPv6 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 you've reviewed the most recent rev of the DHCPv6 spec , please post your comments to dhcwg@ietf.org - even if your comments are as brief as "looks ready for submission for Proposed Standard"... - Ralph Droms -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 13 23:24:35 2002 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 XAA02068; Wed, 13 Feb 2002 23:24:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA25386; Wed, 13 Feb 2002 23:11:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id XAA25096 for ; Wed, 13 Feb 2002 23:11:20 -0500 (EST) Received: from ubik.vipul.net (munitions2.xs4all.nl [194.109.217.74]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28003 for ; Wed, 13 Feb 2002 22:18:52 -0500 (EST) X-Authentication-Warning: sunroof.eng.sun.com: majordomo set sender to owner-ipng@sunroof.eng.sun.com using -f Message-Id: <4.3.2.7.2.20020122050446.036870b0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 22 Jan 2002 05:24:27 -0500 To: dhcwg@ietf.org From: Ralph Droms Cc: ipng@sunroof.eng.sun.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Precedence: bulk Status: RO X-UID: 854 Subject: [dhcwg] Issues raised during last call for DHCPv6 specification 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 following issues were raised during the last call for the DHCPv6 spec ; I will kick off separate discussion threads for each open issue later today. - Ralph Droms Open issues ----------- * We've experienced a proliferation of DHCPv6 options. Should all options *not* used in the base protocol be moved out to separate drafts? * Does DHCPv6 need a "default routes" option? * Does DHCPv6 need a "static routes" option? * Does DHCPv6 need an FQDN option (basically identical to proposed DHCPv4 FQDN option)? * Other options: - NTP servers - NIS servers - NIS+ servers - Subnet selection - NIS domain name - NIS+ domain name - IEEE 1003.1 POSIX timezone - SLP directory agent - SLP service scope * Should the DHCPv6 option codes start at 256 to avoid overlap with DHCPv4 option codes; overlap of option codes would be an issue for the DHCID RR. * What error codes may a server send in response to an Information-Request message? * Should the Decline message have error codes defining the reason for the Decline? * Does the Information-Request message require a DUID? Could the "MUST" in the third paragraph of 18.1.5 be changed to "SHOULD"? If a DUID "SHOULD" be included, text needs to be added pointing out the client-specific information (based on identifying the client with a DUID) cannot be returned if a DUID is not included. * Is a client required to implement the Reconfigure message - supporting Reconfigure will require that the client maintain state. * Do we want to allow a client to request that more normal addresses be added to an IA, perhaps through use of the equivalent of the RTA option? * DHCP/DDNS interaction * Is the text in section 17.1.3 sufficient? Changes to be made in -23 ------------------------- * Editorial changes: - Change "Inform message" to "Information-request message" and "INFORM" to "INFORMATION-REQUEST" throughout the document - In the list of DHCP messages in section 7, fix Reconfigure to start Renew/Reply or Inform/Reply sequence (not Request/Reply) - Fix page 10 (which is blank in -22 draft) - In third paragraph of section 14, change "Requested Temporary Addresses Option 22.5" to "Requested Temporary Addresses Option (see section 22.5)" - Change "Rebind" to "Inform" in the last paragraph of section 18.1.5 (cut-and-paste error) - Fix redundancy between sections 18.2.5 and 18.2.8 - Edit third paragraph of section 19.2 to delete references to IAs - In section 19.3.4, change "Rebind or Information-Request" to "Renew or Information-Request" - Change last sentence of section 22.5 to: "A client MUST only include this option when it wants to have additional temporary address allocated; a client SHOULD NOT send this option if 'num-requested' is 0". - Edit section 22.14 to indicate that the server-address field is in the fixed-format part of the DHCP message, not the unicast option - Clarify the text in section 22.19 to indicate that the 'user class data' items are carried in the data area of the 'user class option' * Clarify text in section 13 about address selection based on source of message from client * Remove references to "IAs" in section 19.2 * Fix chart in Appendix B to allow DSTM option in same messages as IA option * Modify SIP server option according to input from Henning Schulzrinne * Require that the DUID option appear before any IA options to improve processing efficiency * Require that the authentication option be first in th elist of options to reduce the work that a server must expend before discarding a message that fails authentication (reduces effect of denial of service attacks) * Clean up text specifying selection of address by server to insert into 'server-address' field * Clarify that a server MAY return fewer temporary addresses than requested by the client and MUST return AddrUnavail only if no temporary addresses are available * Clarify that a client MUST include all requested options in an ORO and MAY include suggested values by including specific options; also, the server MAY ignore suggestions from client and the client MUST use whatever the server returns * Clarify that a server MAY renew only some of the IAs sent by a client * Change DUID/VUID to have a length field to allow for longer IDs -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to majordomo@sunroof.eng.sun.com -------------------------------------------------------------------- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 14 03:58:50 2002 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 DAA13685; Thu, 14 Feb 2002 03:58:50 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15316; Thu, 14 Feb 2002 03:26:03 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id DAA15293 for ; Thu, 14 Feb 2002 03:26:01 -0500 (EST) Received: from cellgate.btcellnet.net (cellgate.btcellnet.net [158.230.100.102]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13263 for ; Thu, 14 Feb 2002 03:25:58 -0500 (EST) Received: from brwmsw03.cellnet.co.uk by cellgate.btcellnet.net via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 14 Feb 2002 08:26:38 UT Received: from marie.btm.bt.co.uk (unverified) by brwmsw03.btcellnet.net (Content Technologies SMTPRS 4.2.10) with ESMTP id for ; Thu, 14 Feb 2002 08:25:31 +0000 Received: by marie.cellnet.co.uk with Internet Mail Service (5.5.2653.19) id <15AWW7AF>; Thu, 14 Feb 2002 08:25:59 -0000 Message-ID: <9CBA35009A10D61192500040A5B1C8AA011DF9C9@margo> From: Girgis George To: "'dhcwg@ietf.org'" Date: Thu, 14 Feb 2002 08:25:58 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B531.3AA102A0" Subject: [dhcwg] DHCP & option 43 and option 55 (RFC 2132) 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_01C1B531.3AA102A0 Content-Type: text/plain; charset="iso-8859-1" Hi, I need your help please Regarding RFC 2132 , option 55 (Parameter request list) and option 43 (vendor class identifier) Is there any relation between the length field for option 55 and option 43 ? Regards George Girgis Network Designer Data Network Design Team BTcellnet tel +44 (0) 1753 564780 fax +44 (0) 1753 564355 mob +44 (0) 7753 560776 ========================================================= This electronic message contains information from the mmO2 plc Group which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. ========================================================= ------_=_NextPart_001_01C1B531.3AA102A0 Content-Type: text/html; charset="iso-8859-1" DHCP & option 43 and option 55 (RFC 2132)

Hi,

I need your help please

Regarding RFC 2132 , option 55 (Parameter request list) and option 43 (vendor class identifier)

Is there any relation between the length field for option 55 and option 43 ?

Regards

George Girgis
Network Designer
Data Network Design Team
BTcellnet
tel +44 (0) 1753 564780
fax +44 (0) 1753 564355
mob +44 (0) 7753 560776





=========================================================

This electronic message contains information from the mmO2 plc Group 

which may be privileged or confidential. The information is intended to be 

for the use of the individual(s) or entity named above. If you are not the 

intended recipient be aware that any disclosure, copying, distribution or 

use of the contents of this information is prohibited. If you have received 

this electronic message in error, please notify us by telephone or email 

(to the numbers or address above) immediately.

=========================================================

------_=_NextPart_001_01C1B531.3AA102A0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 14 04:31:30 2002 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 EAA14030; Thu, 14 Feb 2002 04:31:29 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17605; Thu, 14 Feb 2002 04:16:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA17586 for ; Thu, 14 Feb 2002 04:16:34 -0500 (EST) Received: from gw.xargs.com (Bessie@dsl.xargs.com [209.239.242.114]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13889 for ; Thu, 14 Feb 2002 04:16:31 -0500 (EST) Received: (qmail 24423 invoked from network); 14 Feb 2002 09:16:28 -0000 Received: from gw.xargs.com (milder@192.168.11.1) by gw.xargs.com with SMTP; 14 Feb 2002 09:16:28 -0000 Date: Thu, 14 Feb 2002 01:16:28 -0800 (PST) From: Thamer Al-Harbash X-X-Sender: To: "'dhcwg@ietf.org'" Subject: Re: [dhcwg] DHCP & option 43 and option 55 (RFC 2132) In-Reply-To: <9CBA35009A10D61192500040A5B1C8AA011DF9C9@margo> Message-ID: 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 On Thu, 14 Feb 2002, Girgis George wrote: > Regarding RFC 2132 , option 55 (Parameter request list) and option 43 > (vendor class identifier) > > Is there any relation between the length field for option 55 and option 43 > ? The parameter request list would just include that tag in its list so yes there is a relation but it's the same with any other option tag. I'm not entirely sure why you would _request_ a vendor specific option. It would seem to me that the client or the server would simply handle it when it comes in or ignore it. -- Thamer Al-Harbash http://www.whitefang.com/dhcp-agent/ cvs commit -m "unb0rk() now uses stdarg;" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 14 09:53:43 2002 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 JAA23265; Thu, 14 Feb 2002 09:53:43 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01667; Thu, 14 Feb 2002 09:52:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA01634 for ; Thu, 14 Feb 2002 09:52:45 -0500 (EST) Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23240 for ; Thu, 14 Feb 2002 09:52:40 -0500 (EST) Received: from green.bisbee.fugue.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.3/8.6.11) with ESMTP id g1EEn1X03587; Thu, 14 Feb 2002 06:49:01 -0800 (PST) Received: from tongpanyi (localhost [127.0.0.1]) by green.bisbee.fugue.com (8.10.2/8.6.11) with ESMTP id g1EEqeK29126; Thu, 14 Feb 2002 08:52:40 -0600 (CST) Date: Thu, 14 Feb 2002 08:52:40 -0600 Subject: Re: [dhcwg] DHCP & option 43 and option 55 (RFC 2132) Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v480) Cc: "'dhcwg@ietf.org'" To: Thamer Al-Harbash From: Ted Lemon In-Reply-To: Message-Id: <7E317E3F-215A-11D6-BB9C-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.480) 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 If you request any parameters at all, you will only get the parameters you requested, so you have to request everything you're interested in. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 15 05:26:54 2002 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 FAA01473; Fri, 15 Feb 2002 05:26:54 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11087; Fri, 15 Feb 2002 05:21:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA11065 for ; Fri, 15 Feb 2002 05:21:27 -0500 (EST) Received: from fep01-svc.swip.net (fep01.swip.net [130.244.199.129]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01453 for ; Fri, 15 Feb 2002 05:21:24 -0500 (EST) Received: from there ([193.12.201.10]) by fep01-svc.swip.net with SMTP id <20020215102055.NDNZ23536.fep01-svc.swip.net@there> for ; Fri, 15 Feb 2002 11:20:55 +0100 Content-Type: text/plain; charset="iso-8859-1" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: "DHCP discussion list" Date: Fri, 15 Feb 2002 11:25:31 +0100 X-Mailer: KMail [version 1.3.2] MIME-Version: 1.0 Message-Id: <20020215102055.NDNZ23536.fep01-svc.swip.net@there> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id FAA11066 Subject: [dhcwg] Maximum message size interpretation 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 When a client gives my server the maximum message size it can receive, should I interpret that as the total IP packet size the client can receive or just the size of the DHCP portion? From the description of this option, it appears that I should interpret the value as the size of the entire IP packet the client can receive. In other words, should I subtract IP and UDP header sizes from a client's Maximum Message Size value? - Bud 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 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 15 16:42:12 2002 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 QAA20548; Fri, 15 Feb 2002 16:42:12 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19829; Fri, 15 Feb 2002 16:41:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA19810 for ; Fri, 15 Feb 2002 16:41:35 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20494 for ; Fri, 15 Feb 2002 16:41:33 -0500 (EST) Received: from rdroms-w2k.cisco.com (ch2-dhcp150-47.cisco.com [161.44.150.47]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA28493 for ; Fri, 15 Feb 2002 16:41:05 -0500 (EST) Message-Id: <4.3.2.7.2.20020215163844.00bb3610@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Feb 2002 16:41:17 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Request for agenda items (2nd request) 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 you have an item you would like to get on the DHC WG agenda for our meeting in Minneapolis, please send me a request for a slot by Thursday, 2/28. - Ralph WEDNESDAY, March 20, 2002 0800-1700 IETF Registration - 0800-0900 Continental Breakfast - 0900-1130 Morning Sessions INT dhc Dynamic Host Configuration WG OPS rmonmib Remote Network Monitoring WG RTG idr Inter-Domain Routing WG TSV avt Audio/Video Transport WG TSV enum Telephone Number Mapping WG _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 15 17:16:02 2002 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 RAA21457; Fri, 15 Feb 2002 17:16:02 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21942; Fri, 15 Feb 2002 17:15:34 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA21907 for ; Fri, 15 Feb 2002 17:15:32 -0500 (EST) Received: from motgate3.mot.com (motgate3.mot.com [144.189.100.103]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA21411 for ; Fri, 15 Feb 2002 17:15:30 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate3.mot.com (motgate3 2.1) with ESMTP id PAA25263 for ; Fri, 15 Feb 2002 15:04:51 -0700 (MST)] Received: [from il06exb01.corp.mot.com (il06exb01.corp.mot.com [199.5.78.83]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id PAA25031 for ; Fri, 15 Feb 2002 15:04:08 -0700 (MST)] Received: by il06exb01.corp.mot.com with Internet Mail Service (5.5.2654.52) id <1P109F05>; Fri, 15 Feb 2002 16:15:31 -0600 Message-ID: <1B1F9F30D74AD51188C8009027E33B3F26BD23@il06exm03.corp.mot.com> From: Malek John-AJM240 To: "'dhcwg@ietf.org'" Date: Fri, 15 Feb 2002 16:15:25 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.52) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] super scope and subnet selection option 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 tried setting up a super scope in Win/NT , it still will not return an address if the address does not match the subnet that the giaddr is on. After looking in to rfc3011(confusing) I guess for this to work, I would have to set this new subnet selection option on the client side. How do I set this option?What software will allow me to do this. Will NT sp6 recognize this option? Thank you, John Malek. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Feb 16 09:48:58 2002 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 JAA12571; Sat, 16 Feb 2002 09:48:58 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05080; Sat, 16 Feb 2002 09:48:02 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id JAA05058 for ; Sat, 16 Feb 2002 09:48:00 -0500 (EST) Received: from localhost ([211.228.6.26]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA12564 for ; Sat, 16 Feb 2002 09:47:52 -0500 (EST) Message-Id: <200202161447.JAA12564@ietf.org> Reply-To: dyd2103@kornet.net From: �ȼ�ö To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Sat, 16 Feb 2002 23:47:53 +0900 Subject: [dhcwg] �� ̷��...'�� ' 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

�� ȳ�

�ڵ�� ޱ��ذ� �� ؾ�� [��]

- �ڵ�� �� ޱ��ؿ� �� ݾ�� ؾ��� ֵ�� Ǿ� �ֽ��ϴ�.

- �� ؿ� �� ϰ� �ֱ⿡ ��ڰ� �ڽ�� Ǹ�� �ƴ�� 𸣴��Ŀ� �� õ�� �� ̷�� ֽ��ϴ�.

�׷��  ��̰� �ִ�� ˾ƺ��ϴ�.

��ȸ�� ޱ��

�� ؾ�

�� м�

��

��

��

��

��

��

��ڷ�

��1�޻��ط�6��Կ��  200��

��14�޻��                9��

��500��700��

��50��100��

��2��10��

�޾��

��ҵ��-��ҵ�� 80%

       -��Ұ� �� Ͽ��ӱ�80%

��Ͽ�ٷ�� ; �� 847,637

                               �� 900,284

-��ҵ��

-��ҵ��

��Ͽ� 900,284

��̳�� 1,281,150

��ҵ�� Ͽ��ӱ�� 1.5�袦2��

��ȣ��

-��Ұ�

-�� ȣ��

-��

-6��̸� �Կ��Ⱓ��

1�޿� 120�� ߻�

��

��

��

��

��ڷ�

-��  20%       80��

-�� 100%     1000��

-��  20%   1000��

-�� 100%   5000��

12.5��

      5��

��Ǽ��

(�Ͻ��)

-�� ǳ� �ҵ�� 50%��

-�߰��ڰ�� L��

-�� Ǹ� 100%��
     (�� )

-�߰��ڰ�� H��

��ڰ�� Ŀ� �� �� ũ�� ̰��

��

��

��

��ڷ�

-20��60��           3200��

-20��̸� 60�� ̻�    2800��

           5000��

1.5��1.78��

�� ǥ�� Ϻ�� ̸� �� .

�� Ȯ�� ˰� ��ô�.
�ڼ�� Ͻø� 060-700-2114 ��...

�� Ȩ�� ÷�� ⸦ Ŭ�� http//www.sos113.com

��  [060-700-2114]

�� ź� �ǰ� ��׿� �ǰ� �� [��]�� ǥ�õ� �� Դϴ�. �� о� �ֽŵ� �� 縦 �帳�ϴ�. ��̻� �� ġ ��ø� ��Űź��� Ŭ��Ͻþ� �� ̸�� ּҸ� �� Է��ϸ� ��Űź�ó�� ˷� �帳�ϴ�.

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 17 02:06:32 2002 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 CAA02328; Sun, 17 Feb 2002 02:06:32 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19571; Sun, 17 Feb 2002 02:05:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id CAA19542 for ; Sun, 17 Feb 2002 02:05:46 -0500 (EST) Received: from palrel11.hp.com (palrel11.hp.com [156.153.255.246]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA02124 for ; Sun, 17 Feb 2002 02:05:43 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by palrel11.hp.com (Postfix) with ESMTP id 556CA600825 for ; Sat, 16 Feb 2002 23:05:13 -0800 (PST) Received: from nt4147 (nt4147.india.hp.com [15.10.41.47]) by hpuxsrv.india.hp.com with SMTP (8.8.6 (PHNE_17135)/8.8.6 SMKit7.02) id MAA13003 for ; Sun, 17 Feb 2002 12:30:44 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'DHCP discussion list'" Date: Sun, 17 Feb 2002 12:36:24 +0530 Message-ID: <000d01c1b781$9c678a20$2f290a0f@india.hp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Content-Transfer-Encoding: 7bit Subject: [dhcwg] unused error codes in 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 Content-Transfer-Encoding: 7bit - In section 7.4.1 and 7.4.2 the following error codes are defined, which are nowhere used in the spec. # UnspecFail # AuthFailed - Section 16 says that, "Servers MUST discard any received messages that include authentication information and fail the authentication check by the server." We can add some text as follows, "It MAY choose to send appropriate reply with only status code option with status code AuthFailed". # PoorlyFormed # InvalidSource If we are not using these error codes, then better we can remove it. ~vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 17 06:10:06 2002 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 GAA04364; Sun, 17 Feb 2002 06:10:06 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29077; Sun, 17 Feb 2002 06:09:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29055 for ; Sun, 17 Feb 2002 06:09:35 -0500 (EST) Received: from palrel10.hp.com (palrel10.hp.com [156.153.255.245]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04352 for ; Sun, 17 Feb 2002 06:09:30 -0500 (EST) Received: from dce.india.hp.com (dce.india.hp.com [15.10.45.122]) by palrel10.hp.com (Postfix) with ESMTP id B3398C004F2 for ; Sun, 17 Feb 2002 03:09:00 -0800 (PST) Received: (from vijayak@localhost) by dce.india.hp.com (8.8.6 (PHNE_17190)/8.8.6 SMKit7.02) id QAA28471 for dhcwg@ietf.org; Sun, 17 Feb 2002 16:43:22 +0530 (IST) From: Vijay Bhaskar A K Message-Id: <200202171113.QAA28471@dce.india.hp.com> To: dhcwg@ietf.org Date: Sun, 17 Feb 2002 16:43:21 +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 Content-Transfer-Encoding: 7bit Subject: [dhcwg] co-existence of temp and normal addresses 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 Consider the following scenario. A client has 3 normal addresses and 2 temporary addresses in an IA identified by IAID 36. After some time, the client releases all the 3 normal addresses. Now, it needs another 1 temporary address. So, it will send a Request, with IA option having IAID 36, encapsulating RTA option having value 3, indicating it needs an another temporary address. Now, what server assumes is.... - the client is requesting to assign a temporary address. - the client is requesting to asssign normal addresses also. This is because, whenever a Request is sent for IA, the server is going to assign new set of normal addresses to the IA according to its policy, unless or otherwise, the server's database says that the IA has been already populated with addresses. In the later case it assumes to be the retransmission and sends back whatever the normal addresses it has already allocated. Thus, server allocates normal addresses also along with the requested temp address. But, the client didn't have requested for normal addresses. *** Thus the mixture of normal addresses and temp addresses in an IA leads to mislead in the server's side. *** The temporay addresses should not be renewed. In the renew message, the IA should not carry temporary address. This means, eventhough the temporary addresses lies in the same IA along with the other normal addresses, they are treated as seperate set of addresses in the case of renewal. Considering the above two points, i have few suggestions. - Why can't we have separate IAs for normal and temporary addresses? - The IAIDs for temporary addresses range from 0-1023 and that of normal addresses range from 1024 onwards. This is to avoid the overlapping of IAID space. - Since, T1 and T2 values for the IA containing only temporary addresses make no sense, i feel that we can have seperate TMP_IA option which doesn't have T1 and T2 fields, as shown below. 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 | | +-+-+-+-+-+-+-+-+ | . Options . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_TMP_IA (TBD) option-len See section 23. IAID The unique identifier for this TMP_IA. It ranges from 0-1023 IA status Status of the IA in this option. options Options associated with this IA. - T bit in the address status of IA address option is also not necessary since we are having seperate IAs for temp addresses. Please let me know your comments. ~Vijay _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Feb 17 12:41:03 2002 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 MAA08949; Sun, 17 Feb 2002 12:41:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18958; Sun, 17 Feb 2002 12:40:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA18929 for ; Sun, 17 Feb 2002 12:40:17 -0500 (EST) 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 MAA08933 for ; Sun, 17 Feb 2002 12:40:12 -0500 (EST) Received: from funnel.cisco.com (funnel.cisco.com [161.44.168.79]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id g1HHdjh24587 for ; Sun, 17 Feb 2002 09:39:45 -0800 (PST) Date: Sun, 17 Feb 2002 12:39:45 -0500 (EST) From: Ralph Droms To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [dhcwg] Away from e-mail 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'm going to be away next week. If you have an agenda item for the DHC WG meeting in Minneapolis, let me know and I'll reply as soon as I get back... - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 18 11:11:20 2002 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 LAA06423; Mon, 18 Feb 2002 11:11:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27108; Mon, 18 Feb 2002 11:10:18 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27085 for ; Mon, 18 Feb 2002 11:10:17 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06237; Mon, 18 Feb 2002 11:10:12 -0500 (EST) Message-Id: <200202181610.LAA06237@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 18 Feb 2002 11:10:12 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-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 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol (DHCP) Server MIB Author(s) : R. Hibbs, G. Waters Filename : draft-ietf-dhc-server-mib-06.txt Pages : 45 Date : 15-Feb-02 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-server-mib-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-server-mib-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: <20020215100602.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-mib-06.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-server-mib-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020215100602.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Feb 18 11:17:05 2002 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 LAA06801; Mon, 18 Feb 2002 11:17:05 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27578; Mon, 18 Feb 2002 11:16:15 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id LAA27551 for ; Mon, 18 Feb 2002 11:16:13 -0500 (EST) Received: from portal.incognito.com (HAZARD.INCOGNITO.COM [207.102.214.30]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06772 for ; Mon, 18 Feb 2002 11:16:04 -0500 (EST) Received: from homer.incognito.com ([207.102.214.21] helo=homer.incognito.com.) by portal.incognito.com with smtp (Exim 3.33 #1) id 16cqFv-0007sz-00 for dhcwg@ietf.org; Mon, 18 Feb 2002 08:03:07 -0800 Received: by homer.incognito.com. with Internet Mail Service (5.5.2653.19) id <13HA4NQJ>; Mon, 18 Feb 2002 08:20:30 -0800 Message-ID: <4FB49E60CFBA724E88867317DAA3D1986922BC@homer.incognito.com.> From: "Cosmo, Patrick" To: dhcwg@ietf.org Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-06.txt Date: Mon, 18 Feb 2002 08:20:29 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1B898.2E6FE770" 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_01C1B898.2E6FE770 Content-Type: text/plain; charset="iso-8859-1" This part of the draft makes no sense, I think there is a missing word: 2.1.1. DHCP MIB Extensions The DHCP MIB extensions will the "dhcp" branch of the standard MIB-2 tree, as illustrated by the following diagram: "The DHCP MIB extensions will" "the ... -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, February 18, 2002 11:10 AM Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-06.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : Dynamic Host Configuration Protocol (DHCP) Server MIB Author(s) : R. Hibbs, G. Waters Filename : draft-ietf-dhc-server-mib-06.txt Pages : 45 Date : 15-Feb-02 This memo defines an experimental portion of the Management Information Base (MIB) for use with network management protocols in the Internet Community. In particular, it defines objects used for the management of Dynamic Host Configuration Protocol (DHCP) and Bootstrap Protocol (BOOTP) servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-server-mib-06.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-server-mib-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-server-mib-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_001_01C1B898.2E6FE770 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-06.txt

This part of the draft makes no sense, I think there = is a missing word:

2.1.1. DHCP MIB Extensions =

The DHCP = MIB extensions will the "dhcp" branch of the standard MIB-2 =
tree, as = illustrated by the following diagram:

"The DHCP MIB extensions will" <what?? = "follow"?> "the ...

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: Monday, February 18, 2002 11:10 AM
Cc: dhcwg@ietf.org
Subject: [dhcwg] I-D = ACTION:draft-ietf-dhc-server-mib-06.txt

A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Dynamic Host = Configuration Working Group of the IETF.

        Title           : = Dynamic Host Configuration Protocol (DHCP) Server MIB
        Author(s)       : R. Hibbs, G. = Waters
        Filename        : = draft-ietf-dhc-server-mib-06.txt
        Pages           : = 45
        Date    =         : 15-Feb-02
       =20
This memo defines an experimental portion of the = Management
Information Base (MIB) for use with network = management protocols in
the Internet Community. In particular, it = defines objects used for
the management of Dynamic Host Configuration = Protocol (DHCP) and
Bootstrap Protocol (BOOTP) servers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-dhc-ser= ver-mib-06.txt

To remove yourself from the IETF Announcement list, = send a message to
ietf-announce-request with the word unsubscribe in = the body of the message.

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-server-mib-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-server-mib-06.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_01C1B898.2E6FE770-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 19 04:23:26 2002 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 EAA12968; Tue, 19 Feb 2002 04:23:26 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22331; Tue, 19 Feb 2002 04:22:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id EAA22304 for ; Tue, 19 Feb 2002 04:21:54 -0500 (EST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12955 for ; Tue, 19 Feb 2002 04:21:52 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id CAA05266; Tue, 19 Feb 2002 02:21:48 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.45]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id BAA21079; Tue, 19 Feb 2002 01:23:38 -0800 (PST) Received: from sun.com (raistlin.Eng.Sun.COM [129.146.86.244]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1J9LlrU359410; Tue, 19 Feb 2002 01:21:48 -0800 (PST) Message-ID: <3C721940.3D1D0D80@sun.com> Date: Tue, 19 Feb 2002 01:22:08 -0800 From: Tobin Coziahr Organization: Sun Microsystems X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Bud Millwood CC: DHCP discussion list Subject: Re: [dhcwg] Maximum message size interpretation References: <20020215102055.NDNZ23536.fep01-svc.swip.net@there> 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 Bud- The Maximum Message Size option is also known as the "maximum DHCP message size" option (See RFC 2131, page 9-10). This ONLY refers to the size of the DHCP packet itself, without the IP and UDP headers. The point of the option is to let servers use messages larger than 548 bytes, which is the default max. So no, don't subtract the header size. -Tobin Bud Millwood wrote: > > When a client gives my server the maximum message size it can receive, should > I interpret that as the total IP packet size the client can receive or just > the size of the DHCP portion? > > >From the description of this option, it appears that I should interpret the > value as the size of the entire IP packet the client can receive. > > In other words, should I subtract IP and UDP header sizes from a client's > Maximum Message Size value? > > - Bud > > 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 > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Tobin Coziahr 650-786-7118 (x87118) Solaris Networking tobin.coziahr@sun.com Sun Microsystems _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 19 06:36:35 2002 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 GAA14422; Tue, 19 Feb 2002 06:36:35 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29296; Tue, 19 Feb 2002 06:35:53 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA29277 for ; Tue, 19 Feb 2002 06:35:52 -0500 (EST) Received: from cichlid.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14401 for ; Tue, 19 Feb 2002 06:35:50 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id g1JBY4B04586; Tue, 19 Feb 2002 06:34:04 -0500 Message-Id: <200202191134.g1JBY4B04586@cichlid.adsl.duke.edu> To: Tobin Coziahr cc: Bud Millwood , DHCP discussion list Subject: Re: [dhcwg] Maximum message size interpretation In-Reply-To: Message from Tobin Coziahr of "Tue, 19 Feb 2002 01:22:08 PST." <3C721940.3D1D0D80@sun.com> Date: Tue, 19 Feb 2002 06:34:04 -0500 From: Thomas Narten 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 Maximum Message Size option is also known as the "maximum DHCP > message size" option (See RFC 2131, page 9-10). This ONLY refers to the > size of the DHCP packet itself, without the IP and UDP headers. The > point of the option is to let servers use messages larger than 548 > bytes, which is the default max. > So no, don't subtract the header size. Hmm. That's not what draft-ietf-dhc-csr-06.txt says: > 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. 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.) Is the above text correct? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 19 07:00:23 2002 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 HAA14706; Tue, 19 Feb 2002 07:00:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00190; Tue, 19 Feb 2002 06:59:32 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA00163 for ; Tue, 19 Feb 2002 06:59:30 -0500 (EST) Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14680 for ; Tue, 19 Feb 2002 06:59:28 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id DAA25449; Tue, 19 Feb 2002 03:59:22 -0800 (PST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.84.45]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id EAA01726; Tue, 19 Feb 2002 04:01:12 -0800 (PST) Received: from sun.com (raistlin.Eng.Sun.COM [129.146.86.244]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JBxLrU380217; Tue, 19 Feb 2002 03:59:22 -0800 (PST) Message-ID: <3C723E2E.46D28F46@sun.com> Date: Tue, 19 Feb 2002 03:59:42 -0800 From: Tobin Coziahr Organization: Sun Microsystems X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Thomas Narten CC: Bud Millwood , DHCP discussion list Subject: Re: [dhcwg] Maximum message size interpretation References: <200202191134.g1JBY4B04586@cichlid.adsl.duke.edu> 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 My apologies, you're right. All of the information I just found on the subject notes that the minimum value for this option is 576, which along with the RFC that you quoted shows that I was mistaken. The Maximum Message Size option DOES include the IP and UDP headers. Thanks for the correction, Thomas. -Tobin Thomas Narten wrote: > > > The Maximum Message Size option is also known as the "maximum DHCP > > message size" option (See RFC 2131, page 9-10). This ONLY refers to the > > size of the DHCP packet itself, without the IP and UDP headers. The > > point of the option is to let servers use messages larger than 548 > > bytes, which is the default max. > > > So no, don't subtract the header size. > > Hmm. That's not what draft-ietf-dhc-csr-06.txt says: > > > 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. 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.) > > Is the above text correct? > > Thomas > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Tobin Coziahr 650-786-7118 (x87118) Solaris Networking tobin.coziahr@sun.com Sun Microsystems _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 19 15:08:42 2002 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 PAA03706; Tue, 19 Feb 2002 15:08:42 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00337; Tue, 19 Feb 2002 15:07:36 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id PAA00309 for ; Tue, 19 Feb 2002 15:07:32 -0500 (EST) Received: from windlord.WWP.COM (mail.worldwidepackets.com [12.46.89.6]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03684 for ; Tue, 19 Feb 2002 15:07:30 -0500 (EST) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Tue, 19 Feb 2002 12:06:42 -0800 Message-ID: <917063BAB0DDB043AF5FAA73C7A835D42132C6@windlord.WWP.COM> Thread-Topic: RE: Maximum message size interpretation in DHCP packet Thread-Index: AcG5gPMwAeDenpK+SVKPHN7erO8qBg== From: "Gopi Krishna" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id PAA00310 Subject: [dhcwg] RE: Maximum message size interpretation in DHCP packet 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 Hi, Does not it include the ethernet header besides IP,UDP and DHCP in finding the Maximum DHCP Packet size? Thanks in advance. -Gopi -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] Sent: Tuesday, February 19, 2002 9:01 AM To: dhcwg@ietf.org Subject: dhcwg digest, Vol 1 #174 - 3 msgs Send dhcwg mailing list submissions to dhcwg@ietf.org To subscribe or unsubscribe via the web, visit https://www1.ietf.org/mailman/listinfo/dhcwg or, via email, send a message with subject or body 'help' to dhcwg-request@ietf.org You can reach the person managing the list at dhcwg-admin@ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of dhcwg digest..." Today's Topics: 1. Re: Maximum message size interpretation (Tobin Coziahr) 2. Re: Maximum message size interpretation (Thomas Narten) 3. Re: Maximum message size interpretation (Tobin Coziahr) --__--__-- Message: 1 Date: Tue, 19 Feb 2002 01:22:08 -0800 From: Tobin Coziahr Organization: Sun Microsystems To: Bud Millwood CC: DHCP discussion list Subject: Re: [dhcwg] Maximum message size interpretation Bud- The Maximum Message Size option is also known as the "maximum DHCP message size" option (See RFC 2131, page 9-10). This ONLY refers to the size of the DHCP packet itself, without the IP and UDP headers. The point of the option is to let servers use messages larger than 548 bytes, which is the default max. So no, don't subtract the header size. -Tobin Bud Millwood wrote: > > When a client gives my server the maximum message size it can receive, should > I interpret that as the total IP packet size the client can receive or just > the size of the DHCP portion? > > >From the description of this option, it appears that I should interpret the > value as the size of the entire IP packet the client can receive. > > In other words, should I subtract IP and UDP header sizes from a client's > Maximum Message Size value? > > - Bud > > 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 > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Tobin Coziahr 650-786-7118 (x87118) Solaris Networking tobin.coziahr@sun.com Sun Microsystems --__--__-- Message: 2 To: Tobin Coziahr cc: Bud Millwood , DHCP discussion list Subject: Re: [dhcwg] Maximum message size interpretation Date: Tue, 19 Feb 2002 06:34:04 -0500 From: Thomas Narten > The Maximum Message Size option is also known as the "maximum DHCP > message size" option (See RFC 2131, page 9-10). This ONLY refers to the > size of the DHCP packet itself, without the IP and UDP headers. The > point of the option is to let servers use messages larger than 548 > bytes, which is the default max. > So no, don't subtract the header size. Hmm. That's not what draft-ietf-dhc-csr-06.txt says: > 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. 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.) Is the above text correct? Thomas --__--__-- Message: 3 Date: Tue, 19 Feb 2002 03:59:42 -0800 From: Tobin Coziahr Organization: Sun Microsystems To: Thomas Narten CC: Bud Millwood , DHCP discussion list Subject: Re: [dhcwg] Maximum message size interpretation My apologies, you're right. All of the information I just found on the subject notes that the minimum value for this option is 576, which along with the RFC that you quoted shows that I was mistaken. The Maximum Message Size option DOES include the IP and UDP headers. Thanks for the correction, Thomas. -Tobin Thomas Narten wrote: > > > The Maximum Message Size option is also known as the "maximum DHCP > > message size" option (See RFC 2131, page 9-10). This ONLY refers to the > > size of the DHCP packet itself, without the IP and UDP headers. The > > point of the option is to let servers use messages larger than 548 > > bytes, which is the default max. > > > So no, don't subtract the header size. > > Hmm. That's not what draft-ietf-dhc-csr-06.txt says: > > > 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. 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.) > > Is the above text correct? > > Thomas > > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg -- Tobin Coziahr 650-786-7118 (x87118) Solaris Networking tobin.coziahr@sun.com Sun Microsystems --__--__-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg End of dhcwg Digest _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Feb 19 16:14:20 2002 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 QAA05724; Tue, 19 Feb 2002 16:14:20 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03459; Tue, 19 Feb 2002 16:14:00 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA03429 for ; Tue, 19 Feb 2002 16:13:58 -0500 (EST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05706 for ; Tue, 19 Feb 2002 16:13:55 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id OAA00782; Tue, 19 Feb 2002 14:13:56 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.87.31]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id NAA05788; Tue, 19 Feb 2002 13:15:45 -0800 (PST) Received: from sun.com (raistlin.Eng.Sun.COM [129.146.86.244]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1JLDrrU468337; Tue, 19 Feb 2002 13:13:54 -0800 (PST) Message-ID: <3C72C026.7315E9F5@sun.com> Date: Tue, 19 Feb 2002 13:14:14 -0800 From: Tobin Coziahr Organization: Sun Microsystems X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.9 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Gopi Krishna CC: dhcwg@ietf.org Subject: Re: [dhcwg] RE: Maximum message size interpretation in DHCP packet References: <917063BAB0DDB043AF5FAA73C7A835D42132C6@windlord.WWP.COM> 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 Nope, just IP, UDP, and DHCP need to be considered. It's stated in draft-ietf-dhc-csr-06.txt that the standard maximum size of a DHCP message is 576 bytes. That's 548 for the maximum basic DHCP packet, and 28 for IP and UDP headers. You then use the maximum message size option to negotiate communication at larger sizes, if desired. As Thomas pointed out, that document also mentions that the Max DHCP message size is the DHCP message plus IP and UDP. -Tobin Gopi Krishna wrote: > > Hi, > Does not it include the ethernet header besides IP,UDP and DHCP in finding the Maximum DHCP Packet size? > Thanks in advance. > > -Gopi --- Tobin Coziahr 650-786-7118 (x87118) Solaris Networking tobin.coziahr@sun.com Sun Microsystems _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Feb 20 20:48:01 2002 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 UAA25811; Wed, 20 Feb 2002 20:48:01 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05347; Wed, 20 Feb 2002 20:45:30 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id UAA05316 for ; Wed, 20 Feb 2002 20:45:27 -0500 (EST) Received: from [12.10.13.162] (hades.labone.com [12.10.13.162]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA25787 for ; Wed, 20 Feb 2002 20:45:24 -0500 (EST) Received: from mailgate by [12.10.13.162] via smtpd (for odin.ietf.org [132.151.1.176]) with SMTP; 21 Feb 2002 01:44:17 UT Received: from 172.24.1.28 by mailgate.labone.com with ESMTP (SMTP Relay (MMS v4.7)); Wed, 20 Feb 2002 19:44:16 -0600 X-Server-Uuid: d2c6f521-be8f-45bd-b261-f27c182a9ace Received: by mail.1.24.172.in-addr.arpa with Internet Mail Service ( 5.5.2650.21) id <1R3PXQPZ>; Wed, 20 Feb 2002 19:44:16 -0600 Message-ID: From: "Gary Gatten" To: "'dhcwg@ietf.org'" Date: Wed, 20 Feb 2002 19:44:13 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 106A8F7A101917-01-02 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhcp relay agent for windows 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 I'm looking for a relay agent for windows platforms. I know the server products have one, but I'm looking for a process I can run on a 9x/Me/2k "workstation" platform. Thanks! Gary This transmission (and any information attached to it) may be confidential and is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient or the person responsible for delivering the transmission to the intended recipient, be advised that you have received this transmission in error and that any use, dissemination, forwarding, printing, or copying of this information is strictly prohibited. If you have received this transmission in error, please immediately notify LabOne at (800)388-4675. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 21 06:01:03 2002 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 GAA13040; Thu, 21 Feb 2002 06:01:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12778; Thu, 21 Feb 2002 06:00:31 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA12732 for ; Thu, 21 Feb 2002 06:00:26 -0500 (EST) Received: from cms1000.cms.co.in ([202.54.21.66]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA13017 for ; Thu, 21 Feb 2002 05:59:48 -0500 (EST) From: rndelec@cms.co.in Received: by cms1000.cms.co.in(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 65256B67.003C56D4 ; Thu, 21 Feb 2002 16:29:03 +0530 X-Lotus-FromDomain: CMS To: dhcwg@ietf.org Message-ID: <65256B67.002D2E05.00@cms1000.cms.co.in> Date: Thu, 21 Feb 2002 13:49:39 +0530 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [dhcwg] DHCP query 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 Dear Sir, Our organisation is engaged In R&D activity related to network. I have one query regarding DHCP protocol. 1. Setup : One PC is DHCP sever allocating IP address to two other PCs. 2.After power ON both The PCs will get IP address and Lease Time. 3. Can the software running on one PC send command to DHCP server asking the what is the IP address of the other PC? Thanks & Regards, Umesh Bhat Sr.R&D engineer. CMS Computers Ltd. first floor,Agarkar-namjoshi Bhavan, LBS road,PUNE INDIA Phone:91-20-4333370 E-mail:rndelec@cms.co.in _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 21 12:14:22 2002 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 MAA25023; Thu, 21 Feb 2002 12:14:22 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08338; Thu, 21 Feb 2002 12:13:19 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id MAA08304 for ; Thu, 21 Feb 2002 12:13:15 -0500 (EST) Received: from localhost ([218.51.122.195]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24975 for ; Thu, 21 Feb 2002 12:13:09 -0500 (EST) Message-Id: <200202211713.MAA24975@ietf.org> Reply-To: young@kimcad.co.kr From: �ѱ��ڸ�� To: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/html; charset="ks_c_5601-1987" Date: Fri, 22 Feb 2002 02:07:26 +0900 Subject: [dhcwg] [��]��ĳ�� ĳ�� Ư�� (�л��)��ǰ�� 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 ��ο�(020218)

��ĳ�� ĳ�� Ư�� (�л��)��ǰ��

�� Ư¡

- AutoCAD�� ɾ�

- AutoCAD�� ȣȯ

- AutoCAD��

�� ߻�(��ڸ��ڸ��) �Ұ�

- (��ϰ��Ź�,�߱�û,��ں�)��ó�� (2001��)

- (��ο��ȸ,��) ��ó 20�� (2001��)

- (�ѱ��Ź�)��ó�� 50�ο� ��(2001��)

- (��ڿ��)��´�ȸ ��ɻ� ��(2000��)

- (��ź�)S/W �� (2000��)

�� (�Һ��ڰ� 90��)�� ٸ��

-VBA(Visual Basic Application)��

-�̹�� Ա��

-3D �� .

�� (ü��)��

�� ,��ڽ�,��Ľ�,�帲��,��ڸ��(��̴��),�ѹ̸�,�ɸ��,��,��,

�޸�� ڷ�� ׷�� ÿ�� ٿ�ε� �Ͻ� �� ֽ��ϴ�.

http://www.kimcad.co.kr/download/cadian_web_eval.exe

�� ǰ�� ǥ

��ǰ��	��ǰ��	��	��
CADian LT	CD+��1��	25,000��	AutoCAD ��
CADian LT ARCH	CD+��2��	45,000��	��༳��
CADian LT MECH	CD+��2��	60,000��	��ǰ5,000��

�� ESD�� Ͻø� 5,000�� .

�� Թ��

��'�ѱ��ڸ��'�� Ȩ�� www.kimcad.co.kr�� �� ̼�� �� û

��ѱ۰��ǻ��,�޸��,��,��ڸ��(��̴��) ,��Ʈ��-MSshop �� ͳ� ��

�� ESD �Ǵ� �ٿ�ε� �� �ڳʿ��

http://www.koreasoft.com/viewSoftware.jsp?pcode=ESD1005260

��ESD : Electronic Software Delivery(�ٿ�ε�� )

�鼭��ó� ��(��,��ǳ,�ڿ�� ﹮�� )��

��Թ��:�ѱ��ڸ��
http://www.kimcad.co.kr
E-Mail : young@kimcad.co.kr
��ȭ:(02)6436-3685, 017-266-3619
�� : ��

_______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Feb 21 22:09:11 2002 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 WAA10763; Thu, 21 Feb 2002 22:09:11 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12213; Thu, 21 Feb 2002 22:05:29 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id WAA12190 for ; Thu, 21 Feb 2002 22:05:26 -0500 (EST) Received: from kathmandu.sun.com (kathmandu.sun.com [192.18.98.36]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10739 for ; Thu, 21 Feb 2002 22:05:21 -0500 (EST) Received: from sunmail1.Sun.COM ([129.145.1.2]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id UAA21143 for ; Thu, 21 Feb 2002 20:05:24 -0700 (MST) Received: from jurassic.eng.sun.com (jurassic.Eng.Sun.COM [129.146.86.38]) by sunmail1.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1-Sun.COM.mod.2) with ESMTP id TAA28349 for ; Thu, 21 Feb 2002 19:07:18 -0800 (PST) Received: from kanawha (kanawha.Eng.Sun.COM [129.146.86.81]) by jurassic.eng.sun.com (8.12.2+Sun/8.12.2) with ESMTP id g1M35Nsu161909 for ; Thu, 21 Feb 2002 19:05:23 -0800 (PST) Message-Id: <200202220305.g1M35Nsu161909@jurassic.eng.sun.com> To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0" Content-ID: <26381.1014346907.0@kanawha> Date: Thu, 21 Feb 2002 19:05:07 -0800 From: Carl Smith Subject: [dhcwg] Host Name option considerations draft 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 ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26381.1014346907.1@kanawha> I just submitted a draft capturing some of the discussions Ted and I had at the SLC meeting about treatment of the Host Name option. To jumpstart discussion without waiting for what must currently be a very busy RFC editor, I've also attached it to this message. Fair warning: Ted's quite busy right now and hasn't had a chance to thoroughly review it yet, so you get my view of things moderated by talking with him rather than something to which we'll both claim to agree upon. But hey, it's just draft -00. Carl ------- =_aaaaaaaaaa0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26381.1014346907.2@kanawha> Content-Description: host name option considerations DHC Working Group Carl Smith Internet Draft Sun Microsystems, Inc. Ted Lemon Nominum, Inc. Updates: RFC 2132 February 2002 Expires August 2002 Considerations for the use of the Host Name option Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". To view the entire list of current Internet-Drafts, please check the 1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). Abstract This document clarifies the use of the DHCP Host Name option. The primary point of this clarification addresses the use of the option by clients to request proxy DNS updates by DHCP servers. 1. Introduction The initial concept of the Host Name option, as documented in RFC 1533[1] and duplicated in RFC 2132 [2], was simply to allow a DHCP server to supply a client with its name (``This option specifies the name of the client''). The DHCP client was merely a consumer of the option information. Even in this case, confusion has been reported in interactions with various domain name options. Behavior of client and server when the client supplies the option was, and still is, unspecified. In the intervening years, the Smith & Lemon [Page 1] RFC DRAFT February 2002 ability to easily update Domain Name Service information [3] has encouraged the use of this option by DHCP clients as a way to request that DHCP servers issue proxy DNS updates on their behalf. Lack of a document describing its exact usage has led, as one would surely expect, to interoperability problems. It is the purpose of this document to outline the expectations that clients and servers should have when using the Host Name option. 2. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [4]. This document also uses the following terms: "DHCP client" DHCP client or "client" is an Internet host using DHCP to obtain configuration parameters such as a network address. "DHCP server" A DHCP server or "server" is an Internet host that returns configuration parameters to DHCP clients. "FQDN" A fully-qualified name, including the host part and Domain Name system domain. 3. Interactions with Name Services A DHCP client's use of the Host Name option should be fairly straightforward, but users report problems, particularly with the interactions between it and Domain Name option and between the DNS (RFC 1034 [5] and RFC 1035 [6]) and other naming services so we reiterate and expand the description of the expected behavior: if a DHCP server supplies both Host Name and Domain Name options to a client, the host name SHOULD NOT be fully-qualified if a DHCP server supplies only a Host Name option, the host name SHOULD be fully qualified; the server MUST append only DNS domain names in forming a fully-qualified name a client MUST check to see whether a Host Name option contains a fully-qualified name and if so, MUST NOT append the value of the Domain Name option (if present) in forming its fully-qualified Smith & Lemon [Page 2] RFC DRAFT February 2002 domain name since a Host Name option's value may be fully-qualified only by supplying the DNS domain name, a client that receives a fully- qualified name in the Host Name option MAY infer the DNS domain name from the suffix of the supplied host name. This inference remains valid even in the presence of client configuration infor- mation or policies that prefer other name services in favor of, or in place of, DNS. 4. DNS Updates for DHCP Clients DNS maintains Resource Records (RRs) for mapping between IP addresses FQDNs. Specifically, A records map FQDNs to IP addresses and PTR records map IP addresses to FQDNs. Several options are available to DHCP clients interested in updating A and PTR records: issuing direct updates to DNS using the DHCP client FQDN option [7] using the DHCP Host Name option Either of the first two methods has the advantage of offering the client a number of approaches for fine-tuning DNS update requests as well as direct feedback on the success or failure of the intended operations. Both are to be preferred over the latter: use of the Host Name option does not even guarantee that the DHCP server will attempt any DNS updates on a client's behalf. Nevertheless, support for this method of requesting proxy DNS updates is widespread and it may be viewed as appropriate for situations in which there are no requirements for other finely-tunable methods. 4.1 DHCP Client Considerations and Behavior A DHCP client that uses the Host Name option to request a DNS update MUST be prepared to independently verify the success or failure of the request before using the name in a manner that would imply its validity. If a DHCP server returns the requested name in the DHCPACK's Host Name option, the client MAY infer that the server has honored its request. There are a number of reasons that a DHCP server may fail to return a Host Name option, so nothing should be inferred from the option's absence in the DHCPACK. The client MAY supply the option on subse- quent RENEW operations as a method of retrying the request. However, if the Host Name option is absent in the DHCPACK, the client MUST NOT use the requested name until it has verified the validity of the Smith & Lemon [Page 3] RFC DRAFT February 2002 association between it and the IP address supplied in the yiaddr field. Moreover, if the name returned in the DHCPACK is different from the one requested, the client MUST use the new name. A DHCP client MAY send either an unqualified or fully-qualified name in the Host Name option. Clients sending unqualified names are implicitly relying on DHCP servers to associate the clients with the appropriate zone before issuing any updates to DNS. A DHCP client in INIT state SHOULD fill in the requested host name in the DHCPDISCOVER packet. It MUST do so in its subsequent DHCPREQUEST packet. Clients in states other than INIT SHOULD avoid ambiguity in their requests by supplying the same Host Name option value on subsequent DHCPREQUESTs as was supplied on their original (INIT state) DHCPRE- QUEST. A client that wishes to change its host name MAY request it by sup- plying a Host Name option with the new name in a subsequent RENEW request. As with the initial request, a client MUST NOT use the newly-requested name until it has verified that it is now valid. 4.2 DHCP Server Considerations and Behavior Use of the FQDN option makes it possible to easily separate update operations into pieces corresponding to what are thought of as the traditional ownership boundaries: DHCP servers own the addresses they lease, while the clients own their names. This boundary is not present when the Host Name option is used: the implied proxy update request assumes that the DHCP server has sufficient privilege to change both the A and PTR records. That is, it ``owns'' both. For this and other reasons, use of the FQDN option is preferred: a DHCP server that receives both a Host Name option and a client FQDN option MUST prefer the FQDN option. In such a case, the server SHOULD behave as if the Host Name option is not present. A DHCP server MAY use the value of the Host Name option in a DHCPDIS- COVER packet in some limited ways: it may check to see whether the requested name belongs to an address that ls leaseable to the client, saving the need for a DNS update, or it may begin preparation of an update request. The server MUST wait for the DHCPREQUEST before ini- tiating any update operations. DNS updates may not complete in a timely manner, forcing the DHCP server to reply to a client before the update has finished. Alterna- tively, an error may be reported in response to the update request. It is not possible to distinguish these cases for the client's bene- fit, and the the DHCP server simply omits the Host Name option from Smith & Lemon [Page 4] RFC DRAFT February 2002 its DHCPACK. For simplicity of implementation, servers may choose to ``orphan'' any outstanding requests, taking no note of subsequent reports of success or failure. Servers that choose to keep track of the results of update requests SHOULD use successful completion reports to avoid subsequent unnecessary work; those servers SHOULD ignore reports of soft, transitory errors. Hard errors SHOULD be logged by the server so that corrective action, if any, may be taken by an administrator. Servers MAY choose to not cache hard failures, retrying on subsequent DHCPREQUESTs in the hope that the errors logged have led to a remedy. Issuing DNS updates on behalf of DHCP clients is an inherently state- ful operation. A DHCP server MUST commit to stable storage the necessary information regarding any updates it successfully makes on behalf of its clients. This state may be needed when a lease expires when communicating with a failover partner on subsequent lease renewals and may need to be recovered when the server is restarted. When a lease expires, a DHCP server MAY use this stored information to expunge the name-to-address association it created on the client's behalf. Because the use of the Host Name option cedes the ownership of the name to the server, a server MAY instead choose to allow the association to continue, saving itself work now and possibly sparing the need for a future update. A server MAY choose to reevaluate the Host Name option each time a client sends a RENEW request via a DHCPREQUEST, or the server MAY choose to view the update request as an action to be taken once, upon initial lease of an address. Servers that take the former view offer their clients the possibility of changing the name associated with a currently valid lease, but may incur additional processing costs because of it. Servers taking the latter view do not afford clients the opportunity to change names, but more importantly do not allow them to retry failed requests, possibly even with different host names. For this reason, the former behavior is preferred: servers SHOULD reevaluate the Host Name option on each RENEW. Some servers interpret a Host Name option on the initial DHCPREQUEST, followed by the absence of the option on subsequent RENEW DHCPRE- QUESTs as a request by the client to delete a name-to-address associ- ation. Here we invoke the principle of least surprise: it is more reasonable for a client to expect that DNS updates apply for the Smith & Lemon [Page 5] RFC DRAFT February 2002 duration of a lease than it is to expect that a client will wish to delete an update but retain the lease. Because clients that expect DNS updates to apply for the duration of a lease may not send a Host Name option when RENEWing, servers SHOULD NOT interpret the absence of the option as a request for deletion of the association. 5. References [1] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 1533, October 1993. [2] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [3] Vixie, P., Thomson, S., Rekhter, Y., Bound, J., "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [4] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [5] Mockapetris, P., "Domain names - Concepts and Facilities", RFC 1034, November 1987. [6] Mockapetris, P., "Domain names - Implementation and Specifica- tion", RFC 1035, November 1987. [7] Stapp, M. and Rekhter, Y., "The DHCP Client FQDN Option", draft- ietf-dhc-fqdn-option-03.txt, November 2001. 6. Author Information Carl Smith Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94043 USA email: cs@Eng.Sun.COM Ted Lemon Nominum, Inc. 950 Charter Street Redwood City, CA 94043 USA email: Ted.Lemon@nominum.com 7. Expiration This document will expire on August 22, 2002. 8. Full Copyright Statement Copyright (C) The Internet Society (1999). All Rights Reserved. This document and translations of it may be copied and furnished to Smith & Lemon [Page 6] RFC DRAFT February 2002 others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MER- CHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Smith & Lemon [Page 7] ------- =_aaaaaaaaaa0-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 22 06:19:52 2002 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 GAA26909; Fri, 22 Feb 2002 06:19:52 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14321; Fri, 22 Feb 2002 06:19:38 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id GAA14296 for ; Fri, 22 Feb 2002 06:19:36 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26832; Fri, 22 Feb 2002 06:19:32 -0500 (EST) Message-Id: <200202221119.GAA26832@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 22 Feb 2002 06:19:32 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-00.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 --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 : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option Author(s) : R. Droms, J. Schnizlein Filename : draft-ietf-dhc-agentopt-radius-00.txt Pages : 7 Date : 21-Feb-02 A network access device may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of an IP address for assignment to the device through its DHCP client. The RADIUS Attributes sub-option allows a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. 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-agentopt-radius-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20020221154422.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentopt-radius-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20020221154422.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 22 07:18:12 2002 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 HAA29065; Fri, 22 Feb 2002 07:18:03 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17808; Fri, 22 Feb 2002 07:17:47 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id HAA17729 for ; Fri, 22 Feb 2002 07:17:43 -0500 (EST) Received: from imr2.ericy.com (imr2.ericy.com [198.24.6.3]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29038 for ; Fri, 22 Feb 2002 07:17:40 -0500 (EST) Received: from mr7.exu.ericsson.se (mr7att.ericy.com [138.85.224.158]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id g1MCHCS26726 for ; Fri, 22 Feb 2002 06:17:12 -0600 (CST) 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 g1MCHBh17851 for ; Fri, 22 Feb 2002 06:17:12 -0600 (CST) Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt747.exu.ericsson.se ; Fri Feb 22 06:17:11 2002 -0600 Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id ; Fri, 22 Feb 2002 06:17:11 -0600 Message-ID: <66F66129A77AD411B76200508B65AC69B4CFEB@EAMBUNT705> From: "Bernie Volz (EUD)" To: "'internet-drafts@ietf.org'" Cc: dhcwg@ietf.org Date: Fri, 22 Feb 2002 06:17:09 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C1BB9A.D97A8E90" Subject: [dhcwg] Draft Submission - draft-ietf-dhc-dhcpv6-loadb-00.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 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_01C1BB9A.D97A8E90 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1BB9A.D97A8E90" ------_=_NextPart_001_01C1BB9A.D97A8E90 Content-Type: text/plain; charset="iso-8859-1" Hello: I am submitting the following Internet-Draft. <> It is a DHC working group effort based on discussions at IETF-52. You might have problems contacting Ralph Droms as he is traveling and does not have email access. I believe he will return on February 26th. If you need to, please submit it as an individual contribution. Thanks in advance. > Bernie Volz > Chief Technical Officer - DNS & DHCP Development Unit > Ericsson, Inc. > Tel: +1-508-875-3162 > Fax: +1-508-875-3018 > Mobile: +1-508-333-4975 > mailto:bernie.volz@ericsson.com > > ------_=_NextPart_001_01C1BB9A.D97A8E90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Draft Submission - draft-ietf-dhc-dhcpv6-loadb-00.txt

Hello:

I am submitting the following = Internet-Draft.

= <<draft-ietf-dhc-dhcpv6-loadb-00.txt>>
It is a DHC working group effort = based on discussions at IETF-52. You might have problems contacting = Ralph Droms as he is traveling and does not have email access. I = believe he will return on February 26th.

If you need to, please submit it as an = individual contribution.

Thanks in advance.

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

------_=_NextPart_001_01C1BB9A.D97A8E90-- ------_=_NextPart_000_01C1BB9A.D97A8E90 Content-Type: text/plain; name="draft-ietf-dhc-dhcpv6-loadb-00.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="draft-ietf-dhc-dhcpv6-loadb-00.txt" Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable Internet Engineering Task Force B. = Volz INTERNET DRAFT = Ericsson DHC Working Group Feb = 2002 Expires: August 22, 2002 Load Balancing for DHCPv6 draft-ietf-dhc-dhcpv6-loadb-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six = months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 22, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document specifies a load balancing algorithm for use with DHCPv6. Load balancing enables multiple cooperating DHCPv6 servers to decide which one should service a client, without exchanging any information beyond initial configuration. It expands on RFC 3074 "DHC Load Balancing Algorithm" to include DHCPv6. 1. Introduction This document extends the load balancing concepts described in RFC 3074 "DHC Load Balancing Algorithm" [3] to DHCPv6 [2]. 2. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in RFC 2119 [1]. Volz Expires 22 Aug 2002 [Page = 1] =0C Internet Draft Load Balancing for DHCPv6 (-00) 22 Feb = 2002 3. Terminology This document uses terminology specific to IPv6 and DHCPv6 as = defined in the "Terminology" section of the DHCP specification [2]. This document uses many of the concepts and terminology specific to load balancing as defined in the "Load Balancing Terminology" = section of the DHC Load Balancing specification [3]. 4. DHCPv6 Server Operation DHCPv6 uses a DUID (DHCP Unique Identifier) to identify clients. The DUID is carried in most client-generated messages in the Client Identifier option as described in [2]. The client's DUID is defined to be the Service Transaction ID (STID) [3]. DHCPv6 uses two types of client messages, those that are directed to a specific server and those that are directed to all servers. The messages directed to a specific server contain a Server Identifier option as described in [2] and include the Request, Renew, Release, Decline, and Information-Request messages. The messages directed to all servers do not include a Server Identifier option and include the Solicit, Confirm, Rebind, and Information-Request messages. For the messages directed to a specific server, this load balancing algorithm does not apply and a server processes that client's request if the Server Identifier option's DUID of the request = matches it own and discards all other requests. For the messages directed to all servers, the load balancing algorithm MAY be used to limit the clients that a server services if the request contains a Client Identifier option. The server uses the hash algorithm described in [3] on the client's DUID (the STID) and uses the resulting hash value to determine if the client is within the server's configured hash bucket assignment (HBA) [3]. If the hash value is assigned to the server, the server MUST process the client request (other server policy may of course determine how the request is processed and whether a reply is sent to the client). If the hash value is not assigned to the server, the server SHOULD NOT process the request. The server MAY process the request if the elapsed time value in the Elapsed Time option of the request exceeds a preconfigured value (the Service Delay or SD in [3]). How the SD = is configured for a server is outside the scope of this document. For client requests (such as Information-Request messages) which do not contain a Client Identifier option, there is no STID and thus = all servers MUST process these requests. The hash bucket assignments for each server must be configured and care must be taken to assign each hash bucket to at least one server. How the hash buckets are configured in servers is outside the scope of this document. If a single hash bucket is assigned to multiple servers, the logic a client uses to select a server applies (just as if there were Volz Expires 22 Aug 2002 [Page = 2] =0C Internet Draft Load Balancing for DHCPv6 (-00) 22 Feb = 2002 multiple servers for clients without load balancing). For example, each server can be configured with a different server preference value [2]. 5. DHCPv6 Relay Operation This document does not specify any techniques related to load balancing for relays. While a similar approach to that described in [3] could be used with DHCPv6 relays, further investigation of the benefits and complexities this may add to DHCPv6 configurations is needed before any recommendations can be made. This is an area of further work and discussion. Relays MUST be configured to forward client requests to all of the DHCPv6 servers that may be part of a load balancing group. 6. DHCPv6 Client Operation DHCPv6 clients need not be aware that load balancing is in use by the servers. A client operates as described in [2]. Client operation with respect to load balancing is the same as client operation with multiple servers. If a server that was servicing a client becomes unavailable for some reason, the client will eventually time-out and communicate with all servers. When this happens, if there are multiple servers assigned to handle that client's hash bucket, one or more of these remaining servers will respond. If there are no other servers for that hash bucket, other servers may respond once the elapsed time value in the Elapsed Time option exceeds their configured SD. If there is only one server (either for all clients or for some of the hash buckets), failure of that server will prevent clients from obtaining or extending the lifetimes of addresses. However, there is no difference whether load balancing is used or not. 7. Security Considerations This proposal in and by itself provides no security, nor does it impact existing security. See [2] for further details as to DHCPv6 security issues. Servers using load balancing are responsible for ensuring that if the contents of the HBA are transmitted over the network as part of the process of configuring any server, that message be secured against tampering, since tempering with the HBA could result in a denial of service for some or all clients. 8. Acknowledgements Thanks to the DHC Working Group for their time and input into the specification starting at IETF-52. Thanks also to the following individuals for their comments and questions (in alphabetical order) Stefan Berg, Herold Fagerberg, Ted Lemon, Tony Lindstr=F6m, Thomas Narten, Anders Strand, and Jack Wong. Volz Expires 22 Aug 2002 [Page = 3] =0C Internet Draft Load Balancing for DHCPv6 (-00) 22 Feb = 2002 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and R. Droms (ed.), "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", draft-ietf-dhc-dhcpv6-23 (work in progress), = February 2002. [3] Volz, B., Gonczi, S., Lemon, T., Stevens, R., "DHC Load=20 Balancing Algorithm", RFC 3074, February 2001. Author's Address Bernie Volz Ericsson 959 Concord Street Framingham, MA 01701 USA Phone: +1 508 875 3162 EMail: bernie.volz@ericsson.com Volz Expires 22 Aug 2002 [Page = 4] =0C Internet Draft Load Balancing for DHCPv6 (-00) 22 Feb = 2002 Full Copyright Statement Copyright (C) The Internet Society (1970). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph = are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Volz Expires 22 Aug 2002 [Page = 5] ------_=_NextPart_000_01C1BB9A.D97A8E90-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Feb 22 14:04:57 2002 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 OAA17093; Fri, 22 Feb 2002 14:04:57 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16578; Fri, 22 Feb 2002 14:04:41 -0500 (EST) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA16561 for ; Fri, 22 Feb 2002 14:04:40 -0500 (EST) Received: from mailgw.ipunplugged.com (217.134.88.213.host.tele1europe.se [213.88.134.217]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17085 for

�� ȳ�

�� 24�ð� ��ٸ�� ־��(��)

*�ܷο򿡼� Ż��! ��Ʈ�� ؼ� 100%!! **

�˼��մϴ� �� Ÿ� �̿�� ǥ��Ͽ�� Űź��ġ�� ϰ� �ֽ��ϴ�.

��ּҴ� ��ͳݻ󿡼� ��Ѱ��̸� ��ּҿ� ��� ʽ��ϴ� ��ġ �� ٸ� �� 帮��, ��Űźθ� �� ֽø� ��ʹ� �� ߼۵�� Դϴ� ��Űź� (30/100)

������ ������ �ȳ�

������ 24�ð� ��ٸ��� �־��(��������)

*�ܷο򿡼� Ż��! ��Ʈ���� �ؼ� 100%!! **

�˼��մϴ� �� ������ ������Ÿ� �̿������� ������ ���� ������������ ǥ���Ͽ����� ���Űź���ġ�� �����ϰ� �ֽ��ϴ�.

�� ȳ�

�� 24�ð� ��ٸ�� ־��(��)

*�ܷο򿡼� Ż��! ��Ʈ�� ؼ� 100%!! **

�˼��մϴ� �� Ÿ� �̿�� ǥ��Ͽ�� Űź��ġ�� ϰ� �ֽ��ϴ�.