From dhcwg-admin@ietf.org Fri Nov 1 10:58:50 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18586; Fri, 1 Nov 2002 10:58:50 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1G08v06164; Fri, 1 Nov 2002 11:00:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1Fwcv05342 for ; Fri, 1 Nov 2002 10:58:38 -0500 Received: from sj-msg-core-2.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18372 for ; Fri, 1 Nov 2002 10:56:10 -0500 (EST) Received: from goblet.cisco.com (IDENT:mirapoint@goblet.cisco.com [161.44.168.80]) by sj-msg-core-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA1FwSgM001400; Fri, 1 Nov 2002 07:58:28 -0800 (PST) Received: from KKINNEAR-W2K.cisco.com (ch2-dhcp150-66.cisco.com [161.44.150.66]) by goblet.cisco.com (Mirapoint) with ESMTP id ACA38638; Fri, 1 Nov 2002 10:58:30 -0500 (EST) Message-Id: <4.3.2.7.2.20021101104458.02355e58@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Nov 2002 10:58:18 -0500 To: Ralph Droms , dhcwg@ietf.org From: Kim Kinnear Subject: Re: [dhcwg] Re: WG last call for "DHCP Lease Query" Cc: kkinnear@cisco.com In-Reply-To: <4.3.2.7.2.20020711054826.03391d98@funnel.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, I have recently submitted draft-ietf-dhc-leasequery-04.txt where I made the following changes that came up during WG last call. Essentially I made all of the changes that Ralph suggested, and fixed several minor wording errors. I also updated one of the author's contact info. Details are interspersed in the changes recommended by Ralph, below. Cheers -- Kim At 09:35 AM 7/14/2002, Ralph Droms wrote: >RIch and Kim, > >The items in this bullet list are more substantive, while the >remaining items are mostly editorial and listed in order of >appearance in the draft... > >* This draft proposes extending and overloading the > Requested IP Address option to carry IP addresses in > leasequery messages. Now that the pressure on new > option codes in DHCPv4 has eased up, we should consider > defining a new option (we could even assign it the > unused failover option code) rather than reusing the > existing option. This is what I originally proposed, and we decided to overload the existing option instead. But I changed it back, so now there are two new options defined by this draft: client-last-transaction-time, and associated-ip. >* I would prefer to see all the messages used with leasequery > transactions renamed to uniformly use the prefix DHCPLEASE. > This isn't as silly as it might sound; using names like > DHCPLEASEKNOWN would point out relationship among the messages, > and leave us room for the name for another message about > knowing something in DHCP (DHCP Done, except DHCPUNIMPLEMENTED was left without change, since it likely has larger utility than just this draft. This changes makes DHCPLEASEUNKNOWN a bit awkward of a respone for a query by client-id where the client-id is unknown, but the benefits seem to outweight that small awkwardness. >* Details in Section 5, Protocol Overview, are repeated in > section 6. It would be better to leave the details out > of section 5 to avoid potential confusing or contradictory > specification. For example, the first bullet item in Section > 5 could be edited to: > > o Query by IP address: > > For this query, the requester supplies an IP address in the > DHCPLEASEQUERY message. The DHCP server will return any > information that it has on the most recent client to have > been assigned that IP address. > > The DHCP server replies with a DHCPKNOWN or DHCPACTIVE > message if the IP address in the DHCPLEASEQUERY message corresponds to > an IP address about which the server has definitive information > (i.e., it is authorized to lease this IP address). The server > replies with a DHCPUNKNOWN message if the server does not have > definitive location information concerning address in the > DHCPLEASEQUERY message. Done. >Section 1, last paragraph: What do DHCPKNOWN and DHCPUNKNOWN do? Explained. >Section 2, definition of "reservation": clarify by inserting the following sentence before the last sentence in the definition: A reservation defines a mapping between a client and an IP address but doesn't establish or record a lease for the address. Done. >Section 3, third paragraph: why is "DHCPACTIVE" not mentioned in the parenthetical phrase? Perhaps simply drop the parenthetical? Dropped the parenthetical. >Section 5, paragraph 4: why is "(and are expected to)" included after SHOULD? Can you give guidance about when a server might send the DHCPUNIMPLEMENTED message instead of silently discarding the DHCPLEASEQUERY message. Also, for consistency, in the same sentence replace "Servers which do not support..." with "Servers that do not implement..." Clarified this language. >Section 5, last paragraph: why is saving the Relay Agent Information option called out specifically here? Shouldn't this be a MUST for the specific use by access concentrators in reconstructing location information? Also in this paragraph, why is the vendor-class-identifier option mentioned? I don't see it mentioned elsewhere in the document. Clarified the reasoning in the document. Other options (e.g., vendor-class-identifier) are mentioned because other users of the leasequery capability may well want them. I was trying to help out the people who implement leasequery realize some of what they may want to do. >Section 6.1, in the first numbered list change "three" to "four" in item 1. Done. >Section 6.2, 1st bullet list, 2nd bullet: under what circumstances will a requester not include a parameter request list option? What will be the consequences if the option is not included - will the server return no options, all options, a subset of options the server thinks is interesting? Clarified, referenced RFC 2131 on the subject. >Section 6.2, next to last paragraph: what does ""ciaddr" field mentioned in the DHCPLEASEQUERY message [...] is a local subnet of the interface specified for the client" mean? Tightened up the giaddr/ciaddr issues. >Section 6.3, last paragraph: any reason not to simply write: The 'giaddr' field MUST contain a valid IP address assigned to the relay agent that sent the DHCPLEASEQUERY message. Clarified the original sentence. Need to ensure that people don't use the giaddr to find a subnet in which the ciaddr / client-id / MAC-address must appear. >Section 6.4, DHCPKNOWN bullet: the first paragraph says the R bit MAY be set, the second paragraph says the R bit MUST be set and the third paragraph says the R bit "is set"; those three statements seem contradictory. The three paragraphs also contain significant repeated information. Clarified that the R bit is set only on output, per comments by Ted Lemmon. >Section 6.4: I think the last paragraph of section 6.4 should be moved to be the first paragraph of 6.4.1. The paragraph in question specifically addresses the topic of 6.4.1 - determining which IP address to respond to. Done. >Section 6.4.1, paragraph 7: add "address" after the first occurrence of "IP". > >Section 6.4.2, paragraph 6: what does "set from the client" mean? "Set to the MAC address belonging to the client"? > >Section 6.4.2, paragraph 7: replace "DHPC" with "DHCP" All done. >Section 6.4.2, paragraph 8: here, as well as elsewhere, the document mentions "IP [BTW, insert "address" here] has been accessed by the client". What does "accessed by the client" mean? The address has been involved in a DHCP message exchange? And, *please*, don't use "IP" for "IP address" (shudder). Added explanatory text. >Section 6.4.2, paragraph 9: doesn't the use of DHCPKNOWN and DHCPACTIVE differentiate whether there is a valid lease for the client? Yes, this is old text. Fixed. >Section 6.4.2, paragraph 10: the first sentence says "if the R bit is set in the DHCPLEASEQUERY", while earlier, section 6.4.1 says "the Reservations bit (the R bit) has no meaning in the DHCPLEASEQUERY message."; these two bits of text seem contradictory. Clarified this use of the R bit as well -- only on output. >Section 6.5, the explanations of the contents of the various messages are redundant and could be elided (e.g., the first sentence of the first paragraph). Well, a nice idea. I still think that it makes sense to leave them in, so I did. > In the second paragraph, perhaps I'm being dense or it's late or I'm still recovering from flying to Japan - how does an access concentrator use DHCPKNOWN to accomplish the good stuff in the last sentence? And is caching the DHCP server information a SHOULD? Why would the access concentrator use that information and under what circumstances would it not cache the information? Clarified the use of the DHCPLEASEKNOWN/DHCPLEASEUNKNOWN caching. >Section 6.5,, paragraph 4: add "does" between "server" and "not" in the first paragraph. Done. >Section 7: I thought I read at one point, but can't find it now, a suggestion that a DHCP server be configured with the addresses of the relay agents from which it would accept DHCPLEASEQUERY messages as a security measure. My apologies if the text is in the draft and I missed it; if I'm hallucinating, would the suggestion make any practical and useful sense? Added these recommendations. >Section 11: Some of this information is stale (mea culpa for taking so long to do the last call)... > > >_______________________________________________ >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 sip-admin@ietf.org Fri Nov 1 11:02:45 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18952 for ; Fri, 1 Nov 2002 11:02:45 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1G4gv07996 for ; Fri, 1 Nov 2002 11:04:42 -0500 Date: Fri, 01 Nov 2002 11:04:42 -0500 Message-ID: <20021101160442.25483.41588.Mailman@www1.ietf.org> Subject: ietf.org mailing list memberships reminder From: mailman-owner@www1.ietf.org To: DHC-ARCHIVE@ietf.org X-No-Archive: yes X-Ack: no Sender: sip-admin@ietf.org Errors-To: sip-admin@ietf.org X-BeenThere: sip@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, dhcwg-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. *************************************************************************** Note Well All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to * the IETF plenary session, * any IETF working group or portion thereof, * the IESG, or any member thereof on behalf of the IESG, * the IAB or any member thereof on behalf of the IAB, * any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, * the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. *************************************************************************** If you have questions, problems, comments, etc, send them to mailman-owner@www1.ietf.org. Thanks! Passwords for DHC-ARCHIVE@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org aCBd https://www1.ietf.org/mailman/options/dhcwg/dhc-archive%40lists.ietf.org From dhcwg-admin@ietf.org Fri Nov 1 11:27:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20793; Fri, 1 Nov 2002 11:27:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1GT7v18192; Fri, 1 Nov 2002 11:29:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1GMVv16109 for ; Fri, 1 Nov 2002 11:22:31 -0500 Received: from hellfire.dsldesigns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20324 for ; Fri, 1 Nov 2002 11:19:59 -0500 (EST) Received: from vanb.com (44.59.83.216.dsldesigns.com [216.83.59.44] (may be forged)) (authenticated (0 bits)) by hellfire.dsldesigns.com (8.11.6/8.11.6) with ESMTP id gA1HiIj06669 for ; Fri, 1 Nov 2002 09:44:18 -0800 Message-ID: <3DC2A9D4.201A2F15@vanb.com> Date: Fri, 01 Nov 2002 08:20:37 -0800 From: Audrey Van Belleghem Reply-To: audrey@vanb.com Organization: Van Belleghem Corporation X-Mailer: Mozilla 4.5 (Macintosh; I; PPC) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; x-mac-type="54455854"; x-mac-creator="4D4F5353" Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] Connectathon 2003 announcement Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Get ready for Connectathon 2003! The 17th annual interoperability testing event for engineers only will be held Feb. 27-March 6, 2003 in San Jose, California. For the past 2 years, Connectathon booth space has sold out! Get your registration forms and fees in early and take advantage of registration discounts available through December 31st. Connectathon, sponsored by Sun Microsystems, Inc., hosts over 50 companies annually in an effort to test and debug source code which utilize the following technologies and protocols: NFS versions 2, 3 and 4 NFS over RDMA NFSv4 replication and migration Lock Manager Kerberos Automounter IPv6 IPsec NDMP Mobile IPv6 Secure Shell CIFS Based on demand, in addition we are considering to offer: Diameter/AAA SCTP LDAP DHCPv6 If you are interested in testing any of the above 4 protocols, please send a note to Cthon@sun.com and we'll gauge interest. Or if you have a suggestion for another technology, feel free to contact us as well. Testing continues 24 hours per day. Technology testing coordinators will organize testing procedures and test suite material. In addition, there will be seminars and speakers addressing various topics. The registration deadline is February 7, 2003. But don't wait that long! And Early Bird Discount on booth fees is available to those who register and pay by December 31, 2002. For the past 2 years, Connectathon has sold out of booth space. Please get your registration materials in quickly to avoid disappointment. Go to http://www.connectathon.org to download all forms and information. If you have any questions, please feel free to contact Audrey Van Belleghem at audrey@vanb.com or (408) 358-9598. We look forward to seeing you at the 17th annual Connectathon event! Audrey Van Belleghem Connectathon Manager _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 1 11:35:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21272; Fri, 1 Nov 2002 11:35:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1GbBv21139; Fri, 1 Nov 2002 11:37:11 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA1GaUv20853 for ; Fri, 1 Nov 2002 11:36:30 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21195 for ; Fri, 1 Nov 2002 11:34:02 -0500 (EST) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA1GacBv016093; Fri, 1 Nov 2002 11:36:38 -0500 (EST) Received: from KKINNEAR-W2K.cisco.com (ch2-dhcp150-66.cisco.com [161.44.150.66]) by goblet.cisco.com (Mirapoint) with ESMTP id ACA39407; Fri, 1 Nov 2002 11:36:20 -0500 (EST) Message-Id: <4.3.2.7.2.20021101110208.0236f520@goblet.cisco.com> X-Sender: kkinnear@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 01 Nov 2002 11:36:18 -0500 To: dhcwg@ietf.org From: Kim Kinnear Cc: kkinnear@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [dhcwg] Failover Draft Status Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, A quick update on the status of the failover draft, so we don't have to spend time during the brief IETF DHC WG meeting discussing it. History ------- The failover draft, draft-ietf-dhc-failover-09.txt went to DHC WG last call on 8/22/2001. That last call ended 9/7/2001 with no serious changes required to the draft. Just about a year ago, in November of 2001 (and well after last call was over), there was some discussion about the failover draft on the list. There were some clarifications made as a result of these discussions in the draft, which was re-issued as draft-ietf-dhc-failover-10.txt in January of 2002. At that time it was ready for the next step, a review prior to IETF last call. During IETF in Yokohama during July this last summer (2002), there was an offline discussion about some concerns that were voiced by someone who had implemented the failover protocol. These concerns were deemed sufficient to delay any review prior to IETF last call, effectively blocking any further progress of the draft until they were resolved in some way. In early September 2002, when checking up on the draft's progress toward IETF last call, I was informed that it was stalled due to these concerns voiced at Yokohama. I have been trying (with increasing insistence) since early September to discover the details of these issues, but have been unable to get a response in sufficient detail to deal substantively with them. Since the draft-ietf-dhc-failover-10.txt has expired, I have submitted (today) draft-ietf-dhc-failover-11.txt, which has only the most minor changes (e.g., expiration dates) from the existing -10 draft. What's next? ------------ I expect to have an opportunity during the upcoming IETF in Atlanta to dig deeper into the issues that have stalled progress of the draft since the summer. I will report on what I discover about the details of these issues to this list soon after IETF in Atlanta is over. We are not planning to spend any time on failover during the WG meeting itself, which is the motivation behind this email. I expect we will resolve these issues one way or the other in 30 to 60 days, and I expect to re-issue a new version of the failover draft by January of 2003 (and possibly sooner). At that point, depending on the resolution, we may require another pass of DHC WG last call and we may not. The point is to get the protocol and the draft to be sufficiently correct to allow people to build operational and interoperational failover servers. Once we have done that, we will see how many changes were required and whether we need another WG last call. Then we will move on from there. Cheers -- Kim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 4 07:08:37 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10254; Mon, 4 Nov 2002 07:08:37 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4C9sv21917; Mon, 4 Nov 2002 07:09:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4C6tv21302 for ; Mon, 4 Nov 2002 07:06:55 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10202 for ; Mon, 4 Nov 2002 07:04:27 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-415.cisco.com [10.82.225.159]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id HAA20435 for ; Mon, 4 Nov 2002 07:06:54 -0500 (EST) Message-Id: <4.3.2.7.2.20021104063643.00b8f980@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Nov 2002 07:06:51 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Status of DHCPv6 specification Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Earlier this year, the DHCPv6 spec (draft-ietf-dhc-dhcpv6-26.txt) was reviewed by the IESG. Based on feedback from that review, we (the DHCPv6 authors) published draft-ietf-dhc-dhcpv6-27.txt. The majority of the changes were related to authentication. I've included a summary of the changes in the -27 rev of the specification below. draft-ietf-dhc-dhcpv6-27.txt is now under review by the IESG. - Ralph - Use of Reconfigure Key message is a new protocol in DHCP authentication - Added "DHCP Realm" to authentication to disambiguate keys from different administrative domains - Renamed IA to IA_NA throughout; now IA refers collectively to IA_NA and IA_TA - Reconfigure Accept option allows client to tell server if it will do Reconfigure and allows server to control whether client accepts Reconfigure - Add desynchronizing randomization for Confirm and Information-request messages - Added requirement for Client Identifier option if Information-request message is to be authenticated - Deleted restriction against more than one Vendor-specific Information option with same enterprise number - Added text in section 15 requiring that a server discards messages received via unicast such as Solicit that must be sent via multicast, to ensure relay agents can add relay agent options when needed - Eliminated use of "message code" in section 5 - Eliminated "AddrUnavail" and "ConfNoMatch" status codes because they are no longer used - Edited to use "IA" for a non-differentiated IA; "IA_NA" and "IA_TA" for specific types of addresses. - Deleted AuthFailed status code; spec requires that receiver discard messages that fail authentication with no response to the sender - DUID now limited to 128 bytes (was 256) - Reconfigure message includes IA option to specifically identify IAs that are to be modified. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 4 10:06:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16505; Mon, 4 Nov 2002 10:06:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4F7Zv31086; Mon, 4 Nov 2002 10:07:35 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4F5Jv30349 for ; Mon, 4 Nov 2002 10:05:19 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15676; Mon, 4 Nov 2002 10:02:49 -0500 (EST) Message-Id: <200211041502.KAA15676@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, 04 Nov 2002 10:02:49 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-failover-11.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Failover Protocol Author(s) : R. Droms, K. Kinnear Filename : draft-ietf-dhc-failover-11.txt Pages : 132 Date : 2002-11-1 DHCP [RFC 2131] allows for multiple servers to be operating on a single network. Some sites are interested in running multiple servers in such a way so as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. This implies that servers will need to coordinate any and all lease activity so that this information is synchronized in case of failover. This document defines a protocol to provide such synchronization between two servers. One server is designated the 'primary' server, the other is the 'secondary' server. This document also describes a way to integrate the failover protocol with the DHCP load balancing approach. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-failover-11.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-failover-11.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-failover-11.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: <2002-11-1142815.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-failover-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-failover-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-1142815.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 4 10:06:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA16545; Mon, 4 Nov 2002 10:06:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4F7gv31114; Mon, 4 Nov 2002 10:07:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4F5Pv30357 for ; Mon, 4 Nov 2002 10:05:25 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15693; Mon, 4 Nov 2002 10:02:55 -0500 (EST) Message-Id: <200211041502.KAA15693@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, 04 Nov 2002 10:02:55 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-packetcable-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Option for CableLabs Client Configuration Author(s) : B. Beser, P. Duffy Filename : draft-ietf-dhc-packetcable-04.txt Pages : 12 Date : 2002-11-1 This document defines a DHCP option that will be used to configure various devices deployed within CableLabs architectures. Specifically, the document describes DHCP option content that will be used to configure one class of CableLabs client device: a PacketCable Media Terminal Adapter (MTA). The option content defined within this document will be extended as future CableLabs client devices are developed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-04.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-packetcable-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 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-packetcable-04.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: <2002-11-1142827.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-packetcable-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-packetcable-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-1142827.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 4 10:16:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17409; Mon, 4 Nov 2002 10:16:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4FICv31897; Mon, 4 Nov 2002 10:18:12 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4FH9v31849 for ; Mon, 4 Nov 2002 10:17:09 -0500 Received: from sj-msg-core-4.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17314 for ; Mon, 4 Nov 2002 10:14:39 -0500 (EST) Received: from sj-msg-av-2.cisco.com (sj-msg-av-2.cisco.com [171.70.145.31]) by sj-msg-core-4.cisco.com (8.12.2/8.12.2) with ESMTP id gA4FH6ot014528; Mon, 4 Nov 2002 07:17:06 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-2.cisco.com (8.12.2/8.12.2) with ESMTP id gA4FGvoN008087; Mon, 4 Nov 2002 07:16:58 -0800 (PST) Received: from cisco.com (mbakke-lnx2.cisco.com [64.101.211.59]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id HAA11404; Mon, 4 Nov 2002 07:17:04 -0800 (PST) Message-ID: <3DC68F70.5DB6F7B6@cisco.com> Date: Mon, 04 Nov 2002 09:17:04 -0600 From: Mark Bakke X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.9-34.cisco.2 i686) X-Accept-Language: en, de MIME-Version: 1.0 To: dhcwg@ietf.org, snmpv3@lists.tislabs.com, mibs@ops.ietf.org Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP Option for SNMP Notifications Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi- I've submitted a new DHCP Option for SNMP Notifications draft, after attempting to incorporate the feedback I received on the first one. Until it pops out of the I-D queue, it's available at: ftp://ftpeng.cisco.com/mbakke/ips/dhcp/draft-bakke-dhc-snmp-trap-01.txt Thanks to everyone who contributed and helped me get the SNMP security stuff figured out. I just realized that I forgot to update some of the acknowledgements; Randy Presuhn and David Perkins also helped with this. I also need to spend more time on the references; I realized that these sections are still not up-to-date. Comments? Thanks, -- Mark A. Bakke Cisco Systems mbakke@cisco.com 763.398.1054 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 4 12:25:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23635; Mon, 4 Nov 2002 12:25:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HQVv08611; Mon, 4 Nov 2002 12:26:32 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HP3v08462 for ; Mon, 4 Nov 2002 12:25:03 -0500 Received: from e6.ny.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23394 for ; Mon, 4 Nov 2002 12:22:33 -0500 (EST) Received: from northrelay03.pok.ibm.com (northrelay03.pok.ibm.com [9.56.224.151]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA4HOSPi274946; Mon, 4 Nov 2002 12:24:29 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by northrelay03.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA4HOQPA084856; Mon, 4 Nov 2002 12:24:26 -0500 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gA4HKko25690; Mon, 4 Nov 2002 12:20:46 -0500 Message-Id: <200211041720.gA4HKko25690@rotala.raleigh.ibm.com> To: "Bernie Volz (EUD)" cc: "'Ralph Droms'" , dhcwg@ietf.org Subject: Re: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt In-Reply-To: Message from "Bernie Volz (EUD)" of "Tue, 29 Oct 2002 12:33:47 CST." Date: Mon, 04 Nov 2002 12:20:46 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Yes, that was the text I was referring to. And, I think we are in > agreement. I just feel it is better to state it the other way around > - a relay agent SHOULD NOT relay a relayed message (giaddr field is > no-zero) using IPsec unless the relay received that message secured > by IPsec. So if you have three DHC "hops" in your path, but one of them is unprotected, it makes no sense to protect the other two ? That doesn't follow at all. The threats one is concerned about may vary on each "hop". It may well make sense to protect the hop(s) that traverse paths where one is particularly worried about threats, while not being as worried about certain other hop on the overal path. Right? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 4 12:37:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24259; Mon, 4 Nov 2002 12:37:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HY4v09017; Mon, 4 Nov 2002 12:34:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4HXwv09002 for ; Mon, 4 Nov 2002 12:33:58 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23979 for ; Mon, 4 Nov 2002 12:31:28 -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 gA4HXrd23365; Mon, 4 Nov 2002 11:33:53 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gA4HXrF03818; Mon, 4 Nov 2002 11:33:53 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Mon, 4 Nov 2002 11:33:53 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Thomas Narten'" Cc: "'Ralph Droms'" , dhcwg@ietf.org Subject: RE: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00. txt Date: Mon, 4 Nov 2002 11:32:50 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28428.3272084C" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C28428.3272084C Content-Type: text/plain; charset="iso-8859-1" Thomas: I agree that as you get closer to the server, the security is likely to improve, but are you willing to allow this to be the default? How can we be sure that these parts of the network are secured? My feeling is that we should never allow (by default) security to INCREASE. If you do, you are giving a false sense of security. I used SHOULD NOT because that should be the default behavior. Sure, it is fine to allow the relay agent to be configurable to allow this but it should not be the default. - Bernie -----Original Message----- From: Thomas Narten [mailto:narten@us.ibm.com] Sent: Monday, November 04, 2002 12:21 PM To: Bernie Volz (EUD) Cc: 'Ralph Droms'; dhcwg@ietf.org Subject: Re: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt > Yes, that was the text I was referring to. And, I think we are in > agreement. I just feel it is better to state it the other way around > - a relay agent SHOULD NOT relay a relayed message (giaddr field is > no-zero) using IPsec unless the relay received that message secured > by IPsec. So if you have three DHC "hops" in your path, but one of them is unprotected, it makes no sense to protect the other two ? That doesn't follow at all. The threats one is concerned about may vary on each "hop". It may well make sense to protect the hop(s) that traverse paths where one is particularly worried about threats, while not being as worried about certain other hop on the overal path. Right? Thomas ------_=_NextPart_001_01C28428.3272084C Content-Type: text/html; charset="iso-8859-1" RE: [dhcwg] RE: I-D ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt

Thomas:

I agree that as you get closer to the server, the security is likely to improve,
but are you willing to allow this to be the default? How can we be sure that these
parts of the network are secured?

My feeling is that we should never allow (by default) security to INCREASE. If you
do, you are giving a false sense of security.

I used SHOULD NOT because that should be the default behavior. Sure, it is fine
to allow the relay agent to be configurable to allow this but it should not be
the default.

- Bernie

-----Original Message-----
From: Thomas Narten [mailto:narten@us.ibm.com]
Sent: Monday, November 04, 2002 12:21 PM
To: Bernie Volz (EUD)
Cc: 'Ralph Droms'; dhcwg@ietf.org
Subject: Re: [dhcwg] RE: I-D
ACTION:draft-droms-dhcp-relay-agent-ipsec-00.txt


> Yes, that was the text I was referring to. And, I think we are in
> agreement. I just feel it is better to state it the other way around
> - a relay agent SHOULD NOT relay a relayed message (giaddr field is
> no-zero) using IPsec unless the relay received that message secured
> by IPsec.

So if you have three DHC "hops" in your path, but one of them is
unprotected, it makes no sense to protect the other two ? That doesn't
follow at all.

The threats one is concerned about may vary on each "hop". It may well
make sense to protect the hop(s) that traverse paths where one is
particularly worried about threats, while not being as worried about
certain other hop on the overal path.

Right?

Thomas

------_=_NextPart_001_01C28428.3272084C-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 4 15:12:11 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04032; Mon, 4 Nov 2002 15:12:11 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KDXv20679; Mon, 4 Nov 2002 15:13:33 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA4KCYv20642 for ; Mon, 4 Nov 2002 15:12:34 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03831 for ; Mon, 4 Nov 2002 15:10:01 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA28652 for ; Mon, 4 Nov 2002 15:12:28 -0500 (EST) Message-Id: <4.3.2.7.2.20021104151022.03700ef8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 04 Nov 2002 15:12:25 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Preliminary agenda for Atlanta WG meeting Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Here's the latest perliminary agenda for the DHC WG meeting in Atlanta. The last few agenda items are tentative, pending publication of revised drafts. - Ralph DHCP Lease Query draft-ietf-dhc-leasequery-05.txt Kim Kinnear 10 minutes Link Selection sub-option for the Relay Agent Information Option draft-ietf-dhc-agent-subnet-selection-04.txt Kim Kinnear 5 minutes VPN Information Option draft-ietf-dhc-vpn-option-02.txt Kim Kinnear 5 minutes Subnet Allocation using DHCP draft-johnson-dhc-subnet-alloc-00.txt Richard Johnson 10 minutes DHCP Server-ID Override Suboption draft-johnson-dhc-server-override-00.txt Richard Johnson 10 minutes DHCP Option for Location Insertion draft-polk-dhcp-geo-loc-00.txt John Schnizlein 5 minutes Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and Servers draft-droms-dhcp-relay-agent-ipsec-00.txt Ralph Droms 5 minutes DHCP Option for CableLabs Client Configuration draft-ietf-dhc-packetcable-04.txt Paul Duffy 5 minutes A Guide to Implementing Stateless DHCPv6 Service draft-droms-dhcpv6-stateless-guide-01.txt Ralph Droms 5 minutes Load Balancing for DHCPv6 draft-ietf-dhc-dhcpv6-loadb-02.txt Bernie Volz 5 minutes IPv6 Prefix Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt Ole Troan 5 minutes Other DHCPv6 options Ralph Droms 15 minutes DNS Configuration options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt DSTM Options for DHCP draft-ietf-dhc-dhcpv6-opt-dstm-01.txt DSTM Ports Option for DHCPv6 draft-ietf-dhc-dhcpv6-opt-dstm-ports-01.txt NIS Configuration Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt Time Configuration Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt Client Preferred Prefix option for DHCPv6 draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt Revised DHC WG charter and milestones http://www.dhcp.org/charter-update.html Ralph Droms 10 minutes Recycling option codes Ralph Droms 5 minutes (Tentative - waiting for new drafts) The DHCP Client FQDN Option Mark Stapp DDNS-DHCP conflict resolution Mark Stapp The Authentication Suboption for the DHCP Relay Agent Option Mark Stapp VPN Identifier sub-option for the Relay Agent Information Option Kim Kinnear Considerations for the use of the Host Name option Carl Smith New authentication draft Ted Lemon _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 5 06:16:55 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11881; Tue, 5 Nov 2002 06:16:55 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5BESv01107; Tue, 5 Nov 2002 06:14:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA5B6vv32602 for ; Tue, 5 Nov 2002 06:06:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA09954; Tue, 5 Nov 2002 06:04:26 -0500 (EST) Message-Id: <200211051104.GAA09954@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 Nov 2002 06:04:26 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agentopt-radius-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : RADIUS Attributes Sub-option for the DHCP Relay Agent Information Option Author(s) : R. Droms, J. Schnizlein Filename : draft-ietf-dhc-agentopt-radius-02.txt Pages : 8 Date : 2002-11-4 A network access device may choose to authenticate the identity of a device before granting that device access to the network. The IEEE 802.1X protocol is an example of a mechanism for providing authenticated layer 2 network access. A network element using RADIUS as an authentication authority will receive attributes from a RADIUS server that may be used by a DHCP server in the selection of an IP address for assignment to the device through its DHCP client. The RADIUS Attributes sub-option allows a network element to pass along attributes for the user of a device received during RADIUS authentication to a DHCP server. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-dhc-agentopt-radius-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-02.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: <2002-11-4171154.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agentopt-radius-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agentopt-radius-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-4171154.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 04:46:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10325; Wed, 6 Nov 2002 04:46:06 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA69lWv30580; Wed, 6 Nov 2002 04:47:36 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA69jrv30509 for ; Wed, 6 Nov 2002 04:45:53 -0500 Received: from penguin.wise.edt.ericsson.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10290 for ; Wed, 6 Nov 2002 04:43:12 -0500 (EST) Received: from esealnt612.al.sw.ericsson.se (esealnt612.al.sw.ericsson.se [153.88.254.71]) by penguin.wise.edt.ericsson.se (8.12.1/8.12.1/WIREfire-1.4) with ESMTP id gA69jdQ1015214 for ; Wed, 6 Nov 2002 10:45:39 +0100 (MET) Received: from ESEALNT444.al.sw.ericsson.se ([153.88.251.48]) by esealnt612.al.sw.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2655.55) id WJRFS78T; Wed, 6 Nov 2002 10:45:39 +0100 Received: by esealnt444 with Internet Mail Service (5.5.2653.19) id ; Wed, 6 Nov 2002 10:38:24 +0100 Message-ID: <1254192C94D3D411B8060008C7E6AEEBF9DE6B@esealnt408> X-Sybari-Trust: 9b8cecb2 ca231590 5b417197 00000138 From: =?iso-8859-1?Q?Tony_Lindstr=F6m_=28EAB=29?= To: "'dhcwg@ietf.org'" Date: Wed, 6 Nov 2002 10:43:26 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] Comments/question to draft-28 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I have read some part of the draft-28 and have listed some minor comments: In chapter 17.2.1 first paragraph This part of the sentence need to be modified: 'if the client indicates with a Reconfigure Accept option in the Solicit message that it will not accept a Reconfigure message' In chapter 18.1.1 1:st paragraph, in chapter 18.1.3 8:th paragraph, 18.1.4 4:th paragraph and in chapter 18.1.5 5:th paragraph The following sentence can be read: 'The client MUST include an Option Request option ...' In Solicit message this is changed to SHOULD (17.1.1), but is this consistent when option 22.7 says: 'A client MAY include an Option Request option...' In chapter 18.1.1 7:th paragraph The following sentence should be changed: 'The client includes a Reconfigure Accept option (see section indicating whether or not the client is willing to accept Reconfigure messages from the server.' to: 'The client includes a Reconfigure Accept option (see section 22.20)if the client is willing to accept Reconfigure messages from the server.' In chapter 22.7 Confirm is not valid in the option Request option anymore: A client MAY include an Option Request option in a Solicit, Request, Renew, Rebind, Confirm or Information-request message to inform the server about options the client wants the server to send to the client. This comment is valid for at least the following drafts: draft-ietf-dhc-dhcpv6-opt-dnsconfig-01.txt draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt In the table A. Appearance of Options in Message Types Remove the '*' for Confirm message in the option Request column. QUESTION ----------------- In the second table for messages Renew/Rebind and Inform there is indicated it is possible to receive the Recon. Accept option. This is not mention in the earlier chapters 18.1.3-5. For the Renew and Rebind I think this is only valid if the client has reconfigured and will start accept Reconfigure message, but how will the client indicate if it stops to accept Reconfigure message? For the Inform-Request message (in chapter 18.1.5). I think the following sentence should be added: 'The client includes a Reconfigure Accept option (see section 22.20)if the client is willing to accept Reconfigure messages from the server.' Regards, Tony _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 06:29:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12201; Wed, 6 Nov 2002 06:29:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BV5v03695; Wed, 6 Nov 2002 06:31:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BTvv03558 for ; Wed, 6 Nov 2002 06:29:57 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11815; Wed, 6 Nov 2002 06:27:26 -0500 (EST) Message-Id: <200211061127.GAA11815@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: Wed, 06 Nov 2002 06:27:26 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-leasequery-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : DHCP Lease Query Author(s) : R. Woundy, K. Kinnear Filename : draft-ietf-dhc-leasequery-04.txt Pages : 26 Date : 2002-11-5 Access concentrators that act as DHCP relay agents need to determine the endpoint locations of IP addresses across public broadband access networks such as cable, DSL, and wireless networks. Because ARP broadcasts are undesirable in public networks, many access concentrator implementations 'glean' location information from DHCP messages forwarded by its relay agent function. Unfortunately, the typical access concentrator loses its gleaned information when the access concentrator is rebooted or is replaced. This memo proposes that when gleaned DHCP information is not available, the access concentrator/relay agent obtains the location information directly from the DHCP server(s) using a new, lightweight DHCPLEASEQUERY message. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-04.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-leasequery-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt 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-leasequery-04.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: <2002-11-5192753.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-leasequery-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-leasequery-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5192753.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 06:30:33 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12408; Wed, 6 Nov 2002 06:30:33 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BW3v03751; Wed, 6 Nov 2002 06:32:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BU2v03583 for ; Wed, 6 Nov 2002 06:30:02 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11827; Wed, 6 Nov 2002 06:27:31 -0500 (EST) Message-Id: <200211061127.GAA11827@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: Wed, 06 Nov 2002 06:27:31 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-ddns-resolution-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Resolution of DNS Name Conflicts Among DHCP Clients Author(s) : M. Stapp Filename : draft-ietf-dhc-ddns-resolution-05.txt Pages : 11 Date : 2002-11-5 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS(RFC1034[1], RFC1035[2]), and specifically updating the name to address and address to name mappings maintained in the DNS. The 'Client FQDN Option'[14] specifies the client FQDN option, through which DHCP clients and servers can exchange information about client FQDNs. This document describes techniques for the resolution of DNS name conflicts among DHCP clients. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-05.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-ddns-resolution-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart 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: <2002-11-5192803.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-ddns-resolution-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-ddns-resolution-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5192803.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 06:30:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12444; Wed, 6 Nov 2002 06:30:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BW5v03784; Wed, 6 Nov 2002 06:32:05 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BUCv03601 for ; Wed, 6 Nov 2002 06:30:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11854; Wed, 6 Nov 2002 06:27:40 -0500 (EST) Message-Id: <200211061127.GAA11854@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: Wed, 06 Nov 2002 06:27:40 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-fqdn-option-05.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The DHCP Client FQDN Option Author(s) : M. Stapp, Y. Rekhter Filename : draft-ietf-dhc-fqdn-option-05.txt Pages : 15 Date : 2002-11-5 DHCP provides a powerful mechanism for IP host configuration. However, the configuration capability provided by DHCP does not include updating DNS, and specifically updating the name to address and address to name mappings maintained in the DNS. This document specifies a DHCP option which can be used to exchange information about a DHCP client's fully-qualified domain name, and about responsibility for updating DNS RRs related to the client's DHCP lease. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.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-fqdn-option-05.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-fqdn-option-05.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart 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: <2002-11-5192820.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-fqdn-option-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-fqdn-option-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5192820.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 06:31:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12561; Wed, 6 Nov 2002 06:31:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BW4v03767; Wed, 6 Nov 2002 06:32:04 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BU7v03589 for ; Wed, 6 Nov 2002 06:30:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11842; Wed, 6 Nov 2002 06:27:36 -0500 (EST) Message-Id: <200211061127.GAA11842@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: Wed, 06 Nov 2002 06:27:36 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-auth-suboption-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The Authentication Suboption for the DHCP Relay Agent Option Author(s) : M. Stapp, T. Lemon Filename : draft-ietf-dhc-auth-suboption-01.txt Pages : 14 Date : 2002-11-5 The DHCP Relay Agent Information Option (RFC3046[1]) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines a new authentication suboption for that option which supports source entity authentication and data integrity for relayed DHCP messages. The authentication suboption contains a cryptographic signature in a payload derived from the option used in DHCP Authentication (RFC3118[2]). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-auth-suboption-01.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-auth-suboption-01.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-auth-suboption-01.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: <2002-11-5192812.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-auth-suboption-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-auth-suboption-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5192812.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 06:31:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA12571; Wed, 6 Nov 2002 06:31:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BW6v03806; Wed, 6 Nov 2002 06:32:06 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6BUGv03610 for ; Wed, 6 Nov 2002 06:30:16 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11867; Wed, 6 Nov 2002 06:27:45 -0500 (EST) Message-Id: <200211061127.GAA11867@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: Wed, 06 Nov 2002 06:27:45 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-agent-vpn-id-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : VPN Identifier sub-option for the Relay Agent Information Option Author(s) : K. Kinnear, M. Stapp, R. Johnson, J. Kumarasamy Filename : draft-ietf-dhc-agent-vpn-id-02.txt Pages : 8 Date : 2002-11-5 In some environments, a relay agent resides in a network element which also has access to one or more VPNs. If one DHCP server wishes to offer service to DHCP clients on those different VPNs the DHCP server needs to know the VPN on which each client resides. The vpn- id sub-option of the relay-agent-information option is used by the relay agent to tell the DHCP server the VPN for every DHCP request it passes on to the DHCP server, and is also used to properly forward any DHCP reply that the DHCP server sends back to the relay agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-02.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-agent-vpn-id-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-02.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: <2002-11-5192829.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-agent-vpn-id-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-agent-vpn-id-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-5192829.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 15:03:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09890; Wed, 6 Nov 2002 15:03:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6K4gv08049; Wed, 6 Nov 2002 15:04:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6K30v07987 for ; Wed, 6 Nov 2002 15:03:00 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09822; Wed, 6 Nov 2002 15:00:27 -0500 (EST) Message-Id: <200211062000.PAA09822@ietf.org> To: IETF-Announce: ; Cc: dhcwg@ietf.org From: The IESG Reply-to: iesg@ietf.org Date: Wed, 06 Nov 2002 15:00:27 -0500 Subject: [dhcwg] Last Call: DHCP Option for CableLabs Client Configuration to Proposed Standard Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The IESG has received a request from the Dynamic Host Configuration Working Group to consider DHCP Option for CableLabs Client Configuration as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-12-6. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-dhc-packetcable-04.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 15:57:41 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12022; Wed, 6 Nov 2002 15:57:41 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6KxDv11443; Wed, 6 Nov 2002 15:59:13 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6KwGv11388 for ; Wed, 6 Nov 2002 15:58:16 -0500 Received: from e31.co.us.ibm.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11954 for ; Wed, 6 Nov 2002 15:55:42 -0500 (EST) Received: from westrelay03.boulder.ibm.com (westrelay03.boulder.ibm.com [9.17.194.24]) by e31.co.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA6Kw9Jw013650 for ; Wed, 6 Nov 2002 15:58:09 -0500 Received: from rotala.raleigh.ibm.com (rotala.raleigh.ibm.com [9.27.12.14]) by westrelay03.boulder.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA6Kw9u3114350 for ; Wed, 6 Nov 2002 13:58:09 -0700 Received: from rotala.raleigh.ibm.com (narten@localhost) by rotala.raleigh.ibm.com (8.11.6/8.11.6) with ESMTP id gA6KsGY18958 for ; Wed, 6 Nov 2002 15:54:16 -0500 Message-Id: <200211062054.gA6KsGY18958@rotala.raleigh.ibm.com> To: dhcwg@ietf.org In-Reply-To: Message from Internet-Drafts@ietf.org of "Wed, 06 Nov 2002 06:27:45 EST." <200211061127.GAA11867@ietf.org> Date: Wed, 06 Nov 2002 15:54:16 -0500 From: Thomas Narten Subject: [dhcwg] Re: I-D ACTION:draft-ietf-dhc-agent-vpn-id-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Looking through this document, could someone explain what problem this ID is solving? In particular, it seems to me that DHCP servers/relay agents shouldn't and don't need to understand about VPNs. I.e., when a node joins the network, it is assigned a VPN. This ID proposes that a relay agent include a string or other identifier in the relay agent option to indicate the VPN the client is assigned to. But, it seems to me that the relay agent could just as easily be assigned an IP address on each VPN, and then just stuff that address into the giaddr field of the packets. This is normal DHC, using existing protocols and standards. In this case, neither the relay agent nor the DHC server need to know about VPNs in any way other than they already do. I.e, the giaddr field indicates a VPN, and existing standard DHC config technique can be used to assign addresses and other paramaters to the client. What is it that I'm not understanding here? Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 16:22:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12879; Wed, 6 Nov 2002 16:22:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6LOJv13167; Wed, 6 Nov 2002 16:24:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6LN7v13134 for ; Wed, 6 Nov 2002 16:23:07 -0500 Received: from sj-msg-core-3.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12801 for ; Wed, 6 Nov 2002 16:20:32 -0500 (EST) Received: from sj-msg-av-1.cisco.com (sj-msg-av-1.cisco.com [171.69.11.151]) by sj-msg-core-3.cisco.com (8.12.2/8.12.2) with ESMTP id gA6LMqxF025117; Wed, 6 Nov 2002 13:22:52 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-1.cisco.com (8.12.2/8.12.2) with ESMTP id gA6LMwbB012209; Wed, 6 Nov 2002 13:22:59 -0800 (PST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-535.cisco.com [10.82.242.23]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id NAA08008; Wed, 6 Nov 2002 13:22:56 -0800 (PST) Message-Id: <4.3.2.7.2.20021106161450.03cbe6c0@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 06 Nov 2002 16:22:56 -0500 To: Thomas Narten From: John Schnizlein Subject: Re: [dhcwg] Re: I-D ACTION:draft-ietf-dhc-agent-vpn-id-02.txt Cc: dhcwg@ietf.org In-Reply-To: <200211062054.gA6KsGY18958@rotala.raleigh.ibm.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , When a service provider has several customers using net-10, but a single DHCP server, it needs to discriminate among them. If the network device closest to the customer is configured with the VPN identifier for that customer network, the DHCP server can manage pools for each VPN independently. John At 03:54 PM 11/6/2002, Thomas Narten wrote: >Looking through this document, could someone explain what problem >this ID is solving? > >In particular, it seems to me that DHCP servers/relay agents shouldn't >and don't need to understand about VPNs. I.e., when a node joins the >network, it is assigned a VPN. This ID proposes that a relay agent >include a string or other identifier in the relay agent option to >indicate the VPN the client is assigned to. But, it seems to me that >the relay agent could just as easily be assigned an IP address on each >VPN, and then just stuff that address into the giaddr field of the >packets. This is normal DHC, using existing protocols and standards. >In this case, neither the relay agent nor the DHC server need to know >about VPNs in any way other than they already do. I.e, the giaddr >field indicates a VPN, and existing standard DHC config technique can >be used to assign addresses and other paramaters to the client. > >What is it that I'm not understanding here? > >Thomas >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 16:34:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13370; Wed, 6 Nov 2002 16:34:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6La8v13596; Wed, 6 Nov 2002 16:36:08 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA6LZav13578 for ; Wed, 6 Nov 2002 16:35:36 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13325 for ; Wed, 6 Nov 2002 16:33:01 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gA6LVP220209; Wed, 6 Nov 2002 15:31:26 -0600 (CST) Date: Wed, 6 Nov 2002 15:35:17 -0600 Subject: Re: [dhcwg] Re: I-D ACTION:draft-ietf-dhc-agent-vpn-id-02.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: dhcwg@ietf.org To: Thomas Narten From: Ted Lemon In-Reply-To: <200211062054.gA6KsGY18958@rotala.raleigh.ibm.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > But, it seems to me that > the relay agent could just as easily be assigned an IP address on each > VPN, and then just stuff that address into the giaddr field of the > packets. You don't even need to do that - you can just use the relay agent subnet selection option! _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 6 22:34:10 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21995; Wed, 6 Nov 2002 22:34:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA73Zdv01178; Wed, 6 Nov 2002 22:35:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA73Y3v01141 for ; Wed, 6 Nov 2002 22:34:03 -0500 Received: from cichlid.adsl.duke.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21828 for ; Wed, 6 Nov 2002 22:31:20 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id gA73XHJ05795; Wed, 6 Nov 2002 22:33:18 -0500 Message-Id: <200211070333.gA73XHJ05795@cichlid.adsl.duke.edu> To: John Schnizlein cc: dhcwg@ietf.org Subject: Re: [dhcwg] Re: I-D ACTION:draft-ietf-dhc-agent-vpn-id-02.txt In-Reply-To: Message from John Schnizlein of "Wed, 06 Nov 2002 16:22:56 EST." <4.3.2.7.2.20021106161450.03cbe6c0@wells.cisco.com> Date: Wed, 06 Nov 2002 22:33:17 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > When a service provider has several customers using net-10, > but a single DHCP server, it needs to discriminate among them. Ah. It would be good if the ID said that. > If the network device closest to the customer is configured with > the VPN identifier for that customer network, the DHCP server > can manage pools for each VPN independently. So, the key requirement is for the relay agent to indicate which customer or "address realm" (using NAT terminology) the request it is relaying comes from. Using VPN IDs is one way, but it only works if VPNs are used. Seems like a more general approach would be desireable. I could imagine the same issue coming up in environments where just IP (or IPsec tunnels) were used, in which case no L2 VPNs would be available. Why can't you use something like the Agent Circuit ID Sub-option (sub-option code 1)? You could stuff an identifier in there to indicate which "VPN" to use. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 7 05:49:38 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09429; Thu, 7 Nov 2002 05:49:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7Ap0v04304; Thu, 7 Nov 2002 05:51:00 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7An3v04242 for ; Thu, 7 Nov 2002 05:49:03 -0500 Received: from msr.hinet.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09367 for ; Thu, 7 Nov 2002 05:46:26 -0500 (EST) Received: from Ilsu (61-228-76-99.HINET-IP.hinet.net [61.228.76.99]) by msr.hinet.net (8.9.3/8.9.3) with SMTP id SAA08483 for ; Thu, 7 Nov 2002 18:48:29 +0800 (CST) Date: Thu, 7 Nov 2002 18:48:29 +0800 (CST) Message-Id: <200211071048.SAA08483@msr.hinet.net> From: ogud To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=FuFzH0nd73C8Kf2209CoOW2f14d3fs1D Subject: [dhcwg] ì Íú Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --FuFzH0nd73C8Kf2209CoOW2f14d3fs1D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) –ˆ“ú.pif is of type executable and is removed. Please contact your network administrator for further information. --------------------------------------------------------- --FuFzH0nd73C8Kf2209CoOW2f14d3fs1D Content-Type: text/html; Content-Transfer-Encoding: quoted-printable --FuFzH0nd73C8Kf2209CoOW2f14d3fs1D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ------------------ Virus Warning Message (on ietf-mx) –ˆ“ú.pif is removed from here because it is of type executable --------------------------------------------------------- --FuFzH0nd73C8Kf2209CoOW2f14d3fs1D Content-Type: application/octet-stream; name=TN_vivdtn0026[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQIASABIAAD//gAdQUNEIFN5c3RlbXMgRGlnaXRhbCBJbWFnaW5n/9sA QwAIBgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0 NB8nOT04MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAYABIAwEiAAIRAQMRAf/EABwAAAEE AwEAAAAAAAAAAAAAAAYAAwUHAQIECP/EADoQAAIBAgQDBQYDBgcAAAAAAAECAwQRAAUSIQYx QRNRYXGBBxQiMpGhQrHRFRcjUqLwJGJyhLLB8f/EABoBAAMBAQEBAAAAAAAAAAAAAAIDBAUB BgD/xAAmEQACAgICAQQBBQAAAAAAAAABAgADBBESITEFIlGxI0GRodHw/9oADAMBAAIRAxEA PwAQiWJoi8lSqlXI7PSTcAXvf7YcK0zO9qnSoJINib8tht1ufpiOiaAs/bu6MttIRbg99wfT DjNRFkVJSq9koJsfnuASfQk+mEx8fkFG08hNQ6IGbSQpOodPLDDy0qvAweRdJ+Mlb33uD9Om GqiSkJRI3ZkCnU7bG53+2HKanpJRJJAZZFUDSHHxBuW1u8kD1PdjjHiNmEo5HQmkhp1p5FjS dnfQyllPwkX1C3dvYc/0bR6Nwu7qVQFtV93uAV8rXPfiRrcpzmhpzUzUwEPwkCIhtO9yW7rA W9ccmYU8Jhp6xiYmm1KxAvcjTpIHipPqMAlwY6jLKSo3HO0o3ijuXMosHNzpIseX2wcezJkT iKqkDqxaFAqnbdnW9h1sL4rxBRuqkTMrhRdQDpJ1Ec/KxxaPsciU5nnMgKsqwQqCDe2pnNv6 cNMTLcAwsZGFjkKeSYZ4lJ1xl15gFrb2PX1w9JVoxV+zHwrpte/riLDEL18cORK9RIsa3JPd tYdcdM4qljpZ0VFajRqscSoFctYAH/rwH0wQZDSPNMiU1UtK6RrNrZQ3xG9ha2+5viHGX5PB dq+WscL8yxOFv4csEHCmS56czaoTK6qoo5oLlWYail7q6iwB+IAbdxxNc4ce2WV0NS/5RqEH EFZX02TyIaOOoDJollVtBUkbHTy7tsDWexRrlDI6FhCyMADa19QP2OHc6qMynzRcvOXV1DTP KHleqhZO1CH5R0sPUm+M8QaVyuZrgaoST5q5t+RwlBxYRl5BB7gxTzUOkdskjabkKORJAHP0 v9sXB7GBEy59NCGVGenXSQNrB/1xRaSAMLMPri9fYghHD+bSn8VYi/RB+uNAzNlqDCxoWsML Aw55MfKqmJyr0eaAgkG9CxHocdVPTvTKTIJg5FgJYjGyjnyO+/PHpNzBTxS1E/wwwo0kjW5B Rc/ljz/m1fUZ5nlRVsC01VNdUHS5sqjyFh6YnuY61N30HHD3m1h0v3/tyZ4F4Xk4hzhqiWAS UdGyPJc2LMTcAX57An/3FtVWbUOT5vMxyzMDp7OGefRaKKHmrKSbMup7HTuLMegvjgDIG4fy GOnks1S8rPOVvYnVp2v0ChfPn1wVytSvIInlQOV1BGO9u+2G1VcVkPqOWt+Sza2JXXFkOUZ/ TJW5fmFPPPBe8asA52vexsR0v53xX0UNNXyVVHVKtlSzK52B1E7+Hf54vSr4ayesd5p6Cmlk dQGZkVtQHIXOKU4xpZsgra2kCCLtZ1aMbH4Dqb8wMIvUg8oOIoucVL+vzB6uyzhuGhqZIjlv apExXRPchrG1hq53xZnsT0ngqrkRgwbMHFwb8kT9cT0XCPC+Y00Nb+wsvK1MSzAe7p+JQ1uX jiXyzKsvyWnany2khpYmYuyQoFUtsL2HWwH0w9AQOzuSWdnxqSJbCw0Wv1wsFBgd7Rampp+D phTlgssqJMwNiEN7jyJCjAN7N8nizLigVMrp2dCnbCJhcu17KR/pJB8wMG/tDnZeF5KREBNQ SSzXuoQqxI+lvXADwBWy0WfVBifTrpWB2Bv8SnriS0hX2Z6TAJb0u0V9Hf8AUuDMs/fJ1p44 oo5WlBdo2BDBb7Hu3PTEQ2c1dXWQVbLBE8SsEVIipIbmGuxuPDzwMVubRZjmtXUSTan1hLM1 lVVUKLAeIJ6YxLX1MFGyQInaICLuu1/5QO/vJvgWvZj0epmV4oAHIdwzruMcmypIJa2CeAy7 FolBXUNyLXvbFR8e5nFm/FbV9JmHvtLJDHoXQyCEhbMtiN9xqv8A5rdMLMamPM62KDPs6mpY tP8AhnjpRINRIupVbE7W3vsFOOj93GcyZfHmUOZ5UuXyi8c1ZI9OxXfdlZNuXK5we7LF8S/B ODjWB3Yhh+31LN4Cr/fuCcvYm7whoG3v8rbf0kYIC2K74Y4i4c4N4dFBPXSZhWSTNNMaGMlN RAFlZ9NxpVd8dp9qNC8gWDJZDGWtqkqNJt32Cn88VLW2h1MTKsQ3sV8EmG18LHFlWb0md0Jq 6LUFUhZI3I1I1r9OY7jhY+1FCQPFKNVVeUUkcYkeb3kaSwFwI1J5+F/rirKBnyHiJ1qo5AKc skwQaiFsRfb0OLQqCtXmuXZnI/8AFoVlWJV2RhIoViw67DbHDntQIKWorVpoZb2aWOwAaw+Y nvtYddrd2IbXRyNeZr4OU2NW9bDpo/l/GdDQ5Wo/YlKaQLuAQWI72OmxPpgOj4topa+sXPMs pp8vlfVCaSUxPCCflUg6SANrG2998MRcUvGF7TJaQRyXUSRSkHnzFxubX6Yjcwlpswri9JTR QxrcyMsAjGonl8LENbvsDviuionq0TNvdV91Lfc34pzLh2aooIuFoZEcNdpKm7SB/wCY6iRp Ubi2zMeoGIyWpqKgJ71VTVUiKR2s7l2O/eeXljEuWxTSGQoocXUNGSDbpjU0ssK/w07YL+G9 mHX1xclYUaEiZ2Y7JjgAZiApa3dh4zrBGACqszAAFh6/bHdlGQV+bqk0waioj+IAGRvALyX1 +mDCr4QyKbh9qWgolirgA6Vcx1uzDozWvZtwbbC/LC2yawdbhihyN6kDkGeVOU1vbU7AalKM DurL1B/vphYhkDws0MqlJom0up2Kn+/1wsN4q3cDkRLL7Co0LaJithYgdMclTT1DwuhhbSyl WBXoRbHM/s8TUzRZ3m8YJJCrVsAPAY0/d/Uj5eJc6H+6uPuuPP6Hz/E19wArcuny+ZIKtJVj jWyNpKoR4f3fDsQiKRpGgVI91ttbywdNwHXBdK8TZufOVSP+OI+b2aVcjXGe1l+8qhP10jGl XnIo00hfFJOxB4LG26P2b25NyO2EbI1pFIJ5MORxOfu3zVfk4hlI7ngVsRVfkmd5TTSyPUwS pGDY9hZm6Da9r74aubSx1uLOK4G5mKsmo2DwzsjddJ2t4jrzwbZTmiVuXxTC6uRpZedmHP0x XcFPVDtGemlZSNQMahtQ6b8r7jbniYyk8SqrjKzDBFqLFKim7Qkk89jcd2+Byq048oeO7b4y Y4kyf3+9fTAJVovxHksijofHuOFjZ4ePqmMRyNlJibZiKZlYDrhYlXJKjQMoahWO5//Z --FuFzH0nd73C8Kf2209CoOW2f14d3fs1D-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 7 06:23:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10569; Thu, 7 Nov 2002 06:23:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7BPIv06305; Thu, 7 Nov 2002 06:25:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7BNDv06222 for ; Thu, 7 Nov 2002 06:23:13 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10090; Thu, 7 Nov 2002 06:20:43 -0500 (EST) Message-Id: <200211071120.GAA10090@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 Nov 2002 06:20:43 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-host-option-considerations-01.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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 : Considerations for the use of the Host Name option Author(s) : C. Smith, T. Lemon Filename : draft-ietf-dhc-host-option-considerations-01.txt Pages : 8 Date : 2002-11-6 This document clarifies the use of the DHCP Host Name option. The primary point of this clarification addresses the use of the option by clients to request proxy DNS updates by DHCP servers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-host-option-considerations-01.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-host-option-considerations-01.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-host-option-considerations-01.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: <2002-11-6173846.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-host-option-considerations-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-host-option-considerations-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-6173846.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 7 17:21:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15607; Thu, 7 Nov 2002 17:21:38 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7MMtv25768; Thu, 7 Nov 2002 17:22:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KZ1v15408 for ; Thu, 7 Nov 2002 15:35:01 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08965 for <1timer>; Thu, 7 Nov 2002 15:11:40 -0500 (EST) Message-Id: <200211072011.PAA08965@ietf.org> From: The IESG To: All IETF Working Groups: ; x-msg: NoteWell Date: Thu, 07 Nov 2002 15:11:40 -0500 Subject: [dhcwg] Note Well Statement Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , From time to time, especially just before a meeting, this statement is to be sent to each and every IETF working group mailing list. =========================================================================== NOTE WELL All statements related to the activities of the IETF and addressed to the IETF are subject to all provisions of Section 10 of RFC 2026, which grants to the IETF and its participants certain licenses and rights in such statements. Such statements include verbal statements in IETF meetings, as well as written and electronic communications made at any time or place, which are addressed to - the IETF plenary session, - any IETF working group or portion thereof, - the IESG, or any member thereof on behalf of the IESG, - the IAB or any member thereof on behalf of the IAB, - any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, - the RFC Editor or the Internet-Drafts function Statements made outside of an IETF meeting, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not subject to these provisions. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 7 17:21:49 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15631; Thu, 7 Nov 2002 17:21:49 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7MN7v25786; Thu, 7 Nov 2002 17:23:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7KvQv18820 for ; Thu, 7 Nov 2002 15:57:26 -0500 Received: from kathmandu.sun.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11907 for ; Thu, 7 Nov 2002 15:54:52 -0500 (EST) Received: from jurassic.eng.sun.com ([129.146.17.55]) by kathmandu.sun.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10409 for ; Thu, 7 Nov 2002 13:57:20 -0700 (MST) Received: from kanawha (kanawha.Eng.Sun.COM [129.146.86.81]) by jurassic.eng.sun.com (8.12.7.Beta0+Sun/8.12.7.Beta0) with ESMTP id gA7KvKLe604582 for ; Thu, 7 Nov 2002 12:57:20 -0800 (PST) Message-Id: <200211072057.gA7KvKLe604582@jurassic.eng.sun.com> To: dhcwg@ietf.org Date: Thu, 07 Nov 2002 12:57:20 -0800 From: Carl Smith Subject: [dhcwg] proxy host name removal Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , One of the items that needs clarification for the Host Options Considerations draft is the removal of host name <-> IP address updates. Specifically, is there a way for a client to ask a DHCP server to remove an update without giving up its lease? Two suggestions were made at the Minneapolis meeting: either the client should send a zero-length host name or a new bit in the FQDN option flags field could be allocated to convey the request. There was no concensus at the WG meeting on the need for such a facility, so I'm polling the mailing list to see whether it's felt we should pursue this further. Personally, I believe that if a way of doing it is to be offered, we should not change the way the Host Name option is used but instead use the FQDN option to express the request. Carl _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 7 17:23:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15679; Thu, 7 Nov 2002 17:23:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7MO3v25835; Thu, 7 Nov 2002 17:24:03 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7MNov25814 for ; Thu, 7 Nov 2002 17:23:50 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15599; Thu, 7 Nov 2002 17:21:14 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id RAA12154; Thu, 7 Nov 2002 17:23:43 -0500 (EST) Message-Id: <4.3.2.7.2.20021107172235.03d62ed8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Thu, 07 Nov 2002 17:23:41 -0500 To: agenda@ietf.org From: Ralph Droms Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHC WG agenda for IETF 55 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DHC WG Agenda, IETF 55, November, 2002 -------------------------------------- Agenda bashing, select scribes, announcements Ralph Droms 5 minutes DHCP Option for CableLabs Client Configuration Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and Servers draft-droms-dhcp-relay-agent-ipsec-00.txt Ralph Droms 5 minutes DHCP Option for SNMP Notifications draft-bakke-dhc-snmp-trap-01.txt Mark Bakke 10 minutes Subnet Allocation using DHCP draft-johnson-dhc-subnet-alloc-00.txt Richard Johnson 10 minutes DHCP Server-ID Override Suboption draft-johnson-dhc-server-override-00.txt Richard Johnson 10 minutes Considerations for the use of the Host Name option draft-ietf-dhc-host-option-considerations-01.txt Carl Smith 10 minutes Load Balancing for DHCPv6 draft-ietf-dhc-dhcpv6-loadb-02.txt Bernie Volz 5 minutes IPv6 Prefix Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt Ole Troan 5 minutes Other DHCPv6 options Ralph Droms 15 minutes DNS Configuration options for DHCPv6 DSTM Options for DHCP DSTM Ports Option for DHCPv6 NIS Configuration Options for DHCPv6 Time Configuration Options for DHCPv6 Client Preferred Prefix option for DHCPv6 A Guide to Implementing Stateless DHCPv6 Service draft-droms-dhcpv6-stateless-guide-01.txt Ralph Droms 5 minutes Revised DHC WG charter and milestones http://www.dhcp.org/charter-update.html Ralph Droms 10 minutes Recycling option codes Ralph Droms 5 minutes DHCP Lease Query draft-ietf-dhc-leasequery-05.txt Kim Kinnear 10 minutes Link Selection sub-option for the Relay Agent Information Option draft-ietf-dhc-agent-subnet-selection-04.txt Kim Kinnear 5 minutes VPN Information Option draft-ietf-dhc-vpn-option-02.txt Kim Kinnear 5 minutes VPN Identifier sub-option for the Relay Agent Information Option draft-ietf-dhc-agent-vpn-id-02.txt Kim Kinnear 10 minutes DHCP Option for Location Insertion draft-polk-dhcp-geo-loc-00.txt John Schnizlein 5 minutes The DHCP Client FQDN Option draft-ietf-dhc-fqdn-option-05.txt Mark Stapp 5 minutes DDNS-DHCP conflict resolution draft-ietf-dhc-ddns-resolution-05.txt Mark Stapp 5 minutes The Authentication Suboption for the DHCP Relay Agent Option draft-ietf-dhc-auth-suboption-01.txt Mark Stapp 10 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 7 17:46:30 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16624; Thu, 7 Nov 2002 17:46:30 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7Mm7v27562; Thu, 7 Nov 2002 17:48:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA7Mjqv27453 for ; Thu, 7 Nov 2002 17:45:52 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16513 for ; Thu, 7 Nov 2002 17:43:16 -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 gA7MjjW24364; Thu, 7 Nov 2002 16:45:45 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gA7MjjS14948; Thu, 7 Nov 2002 16:45:45 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Thu, 7 Nov 2002 16:45:45 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Carl Smith'" , dhcwg@ietf.org Subject: RE: [dhcwg] proxy host name removal Date: Thu, 7 Nov 2002 16:44:40 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C286AF.41C040B4" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C286AF.41C040B4 Content-Type: text/plain; charset="iso-8859-1" Carl: Haven't yet looked at your revised draft, but is there a use case where this would be desired? And, is it really removal of the information after a period of time (but before the address is released) that is desired or not having it entered in the first place? I don't see a case where this would be needed at present, but perhaps someone will present a good case? I do agree with you that using the FQDN option is the best way to go. Especially considering that if the client needs to renew after it has requested the removal of the DNS information, it would want to make sure that the information isn't added again on a subsequent renewal. Perhaps we could consider two bits in the FQDN flags fields? But this may be overkill? No A desired (remove A) No RR desired (remove RR) We'd also need to define how these interact with the "N" bit and whether we could even consider using that bit in a new way? - Bernie -----Original Message----- From: Carl Smith [mailto:Carl.Smith@eng.sun.com] Sent: Thursday, November 07, 2002 3:57 PM To: dhcwg@ietf.org Subject: [dhcwg] proxy host name removal One of the items that needs clarification for the Host Options Considerations draft is the removal of host name <-> IP address updates. Specifically, is there a way for a client to ask a DHCP server to remove an update without giving up its lease? Two suggestions were made at the Minneapolis meeting: either the client should send a zero-length host name or a new bit in the FQDN option flags field could be allocated to convey the request. There was no concensus at the WG meeting on the need for such a facility, so I'm polling the mailing list to see whether it's felt we should pursue this further. Personally, I believe that if a way of doing it is to be offered, we should not change the way the Host Name option is used but instead use the FQDN option to express the request. Carl _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C286AF.41C040B4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] proxy host name removal

Carl:

Haven't yet looked at your revised draft, but is = there a use case
where this would be desired? And, is it really = removal of the
information after a period of time (but before the = address is
released) that is desired or not having it entered = in the first
place?

I don't see a case where this would be needed at = present, but
perhaps someone will present a good case?

I do agree with you that using the FQDN option is the = best way to
go. Especially considering that if the client needs = to renew
after it has requested the removal of the DNS = information, it
would want to make sure that the information isn't = added again
on a subsequent renewal.

Perhaps we could consider two bits in the FQDN flags = fields? But
this may be overkill?
        No A = desired (remove A)
        No RR = desired (remove RR)
We'd also need to define how these interact with the = "N" bit
and whether we could even consider using that bit in = a new way?

- Bernie

-----Original Message-----
From: Carl Smith [mailto:Carl.Smith@eng.sun.com= ]
Sent: Thursday, November 07, 2002 3:57 PM
To: dhcwg@ietf.org
Subject: [dhcwg] proxy host name removal


        One of the = items that needs clarification for the Host Options
Considerations draft is the removal of host name = <-> IP address updates.
Specifically, is there a way for a client to ask a = DHCP server to remove
an update without giving up its lease?  Two = suggestions were made at the
Minneapolis meeting:  either the client should = send a zero-length host
name or a new bit in the FQDN option flags field = could be allocated to
convey the request.
        There was = no concensus at the WG meeting on the need for such a
facility, so I'm polling the mailing list to see = whether it's felt we
should pursue this further.  Personally, I = believe that if a way of doing
it is to be offered, we should not change the way = the Host Name option
is used but instead use the FQDN option to express = the request.

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

------_=_NextPart_001_01C286AF.41C040B4-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 7 19:17:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19187; Thu, 7 Nov 2002 19:17:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA80IIv32249; Thu, 7 Nov 2002 19:18:19 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA804Pv31182 for ; Thu, 7 Nov 2002 19:04:25 -0500 Received: from atlrel7.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18776 for ; Thu, 7 Nov 2002 19:01:48 -0500 (EST) Received: from xatlrelay2.atl.hp.com (xatlrelay2.atl.hp.com [15.45.89.191]) by atlrel7.hp.com (Postfix) with ESMTP id 7A7F180511F for ; Thu, 7 Nov 2002 19:04:18 -0500 (EST) Received: from xatlbh3.atl.hp.com (xatlbh3.atl.hp.com [15.45.89.188]) by xatlrelay2.atl.hp.com (Postfix) with ESMTP id 481FC4000AB for ; Thu, 7 Nov 2002 19:04:03 -0500 (EST) Received: by xatlbh3.atl.hp.com with Internet Mail Service (5.5.2655.55) id ; Thu, 7 Nov 2002 19:03:57 -0500 Message-ID: <499DC368E25AD411B3F100902740AD650E7E0479@xrose03.rose.hp.com> From: "BORZ,JOHN (HP-Roseville,ex1)" To: "'dhcwg@ietf.org'" Date: Thu, 7 Nov 2002 19:02:34 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2655.55) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] RFC 3118 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Is anyone aware of any server implementations of RFC 3118? John Borz Software Design Engineer Hewlett-Packard Company E-mail: john_borz@hp.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 8 07:34:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15531; Fri, 8 Nov 2002 07:34:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CZsv19713; Fri, 8 Nov 2002 07:35:54 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CXjv19395 for ; Fri, 8 Nov 2002 07:33:45 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14745; Fri, 8 Nov 2002 07:31:13 -0500 (EST) Message-Id: <200211081231.HAA14745@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Nov 2002 07:31:13 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-server-mib-07.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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-07.txt Pages : 49 Date : 2002-11-7 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-07.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-07.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-dhc-server-mib-07.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-11-7155346.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-server-mib-07.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-server-mib-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7155346.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 8 07:34:59 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15663; Fri, 8 Nov 2002 07:34:59 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CaVv19787; Fri, 8 Nov 2002 07:36:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8CXnv19408 for ; Fri, 8 Nov 2002 07:33:49 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14760; Fri, 8 Nov 2002 07:31:17 -0500 (EST) Message-Id: <200211081231.HAA14760@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: dhcwg@ietf.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Fri, 08 Nov 2002 07:31:17 -0500 Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-dhcpv6-28.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --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) : R. Droms et al. Filename : draft-ietf-dhc-dhcpv6-28.txt Pages : 89 Date : 2002-11-7 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' (RFC2462), 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-28.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-28.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-28.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: <2002-11-7155355.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-dhcpv6-28.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-dhcpv6-28.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-11-7155355.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 8 08:17:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17828; Fri, 8 Nov 2002 08:17:43 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8DJEv23730; Fri, 8 Nov 2002 08:19:14 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8DIXv23694 for ; Fri, 8 Nov 2002 08:18:33 -0500 Received: from cichlid.adsl.duke.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17801 for ; Fri, 8 Nov 2002 08:15:59 -0500 (EST) Received: from cichlid.adsl.duke.edu (narten@localhost) by cichlid.adsl.duke.edu (8.11.6/8.11.6) with ESMTP id gA8DHw316596; Fri, 8 Nov 2002 08:17:58 -0500 Message-Id: <200211081317.gA8DHw316596@cichlid.adsl.duke.edu> To: "BORZ,JOHN (HP-Roseville,ex1)" cc: "'dhcwg@ietf.org'" Subject: Re: [dhcwg] RFC 3118 In-Reply-To: Message from "BORZ,JOHN (HP-Roseville,ex1)" of "Thu, 07 Nov 2002 19:02:34 EST." <499DC368E25AD411B3F100902740AD650E7E0479@xrose03.rose.hp.com> Date: Fri, 08 Nov 2002 08:17:57 -0500 From: Thomas Narten Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , > Is anyone aware of any server implementations of RFC 3118? The proposed DHC recharter includes the following words: > * RFC 3118 defines current security mechanisms for DHCPv4. > Unfortunately, RFC 3118 has neither been implemented nor deployed to > date. There is widespread feeling that its current restriction to > manual keying of clients limits its deployability. I assume that the above statement is correct. Thomas _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 8 09:44:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20115; Fri, 8 Nov 2002 09:44:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8EjUv30287; Fri, 8 Nov 2002 09:45:30 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Ehxv30211 for ; Fri, 8 Nov 2002 09:43:59 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20087; Fri, 8 Nov 2002 09:41:24 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA29400; Fri, 8 Nov 2002 09:43:54 -0500 (EST) Message-Id: <4.3.2.7.2.20021108094321.03d650d8@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Nov 2002 09:43:51 -0500 To: agenda@ietf.org From: Ralph Droms Cc: dhcwg@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] DHC WG agenda for IETF 55 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , DHC WG agenda, IETF 55 (Last revised 11/8/2002) ------------------------ Administrivia, agenda bashing Ralph Droms 5 minutes DHCP Option for CableLabs Client Configuration DHCPv6 and DHCPv6 SIP option WG charter and milestones Use of IPsec for Securing DHCPv4 Messages Exchanged Between Relay Agents and Servers draft-droms-dhcp-relay-agent-ipsec-00.txt Ralph Droms 5 minutes The Authentication Suboption for the DHCP Relay Agent Option draft-ietf-dhc-auth-suboption-01.txt Mark Stapp 10 minutes DHCP Option for SNMP Notifications draft-bakke-dhc-snmp-trap-01.txt Mark Bakke 10 minutes Subnet Allocation using DHCP draft-johnson-dhc-subnet-alloc-00.txt Richard Johnson 10 minutes DHCP Server-ID Override Suboption draft-johnson-dhc-server-override-00.txt Richard Johnson 10 minutes Considerations for the use of the Host Name option draft-ietf-dhc-host-option-considerations-01.txt Carl Smith 10 minutes Load Balancing for DHCPv6 draft-ietf-dhc-dhcpv6-loadb-02.txt Bernie Volz 5 minutes IPv6 Prefix Options for DHCPv6 draft-ietf-dhc-dhcpv6-opt-prefix-delegation-00.txt Ole Troan 5 minutes Other DHCPv6 options Ralph Droms 15 minutes DNS Configuration options for DHCPv6 DSTM Options for DHCP DSTM Ports Option for DHCPv6 NIS Configuration Options for DHCPv6 Time Configuration Options for DHCPv6 Client Preferred Prefix option for DHCPv6 A Guide to Implementing Stateless DHCPv6 Service draft-droms-dhcpv6-stateless-guide-01.txt Ralph Droms 5 minutes Revised DHC WG charter and milestones http://www.dhcp.org/charter-update.html Ralph Droms 10 minutes Recycling option codes Ralph Droms 5 minutes DHCP Lease Query draft-ietf-dhc-leasequery-05.txt Kim Kinnear 10 minutes Link Selection sub-option for the Relay Agent Information Option draft-ietf-dhc-agent-subnet-selection-04.txt Kim Kinnear 5 minutes VPN Information Option draft-ietf-dhc-vpn-option-02.txt Kim Kinnear 5 minutes VPN Identifier sub-option for the Relay Agent Information Option draft-ietf-dhc-agent-vpn-id-02.txt Kim Kinnear 10 minutes DHCP Option for Location Insertion draft-polk-dhcp-geo-loc-00.txt John Schnizlein 5 minutes The DHCP Client FQDN Option draft-ietf-dhc-fqdn-option-05.txt Mark Stapp 5 minutes DDNS-DHCP conflict resolution draft-ietf-dhc-ddns-resolution-05.txt Mark Stapp 5 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 8 11:43:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26478; Fri, 8 Nov 2002 11:43:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Ghuv09189; Fri, 8 Nov 2002 11:43:56 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Gfav08980 for ; Fri, 8 Nov 2002 11:41:36 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26304 for ; Fri, 8 Nov 2002 11:39:02 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA12075 for ; Fri, 8 Nov 2002 11:41:32 -0500 (EST) Message-Id: <4.3.2.7.2.20021108112530.03d7f810@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 08 Nov 2002 11: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] TTL on service addresses Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , At the last WG meeting, we talked about how to add lifetime information to addresses for services (for example, DNS server addresses). So, what are the requirements? Basically, we want to be able to inform the client the time over which it can expect the service address to be useful. The client can then re-contact the server to confirm the continued validity of those addresses or find out about new service addresses. Question - is it useful to have a separate lifetime for each service or can we make a simplification about lifetime information that applies to all of the services configured on the client? Are there other requirements? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 8 12:13:31 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28920; Fri, 8 Nov 2002 12:13:31 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8HEtv12242; Fri, 8 Nov 2002 12:14:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8HBxv11781 for ; Fri, 8 Nov 2002 12:11:59 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28542 for ; Fri, 8 Nov 2002 12:09:25 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gA8H7Z203900; Fri, 8 Nov 2002 11:07:35 -0600 (CST) Date: Fri, 8 Nov 2002 11:11:48 -0600 Subject: Re: [dhcwg] TTL on service addresses Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: dhcwg@ietf.org To: Ralph Droms From: Ted Lemon In-Reply-To: <4.3.2.7.2.20021108112530.03d7f810@funnel.cisco.com> Message-Id: <2A7B85D7-F33D-11D6-9BDA-00039367340A@nominum.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Why not just have the server set the renewal time on the packet to the shortest TTL in the packet? Why does the client even need to know this, since what it's going to have to do to refresh the information is to renew the lease anyway. And if we do it this way, does it need to be a protocol issue? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 8 18:47:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22651; Fri, 8 Nov 2002 18:47:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Nmhv09509; Fri, 8 Nov 2002 18:48:43 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gA8Nluv09455 for ; Fri, 8 Nov 2002 18:47:56 -0500 Received: from gamma.isi.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22581; Fri, 8 Nov 2002 18:45:18 -0500 (EST) Received: from ISI.EDU (jet.isi.edu [128.9.160.87]) by gamma.isi.edu (8.11.6/8.11.2) with ESMTP id gA8NlmD23197; Fri, 8 Nov 2002 15:47:48 -0800 (PST) Message-Id: <200211082347.gA8NlmD23197@gamma.isi.edu> To: IETF-Announce: ; Cc: rfc-editor@rfc-editor.org, dhcwg@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Fri, 08 Nov 2002 15:47:47 -0800 Subject: [dhcwg] RFC 3396 on Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3396 Title: Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4) Author(s): T. Lemon, S. Cheshire Status: Standards Track Date: November 2002 Mailbox: mellon@nominum.com, rfc@stuartcheshire.org Pages: 9 Characters: 18779 Updates: 2131 I-D Tag: draft-ietf-dhc-concat-05.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3396.txt This document specifies the processing rules for Dynamic Host Configuration Protocol (DHCPv4) options that appear multiple times in the same message. Multiple instances of the same option are generated when an option exceeds 255 octets in size (the maximum size of a single option) or when an option needs to be split apart in order to take advantage of DHCP option overloading. When multiple instances of the same option appear in the options, file and/or sname fields in a DHCP packet, the contents of these options are concatenated together to form a single option prior to processing. This document is a product of Dynamic Host Configuration Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="RFC-INFO@RFC-EDITOR.ORG" Content-Type: text/plain Content-ID: <021108154548.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3396 --OtherAccess Content-Type: Message/External-body; name="rfc3396.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <021108154548.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 10 07:00:52 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA14896; Sun, 10 Nov 2002 07:00:51 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAAC2Hv00460; Sun, 10 Nov 2002 07:02:17 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAAC0Wv00397 for ; Sun, 10 Nov 2002 07:00:32 -0500 Received: from atlrel7.hp.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14850 for ; Sun, 10 Nov 2002 06:58:00 -0500 (EST) Received: from hpuxsrv.india.hp.com (hpuxsrv.india.hp.com [15.10.45.132]) by atlrel7.hp.com (Postfix) with ESMTP id 0DA858050E0; Sun, 10 Nov 2002 07:00:30 -0500 (EST) 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 RAA29053; Sun, 10 Nov 2002 17:23:46 +0530 (IST) Reply-To: From: "Vijayabhaskar A K" To: "'Ralph Droms'" , Subject: RE: [dhcwg] TTL on service addresses Date: Sun, 10 Nov 2002 17:30:08 +0530 Message-ID: <000001c288b0$b82aceb0$2f290a0f@nt4147> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.3.2.7.2.20021108112530.03d7f810@funnel.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Ralph, The service addresses are not likely to change frequently. So, i feel that there is no meaning of having TTL for these addresses and renewing them once in a while. Already, we have a mechanism called "reconfiguration", through which this can be accomplished. Inclusion of TTL will unnecessarily complicate the client, as it needs to keep track of another timer, along with the one for IAs. I think, we can keep the option part as it is, thus, whatever the service addresses it receive, its going to be valid for infinite, and server will notify the change, if any, using the reconfigure-init in course of time ~ Vijay -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of Ralph Droms Sent: Friday, November 08, 2002 10:11 PM To: dhcwg@ietf.org Subject: [dhcwg] TTL on service addresses At the last WG meeting, we talked about how to add lifetime information to addresses for services (for example, DNS server addresses). So, what are the requirements? Basically, we want to be able to inform the client the time over which it can expect the service address to be useful. The client can then re-contact the server to confirm the continued validity of those addresses or find out about new service addresses. Question - is it useful to have a separate lifetime for each service or can we make a simplification about lifetime information that applies to all of the services configured on the client? Are there other requirements? - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 10 23:03:13 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00613; Sun, 10 Nov 2002 23:03:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAB44jv07903; Sun, 10 Nov 2002 23:04:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAB43jv07879 for ; Sun, 10 Nov 2002 23:03:45 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00603 for ; Sun, 10 Nov 2002 23:01:04 -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 gAB43aW07276; Sun, 10 Nov 2002 22:03:36 -0600 (CST) Received: from eamrcnt761.exu.ericsson.se (eamrcnt761.exu.ericsson.se [138.85.133.39]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gAB43ZP17632; Sun, 10 Nov 2002 22:03:35 -0600 (CST) Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Sun, 10 Nov 2002 22:03:34 -0600 Message-ID: From: "Bernie Volz (EUD)" To: Ted Lemon , Ralph Droms Cc: dhcwg@ietf.org Subject: RE: [dhcwg] TTL on service addresses Date: Sun, 10 Nov 2002 22:02:30 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28937.276B4706" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C28937.276B4706 Content-Type: text/plain; charset="iso-8859-1" Ralph: I assume this is for DHCPv6 (Information-Request)? Or? Would this TTL apply to Request as well? I would go with one TTL for all parameters (as Ted suggestions). - Bernie -----Original Message----- From: Ted Lemon [mailto:Ted.Lemon@nominum.com] Sent: Friday, November 08, 2002 12:12 PM To: Ralph Droms Cc: dhcwg@ietf.org Subject: Re: [dhcwg] TTL on service addresses Why not just have the server set the renewal time on the packet to the shortest TTL in the packet? Why does the client even need to know this, since what it's going to have to do to refresh the information is to renew the lease anyway. And if we do it this way, does it need to be a protocol issue? _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C28937.276B4706 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] TTL on service addresses

Ralph:

I assume this is for DHCPv6 (Information-Request)? = Or? Would this TTL apply to Request as well?

I would go with one TTL for all parameters (as Ted = suggestions).

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:Ted.Lemon@nominum.com]<= /FONT>
Sent: Friday, November 08, 2002 12:12 PM
To: Ralph Droms
Cc: dhcwg@ietf.org
Subject: Re: [dhcwg] TTL on service addresses


Why not just have the server set the renewal time on = the packet to the
shortest TTL in the packet?   Why does the = client even need to know
this, since what it's going to have to do to refresh = the information is
to renew the lease anyway.   And if we do = it this way, does it need to
be a protocol issue?

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

------_=_NextPart_001_01C28937.276B4706-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 11 11:41:39 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24164; Mon, 11 Nov 2002 11:41:39 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABGf9v21673; Mon, 11 Nov 2002 11:41:09 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gABGSYv20445 for ; Mon, 11 Nov 2002 11:28:34 -0500 Received: from hotmail.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23728 for ; Mon, 11 Nov 2002 11:25:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 11 Nov 2002 08:28:29 -0800 Received: from 47.234.0.52 by lw3fd.law3.hotmail.msn.com with HTTP; Mon, 11 Nov 2002 16:28:28 GMT X-Originating-IP: [47.234.0.52] From: "Sachin Vora" To: dhcwg@ietf.org Cc: droms@bucknell.edu, rdroms@cisco.com Date: Mon, 11 Nov 2002 11:28:28 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 11 Nov 2002 16:28:29.0722 (UTC) FILETIME=[5E735FA0:01C2899F] Subject: [dhcwg] Dhcp reserved addresses Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , The problem: Assuming that there is no mechanism to prevent the administrator to reserve an address which is in the dynamic allocation pool. If prior to reserving the address the dhcp server has leased that Ip address to a client (say client A) and then before renewal it reconfigures and leaves this assigned address in the dynamic pool but reserves the same address for a client X then how should the dhcp server handle the scenario when the Client X comes and asks for address. Should it refuse the reserved host as the address reserved for it is in use or should it give the reserved host an unreserved address from the pool? Sachin ************************************************************************************ Accept your limitations and then go beyond them ************************************************************************************ _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 12 11:41:16 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05785; Tue, 12 Nov 2002 11:41:16 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACGgkv12746; Tue, 12 Nov 2002 11:42:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACGYbv11877 for ; Tue, 12 Nov 2002 11:34:37 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05533 for ; Tue, 12 Nov 2002 11:31:59 -0500 (EST) Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-126.cisco.com [161.44.149.126]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA23668 for ; Tue, 12 Nov 2002 11:34:31 -0500 (EST) Message-Id: <4.3.2.7.2.20021112112941.00b9ac38@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Nov 2002 11:34:27 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] Proposed milestones Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Based on input from a few draft authors and on the revised WG charter, I've posted a revised list of WG milestones at http://www.dhcp.org/charter-update.html and included the milestones below. Please respond with comments... - Ralph 11/18/2002 Accept as WG work item (standards track) draft-bakke-dhc-snmp-trap-01.txt 11/18/2002 Accept as WG work item (standards track) draft-droms-dhcp-relay-agent-ipsec-00.txt 11/18/2002 Accept as WG work item (informational) draft-droms-dhcpv6-stateless-guide-01.txt 12/31/2002 Submit for WG last call draft-bakke-dhc-snmp-trap-01.txt 12/31/2002 Submit for WG last call draft-droms-dhcp-relay-agent-ipsec-00.txt 12/31/2002 Submit for WG last call draft-ietf-dhc-dhcpv6-opt-cliprefprefix-00.txt 12/31/2002 Submit for WG last call draft-ietf-dhc-dhcpv6-opt-nisconfig-01.txt 12/31/2002 Submit for WG last call draft-ietf-dhc-dhcpv6-opt-timeconfig-01.txt 12/31/2002 Publish new revision (-12) based on WG input draft-ietf-dhc-failover-11.txt 12/31/2002 Submit for WG last call draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt 1/31/2003 Submit for WG last call draft-ietf-dhc-dhcpv6-loadb-02.txt 1/31/2003 Identify DHCP threat model design team 1/31/2003 Identify DHCPv4 specification review design team 2/28/2003 Submit for IESG review draft-droms-dhcp-relay-agent-ipsec-00.txt 2/28/2003 Submit for IESG review draft-ietf-dhc-dhcpv6-opt-dnsconfig-02.txt 3/31/2003 Final report from DHCP threat model design team 6/30/2003 Final report from DHCPv4 specification review design team 6/30/2003 Final report on DHCP authentication requirements 7/31/2003 Submit for IESG review draft-ietf-dhc-agentopt-radius-02.txt _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 12 14:16:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10796; Tue, 12 Nov 2002 14:16:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJIPv22930; Tue, 12 Nov 2002 14:18:26 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJ76v22092 for ; Tue, 12 Nov 2002 14:07:06 -0500 Received: from dnsmx2pya.telcordia.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10545 for ; Tue, 12 Nov 2002 14:04:25 -0500 (EST) From: nabbott@telcordia.com Received: from notes900.cc.telcordia.com (notes900.cc.telcordia.com [128.96.79.7]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with ESMTP id OAA05315; Tue, 12 Nov 2002 14:06:27 -0500 (EST) To: dhcwg@ietf.org, geopriv@mail.apps.ietf.org, "James M. Polk" X-Mailer: Lotus Notes Release 5.0.5 September 22, 2000 Message-ID: Date: Tue, 12 Nov 2002 14:06:47 -0500 X-MIMETrack: Serialize by Router on notes900/Telcordia(Release 5.0.6a |January 17, 2001) at 11/12/2002 02:06:48 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [dhcwg] Re: Two companion IDs for consideration Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , All, I believe the approach described in the afore-mentioned Internet Drafts is dependent upon both LAN switch and DHCP server support of Circuit-ID RAIO defined (as SubOpt 1) in RFC 3046, Patrick M., "DHCP Relay Agent Information Option", January2001. Does anyone have any idea how widely supported these functions are by LAN switches and by DHCP servers? Thanks, Nadine Abbott Telcordia Technologies "James M. Polk" To: geopriv@mail.apps.ietf.org Abbott/Telcordia) Subject: Two companion IDs for consideration 10/30/2002 03:44 PM All A few of us have written two companion Drafts for consideration into 2 WGs (GEOPRIV and DHC). The first ID (into the DHC WG) is at: http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt and defines a Location Object format that satisfies (we hope) the basic required elements to represent a Target as well as the requirement for granular resolution. This ID in no way affects the GEOPRIV Protocol and it's goal for security or user control (ie rules for actively responding to a Location request). It provides a mechanism for getting the location information to an (wired) IP device which can then use the eventual GEOPRIV Protocol as that WG specifies. There are no semantics written into the DHC ID, and leaves some questions as to why the authors made certain choices. Hence the reason for the second ID. The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID. It's at: http://www.ietf.org/internet-drafts/draft-polk-geopriv-loc-object-semantics- 00.txt and shows (with many examples) why the meaning of "resolution" is better suited to meet the requirement of granular (im)precision than "accuracy". The examples of how the location Target device can simply alter the resolution presented to a location request from within 3.11mm x 2.62mm to as much as 1/6th that of the earth. Neither ID talks about the circumstances of these choices - the authors believe this normative text should reside elsewhere in GEOPRIV efforts with whatever rules that WG places on its Protocol efforts and output. Questions and comments have already been raised on the IEPREP WG list in the Transport Area, so this combined effort looks like it will have multiple lists with comments on them regarding these two IDs. Comments are encouraged cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 12 14:38:29 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11547; Tue, 12 Nov 2002 14:38:28 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJe7v24564; Tue, 12 Nov 2002 14:40:07 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gACJdev24511 for ; Tue, 12 Nov 2002 14:39:40 -0500 Received: from sj-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11517 for ; Tue, 12 Nov 2002 14:37:01 -0500 (EST) Received: from sj-msg-av-3.cisco.com (sj-msg-av-3.cisco.com [171.69.17.42]) by sj-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gACJdYIX026374; Tue, 12 Nov 2002 11:39:34 -0800 (PST) Received: from nisser.cisco.com (localhost [127.0.0.1]) by sj-msg-av-3.cisco.com (8.12.2/8.12.2) with ESMTP id gACJdWHe016120; Tue, 12 Nov 2002 11:39:33 -0800 (PST) Received: from jschnizl-w2k.cisco.com (rtp-vpn2-241.cisco.com [10.82.240.241]) by nisser.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with ESMTP id LAA10217; Tue, 12 Nov 2002 11:39:31 -0800 (PST) Message-Id: <4.3.2.7.2.20021112142825.03f90f00@wells.cisco.com> X-Sender: jschnizl@wells.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 12 Nov 2002 14:39:29 -0500 To: nabbott@telcordia.com From: John Schnizlein Subject: Re: [dhcwg] Re: Two companion IDs for consideration Cc: dhcwg@ietf.org, geopriv@mail.apps.ietf.org, "James M. Polk" In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I agree that this mechanism depends on a RAIO like Circuit-ID. We may have a chicken-or-egg situation with widespread support for this sub-option depending on useful features that get built depending on it. It is part of the process of building components of mechanism that their value is not realized until a useful combination of them delivers what people want. The approach here is to enable the phone end-point, or any host, to learn its geographic location from the network. Then it is up to some other application to use this information in a way that its user values. In that sense, the value of the mechanism also depends on the applications. Building valuable features out of standard components is the best way to encourage the implementation of standard components. The specification of the standard components is just a germ for the potential tree. John At 02:06 PM 11/12/2002, nabbott@telcordia.com wrote: >All, >I believe the approach described in the afore-mentioned Internet Drafts is >dependent upon both LAN switch and DHCP server support of Circuit-ID RAIO >defined (as SubOpt 1) in RFC 3046, Patrick M., "DHCP Relay Agent >Information Option", January2001. Does anyone have any idea how widely >supported these functions are by LAN switches and by DHCP servers? >Thanks, >Nadine Abbott >Telcordia Technologies > >A few of us have written two companion Drafts for consideration into 2 WGs >(GEOPRIV and DHC). > >The first ID (into the DHC WG) is at: >http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.txt >and defines a Location Object format that satisfies (we hope) the basic >required elements to represent a Target as well as the requirement for >granular resolution. This ID in no way affects the GEOPRIV Protocol and >it's goal for security or user control (ie rules for actively responding to >a Location request). It provides a mechanism for getting the location >information to an (wired) IP device which can then use the eventual GEOPRIV >Protocol as that WG specifies. There are no semantics written into the DHC >ID, and leaves some questions as to why the authors made certain choices. >Hence the reason for the second ID. > >The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID. >It's at: >http://www.ietf.org/internet-drafts/draft-polk-geopriv-loc-object-semantics- > >00.txt >and shows (with many examples) why the meaning of "resolution" is better >suited to meet the requirement of granular (im)precision than "accuracy". >The examples of how the location Target device can simply alter the >resolution presented to a location request from within 3.11mm x 2.62mm to >as much as 1/6th that of the earth. Neither ID talks about the >circumstances of these choices - the authors believe this normative text >should reside elsewhere in GEOPRIV efforts with whatever rules that WG >places on its Protocol efforts and output. > >Questions and comments have already been raised on the IEPREP WG list in >the Transport Area, so this combined effort looks like it will have >multiple lists with comments on them regarding these two IDs. > >Comments are encouraged _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 13 05:46:22 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA27078; Wed, 13 Nov 2002 05:46:22 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADAltv20113; Wed, 13 Nov 2002 05:47:55 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADAFCv18379 for ; Wed, 13 Nov 2002 05:15:12 -0500 Received: from web12805.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA26497 for ; Wed, 13 Nov 2002 05:12:36 -0500 (EST) Message-ID: <20021113101509.449.qmail@web12805.mail.yahoo.com> Received: from [212.91.166.210] by web12805.mail.yahoo.com via HTTP; Wed, 13 Nov 2002 02:15:09 PST Date: Wed, 13 Nov 2002 02:15:09 -0800 (PST) From: Martin Ivanov To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [dhcwg] Rfc2131 (Dynamic Host Configuration Protocol) Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Hello, I have one question regarding the RFC2131. Excuse me if that quesion is already discussed, I cound find a topic for it. It says that before configuring IP address, one device should send ARP request, for that IP address, with source IP set to 0. What is the motivation for that ? Only ARP cache of other hosts? I mean, that 0 source IP address may really confuse some switches/routers, which use ARP sniffing to capture hosts. In that case, if multiple subnets are configured on one port, and some ingress clasification is done, practucally I think that it will fail on 0 as source IP. It will be interesting for me if you think this problem exist, or I forget for somethiunk. Regards, Martin __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 13 08:34:07 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00298; Wed, 13 Nov 2002 08:34:07 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDZYv29175; Wed, 13 Nov 2002 08:35:34 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gADDYcv29142 for ; Wed, 13 Nov 2002 08:34:38 -0500 Received: from web11703.mail.yahoo.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA00262 for ; Wed, 13 Nov 2002 08:32:02 -0500 (EST) Message-ID: <20021113133435.23404.qmail@web11703.mail.yahoo.com> Received: from [192.35.17.11] by web11703.mail.yahoo.com via HTTP; Wed, 13 Nov 2002 14:34:35 CET Date: Wed, 13 Nov 2002 14:34:35 +0100 (CET) From: =?iso-8859-1?q?fabien=20passilly?= To: dhcwg@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Content-Transfer-Encoding: 8bit Subject: [dhcwg] rfc 2131 in cellular hosts' environment Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hello, I have one question regarding the RFC2131 and its adequation with the cellular hosts' world. I hope this question has not already been discussed before... In case of implementation of a DHCP client on a cellular host (as mentioned in 3GPP 29.061), I would like to get more information on the "htype" and "chaddr" fields used within a DHCP message. Which address could be used as the "chaddr" for the cellular host? The IMEI address or any randomly chosen one? In this IMEI case, which kind of hardware address's type ("htype") may be chosen? 0 or some other (new) value? (RFC1700) In this kind of environment, is it recommended to always use the "client identifier" option to make the mobile be identified on the network? I would be interested in getting any feedback that could clarify these points. I thank you in advance for your help, Regards, Fabien ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 13 23:00:20 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA27057; Wed, 13 Nov 2002 23:00:20 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAE41lv21770; Wed, 13 Nov 2002 23:01:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAE3xZv21653 for ; Wed, 13 Nov 2002 22:59:35 -0500 Received: from imr2.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27007 for ; Wed, 13 Nov 2002 22:56:51 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5att.ericy.com [138.85.224.141]) by imr2.ericy.com (8.11.3/8.11.3) with ESMTP id gAE3xOW25448; Wed, 13 Nov 2002 21:59:24 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gAE3xON12988; Wed, 13 Nov 2002 21:59:24 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Wed, 13 Nov 2002 21:59:24 -0600 Message-ID: From: "Bernie Volz (EUD)" To: "'Martin Ivanov'" , dhcwg@ietf.org Subject: RE: [dhcwg] Rfc2131 (Dynamic Host Configuration Protocol) Date: Wed, 13 Nov 2002 21:58:18 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28B92.0B957328" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C28B92.0B957328 Content-Type: text/plain; charset="iso-8859-1" See http://www.ietf.org/internet-drafts/draft-cheshire-ipv4-acd-02.txt. -----Original Message----- From: Martin Ivanov [mailto:mvi76@yahoo.com] Sent: Wednesday, November 13, 2002 5:15 AM To: dhcwg@ietf.org Subject: [dhcwg] Rfc2131 (Dynamic Host Configuration Protocol) Hello, I have one question regarding the RFC2131. Excuse me if that quesion is already discussed, I cound find a topic for it. It says that before configuring IP address, one device should send ARP request, for that IP address, with source IP set to 0. What is the motivation for that ? Only ARP cache of other hosts? I mean, that 0 source IP address may really confuse some switches/routers, which use ARP sniffing to capture hosts. In that case, if multiple subnets are configured on one port, and some ingress clasification is done, practucally I think that it will fail on 0 as source IP. It will be interesting for me if you think this problem exist, or I forget for somethiunk. Regards, Martin __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C28B92.0B957328 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] Rfc2131 (Dynamic Host Configuration = Protocol)

See http://www.ietf.org/internet-drafts/draft-cheshire-ipv= 4-acd-02.txt.

-----Original Message-----
From: Martin Ivanov [mailto:mvi76@yahoo.com]
Sent: Wednesday, November 13, 2002 5:15 AM
To: dhcwg@ietf.org
Subject: [dhcwg] Rfc2131 (Dynamic Host Configuration = Protocol)


Hello,

I have one question regarding the RFC2131.
Excuse me if that quesion is already discussed, = I
cound find a topic for it.

It says that before configuring IP address,  = one
device should send ARP request, for that IP = address,
with source IP set to 0. What is the motivation = for
that ? Only ARP cache of other hosts?
I mean, that 0 source IP address may really = confuse
some
switches/routers, which use ARP sniffing to = capture
hosts. In that case, if multiple subnets are
configured on one port, and some ingress = clasification
 is done, practucally I think that it will fail = on 0
as source IP.

It will be interesting for me if you think = this
problem exist, or I forget for somethiunk.

Regards,
Martin

__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

------_=_NextPart_001_01C28B92.0B957328-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 14 05:58:21 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15311; Thu, 14 Nov 2002 05:58:21 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEAxnv19870; Thu, 14 Nov 2002 05:59:49 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEAsEv19728 for ; Thu, 14 Nov 2002 05:54:14 -0500 Received: from fep04-svc.swip.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15260; Thu, 14 Nov 2002 05:51:38 -0500 (EST) Received: from offset.weird.se ([193.12.201.10]) by fep04-svc.swip.net with ESMTP id <20021114105411.EWSL19843.fep04-svc.swip.net@offset.weird.se>; Thu, 14 Nov 2002 11:54:11 +0100 Content-Type: text/plain; charset="us-ascii" From: Bud Millwood Reply-To: Bud Millwood Organization: Weird Solutions, Inc. To: dhcwg@ietf.org Date: Thu, 14 Nov 2002 11:55:09 +0100 User-Agent: KMail/1.4.3 Cc: ietf@ietf.org MIME-Version: 1.0 Message-Id: <200211141155.09167.budm@weird-solutions.com> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAEAsEv19729 Subject: [dhcwg] Minor inconsistencies with draft-ietf-dhc-packetcable-04.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Apologies for not getting these out sooner, I've just gotten around to implementing this option. draft-ietf-dhc-packetcable-04.txt In this document, two things seem to veer slightly from the existing DHCP protocol. First, it seems that suboptions 1 and 2 could be consolidated into one suboption only. Regular DHCP options carry multiple values in preferential order, so I don't see why this suboption couldn't do the same. Second, I'd rather see suboption 3 broken out into two different suboptions denoting the different data types. I'm not aware of any other DHCP option that has a type field. Bud Millwood Weird Solutions, Inc. http://www.weird-solutions.com tel: +46 8 758 3700 fax: +46 8 758 3687 mailto:budm@weird-solutions.com _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Thu Nov 14 11:52:35 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24181; Thu, 14 Nov 2002 11:52:35 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEGs1v08332; Thu, 14 Nov 2002 11:54:01 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAEGklv08072 for ; Thu, 14 Nov 2002 11:46:47 -0500 Received: from toccata.fugue.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24006; Thu, 14 Nov 2002 11:44:08 -0500 (EST) Received: from nominum.com (dsl-64-193-175-153.telocity.com [64.193.175.153]) by toccata.fugue.com (8.11.6/8.6.11) with ESMTP id gAEGfN213567; Thu, 14 Nov 2002 10:41:23 -0600 (CST) Date: Thu, 14 Nov 2002 10:46:43 -0600 Subject: Re: [dhcwg] Minor inconsistencies with draft-ietf-dhc-packetcable-04.txt Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v548) Cc: ietf@ietf.org, dhcwg@ietf.org To: Bud Millwood From: Ted Lemon In-Reply-To: <200211141155.09167.budm@weird-solutions.com> Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.548) Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit > Second, I'd rather see suboption 3 broken out into two different > suboptions > denoting the different data types. I'm not aware of any other DHCP > option > that has a type field. This is an excellent point. Options with variable formats _always_ require special code in the DHCP server to support them. I think the authors should choose either an IP address or an FQDN as the format in which the SIP server's IP address is communicated. If this is not possible, then the draft should at least be consistent with the SIP RFC (rfc3361), which does something similar, but chooses exactly the opposite meaning for the flag byte. The problem with allowing the option to contain either an FQDN or an IP address is that now the DHCP server has to have special code to support this specific option. Most DHCP servers (well, admittedly, I only have experience with two) are table-driven with respect to option formats, so this is a big deal. For example, because of the need for a special hack, I don't know when or if the ISC DHCP server will support the SIP option described in rfc3361, since I am no longer working on it. If SIP had chosen one or the other format, it would already be supported. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 15 14:40:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16580; Fri, 15 Nov 2002 14:40:04 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFJfiv10641; Fri, 15 Nov 2002 14:41:44 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAFJYPv09708 for ; Fri, 15 Nov 2002 14:34:25 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16358 for ; Fri, 15 Nov 2002 14:31:44 -0500 (EST) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAFJYfRo020912 for ; Fri, 15 Nov 2002 14:34:41 -0500 (EST) Received: from MJS-W2K.cisco.com (dhcp-161-44-149-97.cisco.com [161.44.149.97]) by goblet.cisco.com (Mirapoint) with ESMTP id ACC57767; Fri, 15 Nov 2002 14:34:17 -0500 (EST) Message-Id: <4.3.2.7.2.20021115133432.01ebd688@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 15 Nov 2002 14:34:17 -0500 To: dhcwg@ietf.org From: Mark Stapp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [dhcwg] update on dhcp/dns drafts' progress Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Folks, The advance summaries that several authors have sent about their drafts have been pretty useful, and Ralph has prodded me to produce something similar about the dhcp/dns drafts. The current versions are: http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-06.txt History The ddns-resolution and fqdn-option drafts last-called in October last year. The related dhcid rr draft also last-called, after some last-minute procedural hijinks almost caused it to be lost. I responded to some post-last-call comments from Thomas Narten in November. It seemed by the March 2002 ietf that the various working-group chairs and ads were in synch. By the summer, I was concerned that we hadn't heard from the iesg, and I asked Ralph to try to help me understand what was going on. In July, a significant issue was raised. Ralph, Olafur, and I agreed that we should address it, and I published revisions to the ddns-resolution and dhcid-rr drafts. The Issue The evolution of the dhcid-rr draft led to a situation in which details about the data within the dhcid-rr were present in two different drafts. History is to blame here, as usual. Years ago, there was a very simple dhcid-rr specification. It said, basically, "This RR holds binary data. If you want to know how to generate this data, go look in the dhc wg's ddns-resolution draft." The dnsext folks were not satisfied with this approach, and over time more and more details about the dhcid rr data leaked from the ddns-resolution draft into the dhcid-rr draft. By the summer, that had led to parallel language in the two specifications. The wg chairs were concerned that that would lead to implementation problems. The Current Drafts The current versions of the drafts have moved all of the specification of the dhcid rr data into the dhcid-rr draft. The use of the dhcid-rr by updaters remains in the ddns-resolution draft. The dhcid rr includes a 16-bit value specifying the source of the client-identity information. The original proposal for the RR proposed that this value would take on one of three values: the value zero if the identifier was the client's MAC address, the value 0xffff was reserved, and any other value would be the option number of the dhcp option that supplied the identifier (like the client-id option number). There was concern that this relied on non-overlapping v4 and v6 option number-spaces. The current draft specifies that this field holds an IANA-managed number. Four values are allocated initially: zero for the MAC address, one for the dhcpv4 client-id option, two for the dhcpv6 duid, and 0xffff is reserved. There is a slot at the end of the Atlanta agenda for discussion about these drafts, if that's necessary. -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sat Nov 16 23:26:15 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01521; Sat, 16 Nov 2002 23:26:15 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAH4Rvv15273; Sat, 16 Nov 2002 23:27:57 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAH4MWv15195 for ; Sat, 16 Nov 2002 23:22:32 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA01473 for ; Sat, 16 Nov 2002 23:19:47 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-552.cisco.com [10.82.226.40]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id XAA20450; Sat, 16 Nov 2002 23:22:22 -0500 (EST) Message-Id: <4.3.2.7.2.20021116220458.00b88dd0@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 16 Nov 2002 22:26:12 -0500 To: Mark Stapp From: Ralph Droms Subject: Re: [dhcwg] update on dhcp/dns drafts' progress Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20021115133432.01ebd688@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Mark - In addition to the issue concerning the description of the dhcid RR you describe below, two other issues were raised by Ted Lemon in the e-mail thread last July. Here is an excerpt from Ted's e-mail: > Unfortunately, I have two tweaks left for > draft-ietf-dhc-ddns-resolution-04.txt: > > 6.2 Adding PTR RR Entries to DNS > > The DHCP server submits a DNS query which deletes all of the PTR > RRs associated with the lease IP address, and adds a PTR RR whose > data is the client's (possibly disambiguated) host name. The server > also adds a DHCID RR as specified in Section 4. > > [...] I mentioned this before, but I don't recall getting any response. I > don't see any reason for the last sentence in this paragraph. [...] > > 5. DNS RR TTLs > > [...] I don't think there's any practical reason why the RR > on a DHCP client's DNS records should be longer than ten minutes by > default. [...] So I think the > text should be changed from this: > > A reasonable basis > for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the > expected lease duration might be reasonable defaults. Because > configured DHCP lease times vary widely from site to site, it may > also be desirable to establish a fixed TTL ceiling. DHCP clients > and servers MAY allow administrators to configure the TTLs they > will supply, possibly as a fraction of the actual lease time, or as > a fixed value. In general, the TTLs of RRs added as a result of > DHCP lease activity SHOULD be less than the initial lease time. > > to this: > > The RR TTL on a DNS record added for a DHCP lease should be > no longer than 10% of the lease time, and for leases longer than 100 > minutes, the TTL should be no longer than ten minutes. DHCP > servers and clients SHOULD allow administrators to configure > TTLs, either as an absolute time interval or as a percentage of the > lease time. In general, the TTLs or RRs added as a result of DHCP > lease activity SHOULD be less than the initial lease time. I believe you have edited your recently published drafts to address these two issues as well. If my understanding is correct, how have you addressed the issues? - Ralph At 02:34 PM 11/15/2002 -0500, Mark Stapp wrote: >Folks, > >The advance summaries that several authors have sent about their drafts >have been pretty useful, and Ralph has prodded me to produce something >similar about the dhcp/dns drafts. The current versions are: > >http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-05.txt >http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt >http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-06.txt > >History > >The ddns-resolution and fqdn-option drafts last-called in October last >year. The related dhcid rr draft also last-called, after some last-minute >procedural hijinks almost caused it to be lost. I responded to some >post-last-call comments from Thomas Narten in November. It seemed by the >March 2002 ietf that the various working-group chairs and ads were in >synch. By the summer, I was concerned that we hadn't heard from the iesg, >and I asked Ralph to try to help me understand what was going on. In July, >a significant issue was raised. Ralph, Olafur, and I agreed that we should >address it, and I published revisions to the ddns-resolution and dhcid-rr >drafts. > >The Issue > >The evolution of the dhcid-rr draft led to a situation in which details >about the data within the dhcid-rr were present in two different drafts. >History is to blame here, as usual. Years ago, there was a very simple >dhcid-rr specification. It said, basically, "This RR holds binary data. If >you want to know how to generate this data, go look in the dhc wg's >ddns-resolution draft." > >The dnsext folks were not satisfied with this approach, and over time more >and more details about the dhcid rr data leaked from the ddns-resolution >draft into the dhcid-rr draft. By the summer, that had led to parallel >language in the two specifications. The wg chairs were concerned that that >would lead to implementation problems. > >The Current Drafts > >The current versions of the drafts have moved all of the specification of >the dhcid rr data into the dhcid-rr draft. The use of the dhcid-rr by >updaters remains in the ddns-resolution draft. > >The dhcid rr includes a 16-bit value specifying the source of the >client-identity information. The original proposal for the RR proposed >that this value would take on one of three values: the value zero if the >identifier was the client's MAC address, the value 0xffff was reserved, >and any other value would be the option number of the dhcp option that >supplied the identifier (like the client-id option number). There was >concern that this relied on non-overlapping v4 and v6 option >number-spaces. The current draft specifies that this field holds an >IANA-managed number. Four values are allocated initially: zero for the MAC >address, one for the dhcpv4 client-id option, two for the dhcpv6 duid, and >0xffff is reserved. > >There is a slot at the end of the Atlanta agenda for discussion about >these drafts, if that's necessary. > >-- Mark > >_______________________________________________ >dhcwg mailing list >dhcwg@ietf.org >https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 17 09:37:08 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18996; Sun, 17 Nov 2002 09:37:08 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHEcgv20531; Sun, 17 Nov 2002 09:38:42 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHEXTv19897 for ; Sun, 17 Nov 2002 09:33:29 -0500 Received: from funnel.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18919 for ; Sun, 17 Nov 2002 09:30:50 -0500 (EST) Received: from rdroms-w2k.cisco.com (rtp-vpn1-128.cisco.com [10.82.224.128]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id JAA12631; Sun, 17 Nov 2002 09:33:25 -0500 (EST) Message-Id: <4.3.2.7.2.20021117090645.00b97c08@funnel.cisco.com> X-Sender: rdroms@funnel.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sun, 17 Nov 2002 09:33:19 -0500 To: ted.lemon@nominum.com From: Ralph Droms Subject: Re: [dhcwg] Minor inconsistencies with draft-ietf-dhc-packetcable-04.txt Cc: dhcwg@ietf.org 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-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , This draft has an unfortunately complex history. It was, in its original incarnation, in front of the WG at least 24 months ago. The WG provided some feedback, but there was no followup from the authors, and the draft lapsed. In the meantime, CableLabs decided to go ahead with the use of an option code from the "reserved for local use" range and defined an option and several sub-options. Now, CableLabs recognizes that it would be a Good Thing to standardize the definition of that option through the IETF. The starting point for the process was that non-standard definition. The draft has gone through several revisions, with edits based on WG input (during WG last call) and Area Director input. So, what we're seeing in the current PacketCable/CableLabs draft is a revision of what CableLabs has been shipping for some time, based on input from the dhc WG and the internet ADs. Paul has taken the initiative for CableLabs to bring the CableLabs client configuration option into the IETF standards process. Of course, ideally, we would have worked through the standard process with Cablelabs without the unfortunate delay and unilateral standard definition by Cablelabs. Thomas Narten and I have been talking with CableLabs to come to an understanding about how to cooperate in the DHCP options standards process in the future. - Ralph At 10:47 AM 11/15/2002 -0600, Ted Lemon wrote: >>The polarity flip will not be a big deal. PacketCable/Cablelabs will >>vigorously oppose any further changes. I need you both to understand >>that this option has been before the WG for over 18 months...with very >>active review over the last 6 months. Why have you both waited so long >>to deliver this input...we are trying to ship product here ! > >Your problem is that you have volunteers in your critical path. The >IETF is a volunteer organization, whose purpose is to define internet >standards. Its purpose is not to help you ship product. Members do not >always have time to review your work when you want it reviewed, >particularly if it's presented late. When someone does have time to >review your work, and finds a problem, you just have to deal with it. > >I have drafts on my critical path that have been stalled for way longer >than 18 months. This is IETF's strength and its weakness. One of two >RFCs I have been working on for about three years now *finally* advanced >this month, after being in last call for over a year. > >I first became aware of this draft in Yokohama - I'm not sure to what WG >you refer when you say 18 months. Look, you know who the players are in >the DHCP community, or you should. If you want people to read your >draft, the least you can do is ask them to. I don't remember you coming >up to me and asking at IETF, and I've been to every IETF in the period you >describe. Rich Woundy asked people in the DHC WG to read the draft in >Yokohama. I skimmed it, but didn't have time for a careful read, so I >wasn't aware of the problem with this draft until Bud mentioned it. > >If, in the future, you would like to avoid this sort of trouble, I'd >suggest a couple of things. First, present the draft to the working >group _as soon as you know what you want in it_. Second, hire >consultants to look at it who are experienced with DHC and know the >issues. Paid workers are more likely to read your draft. That's lame - >this is a volunteer effort and all - but if you are in a hurry, you >shouldn't put volunteers in your critical path. Ideally, hire the >consultants when you are writing the draft, so that you don't even go down >the wrong path. > >This is moot for the present moment - given that SIP has already broken >ground on this switch, I see no reason to oppose some other option using >it in the same way. But I mention this because I think if you have >realistic expectations going into the process, you will get a better outcome. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 17 14:06:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23587; Sun, 17 Nov 2002 14:06:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHJ8cv32116; Sun, 17 Nov 2002 14:08:38 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAHJ3Lv31441 for ; Sun, 17 Nov 2002 14:03:21 -0500 Received: from imr1.ericy.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23490 for ; Sun, 17 Nov 2002 14:00:40 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id gAHJ3Gd29906 for ; Sun, 17 Nov 2002 13:03:16 -0600 (CST) Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by mr5.exu.ericsson.se (8.11.3/8.11.3) with ESMTP id gAHJ3Gx24580 for ; Sun, 17 Nov 2002 13:03:16 -0600 (CST) Received: by eamrcnt760.exu.ericsson.se with Internet Mail Service (5.5.2656.59) id ; Sun, 17 Nov 2002 13:03:16 -0600 Message-ID: From: "Bernie Volz (EUD)" To: dhcwg@ietf.org Date: Sun, 17 Nov 2002 13:02:08 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C28E6B.D38DB1DE" Subject: [dhcwg] Load Balancing for DHCPv6 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , 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_01C28E6B.D38DB1DE Content-Type: text/plain; charset="ISO-8859-1" > During the DHC WG meeting at this week's IETF, I will briefly discuss > the Load Balancing draft to gather any last input before requesting > this go to Working Group last-call. > > Please look at the document and let me know if you have any issues. > > Link: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-loadb-02.txt > > Thanks in advance! > > - Bernie ------_=_NextPart_001_01C28E6B.D38DB1DE Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Load Balancing for DHCPv6

During the DHC = WG meeting at this week's IETF, I will briefly discuss
the Load = Balancing draft to gather any last input before requesting
this go to = Working Group last-call.

Please look at = the document and let me know if you have any issues.

Link: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhc= pv6-loadb-02.txt

Thanks in = advance!

- = Bernie

------_=_NextPart_001_01C28E6B.D38DB1DE-- _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Sun Nov 17 21:09:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29591; Sun, 17 Nov 2002 21:09:01 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAI2Aev17099; Sun, 17 Nov 2002 21:10:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAI25Yv16358 for ; Sun, 17 Nov 2002 21:05:34 -0500 Received: from klapautius.it.su.se (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA29465 for ; Sun, 17 Nov 2002 21:02:49 -0500 (EST) Received: from it.su.se (localhost [127.0.0.1]) by klapautius.it.su.se (8.11.6/8.11.6) with ESMTP id gAI25Ls01993; Mon, 18 Nov 2002 03:05:21 +0100 Message-ID: <3DD84AE0.3080105@it.su.se> Date: Mon, 18 Nov 2002 03:05:20 +0100 From: Leif Johansson User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jonas Oberg CC: dhcwg@ietf.org, stig.vennas@uninett.no Subject: Re: [dhcwg] LDAP schema References: <877ki0acur.fsf@polgara.coyote.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Jonas Oberg wrote: > Once upon a time, the DHC published a draft with an LDAP schema for > DHCP information (draft-ietf-dhc-ldap-schema-01.txt). That was now six > months ago, and the document has expired. Could someone update me on > the progress of this task, or could someone point me to appropriate > resources where I might find information about a recommended LDAP > schema for DHCP? During an unguarded moment Stig Vennas and I almost offered to revise or rewrite this draft. Is anyone else interested in getting together during the Atlanta meeting to talk about ldap schema for dhcp? Cheers Leif _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 18 08:35:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20497; Mon, 18 Nov 2002 08:35:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIDbIv23815; Mon, 18 Nov 2002 08:37:18 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAIDPev22752 for ; Mon, 18 Nov 2002 08:25:40 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20298 for ; Mon, 18 Nov 2002 08:23:01 -0500 (EST) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gAIDPxuS029463; Mon, 18 Nov 2002 08:26:00 -0500 (EST) Received: from MJS-W2K.cisco.com (che-vpn-cluster-2-8.cisco.com [10.86.242.8]) by goblet.cisco.com (Mirapoint) with ESMTP id ACC77667; Mon, 18 Nov 2002 08:25:35 -0500 (EST) Message-Id: <4.3.2.7.2.20021118081831.01d63400@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 18 Nov 2002 08:25:34 -0500 To: Ralph Droms From: Mark Stapp Subject: Re: [dhcwg] update on dhcp/dns drafts' progress Cc: dhcwg@ietf.org In-Reply-To: <4.3.2.7.2.20021116220458.00b88dd0@funnel.cisco.com> References: <4.3.2.7.2.20021115133432.01ebd688@goblet.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Ralph, I reduced the 'strength' of the requirement in section 6.2 to address Ted's concern. At the end of the email exchange this summer, Ted had provided sample text on handling of TTLs, and Olafur had responded to it. I mostly used Olafur's text - that's section 5. -- Mark At 10:26 PM 11/16/2002 -0500, Ralph Droms wrote: >Mark - In addition to the issue concerning the description of the dhcid RR >you describe below, two other issues were raised by Ted Lemon in the >e-mail thread last July. Here is an excerpt from Ted's e-mail: > > > Unfortunately, I have two tweaks left for > > draft-ietf-dhc-ddns-resolution-04.txt: > > > > 6.2 Adding PTR RR Entries to DNS > > > > The DHCP server submits a DNS query which deletes all of the PTR > > RRs associated with the lease IP address, and adds a PTR RR whose > > data is the client's (possibly disambiguated) host name. The server > > also adds a DHCID RR as specified in Section 4. > > > > [...] I mentioned this before, but I don't recall getting any response. I > > don't see any reason for the last sentence in this paragraph. [...] > > > > 5. DNS RR TTLs > > > > [...] I don't think there's any practical reason why the RR > > on a DHCP client's DNS records should be longer than ten minutes by > > default. [...] So I think the > > text should be changed from this: > > > > A reasonable basis > > for RR TTLs is the lease duration itself: TTLs of 1/2 or 1/3 the > > expected lease duration might be reasonable defaults. Because > > configured DHCP lease times vary widely from site to site, it may > > also be desirable to establish a fixed TTL ceiling. DHCP clients > > and servers MAY allow administrators to configure the TTLs they > > will supply, possibly as a fraction of the actual lease time, or as > > a fixed value. In general, the TTLs of RRs added as a result of > > DHCP lease activity SHOULD be less than the initial lease time. > > > > to this: > > > > The RR TTL on a DNS record added for a DHCP lease should be > > no longer than 10% of the lease time, and for leases longer than 100 > > minutes, the TTL should be no longer than ten minutes. DHCP > > servers and clients SHOULD allow administrators to configure > > TTLs, either as an absolute time interval or as a percentage of the > > lease time. In general, the TTLs or RRs added as a result of DHCP > > lease activity SHOULD be less than the initial lease time. > >I believe you have edited your recently published drafts to address these >two issues as well. If my understanding is correct, how have you >addressed the issues? > >- Ralph > >At 02:34 PM 11/15/2002 -0500, Mark Stapp wrote: >>Folks, >> >>The advance summaries that several authors have sent about their drafts >>have been pretty useful, and Ralph has prodded me to produce something >>similar about the dhcp/dns drafts. The current versions are: >> >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-ddns-resolution-05.txt >>http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt >>http://www.ietf.org/internet-drafts/draft-ietf-dnsext-dhcid-rr-06.txt >> >>History >> >>The ddns-resolution and fqdn-option drafts last-called in October last >>year. The related dhcid rr draft also last-called, after some last-minute >>procedural hijinks almost caused it to be lost. I responded to some >>post-last-call comments from Thomas Narten in November. It seemed by the >>March 2002 ietf that the various working-group chairs and ads were in >>synch. By the summer, I was concerned that we hadn't heard from the iesg, >>and I asked Ralph to try to help me understand what was going on. In >>July, a significant issue was raised. Ralph, Olafur, and I agreed that we >>should address it, and I published revisions to the ddns-resolution and >>dhcid-rr drafts. >> >>The Issue >> >>The evolution of the dhcid-rr draft led to a situation in which details >>about the data within the dhcid-rr were present in two different drafts. >>History is to blame here, as usual. Years ago, there was a very simple >>dhcid-rr specification. It said, basically, "This RR holds binary data. >>If you want to know how to generate this data, go look in the dhc wg's >>ddns-resolution draft." >> >>The dnsext folks were not satisfied with this approach, and over time >>more and more details about the dhcid rr data leaked from the >>ddns-resolution draft into the dhcid-rr draft. By the summer, that had >>led to parallel language in the two specifications. The wg chairs were >>concerned that that would lead to implementation problems. >> >>The Current Drafts >> >>The current versions of the drafts have moved all of the specification of >>the dhcid rr data into the dhcid-rr draft. The use of the dhcid-rr by >>updaters remains in the ddns-resolution draft. >> >>The dhcid rr includes a 16-bit value specifying the source of the >>client-identity information. The original proposal for the RR proposed >>that this value would take on one of three values: the value zero if the >>identifier was the client's MAC address, the value 0xffff was reserved, >>and any other value would be the option number of the dhcp option that >>supplied the identifier (like the client-id option number). There was >>concern that this relied on non-overlapping v4 and v6 option >>number-spaces. The current draft specifies that this field holds an >>IANA-managed number. Four values are allocated initially: zero for the >>MAC address, one for the dhcpv4 client-id option, two for the dhcpv6 >>duid, and 0xffff is reserved. >> >>There is a slot at the end of the Atlanta agenda for discussion about >>these drafts, if that's necessary. >> >>-- Mark >> >>_______________________________________________ >>dhcwg mailing list >>dhcwg@ietf.org >>https://www1.ietf.org/mailman/listinfo/dhcwg _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 18 21:23:48 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA11293; Mon, 18 Nov 2002 21:23:48 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAJ2PVv04809; Mon, 18 Nov 2002 21:25:31 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAI0UYv12636 for ; Sun, 17 Nov 2002 19:30:34 -0500 Received: from gateway.hns.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA28230 for ; Sun, 17 Nov 2002 19:27:50 -0500 (EST) Received: from excore1.hns.com (excore1.hns.com [139.85.52.104]) by gateway.hns.com (Switch-3.0.0/Switch-3.0.0) with ESMTP id gAI0UQhE016411 for ; Sun, 17 Nov 2002 19:30:26 -0500 (EST) Received: from hns.com (hnsvpnclient138.md.hns.com [139.85.221.138]) by excore1.hns.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id gAI0UJ102836; Sun, 17 Nov 2002 19:30:20 -0500 (EST) Message-ID: <3DD8349B.466EFD08@hns.com> Date: Sun, 17 Nov 2002 19:30:19 -0500 From: borderlt X-Mailer: Mozilla 4.7 [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 X-Filtered: Sendmail MIME Filter v1.0.7 excore1.hns.com gAI0UJ102836 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Re http://www.ietf.org/internet-drafts/draft-ietf-dhc-agent-vpn-id-02.txt Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit A minor comment on the VPN ID sub-option I-D... The document should specify exactly what the Relay Agent and Server should do if they receive a VPN ID sub-option which has a VPN ID type which they don't recognize. That way, when some future RFC adds a new type, the expected behavior of existing implementations which support the sub-option will be known... John _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 22 17:18:14 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05542; Fri, 22 Nov 2002 17:18:13 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMMJwv13420; Fri, 22 Nov 2002 17:19:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMHlJv31480 for ; Fri, 22 Nov 2002 12:47:19 -0500 Received: from vacexc01.MossBeachHomes.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00039 for ; Fri, 22 Nov 2002 12:44:04 -0500 (EST) Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Date: Fri, 22 Nov 2002 09:47:45 -0800 Message-ID: X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 Thread-Topic: Microsoft DHCP Thread-Index: AcKSC+t9c+18YvyeEdaQ6QCgzGCjKA== From: "Nick Saechow" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www1.ietf.org id gAMHlJv31481 Subject: [dhcwg] Microsoft DHCP Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit I am using multiple privet subnets on a single domain and I can't seem to get Microsoft DHCP server to release MAC addresses from one subnet for use in another. Thanks, Nick _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Fri Nov 22 17:18:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05535; Fri, 22 Nov 2002 17:18:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAMMJlv13397; Fri, 22 Nov 2002 17:19:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gALH1Ev29825 for ; Thu, 21 Nov 2002 12:01:14 -0500 Received: from sweep.pro.gov.uk (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10375 for ; Thu, 21 Nov 2002 11:58:14 -0500 (EST) Received: from gatekeeper.pro.gov.uk (unverified) by sweep.pro.gov.uk (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Thu, 21 Nov 2002 16:57:52 +0000 Received: by PRO06A with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Nov 2002 16:58:30 -0000 Message-ID: <113A2921FB16D511A26C00508BB8456C03762C43@PRO06A> From: "Folarin, Waheed" To: "'dhcwg@ietf.org'" Date: Thu, 21 Nov 2002 16:58:29 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [dhcwg] udp broadcast on port 68 Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , hi was wondering if you can answer a question for me .I have an NT4 dhcp server on my lan that is broadcasting to 255.255.255.255 on port 68. How can i stop this, dont understand why it is doing this since this is the client port and the machine is a server. Thanks Waheed Folarin PRO Network Support Engineer ICTD DIRECT 0208 876 2285 This e-mail message (and attachments) may contain information that is confidential to The Public Record Office. If you are not the intended recipient you cannot use, distribute or copy the message or attachments. In such a case, please notify the sender by return e-mail immediately and erase all copies of the message and attachments. Opinions, conclusions and other information in this message and attachments that do not relate to the official business of the Public Record Office are neither given nor endorsed by it. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Mon Nov 25 18:36:05 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01034; Mon, 25 Nov 2002 18:36:05 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAPNbpv05937; Mon, 25 Nov 2002 18:37:51 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAP9wKv22318 for ; Mon, 25 Nov 2002 04:58:20 -0500 Received: from mail.alcatel.be (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23515 for ; Mon, 25 Nov 2002 04:55:09 -0500 (EST) Received: from bemail02.net.alcatel.be (relay3 [127.0.0.1]) by mail.alcatel.be (8.11.0/8.11.4) with ESMTP id gAP9vnH18651 for ; Mon, 25 Nov 2002 10:57:49 +0100 Received: from adcc.alcatel.be ([202.65.8.56]) by bemail02.net.alcatel.be (Lotus Domino Release 5.0.8) with ESMTP id 2002112510574692:2854 ; Mon, 25 Nov 2002 10:57:46 +0100 From: prakash ram Message-ID: <3DE1F20B.917EFE37@adcc.alcatel.be> Date: Mon, 25 Nov 2002 15:18:59 +0530 From: Ramanamurthy_PRAKASH/IN/ALCATEL@ALCATEL X-Mailer: Mozilla 4.78 [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: dhcwg@ietf.org X-MIMETrack: Itemize by SMTP Server on BEMAIL02/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 10:57:48, Serialize by Router on BEMAIL02/BE/ALCATEL(Release 5.0.8 |June 18, 2001) at 11/25/2002 10:57:49, Serialize complete at 11/25/2002 10:57:49 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [dhcwg] JDHCP from www.dhcp.org/javadhcp Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Hi..

I'm Prakash, a s/w enginner working in Alcatel.
I downloaded the JDHCP code from the site
www.dhcp.org/javadhcp and I find there are some
files need to be included vide..

import edu.bucknell.net.JDHCP.*;

Can u help me in downloading these include files for my
further execution of the code??like where can I find those
include files etc..!!

Thanx in advance...

Regards,Prakash.
 
 
  _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 26 05:17:57 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26353; Tue, 26 Nov 2002 05:17:57 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQAJbv14875; Tue, 26 Nov 2002 05:19:37 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQAIIv14826 for ; Tue, 26 Nov 2002 05:18:18 -0500 Received: from mta7.pltn13.pbi.net (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26317 for ; Tue, 26 Nov 2002 05:15:34 -0500 (EST) Received: from Barr1LKL501 ([64.170.116.18]) by mta7.pltn13.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with SMTP id <0H6600FZH7D9KE@mta7.pltn13.pbi.net> for dhcwg@ietf.org; Mon, 25 Nov 2002 22:29:37 -0800 (PST) Date: Mon, 25 Nov 2002 22:30:00 -0800 From: Barr Hibbs Subject: RE: [dhcwg] Two companion IDs for consideration In-reply-to: <4.1.20021030145152.013ae820@localhost> To: "James M. Polk" , geopriv@mail.apps.ietf.org Cc: dhcwg@ietf.org Reply-to: rbhibbs@pacbell.net Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 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-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7BIT -----Original Message----- From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of James M. Polk Sent: Wednesday, October 30, 2002 15:44 A few of us have written two companion Drafts for consideration into 2 WGs (GEOPRIV and DHC). The first ID (into the DHC WG) is at: http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.tx t and defines a Location Object format... The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID. It's at: http://www.ietf.org/internet-drafts/draft-polk-geopriv-loc-object-semant ics-00.txt and shows why the meaning of "resolution" is better suited to meet the requirement of granular (im)precision than "accuracy". ...comments about the two drafts follow. --Barr draft-polk-dhcp-geo-loc-option-00: --editorial matters as you never repeat the acronym "RAIO" in the document, please spell it out completely ("Relay Agent Information Option") in the first sentence of the second paragraph of section 1.0, "Introduction." --content matters 1. the first sentence of the first paragraph of section 1.0 "Introduction" clearly limits the scope of this option to be data provided BY the server TO the client. This seems applicable to both wire-connected clients and some wireless clients (a specific access point might identify location with sufficient precision), but can you imagine a future scenario where a wireless or roaming client supplies the location information TO the server? If so, perhaps this sentence needs to be generalized, or a specific exclusion be included that prevents client to server notification (I'm not clear on how or why a DHCP server might use this information as it seems more application-oriented than network-oriented.) 2. section 1.2, "Motivation," provides some of the background for this option that I asked about above, but I see the use of the location information as application data, not entirely appropriate for DHCP. If I could see a clear motivation for needing location information at this point in the initialization process (likely to be before higher-layer protocols, such as IP telephony, are loaded and activated) I wouldn't question the need. I can think of other uses for this information besides E911 over IPtel (operations, management, and troubleshooting come to mind) but all are really applications-layer functions. 3. section 1.3, "Rationale," includes rationale for the composition of the three components of location (latitude, longitude, and altitude) but has a few interesting discrepancies. Let me state that I'm NOT an expert in geolocation, so I may not appreciate the design choices that have been made here, but I wonder why only 48 bits is used for the maximum precision of latitude and longitude? Here I'm imagining future implementations of millimeter-sized devices such as medical implants where additional precision might be considered essential. 4. in fact, I wonder whether even less-precise planar coordinates might be completely appropriate, such as room and cubicle number. If so, then some mechanism for specifying which units were employed for the coordinates would seem to be required. 5. altitude should be able to be specified to near-orbital precision in 30 bits, but I wonder if latitude, longitude and altitude is the best measure if devices are much above passenger aviation levels? Again, I'm not sufficiently conversant in the technology of location to know even what system is used for, say, the lunar lander or a mars probe, let alone what is sufficient precision, but it seems appropriate to ask. draft-polk-geopriv-loc-object-semantics-00; --my only comments on this draft are that some of the explanation and examples presented here could be included in the other draft so that it would be more complete in and of itself. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 26 13:45:44 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15084; Tue, 26 Nov 2002 13:45:44 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQIlLv16088; Tue, 26 Nov 2002 13:47:21 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAQIa0v14897 for ; Tue, 26 Nov 2002 13:36:00 -0500 Received: from shell.nominum.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14519 for ; Tue, 26 Nov 2002 13:33:12 -0500 (EST) Received: from yomiko.engr.nominum.com (dhcp-132.engr.nominum.com [128.177.194.132]) by shell.nominum.com (Postfix) with ESMTP id 28247137F11 for ; Tue, 26 Nov 2002 10:35:55 -0800 (PST) Received: from yomiko.engr.nominum.com (localhost [127.0.0.1]) by yomiko.engr.nominum.com (8.12.6/8.9.3) with ESMTP id gAQIZsR6047943 for ; Tue, 26 Nov 2002 10:35:54 -0800 (PST) Message-Id: <200211261835.gAQIZsR6047943@yomiko.engr.nominum.com> To: dhcwg@ietf.org In-reply-to: Your message of "Tue, 26 Nov 2002 12:00:02 EST." <20021126170002.8366.97332.Mailman@www1.ietf.org> X-URI: http://www.nominum.com/ X-Face: 6K2.ZvQgQ.NDQLIx.1pW(xRu*">:}&PX-Ad_!!?wU7H4L"wF"0xEwYu=8Or0V+=5?-eO1XL 7-0Hom/|]B2C7Uznyol-NVnvEk:+sod^MyB4v4qVpPDemr;b@pZdRSXu.'Gm^t0?2l,j[&t.kbc[UW x6Lz^e$K$W Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Tue, 26 Nov 2002 10:35:54 -0800 From: Eric Scanner Luce Subject: [dhcwg] Re: dhcwg digest, Vol 1 #410 - 2 msgs Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , >>>>> "bh" == dhcwg-request >>>>> wrote the following on Tue, 26 Nov 2002 12:00:02 -0500 bh> 5. altitude should be able to be specified to near-orbital bh> precision in 30 bits, but I wonder if latitude, longitude and bh> altitude is the best measure if devices are much above bh> passenger aviation levels? Again, I'm not sufficiently bh> conversant in the technology of location to know even what bh> system is used for, say, the lunar lander or a mars probe, let bh> alone what is sufficient precision, but it seems appropriate bh> to ask. While I do not think this is reasonable for a lunar lander or things that far out the amateur sattelite organization has shown that you can get GPS lock out beyond geo-sync orbit. We should at least include such altitudes -- although at this time a dhcp client on a satellite seems a bit far fetched we have seen stranger things come to pass. -- Scanner (scanner@nominum.com) Nominum, Inc. | www.nominum.com | +1.650.779.6035 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Tue Nov 26 22:46:09 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03825; Tue, 26 Nov 2002 22:46:09 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR3lwv17772; Tue, 26 Nov 2002 22:47:58 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gAR3ktv17731 for ; Tue, 26 Nov 2002 22:46:55 -0500 Received: from scutsv39.scut.edu.cn (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA03793 for ; Tue, 26 Nov 2002 22:44:00 -0500 (EST) Received: from smtp.scut.edu.cn (smtp.scut.edu.cn [202.38.193.66]) by scutsv39.scut.edu.cn (8.9.3/8.9.3) with ESMTP id LAA26893 for ; Wed, 27 Nov 2002 11:45:08 +0800 (CST) Received: from letterbox.scut.edu.cn (mail.scut.edu.cn [202.38.193.69]) by smtp.scut.edu.cn (8.12.3/8.12.3) with ESMTP id gAR3oCAI020807 for ; Wed, 27 Nov 2002 11:50:12 +0800 (CST) Received: from penny-figki2z ([202.38.197.70]) by letterbox.scut.edu.cn (8.12.2/8.12.2) with ESMTP id gAR3irqA015654 for ; Wed, 27 Nov 2002 11:45:07 +0800 (CST) Message-Id: <200211270345.gAR3irqA015654@letterbox.scut.edu.cn> Date: Wed, 27 Nov 2002 11:51:19 +0800 From: Penny To: DHCP X-mailer: FoxMail 4.0 beta 2 [cn] Mime-Version: 1.0 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by www1.ietf.org id gAR3ktv17732 Subject: [dhcwg] A question Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 8bit Hi,everyone: I am a novelist in DHCP, I'd like to know when client leave its domain and and doesn't tell server, does DHCP server notice it? Will it check the client once per time unit or will it release its client address in preferred valid time and never check the client? Thank you. ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡Penny ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 27 12:33:01 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20655; Wed, 27 Nov 2002 12:33:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARHYev10931; Wed, 27 Nov 2002 12:34:40 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARHXUv10810 for ; Wed, 27 Nov 2002 12:33:30 -0500 Received: from wells.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20573 for ; Wed, 27 Nov 2002 12:30:41 -0500 (EST) Received: from JMPOLK-W2K (ssh-sjc-1.cisco.com [171.68.225.134]) by wells.cisco.com (8.8.6 (PHNE_14041)/CISCO.SERVER.1.2) with SMTP id JAA12910; Wed, 27 Nov 2002 09:33:13 -0800 (PST) Message-Id: <4.1.20021126122358.015d7eb0@localhost> X-Sender: jmpolk@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Wed, 27 Nov 2002 11:33:10 -0600 To: rbhibbs@pacbell.net, geopriv@mail.apps.ietf.org From: "James M. Polk" Subject: RE: [dhcwg] Two companion IDs for consideration Cc: dhcwg@ietf.org In-Reply-To: References: <4.1.20021030145152.013ae820@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Barr Interesting comments, I've provided some replies in-line below At 10:30 PM 11/25/2002 -0800, Barr Hibbs wrote: > >-----Original Message----- >From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of >James M. Polk >Sent: Wednesday, October 30, 2002 15:44 > >A few of us have written two companion Drafts for consideration into 2 >WGs (GEOPRIV and DHC). > >The first ID (into the DHC WG) is at: >http://www.ietf.org/internet-drafts/draft-polk-dhcp-geo-loc-option-00.tx >t >and defines a Location Object format... > >The second ID (into the GEOPRIV WG) is the semantics ID for the DHC ID. >It's at: >http://www.ietf.org/internet-drafts/draft-polk-geopriv-loc-object-semant >ics-00.txt >and shows why the meaning of "resolution" is better suited to meet the >requirement of granular (im)precision than "accuracy". > >...comments about the two drafts follow. > >--Barr > > >draft-polk-dhcp-geo-loc-option-00: > >--editorial matters > >as you never repeat the acronym "RAIO" in the document, please spell it >out completely ("Relay Agent Information Option") in the first sentence >of the second paragraph of section 1.0, "Introduction." This will be changed, thanks for the suggestion > > > >--content matters > >1. the first sentence of the first paragraph of section 1.0 >"Introduction" clearly limits the scope of this option to be data >provided BY the server TO the client. This is the direction DHCP works in. RAIO is a special case and one that the client will never know about I believe. >This seems applicable to both >wire-connected clients and some wireless clients It can be, but the wired applicability is a known when the DHCP Server interfaces to a known wiring map of the infrastructure, wireless isn't as known, except maybe for: >(a specific access >point might identify location with sufficient precision), This can provided for with this option proposal. The AP is a wired device (typically) and is connected to a wired port (hopefully in a known wiring map infrastructure). >but can you >imagine a future scenario where a wireless or roaming client supplies >the location information TO the server? We don't (at this time) consider this to be under the charter of DHCP, but it does fit into GEOPRIV's charter explicitly (a device providing its location). >If so, perhaps this sentence >needs to be generalized, or a specific exclusion be included that >prevents client to server notification (I'm not clear on how or why a >DHCP server might use this information as it seems more >application-oriented than network-oriented.) I agree with your last comment here > >2. section 1.2, "Motivation," provides some of the background for this >option that I asked about above, but I see the use of the location >information as application data, not entirely appropriate for DHCP. I don't agree. Getting the location object (LO) into the endpoint at configuration time allows the application layer to use and manipulate it as whatever/however the user/policy wants to (with GEOPRIV or SIP or another protocol) >If >I could see a clear motivation for needing location information at this >point in the initialization process (likely to be before higher-layer >protocols, such as IP telephony, are loaded and activated) I wouldn't >question the need. Getting the LO to the IPT endpoint/UA allows it to then immediately place an e911 session/call without another process potentially failing. No one knows if GEOPRIV will be coded into all UAs or other endpoints, but this option in DHC is fairly trivial to add. I for one want a consistent LO format (at least in certain critical fields). Another protocol can then use this LO for its purposes. If GEOPRIV is coded into a particular UA or Target/endpoint, then the fullness of the GEOPRIV Protocol can be used with the LO already local to it. This can provide the ability to do some relative location determination (where the nearest Pizza Hut to me?), which isn't part of GEOPRIV in its current form (but is foreseen in its future dev) >I can think of other uses for this information >besides E911 over IPtel (operations, management, and troubleshooting >come to mind) but all are really applications-layer functions. Once the LO is in the endpoint, those other apps can use it (preferably if they meet GEOPRIV's security requirements) > >3. section 1.3, "Rationale," includes rationale for the composition of >the three components of location (latitude, longitude, and altitude) but >has a few interesting discrepancies. Let me state that I'm NOT an >expert in geolocation, so I may not appreciate the design choices that >have been made here, but I wonder why only 48 bits is used for the >maximum precision of latitude and longitude? 34 bits are used for each (and 30 for Altitude) >Here I'm imagining future >implementations of millimeter-sized devices such as medical implants >where additional precision might be considered essential. On the equator, 34 bits of La/Lo will get to a granularity of 3.11mm x 2.62mm (this trapezoid gets smaller as you get nearer the poles), do you want explicitly more granularity than that? We could add 4 or 8 bits more to each (La/Lo) field if the WGs desire it, but I don't know if this is terribly useful at this point. comments? > >4. in fact, I wonder whether even less-precise planar coordinates might >be completely appropriate, such as room and cubicle number. Ahhh, what Henning calls "Civil" coordinates. We thought about this, but couldn't come up with how a endpoint can make its location deterministrically less precise based only on Civil addressing. I agree that this is more information, but it's also only known to those who built the building. This can be gotten upon entrance to the building (based on the wire-map and provided La/Lo/Alt (in Floors). >If so, then >some mechanism for specifying which units were employed for the >coordinates would seem to be required. I agree that this would be required if employed, but this will also be unique to each building (conceivably everywhere). > >5. altitude should be able to be specified to near-orbital precision in >30 bits, but I wonder if latitude, longitude and altitude is the best >measure if devices are much above passenger aviation levels? Anyone in a plane isn't in a wired connection (even considering Boeing's future plans). Further, that device in the plane moving at between 200 and 650nmph wouldn't have their location provided very precisely moment to moment... GEOPRIV is working on providing the necessary information for tracking a moving target (with the vector/velocity fields, and potentially a delta field), and thus I don't think that DHCP Reply should attempt to tackle that situation. BTW - if another Altitude Measurement Unit were proposed, satellites in Geo-synchronous Orbit could have known LOs applied to them. But everything between the top of Mt. Everest and Geo-sync would not be stable (or wired) so we chose not to include km as a MU in this version of the doc. >Again, I'm >not sufficiently conversant in the technology of location to know even >what system is used for, say, the lunar lander or a mars probe, All related GEOPRIV efforts are based on a spheroid with a single and know center. Any LO for our Moon or Mars will be possible with a given datum to work from (but it won't be from Earth) >let >alone what is sufficient precision, but it seems appropriate to ask. > > >draft-polk-geopriv-loc-object-semantics-00; > >--my only comments on this draft are that some of the explanation and >examples presented here could be included in the other draft so that it >would be more complete in and of itself. This split explanation was always the intent with this effort. I believe an informational semantics doc should be right along side this standards track option doc through this process (allows for freer wording/writing and explanation that mechanism docs don't like in them) > cheers, James ************************************* "People generally demand more respect for their own rights than they are willing to allow for others" _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 27 17:03:00 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29562; Wed, 27 Nov 2002 17:03:00 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARM4jv28375; Wed, 27 Nov 2002 17:04:47 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARFC9v32638 for ; Wed, 27 Nov 2002 10:12:09 -0500 Received: from eamail1-out.unisys.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA13689 for ; Wed, 27 Nov 2002 10:09:22 -0500 (EST) Received: from us-ea-gtwy-4.ea.unisys.com (us-ea-gtwy-4.ea.unisys.com [192.61.146.122]) by eamail1-out.unisys.com (8.9.3/8.9.3) with ESMTP id PAA12104 for ; Wed, 27 Nov 2002 15:08:07 GMT Received: by us-ea-gtwy-4.ea.unisys.com with Internet Mail Service (5.5.2656.59) id ; Wed, 27 Nov 2002 09:11:48 -0600 Message-ID: <99E75AF675B7D211A31800105A1770CA031F60A3@gb-csc-exch-3.mk.unisys.com> From: "Keasey, Adrian" To: "'dhcwg@ietf.org'" Date: Wed, 27 Nov 2002 09:10:26 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Subject: [dhcwg] DDNS FQDN Registration - PTR records Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , I have a question on the DHCP Client FQDN Option for registering DDNS records. We have a commercial DHCP server which is configured to register the client's A record with the FQDN listed in the Domain field of Option 81 in the DHCP Request packet. This registration works correctly. However, the DHCP server is registering the client's PTR record with the clients hostname, but a different DNS domain - i.e. not the FQDN listed in the Domain field of Option 81 in the DHCP Request packet. This creates a situation where the client has a different FQDN listed in the PTR record and the A record. I assume that this is not expected behaviour, but "The DHCP Client FQDN Option" (http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt ) does not explicitly state that the PTR registration SHOULD / MUST / MAY use the FQDN that the client responds with. Regards, Adrian Keasey _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-admin@ietf.org Wed Nov 27 17:44:36 2002 Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00958; Wed, 27 Nov 2002 17:44:36 -0500 (EST) Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARMkSv31272; Wed, 27 Nov 2002 17:46:28 -0500 Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id gARMjxv31210 for ; Wed, 27 Nov 2002 17:45:59 -0500 Received: from rtp-msg-core-1.cisco.com (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA00829 for ; Wed, 27 Nov 2002 17:43:08 -0500 (EST) Received: from goblet.cisco.com (localhost [127.0.0.1]) by rtp-msg-core-1.cisco.com (8.12.2/8.12.2) with ESMTP id gARMkC8O015344; Wed, 27 Nov 2002 17:46:18 -0500 (EST) Received: from MJS-W2K.cisco.com (dhcp-161-44-149-122.cisco.com [161.44.149.122]) by goblet.cisco.com (Mirapoint) with ESMTP id ACE37453; Wed, 27 Nov 2002 17:45:43 -0500 (EST) Message-Id: <4.3.2.7.2.20021127171115.01efa8e0@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 27 Nov 2002 17:45:11 -0500 To: "Keasey, Adrian" From: Mark Stapp Subject: Re: [dhcwg] DDNS FQDN Registration - PTR records Cc: dhcwg@ietf.org In-Reply-To: <99E75AF675B7D211A31800105A1770CA031F60A3@gb-csc-exch-3.mk. unisys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: dhcwg-admin@ietf.org Errors-To: dhcwg-admin@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , Adrian, It's often useful for there to be an A and PTR 'pair', in which the PTR associated with an address names the A whose data is the address. That said, it's entirely an administrator's decision whether or not to configure the dhcp and dns servers to make that happen. And of course, it's entirely up to implementors to determine what combinations to support in their software. In some win2k deployments, dhcp clients are encouraged to update one forward zone while the server updates another. In these cases, the server probably prefers a PTR which reflects the forward name that it is managing along with the dhcp lease, over the name that the client is responsible for. The FQDN option draft specifies how the client and server exchange information about the fqdn, and some information about the dns updating that's going to happen. It's not a general-purpose dns update proxy option, and it's also explicitly not a set of restrictions on administrators' configurations. There are some more-detailed operational recommendations in draft-ietf-dhc-ddns-resolution-*.txt. Regards, Mark At 09:10 AM 11/27/2002 -0600, Keasey, Adrian wrote: >I have a question on the DHCP Client FQDN Option for registering DDNS >records. We have a commercial DHCP server which is configured to register >the client's A record with the FQDN listed in the Domain field of Option 81 >in the DHCP Request packet. This registration works correctly. > >However, the DHCP server is registering the client's PTR record with the >clients hostname, but a different DNS domain - i.e. not the FQDN listed in >the Domain field of Option 81 in the DHCP Request packet. This creates a >situation where the client has a different FQDN listed in the PTR record and >the A record. > >I assume that this is not expected behaviour, but "The DHCP Client FQDN >Option" >(http://www.ietf.org/internet-drafts/draft-ietf-dhc-fqdn-option-05.txt > ) >does not explicitly state that the PTR registration SHOULD / MUST / MAY use >the FQDN that the client responds with. > >Regards, > >Adrian Keasey > > >_______________________________________________ >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