From daemon@optimus.ietf.org Fri Feb 1 04:16: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 EAA07049 for ; Fri, 1 Feb 2002 04:16:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA04367 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 04:17: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 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 daemon@optimus.ietf.org Fri Feb 1 11:57: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 LAA03458 for ; Fri, 1 Feb 2002 11:57:30 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA25772 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 11:57: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 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 daemon@optimus.ietf.org Fri Feb 1 12:12: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 MAA04290 for ; Fri, 1 Feb 2002 12:12:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA27995 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 12:12: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 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 daemon@optimus.ietf.org Fri Feb 1 12:18: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 MAA04531 for ; Fri, 1 Feb 2002 12:18:00 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28413 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 12: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 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 daemon@optimus.ietf.org Fri Feb 1 12:18:15 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 MAA04549 for ; Fri, 1 Feb 2002 12:18:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA28427 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 12:18:17 -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 daemon@optimus.ietf.org Fri Feb 1 13:05: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 NAA06084 for ; Fri, 1 Feb 2002 13:05:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA01412 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 13:05: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 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 daemon@optimus.ietf.org Fri Feb 1 13:53: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 NAA07843 for ; Fri, 1 Feb 2002 13:53:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA03473 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 13:53:25 -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 daemon@optimus.ietf.org Fri Feb 1 16:37:27 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 QAA12541 for ; Fri, 1 Feb 2002 16:37:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA11902 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 16:37: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 daemon@optimus.ietf.org Fri Feb 1 19:00:40 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 TAA14524 for ; Fri, 1 Feb 2002 19:00:40 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA18420 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 19:00: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 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 daemon@optimus.ietf.org Fri Feb 1 21:45: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 VAA17729 for ; Fri, 1 Feb 2002 21:45:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id VAA25042 for dhcwg-archive@odin.ietf.org; Fri, 1 Feb 2002 21:45: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 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 daemon@optimus.ietf.org Sat Feb 2 05:16: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 FAA01503 for ; Sat, 2 Feb 2002 05:16:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA20469 for dhcwg-archive@odin.ietf.org; Sat, 2 Feb 2002 05:16: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 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 daemon@optimus.ietf.org Mon Feb 4 01:02: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 BAA06364 for ; Mon, 4 Feb 2002 01:02:53 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA29489 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 01:02: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 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 daemon@optimus.ietf.org Mon Feb 4 01:42:33 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 BAA06778 for ; Mon, 4 Feb 2002 01:42:33 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA10011 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 01:42:34 -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 daemon@optimus.ietf.org Mon Feb 4 10:22: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 KAA25428 for ; Mon, 4 Feb 2002 10:22:14 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA08808 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 10:22:16 -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 daemon@ns.ietf.org Mon Feb 4 15:26: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 PAA05200 for ; Mon, 4 Feb 2002 15:26:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id PAA28901 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 15:26: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 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 daemon@ns.ietf.org Mon Feb 4 17:03: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 RAA06836 for ; Mon, 4 Feb 2002 17:03:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA03502 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 17:02: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 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 daemon@ns.ietf.org Mon Feb 4 19:46: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 TAA09331 for ; Mon, 4 Feb 2002 19:46:19 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA11802 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 19:46: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 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 daemon@ns.ietf.org Mon Feb 4 20:24:46 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 UAA09627 for ; Mon, 4 Feb 2002 20:24:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA13264 for dhcwg-archive@odin.ietf.org; Mon, 4 Feb 2002 20:24: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 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 daemon@optimus.ietf.org Tue Feb 5 01:35: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 BAA15603 for ; Tue, 5 Feb 2002 01:35:54 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA06448 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 01:35:55 -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 daemon@optimus.ietf.org Tue Feb 5 01:37:33 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 BAA15664 for ; Tue, 5 Feb 2002 01:37:32 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA06624 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 01:37:34 -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 daemon@optimus.ietf.org Tue Feb 5 01:48: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 BAA15865 for ; Tue, 5 Feb 2002 01:48:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA07455 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 01:48:27 -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 daemon@optimus.ietf.org Tue Feb 5 02:58:17 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 CAA24989 for ; Tue, 5 Feb 2002 02:58:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA10715 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 02:58: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 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 daemon@optimus.ietf.org Tue Feb 5 10:04: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 KAA02547 for ; Tue, 5 Feb 2002 10:04:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA04979 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 10:04:24 -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 daemon@optimus.ietf.org Tue Feb 5 10:13: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 KAA02942 for ; Tue, 5 Feb 2002 10:13:57 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA05471 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 10:13: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 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 daemon@optimus.ietf.org Tue Feb 5 10:29:25 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 KAA03790 for ; Tue, 5 Feb 2002 10:29:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA06373 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 10:29:27 -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 daemon@optimus.ietf.org Tue Feb 5 10:41: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 KAA04473 for ; Tue, 5 Feb 2002 10:41:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA07680 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 10:41: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 daemon@optimus.ietf.org Tue Feb 5 11:59: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 LAA08254 for ; Tue, 5 Feb 2002 11:59:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA15124 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 11:59:25 -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 daemon@ns.ietf.org Tue Feb 5 12:52: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 MAA10808 for ; Tue, 5 Feb 2002 12:52:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA21221 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 12:52: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 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 daemon@ns.ietf.org Tue Feb 5 13:15:45 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 NAA11809 for ; Tue, 5 Feb 2002 13:15:45 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA22791 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 13:15:47 -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 daemon@ns.ietf.org Tue Feb 5 13:55:37 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 NAA13667 for ; Tue, 5 Feb 2002 13:55:36 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA25042 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 13:55: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 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 daemon@ns.ietf.org Tue Feb 5 20:38: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 UAA27216 for ; Tue, 5 Feb 2002 20:38:11 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id UAA15622 for dhcwg-archive@odin.ietf.org; Tue, 5 Feb 2002 20: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 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 daemon@optimus.ietf.org Wed Feb 6 01:00: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 BAA04223 for ; Wed, 6 Feb 2002 01:00:50 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA28987 for dhcwg-archive@odin.ietf.org; Wed, 6 Feb 2002 01:00: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 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 daemon@optimus.ietf.org Wed Feb 6 01:26: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 BAA04459 for ; Wed, 6 Feb 2002 01:26:23 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id BAA09002 for dhcwg-archive@odin.ietf.org; Wed, 6 Feb 2002 01:26:24 -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 daemon@optimus.ietf.org Wed Feb 6 08:18:15 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 IAA18899 for ; Wed, 6 Feb 2002 08:18:15 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA00662 for dhcwg-archive@odin.ietf.org; Wed, 6 Feb 2002 08:18: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 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 daemon@optimus.ietf.org Wed Feb 6 13:29: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 NAA27759 for ; Wed, 6 Feb 2002 13:29:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA18867 for dhcwg-archive@odin.ietf.org; Wed, 6 Feb 2002 13:29:24 -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 daemon@ns.ietf.org Thu Feb 7 13:30: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 NAA04982 for ; Thu, 7 Feb 2002 13:30:52 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA07878 for dhcwg-archive@odin.ietf.org; Thu, 7 Feb 2002 13:30: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 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 daemon@optimus.ietf.org Fri Feb 8 10:11: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 KAA10146 for ; Fri, 8 Feb 2002 10:11:56 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA12380 for dhcwg-archive@odin.ietf.org; Fri, 8 Feb 2002 10:12: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 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 daemon@ns.ietf.org Mon Feb 11 05:23:17 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 FAA27728 for ; Mon, 11 Feb 2002 05:23:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA28440 for dhcwg-archive@odin.ietf.org; Mon, 11 Feb 2002 05:23: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 daemon@ns.ietf.org Mon Feb 11 11:51:10 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 LAA09645 for ; Mon, 11 Feb 2002 11:51:09 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA19423 for dhcwg-archive@odin.ietf.org; Mon, 11 Feb 2002 11:51: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 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 daemon@optimus.ietf.org Mon Feb 11 19:08:27 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 TAA20689 for ; Mon, 11 Feb 2002 19:08:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id TAA10684 for dhcwg-archive@odin.ietf.org; Mon, 11 Feb 2002 19:08:27 -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 daemon@optimus.ietf.org Mon Feb 11 22:54: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 WAA24900 for ; Mon, 11 Feb 2002 22:54:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA18693 for dhcwg-archive@odin.ietf.org; Mon, 11 Feb 2002 22:54: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 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 daemon@optimus.ietf.org Tue Feb 12 11:02: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 LAA16318 for ; Tue, 12 Feb 2002 11:02:21 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA29516 for dhcwg-archive@odin.ietf.org; Tue, 12 Feb 2002 11:02: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 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 daemon@optimus.ietf.org Wed Feb 13 22:34: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 WAA29455 for ; Wed, 13 Feb 2002 22:34:59 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id WAA22003 for dhcwg-archive@odin.ietf.org; Wed, 13 Feb 2002 22:35: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 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 daemon@optimus.ietf.org Wed Feb 13 23:31:17 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 XAA02450 for ; Wed, 13 Feb 2002 23:31:17 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id XAA27151 for dhcwg-archive@odin.ietf.org; Wed, 13 Feb 2002 23:31: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 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 daemon@optimus.ietf.org Thu Feb 14 04:33:25 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 EAA14090 for ; Thu, 14 Feb 2002 04:33:25 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA18421 for dhcwg-archive@odin.ietf.org; Thu, 14 Feb 2002 04:33:27 -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 daemon@optimus.ietf.org Thu Feb 14 04:59: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 EAA14429 for ; Thu, 14 Feb 2002 04:59:48 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA19562 for dhcwg-archive@odin.ietf.org; Thu, 14 Feb 2002 04:59: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 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 daemon@optimus.ietf.org Thu Feb 14 10:01: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 KAA23589 for ; Thu, 14 Feb 2002 10:01:27 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id KAA02383 for dhcwg-archive@odin.ietf.org; Thu, 14 Feb 2002 10:01: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 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 daemon@optimus.ietf.org Fri Feb 15 05:43: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 FAA01725 for ; Fri, 15 Feb 2002 05:43:07 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id FAA12197 for dhcwg-archive@odin.ietf.org; Fri, 15 Feb 2002 05:43:09 -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 daemon@optimus.ietf.org Fri Feb 15 16:46: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 QAA20706 for ; Fri, 15 Feb 2002 16:46:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id QAA20087 for dhcwg-archive@odin.ietf.org; Fri, 15 Feb 2002 16:46:27 -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 daemon@optimus.ietf.org Fri Feb 15 17:23: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 RAA21647 for ; Fri, 15 Feb 2002 17:23:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA22377 for dhcwg-archive@odin.ietf.org; Fri, 15 Feb 2002 17:23: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 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 daemon@optimus.ietf.org Sat Feb 16 09:53:24 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 JAA12628 for ; Sat, 16 Feb 2002 09:53:24 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id JAA05185 for dhcwg-archive@odin.ietf.org; Sat, 16 Feb 2002 09:53: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 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 daemon@optimus.ietf.org Sun Feb 17 02:14: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 CAA02409 for ; Sun, 17 Feb 2002 02:14:05 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id CAA19781 for dhcwg-archive@odin.ietf.org; Sun, 17 Feb 2002 02:14: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 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 daemon@optimus.ietf.org Sun Feb 17 06: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 GAA04410 for ; Sun, 17 Feb 2002 06:14:22 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29258 for dhcwg-archive@odin.ietf.org; Sun, 17 Feb 2002 06:14:25 -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 daemon@optimus.ietf.org Sun Feb 17 12:51: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 MAA09128 for ; Sun, 17 Feb 2002 12:51:29 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id MAA19334 for dhcwg-archive@odin.ietf.org; Sun, 17 Feb 2002 12:51: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 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 daemon@optimus.ietf.org Mon Feb 18 11:20:16 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 LAA06956 for ; Mon, 18 Feb 2002 11:20:16 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA27772 for dhcwg-archive@odin.ietf.org; Mon, 18 Feb 2002 11:20: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 daemon@optimus.ietf.org Mon Feb 18 11:24: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 LAA07201 for ; Mon, 18 Feb 2002 11:24:26 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id LAA28033 for dhcwg-archive@odin.ietf.org; Mon, 18 Feb 2002 11:24: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 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 daemon@optimus.ietf.org Tue Feb 19 04:31: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 EAA13038 for ; Tue, 19 Feb 2002 04:31:28 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id EAA23024 for dhcwg-archive@odin.ietf.org; Tue, 19 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 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 daemon@optimus.ietf.org Tue Feb 19 06:40:41 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 GAA14520 for ; Tue, 19 Feb 2002 06:40:41 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id GAA29530 for dhcwg-archive@odin.ietf.org; Tue, 19 Feb 2002 06:40: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 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 daemon@optimus.ietf.org Tue Feb 19 07:11: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 HAA15509 for ; Tue, 19 Feb 2002 07:11:08 -0500 (EST) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id HAA01250 for dhcwg-archive@odin.ietf.org; Tue, 19 Feb 2002 07:11:09 -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

�� ȳ�

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

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

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

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

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

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

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

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

�� ȳ�

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

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

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