From mailman-bounces@ietf.org Mon Nov 1 09:04:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04478 for ; Mon, 1 Nov 2004 09:04:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COZl4-0001V7-7j for dhcipv6-archive@lists.ietf.org; Mon, 01 Nov 2004 05:49:54 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Subject: ietf.org mailing list memberships reminder From: mailman-owner@ietf.org To: dhcipv6-archive@ietf.org X-No-Archive: yes Message-ID: Date: Mon, 01 Nov 2004 05:19:29 -0500 Precedence: bulk X-BeenThere: mailman@lists.ietf.org X-Mailman-Version: 2.1.5 List-Id: Mailman site list X-List-Administrivia: yes Sender: mailman-bounces@ietf.org Errors-To: mailman-bounces@ietf.org Content-Transfer-Encoding: 7bit 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, mailman-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: Any submission to the IETF intended by the Contributor for publication as all or part of an IETF Internet-Draft or RFC and any statement made within the context of an IETF activity is considered an "IETF Contribution". Such statements include oral statements in IETF sessions, as well as written and electronic communications made at any time or place, which are addressed to: o the IETF plenary session, o any IETF working group or portion thereof, o the IESG, or any member thereof on behalf of the IESG, o the IAB or any member thereof on behalf of the IAB, o any IETF mailing list, including the IETF list itself, any working group or design team list, or any other list functioning under IETF auspices, o the RFC Editor or the Internet-Drafts function All IETF Contributions are subject to the rules of RFC 3667 and RFC 3668. Statements made outside of an IETF session, mailing list or other function, that are clearly not intended to be input to an IETF activity, group or function, are not IETF Contributions in the context of this notice. Please consult RFC 3667 for details. ******************************************************************************* If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for dhcipv6-archive@lists.ietf.org: List Password // URL ---- -------- dhcwg@ietf.org xJod https://www1.ietf.org/mailman/options/dhcwg/dhcipv6-archive%40lists.ietf.org From dhcwg-bounces@ietf.org Mon Nov 1 15:51:50 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29629; Mon, 1 Nov 2004 15:51:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COios-0005N7-OY; Mon, 01 Nov 2004 15:30:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COicX-0000Zk-Sb; Mon, 01 Nov 2004 15:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA26030; Mon, 1 Nov 2004 15:17:39 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COirW-0001ny-6b; Mon, 01 Nov 2004 15:33:10 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1COiJY-0006G4-KP; Mon, 01 Nov 2004 14:58:04 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Mon, 01 Nov 2004 14:58:04 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'Rapid Commit Option for DHCPv4' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'Rapid Commit Option for DHCPv4 ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary This specification defines a new mechanism for DHCPv4, modeled on the DHCPv6 Rapid Commit option and mechanism, for obtaining IP address and configuration information using a 2 message exchange instead of the usual 4 message exchange. Working Group Summary There was consensus in the WG for approval of the DHCPv4 rapid commit option and associated mechanism. It has been thoroughly reviewed by the dhc WG and discussed in WG meetings and on the dhcwg mailing list. Samsung has published an IPR claim, in which it promises to provide zero-cost licensing, related to this specification. Protocol Quality This extension to the DHCPv4 protocol and its specification is of high quality and had been thoroughly reviewed by the dhc WG. Several vendors have expressed interest in implementing this extension to DHCPv4. This document has been reviewed for the IESG by Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 1 20:29:30 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00315; Mon, 1 Nov 2004 20:29:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnGJ-0001U9-Pb; Mon, 01 Nov 2004 20:15:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnEc-0008OH-OQ for dhcwg@megatron.ietf.org; Mon, 01 Nov 2004 20:13:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA28868 for ; Mon, 1 Nov 2004 20:13:15 -0500 (EST) Received: from mailout1.samsung.com ([203.254.224.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnTS-0002ZT-CU for dhcwg@ietf.org; Mon, 01 Nov 2004 20:28:49 -0500 Received: from custom-daemon.mailout1.samsung.com by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) id <0I6J00A9J20ZNJ@mailout1.samsung.com> for dhcwg@ietf.org; Tue, 02 Nov 2004 10:12:35 +0900 (KST) Received: from ep_mmp1 (mailout1.samsung.com [203.254.224.24]) by mailout1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6J008YG1XPS8@mailout1.samsung.com> for dhcwg@ietf.org; Tue, 02 Nov 2004 10:10:37 +0900 (KST) Received: from LocalHost ([168.219.198.109]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I6J007AL1XOQN@mmp1.samsung.com> for dhcwg@ietf.org; Tue, 02 Nov 2004 10:10:37 +0900 (KST) Date: Tue, 02 Nov 2004 10:12:09 +0900 From: Soohong Daniel Park In-reply-to: To: v6ops@ops.ietf.org, jordi.palet@consulintel.es Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7BIT Cc: Dhcwg Subject: [dhcwg] RE: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT >I'm not considering DHCP at all. May be need to be further >clarified. Is one more option, but more related, in my opinion, >to very controlled networks where you are sure that DHCP >options are relayed. We can even delete this section if it >creates confusion. *controlled networks* is also important domain for adopting IPv6 widely, especially enterprise network is entirely controlled by network administrator. Also enabling DHCP is quite normal, cheap and a widely deployed scenario. This solution works very well within our enterprise network. >Thoughts from the WG well be needed here ! Which WG do you mean ? DHC WG or V6OPS WG or both ? Daniel (Soohong Daniel Park) Mobile Platform Lab. Samsung Electronics. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 1 20:52:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA02204; Mon, 1 Nov 2004 20:52:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnWg-0000UO-7k; Mon, 01 Nov 2004 20:31:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COnSR-00069q-0b for dhcwg@megatron.ietf.org; Mon, 01 Nov 2004 20:27:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00023 for ; Mon, 1 Nov 2004 20:27:32 -0500 (EST) Received: from mail.consulintel.es ([213.172.48.142] helo=consulintel.es) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COnhP-0002rv-BY for dhcwg@ietf.org; Mon, 01 Nov 2004 20:43:06 -0500 Received: from [10.10.10.102] ([217.126.187.160]) by consulintel.es (consulintel.es [127.0.0.1]) (MDaemon.PRO.v7.2.0.R) with ESMTP id md50000543586.msg for ; Tue, 02 Nov 2004 02:32:23 +0100 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 02 Nov 2004 02:26:46 +0100 From: JORDI PALET MARTINEZ To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Spam-Processed: consulintel.es, Tue, 02 Nov 2004 02:32:23 +0100 (not processed: message from valid local sender) X-MDRemoteIP: 217.126.187.160 X-Return-Path: jordi.palet@consulintel.es X-MDaemon-Deliver-To: dhcwg@ietf.org X-MDAV-Processed: consulintel.es, Tue, 02 Nov 2004 02:32:26 +0100 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org Subject: [dhcwg] Re: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jordi.palet@consulintel.es List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Daniel, My original email was in v6ops, because I think is that WG who should decide about if the document (draft-palet-v6ops-solution-tun-auto-disc-01.txt) need to keep or not the DHCP solution for "controlled networks". I agree with your comment, let's see what the rest of the WG say. Regards, Jordi > De: Soohong Daniel Park > Responder a: owner-v6ops@ops.ietf.org > Fecha: Tue, 02 Nov 2004 10:12:09 +0900 > Para: v6ops@ops.ietf.org, jordi.palet@consulintel.es > CC: Dhcwg > Asunto: RE: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt > >> I'm not considering DHCP at all. May be need to be further >> clarified. Is one more option, but more related, in my opinion, >> to very controlled networks where you are sure that DHCP >> options are relayed. We can even delete this section if it >> creates confusion. > > *controlled networks* is also important domain for adopting > IPv6 widely, especially enterprise network is entirely controlled > by network administrator. Also enabling DHCP is quite normal, > cheap and a widely deployed scenario. This solution works > very well within our enterprise network. > >> Thoughts from the WG well be needed here ! > > Which WG do you mean ? DHC WG or V6OPS WG or both ? > > > Daniel (Soohong Daniel Park) > Mobile Platform Lab. Samsung Electronics. > > > ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 2 01:38:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03047; Tue, 2 Nov 2004 01:38:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COs7k-0000jJ-ET; Tue, 02 Nov 2004 01:26:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COs2u-0006Tl-7c for dhcwg@megatron.ietf.org; Tue, 02 Nov 2004 01:21:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01894 for ; Tue, 2 Nov 2004 01:21:30 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COsHv-0000Z7-Mg for dhcwg@ietf.org; Tue, 02 Nov 2004 01:37:05 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id iA26Kn903948; Tue, 2 Nov 2004 08:20:50 +0200 Date: Tue, 2 Nov 2004 08:20:49 +0200 (EET) From: Pekka Savola To: Soohong Daniel Park In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: v6ops@ops.ietf.org, Dhcwg , jordi.palet@consulintel.es Subject: [dhcwg] RE: DHCP issue in draft-palet-v6ops-solution-tun-auto-disc-01.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, 2 Nov 2004, Soohong Daniel Park wrote: >> I'm not considering DHCP at all. May be need to be further >> clarified. Is one more option, but more related, in my opinion, >> to very controlled networks where you are sure that DHCP >> options are relayed. We can even delete this section if it >> creates confusion. > > *controlled networks* is also important domain for adopting > IPv6 widely, especially enterprise network is entirely controlled > by network administrator. Also enabling DHCP is quite normal, > cheap and a widely deployed scenario. This solution works > very well within our enterprise network. I've no doubt it works within an enterprise network, but because it does not work under all the major scenarios (for example, over dial-ups, ADSLs, over VPN or v6-in-[udp]v4 tunnels, etc. where you don't run DHCP, and not necessarilily even PPP), the real question is: "is DHCP a sufficiently convincing method in a subset of all scenarios for configuration of the tunnel endpoint?" DNS works under every scenario. DHCP provides a slightly more customization per client but I'm sceptical whether this is an actual necessity. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 2 03:43:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27071; Tue, 2 Nov 2004 03:43:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COu5d-0002pB-IV; Tue, 02 Nov 2004 03:32:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COu3U-0001S7-He for dhcwg@megatron.ietf.org; Tue, 02 Nov 2004 03:30:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26016 for ; Tue, 2 Nov 2004 03:30:15 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1COuIY-0003Mr-MV for dhcwg@ietf.org; Tue, 02 Nov 2004 03:45:51 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6J0071RM9ILW@mailout3.samsung.com> for dhcwg@ietf.org; Tue, 02 Nov 2004 17:29:42 +0900 (KST) Received: from ep_mmp2 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6J007M1M24L4@mailout3.samsung.com> for dhcwg@ietf.org; Tue, 02 Nov 2004 17:25:16 +0900 (KST) Received: from SYAM ([107.108.71.123]) by mmp2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTPA id <0I6J002BPM1UM7@mmp2.samsung.com> for dhcwg@ietf.org; Tue, 02 Nov 2004 17:25:16 +0900 (KST) Date: Tue, 02 Nov 2004 13:53:08 +0530 From: Syam Madanapalli Subject: Re: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 To: Ralph Droms , dhcwg@ietf.org Message-id: <016e01c4c0b5$34a9bfd0$7b476c6b@sisodomain.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Mailer: Microsoft Outlook Express 6.00.2800.1409 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <4.3.2.7.2.20041028233131.0276e800@flask.cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7BIT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT > > Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes > > Accept as dhc WG work item? > I am just providing the link to this draft http://www.ietf.org/internet-drafts/draft-madanapalli-dhcpv6-anycast-00.txt Thank you, Syam _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 2 10:06:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27514; Tue, 2 Nov 2004 10:06:43 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP06Z-0002pe-1e; Tue, 02 Nov 2004 09:57:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1COzv2-0006Tb-Jx for dhcwg@megatron.ietf.org; Tue, 02 Nov 2004 09:45:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25262 for ; Tue, 2 Nov 2004 09:45:51 -0500 (EST) Received: from [61.16.238.202] (helo=alice.acmet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP0A5-0003Af-Eo for dhcwg@ietf.org; Tue, 02 Nov 2004 10:01:31 -0500 Received: from gobinath (localhost [127.0.0.1] (may be forged)) by alice.acmet.com (8.11.6/8.11.6) with ESMTP id iA2Dwe315090 for ; Tue, 2 Nov 2004 19:28:40 +0530 From: "Gobinath.S" To: Date: Tue, 2 Nov 2004 19:21:48 -0800 Message-ID: <001f01c4c154$41af2ef0$4e00a8c0@gobinath> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Score: 2.0 (++) X-Scan-Signature: a92270ba83d7ead10c5001bb42ec3221 Subject: [dhcwg] Help_on_FreeBSD_Installation X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1814227150==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1814227150== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0020_01C4C111.338BEEF0" This is a multi-part message in MIME format. ------=_NextPart_000_0020_01C4C111.338BEEF0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit I need to update the FreeBSD with DHCPv6 support. For this requirement I have downloaded the package and source from the following link, http://www.freebsd.org/ports/net.html (dhcp6-20040903a ) But I don't know how to install it. I have searched for the installation help file also. But I didn't get it. Please tell me if any available (as soon as possible). With regards, S.Gobinath. ------=_NextPart_000_0020_01C4C111.338BEEF0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

I need to update the FreeBSD with DHCPv6 support. For = this requirement I have downloaded the package and source from the following = link,

http://www.freebsd.org/por= ts/net.html  (dhcp6-2004= 0903a)

 

But I don’t know how to install = it. I have searched for the installation help file also. But I didn’t get = it.

 

Please tell me if any available (as = soon as possible).

 

With = regards,

S.Gobinath.

 

------=_NextPart_000_0020_01C4C111.338BEEF0-- --===============1814227150== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1814227150==-- From dhcwg-bounces@ietf.org Tue Nov 2 16:30:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16015; Tue, 2 Nov 2004 16:30:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP635-0000qX-19; Tue, 02 Nov 2004 16:18:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP5dS-0006VR-CW for dhcwg@megatron.ietf.org; Tue, 02 Nov 2004 15:52:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10590 for ; Tue, 2 Nov 2004 15:52:08 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP5sd-0005Og-3A for dhcwg@ietf.org; Tue, 02 Nov 2004 16:07:51 -0500 Received: from zrtpd0j7.us.nortel.com (zrtpd0j7.us.nortel.com [47.140.203.25]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id iA2Kpa112750; Tue, 2 Nov 2004 15:51:36 -0500 (EST) Received: by zrtpd0j7.us.nortel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 2 Nov 2004 15:51:35 -0500 Message-ID: <591B780D9676844E8A704B5B013FFE92039A9185@zrc2hxm1.corp.nortel.com> From: "Kuntal Chowdhury" To: Bernie Volz , "'Ralph Droms'" Subject: RE: [dhcwg] BCMCS server option drafts Date: Tue, 2 Nov 2004 15:51:25 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: 9b157e6e8a3799aef911c0bc37fc93a6 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello Bernie, Thanks for the details. Although what you suggest would need more code changes on the DHCP server, I think it would work. I will take this proposal back to 3GPP2 and have this discussed there. Regards, Kuntal >-----Original Message----- >From: Bernie Volz [mailto:volz@cisco.com] >Sent: Friday, October 29, 2004 2:40 PM >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' >Cc: dhcwg@ietf.org >Subject: RE: [dhcwg] BCMCS server option drafts > > >I suspect Ralph meant that you're free to do whatever you want >within the bounds of the standard. This means you need to >define 3GPP2 vendor specific option codes, lengths, and contents. > >So, you might define the following 3GPP2 vendor-specific >information options that would be carried in the DHCPv6 >OPTION_VENDOR_OPTS when the enterprise ID is the 3GPP2 one: > >1. 3GPP2_OPTION_ORO (=1). Same format as the ORO option, but >carries the 3GPP2 option numbers, not DHCPv6 ones. > >2. 3GPP2_OPTION_BCMCS_SERVER_D (=2) (same format as in >draft-chowdhury-dhc-bcmcv6-option-01.txt) > >3. 3GPP2_OPTION_BCMCS_SERVER_A (=3) (same format as in >draft-chowdhury-dhc-bcmcv6-option-01.txt) > >You can then have text that says "A server SHOULD return the >3GPP2 Vendor-Specific Options requested in the >3GPP2_OPTION_ORO option in a OPTION_VENDOR_OPTS with the 3GPP2 >enterprise ID." > >A client would then send: > OPTION_VENDOR_OPTS, length=xx, data=<3ggp2 enterprise >ID>, <3GPP2_OPTION_ORO>, , > <3GPP2_OPTION_BCMCS_SERVER_D >code>,<3GPP2_OPTION_BCMCS_SERVER_A code> > >The server would then respond with: > OPTION_VENDOR_OPTS, length=xx, data<3gpp2 enterprise ID>, > <3GPP2_OPTION_BCMCS_SERVER_D>, , > <3GPP2_OPTION_BCMCS_SERVER_A>, , > >- Bernie > >> -----Original Message----- >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] >> On Behalf Of Kuntal Chowdhury >> Sent: Friday, October 29, 2004 2:44 PM >> To: Ralph Droms >> Cc: dhcwg@ietf.org; Bernie Volz >> Subject: RE: [dhcwg] BCMCS server option drafts >> >> >> Hello Ralph, >> >> >The 3GPP2 standards bodies are free to define any syntax or >semantics >> >for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2 coule >require that a >> >client sends a 3GPP2 OPTION_VENDOR_OPTS request, which the server >> >parses and responds with 3GPP2 OPTION_VENDOR_OPTS containing >> >information for the client. >> >> If I understand what your are saying, the semantics to >> request/respond vendor specific information should also be >> vendor specific. I guess this is well understood to the DHCP >> implementers. It was not clear to me when I read RFC 3115. >> >> The syntax of OPTION_VENDOR_OPTS is defined in 3315: >> >> " >> The encapsulated vendor-specific options field MUST be >encoded as a >> sequence of code/length/value fields of identical format >> to the DHCP >> options field. The option codes are defined by the vendor >> identified >> in the enterprise-number field and are not managed by >> IANA. Each of >> the encapsulated options is formatted as follows: >> >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 >7 8 9 0 1 >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | opt-code | >> option-len | >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> . >> . >> . option-data >> . >> . >> . >> >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> " >> >> So, I don't understand your statement "3GPP2 is free to >> define the syntax of OPTION_VENDOR_OPTS". The syntax of >> OPTION_VENDOR_OPTS when it appears in a request message from >> the client is not clear. >> >> The suggested behavior of a 3GPP2 DHCP server sending all >> 3GPP2 specific information to the client (blindly) is not an >> ideal one. The approach where the client sends specific >> information request and the server returns the requested >> information only is a better one, IMHO. >> >> -Kuntal >> >> >-----Original Message----- >> >From: Ralph Droms [mailto:rdroms@cisco.com] >> >Sent: Friday, October 29, 2004 6:49 AM >> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] >> >Cc: Bernie Volz; dhcwg@ietf.org >> >Subject: RE: [dhcwg] BCMCS server option drafts >> > >> > >> >Kuntal - in both DHCPv4 and DHCPv6, there are no required semantic >> >ties between the message from the client to the server and the >> >response from the server. That is, the client is not required to >> >include any option request information or vendor >identification (I'm >> >using general terms rather than specific options because of the >> >differences between DHCPv4 and >> >DHCPv6) to cause the server to send certain options or >> >vendor-specific information back to the client. The server >> >uses any option request information or vendor identification >> >or vendor-specific information as input ("hints") to the rules >> >the server uses to send a response to the client. The server >> >is free to send information that has not been specifically >> >requested by the client, based on other information the server >> >gleans from the message it receives from the client. >> > >> >So, in the DHCPv6 case, the client is not required to send an >> >OPTION_ORO requesting OPTION_VENDOR_OPTS (although it may do >> >so) and the server, based on other information, is free to >> >send OPTION_VENDOR_OPTS. In a 3GPP2 deployment, if the DHCPv6 >> >server sees a request from a part of the network topology >> >known to be using 3GPP2, the server may assume that the device >> >sending the request is a 3GPP2 device and send 3GPP2 >> >OPTION_VENDOR_OPTS to that client. And, if, for some reason, >> >the client is not a 3GPP2 device, the client can simply ignore >> >the 3GPP2 OPTION_VENDOR_OPTS. >> > >> >The 3GPP2 standards bodies are free to define any syntax or >semantics >> >for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2 coule >require that a >> >client sends a 3GPP2 OPTION_VENDOR_OPTS request, which the server >> >parses and responds with 3GPP2 OPTION_VENDOR_OPTS containing >> >information for the client. >> > >> > >> >- Ralph >> > >> > >> >At 03:08 PM 10/28/2004 -0400, Kuntal Chowdhury wrote: >> >>Hello Bernie, >> >> >> >>Thanks for the response. I guess what is not clear to me is >> >how a DHCP >> >>client requests vendor specific information from the DHCP server: >> >> >> >>" >> >>- A Client includes OPTION_VENDOR_CLASS to identify itself. >> >>- A Client MAY include OPTION_VENDOR_OPTS if it has vendor >specific >> >>data (other than classing information) to communicate. >> >>- A Server includes OPTION_VENDOR_OPTS for matching >> >enterprise IDs (and >> >>class data, if appropriate). This is only REQUIRED if the ORO >> >includes >> >>the OPTION_VENDOR_OPTS code (the ORO doesn't say which >> >vendors; that is >> >>handled by OPTION_VENDOR_CLASS). " >> >> >> >>Second bullet seems to say that the DHCP client includes >> >>OPTION_VENDOR_OPTS to convey some vendor specific >> information to the >> >>DHCP server beside the vendor class info (which is in >> >>OPTION_VENDOR_CLASS). It does not state that OPTION_VENDOR_OPTS is >> >>included in a DHCP message (such as information >> >>request) to REQUEST for vendor specific info from the server. >> >It is true >> >>that opcode for OPTION_VENDOR_OPTS can be included in ORO, >> >but that won't >> >>necessarily indicate to the server which vendor specific >> >codes it needs to >> >>return to the client. Also, the format of the >> >OPTION_VENDOR_OPTS when it >> >>appears in the REQUEST message is unclear. >> >> >> >>A clear description of how to use OPTION_VENDOR_OPTS to >> >request vendor >> >>specific information (such as broadcast server address) will be >> >>required by SDOs such as 3GPP2. >> >> >> >>Regards, >> >>Kuntal >> >> >> >> >> >> >-----Original Message----- >> >> >From: Bernie Volz [mailto:volz@cisco.com] >> >> >Sent: Wednesday, October 27, 2004 8:34 PM >> >> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' >> >> >Cc: dhcwg@ietf.org >> >> >Subject: RE: [dhcwg] BCMCS server option drafts >> >> > >> >> > >> >> >Hi: >> >> > >> >> >I believe the original model was for OPTION_VENDOR_CLASS to be >> >> >similar to DHCPv4 Vendor class identifier option (option >> >60) and for >> >> >OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor Specific >> >> >Information (option 43). >> >> > >> >> >You might refer to draft-ietf-dhc-vendor-03.txt, while for >> >DHCPv4, it >> >> >does have some additional information about how the options >> >might be >> >> >used. That work is modeled on the DHCPv6 options. In >> >particular, see >> >> >section 4: >> >> > >> >> >4. Vendor-Identifying Vendor-Specific Information Option >> >> > >> >> > DHCP clients and servers may use this option to >> exchange vendor- >> >> > specific information. Either party may send this >> >option, as needed. >> >> > While a typical case might be for a client to send the >> >> > Vendor-Identifying Vendor Class option, to elicit a useful >> >> > Vendor-Identifying Vendor-Specific Information Option, >> >there is no >> >> > requirement for such a flow. >> >> > >> >> >It would be good to get general agreement on this as >> you're perhaps >> >> >the first user. And, it would be best to set a "standard" >> >for others >> >> >to follow. >> >> > >> >> >I kind of liked the DHCPv4 model, as it is much easier and >> >clearly to >> >> >understand (and implement for clients and servers): >> >> >- A Client includes OPTION_VENDOR_CLASS to identify itself. >> >> >- A Client MAY include OPTION_VENDOR_OPTS if it has >> vendor specific >> >> >data (other than classing information) to communicate. >> >> >- A Server includes OPTION_VENDOR_OPTS for matching >> enterprise IDs >> >> >(and class data, if appropriate). This is only REQUIRED >> if the ORO >> >> >includes the OPTION_VENDOR_OPTS code (the ORO doesn't say which >> >> >vendors; that is handled by OPTION_VENDOR_CLASS). >> >> >- I'm not sure why a server would ever need to include >> >> >OPTION_VENDOR_CLASS, though perhaps it could tell the >client what >> >> >implementation the server is so that perhaps the client knows it >> >> >could use some extended capabilities? Or, the server could >> >send back >> >> >whatever the client sent to it? >> >> > >> >> >But, as draft-ietf-dhc-vendor-03.tx states, this is not the only >> >> >possible model. >> >> > >> >> >Note that in your case, I would assume that the >> OPTION_VENDOR_CLASS >> >> >would have your enterprise ID and some class information to >> >indicate >> >> >what capabilities the client supports (and therefore the server >> >> >should provide configuration for in the OPTION_VENDOR_OPTS). >> >> > >> >> >So, this is a good issue for the DHC WG to resolve and >> >clarify for a >> >> >future RFC 3315bis. >> >> > >> >> >- Bernie >> >> > >> >> >> -----Original Message----- >> >> >> From: dhcwg-bounces@ietf.org >[mailto:dhcwg-bounces@ietf.org] On >> >> >> Behalf Of Kuntal Chowdhury >> >> >> Sent: Wednesday, October 27, 2004 4:33 PM >> >> >> To: Ralph Droms; volz@cisco.com >> >> >> Cc: dhcwg@ietf.org >> >> >> Subject: RE: [dhcwg] BCMCS server option drafts >> >> >> >> >> >> >> >> >> I have a few questions on the possible use of DHCPv6 >> >> >> OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor >> >> >> specific info: >> >> >> >> >> >> 1. Since the enterprise number is included in >> OPTION_VENDOR_OPTS, >> >> >> will it suffice to use only this option in the >> >information request >> >> >> message from the DHCP client? Is the use of >OPTION_VENDOR_CLASS >> >> >> mandatory while vendor specific options are requested? >> >> >> >> >> >> 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the >> >information >> >> >> request message indicate to the DHCP server that the DHCP >> >client is >> >> >> requesting for some specific vendor specific options? >> >> >> >> >> >> 3. O-R-O has the format where each of requested option >codes are >> >> >> listed in it. However, in OPTION_VENDOR_OPTS the encapsulated >> >> >> vendor-specific options field MUST be encoded as a sequence of >> >> >> code/length/value fields. What value does the DHCP client >> >use while >> >> >> requesting for a vendor specific option? >> >> >> >> >> >> These things are not clearly defined in RFC3315. >> >> >> >> >> >> Regards, >> >> >> Kuntal >> >> >> >> >> >> >-----Original Message----- >> >> >> >From: dhcwg-bounces@ietf.org >[mailto:dhcwg-bounces@ietf.org] On >> >> >> >Behalf Of Ralph Droms >> >> >> >Sent: Wednesday, October 27, 2004 2:29 PM >> >> >> >To: dhcwg@ietf.org >> >> >> >Subject: RE: [dhcwg] BCMCS server option drafts >> >> >> > >> >> >> > >> >> >> > >> >> >> >What about the deployment issue? The 3GGP2 >> specification will be >> >> >> >ratified in November, with deployment following soon. Some >> >> >> >service providers already have DHCP servers in place >> that must be >> >> >updated for >> >> >> >any new options. The options defined in the current >drafts can >> >> >> >likely be supported without code changes to existing servers, >> >> >> >allowing for faster deployment. Use of a VIVSO >> sub-option would >> >> >> >require code changes to existing servers. How long would >> >> >it take to >> >> >> >deploy DHCP server that can support VIVSO? >> >> >> > >> >> >> >BTW, we need more discussion of this issue *soon* due to >> >the time >> >> >> >constraints of the upcoming 3GPP2 standards process and >> >> >> >deployment. >> >> >> > >> >> >> >- Ralph >> >> >> > >> >> >> >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: >> >> >> >>Personally, I'd like to see the DHCPv4 VIVSO get deployed >> >> >> and pushing >> >> >> >>these options to using it would be a step at making this >> >> >> >happen (as one >> >> >> >>would expect 3GPP2 vendors to have some significant >> >input to the >> >> >> >>decisions of DHCP server vendors). >> >> >> >> >> >> >> >>It also means that 3GPP2 is free to define other VIVSO >> >> >> options in the >> >> >> >>future within their own forum and need not go to the IETF >> >> >> >(and DHC WG). >> >> >> >>I suspect that this would provide much faster deployment >> >> >for them in >> >> >> >>the future. >> >> >> >> >> >> >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS >> >> >> >are already >> >> >> >>there for DHCPv6. >> >> >> >> >> >> >> >>BTW, 3GPP2 already has an enterprise-id number: >> >> >> >> >> >> >> >>5535 >> >> >> >> 3rd Generation Partnership Project 2 (3GPP2) >> >> >> >> Allen Long >> >> >> >> along@cisco.com >> >> >> >> >> >> >> >>So, they'd be good to go! >> >> >> >> >> >> >> >>- Bernie >> >> >> >> >> >> >> >> > -----Original Message----- >> >> >> >> > From: dhcwg-bounces@ietf.org >> [mailto:dhcwg-bounces@ietf.org] >> >> >> >> > On Behalf Of Ralph Droms >> >> >> >> > Sent: Thursday, October 21, 2004 2:35 PM >> >> >> >> > To: dhcwg@ietf.org >> >> >> >> > Subject: [dhcwg] BCMCS server option drafts >> >> >> >> > >> >> >> >> > >> >> >> >> > We need to have a short WG conversation about two options >> >> >> >that were >> >> >> >> > discussed at the WG meeting in San Diego. The >> >outcome of the >> >> >> >> > conversation will be to determine consensus about taking >> >> >> on these >> >> >> >> > two >> >> >> >> > drafts: >> >> >> >> > >> >> >> >> > draft-chowdhury-dhc-bcmcv4-option-01.txt >> >> >> >> > draft-chowdhury-dhc-bcmcv6-option-01.txt >> >> >> >> > >> >> >> >> > as dhc WG work items or recommending that 3GPP2 define >> >> >> >> > vendor-identifying vendor-specific option (VIVSO; >> option code >> >> >> >> > 125) sub-options to carry the information described in >> >> >> the drafts. >> >> >> >> > >> >> >> >> > If the WG consensus is to take on the drafts as WG >> >work items >> >> >> >> > drafts, are they acceptable as currently published? >> >> >> >> > >> >> >> >> > Because of the time constraints imposed by the 3GPP2 >> >> >> schedule, I'm >> >> >> >> > going to cut off discussion on this topic next Thursday, >> >> >> >10/28, and >> >> >> >> > determine WG consensus at that time. >> >> >> >> > >> >> >> >> > Here are some considerations for discussion: >> >> >> >> > >> >> >> >> > 3GPP2 has defined some vendor-specific sub-options, for >> >> >> >example, to >> >> >> >> > identify a MIP home agent for the DHCP client. >> >> >> >> > >> >> >> >> > A 3GPP2 client needs to specify to the DHCP server which >> >> >> >parameters >> >> >> >> > it needs - specifically, whether it needs to receive >> >the BCMCS >> >> >> >> > servers. If the current drafts are adopted, the client >> >> >> can simply >> >> >> >> > use the parameter request list option (option code >> >55) for the >> >> >> >> > request. If a VIVSO sub-option is used, 3GPP2 would >> >> >> also define a >> >> >> >> > parameter request list sub-option. >> >> >> >> > >> >> >> >> > There is a deployment issue, as some service providers >> >> >> >already have >> >> >> >> > DHCP servers in place that must be updated for any new >> >> >> >options. Is >> >> >> >> > it the case that the options defined in the current >> >> >drafts can be >> >> >> >> > supported without code changes to existing servers? Use >> >> >> >of a VIVSO >> >> >> >> > sub-option would require code changes to existing servers. >> >> >> > How long >> >> >> >> > would it take to deploy DHCP server that can >support VIVSO. >> >> >> >> > >> >> >> >> > BCMCS may be adopted across multiple technologies, so the >> >> >> >options in >> >> >> >> > the current drafts would not be specific to 3GPP2. >> >> >However, the >> >> >> >> > BCMCS specification has not adopted by other standards, >> >> >> yet, so we >> >> >> >> > may need to define additional options for related >> >> >> services in the >> >> >> >> > future if those services are not interoperable with the >> >> >> >3GPP2 BCMCS >> >> >> >> > service. >> >> >> >> > >> >> >> >> > CableLabs has one option with sub-options (RFC 3495) >> >> >rather than >> >> >> >> > multiple options because: >> >> >> >> > * wanted to avoid exhaustion of DHCP option code space; >> >> >> >perhaps less >> >> >> >> > of an issue with option code reclassification >> >> >> >> > * would have used VIVSO if available >> >> >> >> > * use of VIVSO with sub-options would give 3GPP2 freedom >> >> >> >to define new >> >> >> >> > sub-options on demand >> >> >> >> > Do these considerations have an impact on our decision >> >> >> >about how to >> >> >> >> > proceed with the 3GPP2 options? >> >> >> >> > >> >> >> >> > - 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 >> >> >> > >> >> >> > >> >> >> >> >> >> _______________________________________________ >> >> >> 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 >> > >> > >> > >> >> _______________________________________________ >> 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-bounces@ietf.org Tue Nov 2 17:21:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA23097; Tue, 2 Nov 2004 17:21:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6cR-00032F-S9; Tue, 02 Nov 2004 16:55:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP6GT-0005at-Gd for dhcwg@megatron.ietf.org; Tue, 02 Nov 2004 16:32:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16515 for ; Tue, 2 Nov 2004 16:32:27 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP6Ve-0006iu-65 for dhcwg@ietf.org; Tue, 02 Nov 2004 16:48:11 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id 5B04915218; Wed, 3 Nov 2004 06:32:23 +0900 (JST) Date: Wed, 03 Nov 2004 06:32:26 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: "Gobinath.S" Subject: Re: [dhcwg] Help_on_FreeBSD_Installation In-Reply-To: <001f01c4c154$41af2ef0$4e00a8c0@gobinath> References: <001f01c4c154$41af2ef0$4e00a8c0@gobinath> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Tue, 2 Nov 2004 19:21:48 -0800, >>>>> "Gobinath.S" said: > I need to update the FreeBSD with DHCPv6 support. For this requirement I > have downloaded the package and source from the following link, > http://www.freebsd.org/ports/net.html (dhcp6-20040903a > ) > But I don't know how to install it. I have searched for the installation > help file also. But I didn't get it. > Please tell me if any available (as soon as possible). If you are familiar with the FreeBSD ports collection (though I suspect not), you can simply go down to ports/net/dhcp6 and type 'make install' as root. In any event, I'm afraid this (the IETF dhcwg ML) is not an appropriate place to ask such implementation-specific questions. I'd recommend freebsd-net@freebsd.org or snap-users@kame.net for further questions. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 2 17:54:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26056; Tue, 2 Nov 2004 17:54:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP7O3-0001vM-He; Tue, 02 Nov 2004 17:44:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CP7Cr-0001gG-4F for dhcwg@megatron.ietf.org; Tue, 02 Nov 2004 17:32:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24019 for ; Tue, 2 Nov 2004 17:32:46 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CP7S2-0000Kj-3h for dhcwg@ietf.org; Tue, 02 Nov 2004 17:48:31 -0500 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-5.cisco.com with ESMTP; 02 Nov 2004 14:32:35 -0800 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id iA2MWAVD009878; Tue, 2 Nov 2004 14:32:13 -0800 (PST) Received: from volzw2k ([161.44.65.208]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMT14795; Tue, 2 Nov 2004 17:32:09 -0500 (EST) From: "Bernie Volz" To: "'Kuntal Chowdhury'" , "'Ralph Droms'" Subject: RE: [dhcwg] BCMCS server option drafts Date: Tue, 2 Nov 2004 17:32:09 -0500 Organization: Cisco Message-ID: <003901c4c12b$ca8b5560$d0412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <591B780D9676844E8A704B5B013FFE92039A9185@zrc2hxm1.corp.nortel.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ed37b243475b9c4ffb6a3f90050819d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: Yes, it is more complex. That's why Ralph's suggestion to let other information, such as the = network location of the client (ie, link or prefix it is connected to), control whether or not the 3GPP2 Vendor-Specific Information option is sent to = the client is simpler -- and clients that don't understand it will ignore = this data. I think you should propose a way for the client to request the = information, but ALLOW servers to simply be configured to send it (perhaps in = specific cases, such as based on client network location). This way, servers without the added 3GPP2 logic can still be used -- = they'll always return it (or return it for some subset of clients). - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Kuntal Chowdhury > Sent: Tuesday, November 02, 2004 3:51 PM > To: Bernie Volz; 'Ralph Droms' > Cc: dhcwg@ietf.org > Subject: RE: [dhcwg] BCMCS server option drafts >=20 >=20 > Hello Bernie, >=20 > Thanks for the details. Although what you suggest would need=20 > more code changes on the DHCP server, I think it would work.=20 > I will take this proposal back to 3GPP2 and have this discussed there. >=20 > Regards, > Kuntal >=20 > >-----Original Message----- > >From: Bernie Volz [mailto:volz@cisco.com] > >Sent: Friday, October 29, 2004 2:40 PM > >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' > >Cc: dhcwg@ietf.org > >Subject: RE: [dhcwg] BCMCS server option drafts > > > > > >I suspect Ralph meant that you're free to do whatever you want > >within the bounds of the standard. This means you need to=20 > >define 3GPP2 vendor specific option codes, lengths, and contents. > > > >So, you might define the following 3GPP2 vendor-specific > >information options that would be carried in the DHCPv6=20 > >OPTION_VENDOR_OPTS when the enterprise ID is the 3GPP2 one: > > > >1. 3GPP2_OPTION_ORO (=3D1). Same format as the ORO option, but > >carries the 3GPP2 option numbers, not DHCPv6 ones. > > > >2. 3GPP2_OPTION_BCMCS_SERVER_D (=3D2) (same format as in > >draft-chowdhury-dhc-bcmcv6-option-01.txt) > > > >3. 3GPP2_OPTION_BCMCS_SERVER_A (=3D3) (same format as in > >draft-chowdhury-dhc-bcmcv6-option-01.txt) > > > >You can then have text that says "A server SHOULD return the > >3GPP2 Vendor-Specific Options requested in the=20 > >3GPP2_OPTION_ORO option in a OPTION_VENDOR_OPTS with the 3GPP2=20 > >enterprise ID." > > > >A client would then send: > > OPTION_VENDOR_OPTS, length=3Dxx, data=3D<3ggp2 enterprise > >ID>, <3GPP2_OPTION_ORO>, , > > <3GPP2_OPTION_BCMCS_SERVER_D > >code>,<3GPP2_OPTION_BCMCS_SERVER_A code> > > > >The server would then respond with: > > OPTION_VENDOR_OPTS, length=3Dxx, data<3gpp2 enterprise ID>,=20 > > <3GPP2_OPTION_BCMCS_SERVER_D>, , > > <3GPP2_OPTION_BCMCS_SERVER_A>, , > > > >- Bernie > > > >> -----Original Message----- > >> From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On=20 > >> Behalf Of Kuntal Chowdhury > >> Sent: Friday, October 29, 2004 2:44 PM > >> To: Ralph Droms > >> Cc: dhcwg@ietf.org; Bernie Volz > >> Subject: RE: [dhcwg] BCMCS server option drafts > >>=20 > >>=20 > >> Hello Ralph, > >>=20 > >> >The 3GPP2 standards bodies are free to define any syntax or > >semantics > >> >for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2 coule > >require that a > >> >client sends a 3GPP2 OPTION_VENDOR_OPTS request, which the server > >> >parses and responds with 3GPP2 OPTION_VENDOR_OPTS containing=20 > >> >information for the client. > >>=20 > >> If I understand what your are saying, the semantics to=20 > >> request/respond vendor specific information should also be vendor=20 > >> specific. I guess this is well understood to the DHCP=20 > implementers.=20 > >> It was not clear to me when I read RFC 3115. > >>=20 > >> The syntax of OPTION_VENDOR_OPTS is defined in 3315: > >>=20 > >> " > >> The encapsulated vendor-specific options field MUST be > >encoded as a > >> sequence of code/length/value fields of identical format to the=20 > >> DHCP > >> options field. The option codes are defined by the vendor > >> identified > >> in the enterprise-number field and are not managed by=20 > >> IANA. Each of > >> the encapsulated options is formatted as follows: > >>=20 > >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 > >7 8 9 0 1 > >> =20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> | opt-code | =20 > >> option-len | > >> =20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> . =20 > >> . > >> . option-data =20 > >> . > >> . =20 > >> . > >> =20 > >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >> " > >>=20 > >> So, I don't understand your statement "3GPP2 is free to define the=20 > >> syntax of OPTION_VENDOR_OPTS". The syntax of=20 > OPTION_VENDOR_OPTS when=20 > >> it appears in a request message from the client is not clear. > >>=20 > >> The suggested behavior of a 3GPP2 DHCP server sending all 3GPP2=20 > >> specific information to the client (blindly) is not an=20 > ideal one. The=20 > >> approach where the client sends specific information=20 > request and the=20 > >> server returns the requested information only is a better=20 > one, IMHO. > >>=20 > >> -Kuntal > >>=20 > >> >-----Original Message----- > >> >From: Ralph Droms [mailto:rdroms@cisco.com] > >> >Sent: Friday, October 29, 2004 6:49 AM > >> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH] > >> >Cc: Bernie Volz; dhcwg@ietf.org > >> >Subject: RE: [dhcwg] BCMCS server option drafts > >> > > >> > > >> >Kuntal - in both DHCPv4 and DHCPv6, there are no required semantic > >> >ties between the message from the client to the server and the=20 > >> >response from the server. That is, the client is not required to=20 > >> >include any option request information or vendor=20 > >identification (I'm > >> >using general terms rather than specific options because of the > >> >differences between DHCPv4 and > >> >DHCPv6) to cause the server to send certain options or > >> >vendor-specific information back to the client. The server=20 > >> >uses any option request information or vendor identification=20 > >> >or vendor-specific information as input ("hints") to the rules=20 > >> >the server uses to send a response to the client. The server=20 > >> >is free to send information that has not been specifically=20 > >> >requested by the client, based on other information the server=20 > >> >gleans from the message it receives from the client. > >> > > >> >So, in the DHCPv6 case, the client is not required to send an > >> >OPTION_ORO requesting OPTION_VENDOR_OPTS (although it may do > >> >so) and the server, based on other information, is free to > >> >send OPTION_VENDOR_OPTS. In a 3GPP2 deployment, if the DHCPv6=20 > >> >server sees a request from a part of the network topology=20 > >> >known to be using 3GPP2, the server may assume that the device=20 > >> >sending the request is a 3GPP2 device and send 3GPP2=20 > >> >OPTION_VENDOR_OPTS to that client. And, if, for some reason,=20 > >> >the client is not a 3GPP2 device, the client can simply ignore=20 > >> >the 3GPP2 OPTION_VENDOR_OPTS. > >> > > >> >The 3GPP2 standards bodies are free to define any syntax or > >semantics > >> >for the 3GPP2 OPTION_VENDOR_OPTS. So, if 3GPP2 coule > >require that a > >> >client sends a 3GPP2 OPTION_VENDOR_OPTS request, which the server > >> >parses and responds with 3GPP2 OPTION_VENDOR_OPTS containing=20 > >> >information for the client. > >> > > >> > > >> >- Ralph > >> > > >> > > >> >At 03:08 PM 10/28/2004 -0400, Kuntal Chowdhury wrote: > >> >>Hello Bernie, > >> >> > >> >>Thanks for the response. I guess what is not clear to me is > >> >how a DHCP > >> >>client requests vendor specific information from the DHCP server: > >> >> > >> >>" > >> >>- A Client includes OPTION_VENDOR_CLASS to identify itself. > >> >>- A Client MAY include OPTION_VENDOR_OPTS if it has vendor > >specific > >> >>data (other than classing information) to communicate. > >> >>- A Server includes OPTION_VENDOR_OPTS for matching > >> >enterprise IDs (and > >> >>class data, if appropriate). This is only REQUIRED if the ORO > >> >includes > >> >>the OPTION_VENDOR_OPTS code (the ORO doesn't say which > >> >vendors; that is > >> >>handled by OPTION_VENDOR_CLASS). " > >> >> > >> >>Second bullet seems to say that the DHCP client includes > >> >>OPTION_VENDOR_OPTS to convey some vendor specific > >> information to the > >> >>DHCP server beside the vendor class info (which is in=20 > >> >>OPTION_VENDOR_CLASS). It does not state that=20 > OPTION_VENDOR_OPTS is=20 > >> >>included in a DHCP message (such as information > >> >>request) to REQUEST for vendor specific info from the server. > >> >It is true > >> >>that opcode for OPTION_VENDOR_OPTS can be included in ORO, > >> >but that won't > >> >>necessarily indicate to the server which vendor specific > >> >codes it needs to > >> >>return to the client. Also, the format of the > >> >OPTION_VENDOR_OPTS when it > >> >>appears in the REQUEST message is unclear. > >> >> > >> >>A clear description of how to use OPTION_VENDOR_OPTS to > >> >request vendor > >> >>specific information (such as broadcast server address) will be > >> >>required by SDOs such as 3GPP2. > >> >> > >> >>Regards, > >> >>Kuntal > >> >> > >> >> > >> >> >-----Original Message----- > >> >> >From: Bernie Volz [mailto:volz@cisco.com] > >> >> >Sent: Wednesday, October 27, 2004 8:34 PM > >> >> >To: Chowdhury, Kuntal [RICH1:2H18:EXCH]; 'Ralph Droms' > >> >> >Cc: dhcwg@ietf.org > >> >> >Subject: RE: [dhcwg] BCMCS server option drafts > >> >> > > >> >> > > >> >> >Hi: > >> >> > > >> >> >I believe the original model was for OPTION_VENDOR_CLASS to be > >> >> >similar to DHCPv4 Vendor class identifier option (option > >> >60) and for > >> >> >OPTION_VENDOR_OPTS to be similar to DHCPv4 Vendor Specific > >> >> >Information (option 43). > >> >> > > >> >> >You might refer to draft-ietf-dhc-vendor-03.txt, while for > >> >DHCPv4, it > >> >> >does have some additional information about how the options > >> >might be > >> >> >used. That work is modeled on the DHCPv6 options. In > >> >particular, see > >> >> >section 4: > >> >> > > >> >> >4. Vendor-Identifying Vendor-Specific Information Option > >> >> > > >> >> > DHCP clients and servers may use this option to > >> exchange vendor- > >> >> > specific information. Either party may send this > >> >option, as needed. > >> >> > While a typical case might be for a client to send the > >> >> > Vendor-Identifying Vendor Class option, to elicit a useful > >> >> > Vendor-Identifying Vendor-Specific Information Option, > >> >there is no > >> >> > requirement for such a flow. > >> >> > > >> >> >It would be good to get general agreement on this as > >> you're perhaps > >> >> >the first user. And, it would be best to set a "standard" > >> >for others > >> >> >to follow. > >> >> > > >> >> >I kind of liked the DHCPv4 model, as it is much easier and > >> >clearly to > >> >> >understand (and implement for clients and servers): > >> >> >- A Client includes OPTION_VENDOR_CLASS to identify itself. > >> >> >- A Client MAY include OPTION_VENDOR_OPTS if it has > >> vendor specific > >> >> >data (other than classing information) to communicate. > >> >> >- A Server includes OPTION_VENDOR_OPTS for matching > >> enterprise IDs > >> >> >(and class data, if appropriate). This is only REQUIRED > >> if the ORO > >> >> >includes the OPTION_VENDOR_OPTS code (the ORO doesn't=20 > say which=20 > >> >> >vendors; that is handled by OPTION_VENDOR_CLASS). > >> >> >- I'm not sure why a server would ever need to include > >> >> >OPTION_VENDOR_CLASS, though perhaps it could tell the=20 > >client what > >> >> >implementation the server is so that perhaps the=20 > client knows it > >> >> >could use some extended capabilities? Or, the server could=20 > >> >send back > >> >> >whatever the client sent to it? > >> >> > > >> >> >But, as draft-ietf-dhc-vendor-03.tx states, this is=20 > not the only > >> >> >possible model. > >> >> > > >> >> >Note that in your case, I would assume that the > >> OPTION_VENDOR_CLASS > >> >> >would have your enterprise ID and some class information to > >> >indicate > >> >> >what capabilities the client supports (and therefore the server > >> >> >should provide configuration for in the OPTION_VENDOR_OPTS). > >> >> > > >> >> >So, this is a good issue for the DHC WG to resolve and > >> >clarify for a > >> >> >future RFC 3315bis. > >> >> > > >> >> >- Bernie > >> >> > > >> >> >> -----Original Message----- > >> >> >> From: dhcwg-bounces@ietf.org > >[mailto:dhcwg-bounces@ietf.org] On > >> >> >> Behalf Of Kuntal Chowdhury > >> >> >> Sent: Wednesday, October 27, 2004 4:33 PM > >> >> >> To: Ralph Droms; volz@cisco.com > >> >> >> Cc: dhcwg@ietf.org > >> >> >> Subject: RE: [dhcwg] BCMCS server option drafts > >> >> >> > >> >> >> > >> >> >> I have a few questions on the possible use of DHCPv6 > >> >> >> OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS to request vendor=20 > >> >> >> specific info: > >> >> >> > >> >> >> 1. Since the enterprise number is included in > >> OPTION_VENDOR_OPTS, > >> >> >> will it suffice to use only this option in the > >> >information request > >> >> >> message from the DHCP client? Is the use of > >OPTION_VENDOR_CLASS > >> >> >> mandatory while vendor specific options are requested? > >> >> >> > >> >> >> 2. Does the mere inclusion of OPTION_VENDOR_OPTS in the > >> >information > >> >> >> request message indicate to the DHCP server that the DHCP > >> >client is > >> >> >> requesting for some specific vendor specific options? > >> >> >> > >> >> >> 3. O-R-O has the format where each of requested option > >codes are > >> >> >> listed in it. However, in OPTION_VENDOR_OPTS the encapsulated > >> >> >> vendor-specific options field MUST be encoded as a=20 > sequence of=20 > >> >> >> code/length/value fields. What value does the DHCP client > >> >use while > >> >> >> requesting for a vendor specific option? > >> >> >> > >> >> >> These things are not clearly defined in RFC3315. > >> >> >> > >> >> >> Regards, > >> >> >> Kuntal > >> >> >> > >> >> >> >-----Original Message----- > >> >> >> >From: dhcwg-bounces@ietf.org > >[mailto:dhcwg-bounces@ietf.org] On > >> >> >> >Behalf Of Ralph Droms > >> >> >> >Sent: Wednesday, October 27, 2004 2:29 PM > >> >> >> >To: dhcwg@ietf.org > >> >> >> >Subject: RE: [dhcwg] BCMCS server option drafts > >> >> >> > > >> >> >> > > >> >> >> > > >> >> >> >What about the deployment issue? The 3GGP2 > >> specification will be > >> >> >> >ratified in November, with deployment following soon. Some=20 > >> >> >> >service providers already have DHCP servers in place > >> that must be > >> >> >updated for > >> >> >> >any new options. The options defined in the current > >drafts can > >> >> >> >likely be supported without code changes to=20 > existing servers, > >> >> >> >allowing for faster deployment. Use of a VIVSO > >> sub-option would > >> >> >> >require code changes to existing servers. How long would > >> >> >it take to > >> >> >> >deploy DHCP server that can support VIVSO? > >> >> >> > > >> >> >> >BTW, we need more discussion of this issue *soon* due to > >> >the time > >> >> >> >constraints of the upcoming 3GPP2 standards process and > >> >> >> >deployment. > >> >> >> > > >> >> >> >- Ralph > >> >> >> > > >> >> >> >At 04:12 PM 10/21/2004 -0400, Bernie Volz wrote: > >> >> >> >>Personally, I'd like to see the DHCPv4 VIVSO get deployed > >> >> >> and pushing > >> >> >> >>these options to using it would be a step at making this > >> >> >> >happen (as one > >> >> >> >>would expect 3GPP2 vendors to have some significant > >> >input to the > >> >> >> >>decisions of DHCP server vendors). > >> >> >> >> > >> >> >> >>It also means that 3GPP2 is free to define other VIVSO > >> >> >> options in the > >> >> >> >>future within their own forum and need not go to the IETF > >> >> >> >(and DHC WG). > >> >> >> >>I suspect that this would provide much faster deployment > >> >> >for them in > >> >> >> >>the future. > >> >> >> >> > >> >> >> >>Also, the DHCPv6 OPTION_VENDOR_CLASS and OPTION_VENDOR_OPTS > >> >> >> >are already > >> >> >> >>there for DHCPv6. > >> >> >> >> > >> >> >> >>BTW, 3GPP2 already has an enterprise-id number: > >> >> >> >> > >> >> >> >>5535 > >> >> >> >> 3rd Generation Partnership Project 2 (3GPP2) > >> >> >> >> Allen Long > >> >> >> >> along@cisco.com > >> >> >> >> > >> >> >> >>So, they'd be good to go! > >> >> >> >> > >> >> >> >>- Bernie > >> >> >> >> > >> >> >> >> > -----Original Message----- > >> >> >> >> > From: dhcwg-bounces@ietf.org > >> [mailto:dhcwg-bounces@ietf.org] > >> >> >> >> > On Behalf Of Ralph Droms > >> >> >> >> > Sent: Thursday, October 21, 2004 2:35 PM > >> >> >> >> > To: dhcwg@ietf.org > >> >> >> >> > Subject: [dhcwg] BCMCS server option drafts > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > We need to have a short WG conversation about=20 > two options > >> >> >> >that were > >> >> >> >> > discussed at the WG meeting in San Diego. The > >> >outcome of the > >> >> >> >> > conversation will be to determine consensus about taking > >> >> >> on these > >> >> >> >> > two > >> >> >> >> > drafts: > >> >> >> >> > > >> >> >> >> > draft-chowdhury-dhc-bcmcv4-option-01.txt > >> >> >> >> > draft-chowdhury-dhc-bcmcv6-option-01.txt > >> >> >> >> > > >> >> >> >> > as dhc WG work items or recommending that 3GPP2 define > >> >> >> >> > vendor-identifying vendor-specific option (VIVSO; > >> option code > >> >> >> >> > 125) sub-options to carry the information described in > >> >> >> the drafts. > >> >> >> >> > > >> >> >> >> > If the WG consensus is to take on the drafts as WG > >> >work items > >> >> >> >> > drafts, are they acceptable as currently published? > >> >> >> >> > > >> >> >> >> > Because of the time constraints imposed by the 3GPP2 > >> >> >> schedule, I'm > >> >> >> >> > going to cut off discussion on this topic next Thursday, > >> >> >> >10/28, and > >> >> >> >> > determine WG consensus at that time. > >> >> >> >> > > >> >> >> >> > Here are some considerations for discussion: > >> >> >> >> > > >> >> >> >> > 3GPP2 has defined some vendor-specific sub-options, for > >> >> >> >example, to > >> >> >> >> > identify a MIP home agent for the DHCP client. > >> >> >> >> > > >> >> >> >> > A 3GPP2 client needs to specify to the DHCP server which > >> >> >> >parameters > >> >> >> >> > it needs - specifically, whether it needs to receive > >> >the BCMCS > >> >> >> >> > servers. If the current drafts are adopted, the client > >> >> >> can simply > >> >> >> >> > use the parameter request list option (option code > >> >55) for the > >> >> >> >> > request. If a VIVSO sub-option is used, 3GPP2 would > >> >> >> also define a > >> >> >> >> > parameter request list sub-option. > >> >> >> >> > > >> >> >> >> > There is a deployment issue, as some service providers > >> >> >> >already have > >> >> >> >> > DHCP servers in place that must be updated for any new > >> >> >> >options. Is > >> >> >> >> > it the case that the options defined in the current > >> >> >drafts can be > >> >> >> >> > supported without code changes to existing servers? Use > >> >> >> >of a VIVSO > >> >> >> >> > sub-option would require code changes to=20 > existing servers. > >> >> >> > How long > >> >> >> >> > would it take to deploy DHCP server that can > >support VIVSO. > >> >> >> >> > > >> >> >> >> > BCMCS may be adopted across multiple=20 > technologies, so the > >> >> >> >options in > >> >> >> >> > the current drafts would not be specific to 3GPP2. > >> >> >However, the > >> >> >> >> > BCMCS specification has not adopted by other standards, > >> >> >> yet, so we > >> >> >> >> > may need to define additional options for related > >> >> >> services in the > >> >> >> >> > future if those services are not interoperable with the > >> >> >> >3GPP2 BCMCS > >> >> >> >> > service. > >> >> >> >> > > >> >> >> >> > CableLabs has one option with sub-options (RFC 3495) > >> >> >rather than > >> >> >> >> > multiple options because: > >> >> >> >> > * wanted to avoid exhaustion of DHCP option code space; > >> >> >> >perhaps less > >> >> >> >> > of an issue with option code reclassification > >> >> >> >> > * would have used VIVSO if available > >> >> >> >> > * use of VIVSO with sub-options would give 3GPP2 freedom > >> >> >> >to define new > >> >> >> >> > sub-options on demand > >> >> >> >> > Do these considerations have an impact on our decision > >> >> >> >about how to > >> >> >> >> > proceed with the 3GPP2 options? > >> >> >> >> > > >> >> >> >> > - Ralph > >> >> >> >> > > >> >> >> >> > > >> >> >> >> > _______________________________________________ > >> >> >> >> > dhcwg mailing list > >> >> >> >> > dhcwg@ietf.org > >https://www1.ietf.org/mailman/listinfo/dhcwg > >> >> >> >> > > >> >>=20 > >>> > > >> >> >> > > >> >> >> >_______________________________________________ > >> >> >> >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 > >> >> >> > >> >> > > >> >> > > >> >> > > >> >> > >> >>_______________________________________________ > >> >>dhcwg mailing list > >> >>dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg > >> > > >> > > >> > > >>=20 > >> _______________________________________________ > >> dhcwg mailing list > >> dhcwg@ietf.org > >> https://www1.ietf.org/mailman/listinfo/dhcwg > >>=20 > > > > > > >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 4 13:55:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21556; Thu, 4 Nov 2004 13:55:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmeT-0004Nf-8b; Thu, 04 Nov 2004 13:48:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPmVx-00029s-4m for dhcwg@megatron.ietf.org; Thu, 04 Nov 2004 13:39:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20233 for ; Thu, 4 Nov 2004 13:39:13 -0500 (EST) Received: from zeus.umich.mx ([148.216.1.2]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPmlW-0003WO-83 for dhcwg@ietf.org; Thu, 04 Nov 2004 13:55:22 -0500 Received: from zeus.umich.mx (zeus.umich.mx [148.216.1.2]) by zeus.umich.mx with ESMTP (8.11.1/8.7.1) id iA4IbDb21825; Thu, 4 Nov 2004 12:37:13 -0600 (CST) Message-ID: <418A74F6.4010701@zeus.umich.mx> Date: Thu, 04 Nov 2004 12:29:10 -0600 From: "Juan J. Flores" Organization: Universidad Michoacana User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.0.1) Gecko/20020920 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Subject: [dhcwg] DHCP and MAC Addresses X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Dear all, Is there a way to have a DHCP server provide service only to a subset of computers in the local network? We assume we know the MAC Addresses of those computers. Using host is not nice, since it would tie computers to IPs and we'd be giving away the D (dynamic) from DHCP. Any help will be greatly appreciated. Best regards, Juan Flores _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Thu Nov 4 14:23:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24293; Thu, 4 Nov 2004 14:23:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPn7C-0001vN-HU; Thu, 04 Nov 2004 14:17:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPn4B-0000xD-GX for dhcwg@megatron.ietf.org; Thu, 04 Nov 2004 14:14:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23320 for ; Thu, 4 Nov 2004 14:14:38 -0500 (EST) Received: from endeavor.poss.com ([198.70.184.137] helo=smtp.poss.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPnJl-0004Ki-J8 for dhcwg@ietf.org; Thu, 04 Nov 2004 14:30:45 -0500 Received: from KNOLLXPLT (ws-194065.va.rr.com [24.28.194.65]) by endeavor.poss.com (iPlanet Messaging Server 5.2 HotFix 1.16 (built May 14 2003)) with ESMTPA id <0I6O006YS5FI8M@endeavor.poss.com> for dhcwg@ietf.org; Thu, 04 Nov 2004 14:14:06 -0500 (EST) Date: Thu, 04 Nov 2004 14:14:06 -0500 From: "Kevin A. Noll" Subject: RE: [dhcwg] DHCP and MAC Addresses In-reply-to: <418A74F6.4010701@zeus.umich.mx> To: "'Juan J. Flores'" , dhcwg@ietf.org Message-id: <008501c4c2a2$74413ee0$6c0315ac@KNOLLXPLT> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook, Build 10.0.6626 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: 7BIT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Someone correct me if I'm wrong, but I'm pretty sure that this is not directly addressed by any of the current RFCs or drafts. This actually is intentional since one of the requirements of DHCP is not to dictate policy, but to provide a mechanism (see RFC 2131, section 1.6). By picking and choosing which MAC addresses you service via DHCP, you are implementing policy. That said, how to accomplish your goal depends on the DHCP implementation that you are using. There are several DHCP server implementations that can do what you are seeking to accomplish. --kan-- -- Kevin A. Noll, KD4WOZ CCIE, CCDP Perfect Order, Inc. Kevin.Noll@perfectorder.com 717-796-1936 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Juan J. Flores Sent: Thursday, November 04, 2004 1:29 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCP and MAC Addresses Dear all, Is there a way to have a DHCP server provide service only to a subset of computers in the local network? We assume we know the MAC Addresses of those computers. Using host is not nice, since it would tie computers to IPs and we'd be giving away the D (dynamic) from DHCP. Any help will be greatly appreciated. Best regards, Juan Flores _______________________________________________ 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-bounces@ietf.org Thu Nov 4 16:41:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09176; Thu, 4 Nov 2004 16:41:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpEV-00007J-SY; Thu, 04 Nov 2004 16:33:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPoyu-0002Vt-Pd for dhcwg@megatron.ietf.org; Thu, 04 Nov 2004 16:17:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06151 for ; Thu, 4 Nov 2004 16:17:16 -0500 (EST) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPpEQ-00077e-9W for dhcwg@ietf.org; Thu, 04 Nov 2004 16:33:26 -0500 Received: from [206.172.52.116] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.34) id 1CPoy5-0005JN-1I; Thu, 04 Nov 2004 13:16:31 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Thu, 4 Nov 2004 13:15:58 -0800 Message-ID: From: "Kostur, Andre" To: "'Kevin A. Noll'" , "'Juan J. Flores'" , dhcwg@ietf.org Subject: RE: [dhcwg] DHCP and MAC Addresses Date: Thu, 4 Nov 2004 13:15:57 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: -5.9 (-----) X-Spam-Score: 0.5 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0861824107==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============0861824107== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C2B3.7A356270" 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_01C4C2B3.7A356270 Content-Type: text/plain; charset="iso-8859-1" I concur. The DHC Protocol and RFCs don't dictate that sort of policy. It's entirely up to the implementor/vendor of the DHCP server as to whether it can do that sort of decision-making. -----Original Message----- From: Kevin A. Noll [mailto:kevin.noll@perfectorder.com] Sent: Thursday, November 04, 2004 11:14 AM To: 'Juan J. Flores'; dhcwg@ietf.org Subject: RE: [dhcwg] DHCP and MAC Addresses Someone correct me if I'm wrong, but I'm pretty sure that this is not directly addressed by any of the current RFCs or drafts. This actually is intentional since one of the requirements of DHCP is not to dictate policy, but to provide a mechanism (see RFC 2131, section 1.6). By picking and choosing which MAC addresses you service via DHCP, you are implementing policy. That said, how to accomplish your goal depends on the DHCP implementation that you are using. There are several DHCP server implementations that can do what you are seeking to accomplish. --kan-- -- Kevin A. Noll, KD4WOZ CCIE, CCDP Perfect Order, Inc. Kevin.Noll@perfectorder.com 717-796-1936 -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Juan J. Flores Sent: Thursday, November 04, 2004 1:29 PM To: dhcwg@ietf.org Subject: [dhcwg] DHCP and MAC Addresses Dear all, Is there a way to have a DHCP server provide service only to a subset of computers in the local network? We assume we know the MAC Addresses of those computers. Using host is not nice, since it would tie computers to IPs and we'd be giving away the D (dynamic) from DHCP. Any help will be greatly appreciated. Best regards, Juan Flores ------_=_NextPart_001_01C4C2B3.7A356270 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] DHCP and MAC Addresses

I concur.  The DHC Protocol and RFCs don't = dictate that sort of policy.  It's entirely up to the = implementor/vendor of the DHCP server as to whether it can do that sort = of decision-making.

-----Original Message-----
From: Kevin A. Noll [mailto:kevin.noll@perfectord= er.com]
Sent: Thursday, November 04, 2004 11:14 AM
To: 'Juan J. Flores'; dhcwg@ietf.org
Subject: RE: [dhcwg] DHCP and MAC Addresses



Someone correct me if I'm wrong, but I'm pretty sure = that this is not
directly addressed by any of the current RFCs or = drafts.

This actually is intentional since one of the = requirements of DHCP
is not to dictate policy, but to provide a mechanism = (see RFC 2131,
section 1.6).

By picking and choosing which MAC addresses you = service via DHCP, you
are implementing policy.

That said, how to accomplish your goal depends on the = DHCP implementation
that you are using. There are several DHCP server = implementations that
can do what you are seeking to accomplish.

--kan--

--
Kevin A. Noll, KD4WOZ
CCIE, CCDP
Perfect Order, Inc.     =        
Kevin.Noll@perfectorder.com
717-796-1936


-----Original Message-----
From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org= ] On Behalf Of
Juan J. Flores
Sent: Thursday, November 04, 2004 1:29 PM
To: dhcwg@ietf.org
Subject: [dhcwg] DHCP and MAC Addresses


Dear all,

Is there a way to have a DHCP server provide service = only to a subset of
computers in the local network?  We assume we = know the MAC Addresses of
those computers.  Using host is not nice, since = it would tie computers
to IPs and we'd be giving away the D (dynamic) from = DHCP.

Any help will be greatly appreciated.

Best regards,

Juan Flores

------_=_NextPart_001_01C4C2B3.7A356270-- --===============0861824107== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0861824107==-- From dhcwg-bounces@ietf.org Thu Nov 4 17:31:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15264; Thu, 4 Nov 2004 17:31:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpuX-0003MK-M4; Thu, 04 Nov 2004 17:16:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CPpn7-0001LQ-A9; Thu, 04 Nov 2004 17:09:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12395; Thu, 4 Nov 2004 17:09:11 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CPq2j-0000RL-9B; Thu, 04 Nov 2004 17:25:21 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CPpfN-0006pr-5T; Thu, 04 Nov 2004 17:01:13 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 04 Nov 2004 17:01:13 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Document Action: 'Renumbering Requirements for Stateless DHCPv6' to Informational RFC X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'Renumbering Requirements for Stateless DHCPv6 ' as an Informational RFC This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Thomas Narten. Technical Summary IPv6 hosts using Stateless Address Autoconfiguration are able to automatically configure their IPv6 address and default router settings. However, further settings are not available. If such hosts wish to automatically configure their DNS, NTP or other specific settings the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using such a combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings, e.g. the addition of a new NTP server address, changes in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document. Working Group Summary This document is a work item of the DHC WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 5 07:39:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07559; Fri, 5 Nov 2004 07:39:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ3Kq-00079y-Eb; Fri, 05 Nov 2004 07:36:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ3HH-0006k9-Hx for dhcwg@megatron.ietf.org; Fri, 05 Nov 2004 07:33:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06908 for ; Fri, 5 Nov 2004 07:33:14 -0500 (EST) From: Patrick.Guelat@imp.ch Received: from mx1.imp.ch ([157.161.9.16]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ3Wz-0001ev-MR for dhcwg@ietf.org; Fri, 05 Nov 2004 07:49:31 -0500 Received: from mx3.imp.ch (mx3.imp.ch [157.161.9.18]) by mx1.imp.ch (8.12.11/8.12.11) with ESMTP id iA5CWu5P036204 for ; Fri, 5 Nov 2004 13:32:58 +0100 (CET) (envelope-from Patrick.Guelat@imp.ch) Received: from mx3.imp.ch (localhost [127.0.0.1]) by mx3.imp.ch (8.12.11/8.12.11/Submit) with ESMTP id iA5CWs2a077654 for ; Fri, 5 Nov 2004 13:32:55 +0100 (CET) (envelope-from Patrick.Guelat@imp.ch) Received: (from clamav@localhost) by mx3.imp.ch (8.12.11/8.12.11/Submit) id iA5CWsbh077651 for ; Fri, 5 Nov 2004 13:32:54 +0100 (CET) (envelope-from Patrick.Guelat@imp.ch) Received: from nbs.imp.ch (nbs.imp.ch [157.161.4.7]) by ns1.imp.ch (MIMEDefang) with ESMTP id iA5CWkQ2018848; Fri, 05 Nov 2004 13:32:54 +0100 (CET) Received: from murphy.imp.ch (murphy.imp.ch [157.161.4.77]) by nbs.imp.ch (8.12.10/8.12.3) with ESMTP id iA5CWk2s9788767; Fri, 5 Nov 2004 13:32:46 +0100 (MEZ) Date: Fri, 5 Nov 2004 13:32:46 +0100 (CET) X-X-Sender: patg@murphy.imp.ch To: "Juan J. Flores" Subject: Re: [dhcwg] DHCP and MAC Addresses In-Reply-To: <418A74F6.4010701@zeus.umich.mx> Message-ID: <20041105132724.D50718@murphy.imp.ch> References: <418A74F6.4010701@zeus.umich.mx> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Resent: Yes X-Spam-Checksum: a7ae3a8af51be28e66eed05915c91784 X-Virus-Message-Status: No X-Virus-Status: No, scantime="0.0013 seconds" X-Spam-Status: No, hits=-4.893 required=5 scantime="5.8332 seconds" tests=BAYES_00, NO_REAL_NAME X-Scanned-By: MIMEDefang 2.48 on 157.161.9.18 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org > Is there a way to have a DHCP server provide service only to a subset of > computers in the local network? We assume we know the MAC Addresses of those > computers. Using host is not nice, since it would tie computers to IPs and > we'd be giving away the D (dynamic) from DHCP. That's really dependant on the implementation of the dhcp server. We've developed such a server for docsis provisioning of cable modems. Only mac-addrs of registred modems get an ip (which may be dynamic). I think this is not possible with the ISC or Microsoft DHCP server. On a unix-machine you could use 'pf', 'ipfw' or any other firewall support layer2-filtering to achieve the same thing. Regards Patrick Guelat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 5 11:17:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25201; Fri, 5 Nov 2004 11:17:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ6ey-0002MK-OY; Fri, 05 Nov 2004 11:09:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ6XR-00014Q-3P for dhcwg@megatron.ietf.org; Fri, 05 Nov 2004 11:02:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23974 for ; Fri, 5 Nov 2004 11:02:06 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ6nC-0006GI-50 for dhcwg@ietf.org; Fri, 05 Nov 2004 11:18:26 -0500 Received: from ocean.jinmei.org (shuttle.wide.toshiba.co.jp [3ffe:501:100f::35]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id A6EF015214; Sat, 6 Nov 2004 01:02:05 +0900 (JST) Date: Sat, 06 Nov 2004 01:02:08 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Mayumi Yanagiya Subject: Re: [dhcwg] Authentication for Information-request In-Reply-To: <413FEA08.6030500@lab.ntt.co.jp> References: <413FEA08.6030500@lab.ntt.co.jp> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=ISO-2022-JP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Dhcwg X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Thu, 09 Sep 2004 14:28:40 +0900, >>>>> Mayumi Yanagiya said: > I have a question about transmitting Information-request message. > In RFC3115, it is not specified clearly that solicit/advertise messages > are exchanged between client and server before exchanging > Information-request/reply message. > On the other hand, it is defined that the client requests > authentication in its Solicit message. > So, I think that solicit/advertise messaged are exchanged before sending > information-request when clients want to use authentication for > information-request. > Is my understanding right? > (I know that Jinmei-san submitted $B!H(BClarifications on DHCPv6 > Authentication$B!I(B. But I couldn't find any discussion for above issue on > this mailing list.) I don't know much about the past discussion, but when I asked a similar question, no one had an answer with confidence. So I tried to propose a clarification on this so that the client does not have to exchange Solicit/Advertise before using DHCPv6 authentication for Information-request/Reply exchanges. (It's just my personal proposal. I don't know if others agree with this.) See Section 2 of draft-ietf-dhc-dhcpv6-clarify-auth-00.txt for more details. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 5 12:42:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01907; Fri, 5 Nov 2004 12:42:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7s8-0000oN-PN; Fri, 05 Nov 2004 12:27:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQ7eq-0004xQ-T8 for dhcwg@megatron.ietf.org; Fri, 05 Nov 2004 12:13:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29607 for ; Fri, 5 Nov 2004 12:13:49 -0500 (EST) Received: from kaboom.isc.org ([204.152.187.72]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQ7ub-0007nL-OB for dhcwg@ietf.org; Fri, 05 Nov 2004 12:30:11 -0500 Received: by kaboom.isc.org (Postfix, from userid 10200) id D6F53B246C; Fri, 5 Nov 2004 09:13:17 -0800 (PST) Date: Fri, 5 Nov 2004 09:13:17 -0800 From: "David W. Hankins" To: dhcwg@ietf.org Subject: Re: [dhcwg] DHCP and MAC Addresses Message-ID: <20041105171317.GA13363@isc.org> References: <418A74F6.4010701@zeus.umich.mx> <20041105132724.D50718@murphy.imp.ch> Mime-Version: 1.0 In-Reply-To: <20041105132724.D50718@murphy.imp.ch> User-Agent: Mutt/1.4.2.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1012335978==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1012335978== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="yrj/dFKFPuw6o+aM" Content-Disposition: inline --yrj/dFKFPuw6o+aM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 05, 2004 at 01:32:46PM +0100, Patrick.Guelat@imp.ch wrote: > I think this is not possible with the ISC or Microsoft DHCP server. This isn't true; it is possible with the ISC server. I can elaborate off-list if you wish. I've given Juan Flores all the clues he needs off-list to accomplish what he's trying to (with ISC DHCP, as it turns out what he's using). So I don't think there's a reason for further comment on this thread. --=20 David W. Hankins "If you don't do it right the first time, Operations Engineer you'll just have to do it again." Internet Systems Consortium, Inc. -- Jack T. Hankins --yrj/dFKFPuw6o+aM Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (FreeBSD) iD8DBQFBi7StcXeLeWu2vmoRAlxiAJ99ijCIvwdpZFK7dwB7R3m71e4p1gCeJKM9 AnqQ9WI3HAovt1+TOwVgqCc= =LPci -----END PGP SIGNATURE----- --yrj/dFKFPuw6o+aM-- --===============1012335978== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1012335978==-- From dhcwg-bounces@ietf.org Fri Nov 5 19:08:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03789; Fri, 5 Nov 2004 19:08:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQE2h-0001PZ-EL; Fri, 05 Nov 2004 19:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQDt8-00007X-MZ for dhcwg@megatron.ietf.org; Fri, 05 Nov 2004 18:53:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02443; Fri, 5 Nov 2004 18:52:59 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQDt9-00082x-Je; Fri, 05 Nov 2004 18:53:03 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 16:03:26 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA5NqQom020653; Fri, 5 Nov 2004 15:52:27 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([128.107.169.90]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMV65164; Fri, 5 Nov 2004 18:52:27 -0500 (EST) Message-Id: <4.3.2.7.2.20041105184916.0294a780@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Nov 2004 18:52:19 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: agenda@ietf.org Subject: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here is the latest draft agenda for the dhc WG meeting at IETF 61. - Ralph DHC WG agenda - IETF 61 0900 Tue 2004-11-09 (tentative) (Last revised 2004-11-05 06:47 PM) ---------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options TBD 10 minutes How to implement the process after RFC is published? Vendor-Specific Information Suboption Mark Stapp 10 minutes Ready for WG last call? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes Accept as dhc WG work item? Source Address Selection Policy option for DHCPv6 T. Fujisaki 10 minutes Accept as dhc WG work item? DHCPv6 Relay Agent Information Option Wing Cheong Lau 10 minutes Accept as dhc WG work item? DHCP Relay Agent Opt for MIPv6 bootstrapping Kuntal Chowdhury 10 minutes Accept as dhc WG work item? DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 130 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 5 19:19:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04485; Fri, 5 Nov 2004 19:19:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEEj-0004Dy-1D; Fri, 05 Nov 2004 19:15:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQE6J-00029v-OO for dhcwg@megatron.ietf.org; Fri, 05 Nov 2004 19:06:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03636 for ; Fri, 5 Nov 2004 19:06:36 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQE6K-0008KM-Qg for dhcwg@ietf.org; Fri, 05 Nov 2004 19:06:41 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 05 Nov 2004 19:06:09 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA60669D010397 for ; Fri, 5 Nov 2004 19:06:07 -0500 (EST) Received: from rdroms-w2k01.cisco.com ([128.107.169.90]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMV65800; Fri, 5 Nov 2004 19:06:05 -0500 (EST) Message-Id: <4.3.2.7.2.20041105190414.0292fa30@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Nov 2004 19:06:02 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here is the latest draft agenda for the dhc WG meeting at IETF 61. I need to identify volunteers to take notes and act as jabber scribe. - Ralph DHC WG agenda - IETF 61 0900 Tue 2004-11-09 (tentative) (Last revised 2004-11-05 07:00 PM ET) ------------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options TBD 10 minutes How to implement the process after RFC is published? Vendor-Specific Information Suboption Mark Stapp 10 minutes Ready for WG last call? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes Accept as dhc WG work item? Source Address Selection Policy option for DHCPv6 T. Fujisaki 10 minutes Accept as dhc WG work item? DHCPv6 Relay Agent Information Option Wing Cheong Lau 10 minutes Accept as dhc WG work item? DHCP Relay Agent Opt for MIPv6 bootstrapping Kuntal Chowdhury 10 minutes Accept as dhc WG work item? DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 130 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 5 19:27:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04976; Fri, 5 Nov 2004 19:27:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEFr-0004wr-IW; Fri, 05 Nov 2004 19:16:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQED9-0003d7-SJ for dhcwg@megatron.ietf.org; Fri, 05 Nov 2004 19:13:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04089 for ; Fri, 5 Nov 2004 19:13:40 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEDA-0008Uo-Ow for dhcwg@ietf.org; Fri, 05 Nov 2004 19:13:45 -0500 Received: from ocean.jinmei.org (unknown [2001:4f8:3:bb:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id D56B415210; Sat, 6 Nov 2004 09:13:40 +0900 (JST) Date: Sat, 06 Nov 2004 09:13:43 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: Ralph Droms Subject: Re: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 In-Reply-To: <4.3.2.7.2.20041105184916.0294a780@flask.cisco.com> References: <4.3.2.7.2.20041105184916.0294a780@flask.cisco.com> User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org >>>>> On Fri, 05 Nov 2004 18:52:19 -0500, >>>>> Ralph Droms said: > Here is the latest draft agenda for the dhc WG meeting at IETF 61. Can I get a short slot (maximum 10 minutes, I guess) for the updates in draft-ietf-dhc-dhcpv6-clarify-auth-00.txt? I've not seen any comments on it, but I believe I've at least proposed resolutions of all outstanding issues. In that since, it's even ready for a wg last call. Regardless of whether we can or need to allocate a slot for this, comments on the draft are welcome, of course. Thanks, JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Fri Nov 5 19:33:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA05364; Fri, 5 Nov 2004 19:33:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEQB-0007jr-Pm; Fri, 05 Nov 2004 19:27:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQEO4-0006zp-PE for dhcwg@megatron.ietf.org; Fri, 05 Nov 2004 19:25:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04779 for ; Fri, 5 Nov 2004 19:24:57 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQEO5-0000GP-11 for dhcwg@ietf.org; Fri, 05 Nov 2004 19:25:02 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 05 Nov 2004 16:35:23 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA60OMom005285 for ; Fri, 5 Nov 2004 16:24:22 -0800 (PST) Received: from rdroms-w2k01.cisco.com ([128.107.169.90]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMV66550; Fri, 5 Nov 2004 19:24:25 -0500 (EST) Message-Id: <4.3.2.7.2.20041105192319.02967bf8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 05 Nov 2004 19:23:47 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here is yet another latest draft agenda for the dhc WG meeting at IETF 61. - Ralph DHC WG agenda - IETF 61 0900 Tue 2004-11-09 (tentative) (Last revised 2004-11-05 07:21 PM ET) ------------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options TBD 10 minutes How to implement the process after RFC is published? Vendor-Specific Information Suboption Mark Stapp 10 minutes Ready for WG last call? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes Accept as dhc WG work item? Source Address Selection Policy option for DHCPv6 T. Fujisaki 10 minutes Accept as dhc WG work item? DHCPv6 Relay Agent Information Option Wing Cheong Lau 10 minutes Accept as dhc WG work item? DHCP Relay Agent Opt for MIPv6 bootstrapping Kuntal Chowdhury 10 minutes Accept as dhc WG work item? Clarifications on DHCPv6 Authentication T. Jinmei 10 minutes Technical discussion DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 140 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From nfaje@msn.com Sat Nov 6 19:15:15 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18861; Sat, 6 Nov 2004 19:15:15 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQaiS-0001py-3x; Sat, 06 Nov 2004 19:15:33 -0500 Received: from 68-117-214-78.cpe.ga.charter.com ([68.117.214.78]) by mx2.foretec.com with smtp (Exim 4.24) id 1CQaiB-0007I1-P5; Sat, 06 Nov 2004 19:15:16 -0500 X-Message-Info: J9N173LBQhk8oBudS80VG441kVOQajWM8 Received: from chambermaid1archaictorrance (50.44.535.19) by mail703.nfaje@msn.com (Bluewin AG 9.9.838) id 43553N9EG627YOB60211 for dhcipv6-archive@ietf.org; Sat, 06 Nov 2004 18:15:05 -0600 Message-ID: <111956439313.86595@nfaje@msn.com> Reply-To: "Gonzalo Valentin" From: "Gonzalo Valentin" To: "Dhcipv6-archive" Subject: Vicodin shipping worldwide. Date: Sun, 07 Nov 2004 02:11:05 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--2169751057120277057" X-Spam-Score: 5.7 (+++++) X-Spam-Flag: YES X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 ----2169751057120277057 Content-Type: text/html; charset="iso-4960-4" Content-Description: oxygen dobbs1.drain Content-Transfer-Encoding: quoted-printable You need Vicodin. You get it here. No need to wait any longer!
It is y= our unique chance to save on the medications up to 80%.
It is not just about saving. It is about boosting your health.










?OjQwkoPF3SpXNOOdissertatio= n|dhcipv6-archive@ietf.org">u*n*s*u*b*s*c*r*i*b*e
patrolman crucial norris strum fish ghost tentative blunt enthusiastic han= gmen cryptology incommunicable workday claremont shareown robbins nepal na= vigate=20 horn masseur wilcox illimitable glandular conundrum technocrat= ic current approval afield gavel ghoulish elan wolve spud antecedent titia= n husky uptown=20 sign canada streetcar equinoctial magistrate precoci= ous commonwealth eft force indeed albumin dickey rector cosh asheville com= pactify foxhole monomial reredos dick abe compensate dick raritan claw=20 ----2169751057120277057-- From dhcwg-bounces@ietf.org Sat Nov 6 19:39:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20975; Sat, 6 Nov 2004 19:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQb0g-0003ba-3r; Sat, 06 Nov 2004 19:34:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQatz-0001da-2u for dhcwg@megatron.ietf.org; Sat, 06 Nov 2004 19:27:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19854 for ; Sat, 6 Nov 2004 19:27:23 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQauB-00024a-VP for dhcwg@ietf.org; Sat, 06 Nov 2004 19:27:41 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 06 Nov 2004 19:26:55 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA70Qq9D007287 for ; Sat, 6 Nov 2004 19:26:53 -0500 (EST) Received: from rdroms-w2k01.cisco.com (sjc-vpn1-1203.cisco.com [10.21.100.179]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMV90412; Sat, 6 Nov 2004 19:25:44 -0500 (EST) Message-Id: <4.3.2.7.2.20041106192511.02488b80@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Sat, 06 Nov 2004 19:25:18 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Subject: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Here is yet another latest draft agenda for the dhc WG meeting at IETF 61. - Ralph DHC WG agenda - IETF 61 0900 Tue 2004-11-09 (tentative) (Last revised 2004-11-06 07:20 PM ET) ------------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options Bernie Volz 10 minutes How to implement the process after RFC is published? Vendor-Specific Information Suboption Mark Stapp 10 minutes Ready for WG last call? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? Multicast Reconfig. Protocol for Stateless DHCPv6 Daniel Park 10 minutes Technical discussion Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes Accept as dhc WG work item? Source Address Selection Policy option for DHCPv6 T. Fujisaki 10 minutes Accept as dhc WG work item? DHCPv6 Relay Agent Information Option Wing Cheong Lau 10 minutes Accept as dhc WG work item? DHCP Relay Agent Opt for MIPv6 bootstrapping Kuntal Chowdhury 10 minutes Accept as dhc WG work item? Clarifications on DHCPv6 Authentication T. Jinmei 10 minutes Technical discussion DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 150 minutes _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 7 09:25:09 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA21974; Sun, 7 Nov 2004 09:25:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQnur-0006tp-EI; Sun, 07 Nov 2004 09:21:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3w1-0003Bp-Rx for dhcwg@megatron.ietf.org; Fri, 22 Oct 2004 14:14:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26108 for ; Fri, 22 Oct 2004 14:14:38 -0400 (EDT) Received: from bay16-f36.bay16.hotmail.com ([65.54.186.86] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL48r-0003ZT-4Q for dhcwg@ietf.org; Fri, 22 Oct 2004 14:27:57 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Oct 2004 11:14:03 -0700 Received: from 80.103.37.207 by by16fd.bay16.hotmail.msn.com with HTTP; Fri, 22 Oct 2004 18:13:21 GMT X-Originating-IP: [80.103.37.207] X-Originating-Email: [placidamenteinsensible@hotmail.com] X-Sender: placidamenteinsensible@hotmail.com From: "fer g.r." To: dhcwg@ietf.org Subject: [dhcwg] Server Unicast Option, in DHCPv6 Date: Fri, 22 Oct 2004 20:13:21 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 22 Oct 2004 18:14:03.0529 (UTC) FILETIME=[E965DF90:01C4B862] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA26108 X-Mailman-Approved-At: Sun, 07 Nov 2004 09:21:10 -0500 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, I need some help to clear some doubts on the Server Unicast Option, i= n=20 DHCPv6. The first doubt is on the scope has the server and client address to unic= ast=20 communication. Initially I though that they must be global unicast addresses, but thinki= ng=20 deeply and looking at the next on RFC3315 I think it could be more=20 flexible. RFC3315, 18.1. , Page 39, second paragraph =93If the client has a source address of sufficient scope that can be used by the server as a return address=94 Attending to the =93sufficient scope=94 of client address. Cannot we assu= me that=20 link-local addresses are of sufficient scope to unicast communication on = the=20 same link? I think that for servers and clients on the same link, they MAY use their= =20 link local addr. to unicast. Is this possible or is there any error in my supposition? I wish some one= =20 could give me their opinion. Finally I have a little doubt on when a server MAY or SHOULD NOT send=20 Unicast Option to a client. RFC 3315, 22.12 says: =93When the server sends a Unicast option to the client, some messages from the client will not be relayed by Relay Agents, and will not include Relay Agent options from the Relay Agents. Therefore, a server should only send a Unicast option to a client when Re= lay=20 Agents are not sending Relay Agent options.=94 I wonder the real meaning of =93when Relay Agents are not sending Relay A= gent=20 options=94. It means that for a particular client, whose message relayed from a R.A.=20 includes Relay Agent options, then the server SHOULD NOT send Unicast opt= ion=20 to that client? or it means that if any message from any R.A. includes Re= lay=20 Agent options then the server SHOULD NOT send Unicast option to any clien= t?=20 (I suppose the former). But in any case, at the moment the R.A. don=92t send Relay Agent Options = in=20 one message can the server assumes that since that it can send Unicast=20 Options to the client/s? Any opinions and help on these would be appreciated. Thank, bye. _________________________________________________________________ Hor=F3scopo, tarot, numerolog=EDa... Escucha lo que te dicen los astros.=20 http://astrocentro.msn.es/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 7 09:27:41 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22261; Sun, 7 Nov 2004 09:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQnur-0006tu-Of; Sun, 07 Nov 2004 09:21:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL3yA-0003mD-62 for dhcwg@megatron.ietf.org; Fri, 22 Oct 2004 14:16:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26295 for ; Fri, 22 Oct 2004 14:16:51 -0400 (EDT) Received: from bay16-f29.bay16.hotmail.com ([65.54.186.79] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4Ay-0003bL-DO for dhcwg@ietf.org; Fri, 22 Oct 2004 14:30:09 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Oct 2004 11:16:09 -0700 Received: from 80.103.37.207 by by16fd.bay16.hotmail.msn.com with HTTP; Fri, 22 Oct 2004 18:15:27 GMT X-Originating-IP: [80.103.37.207] X-Originating-Email: [placidamenteinsensible@hotmail.com] X-Sender: placidamenteinsensible@hotmail.com From: "fer g.r." To: dhcwg@ietf.org Subject: [dhcwg] relay forward in DHCPv6 Date: Fri, 22 Oct 2004 20:15:27 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 22 Oct 2004 18:16:09.0170 (UTC) FILETIME=[34492B20:01C4B863] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA26295 X-Mailman-Approved-At: Sun, 07 Nov 2004 09:21:10 -0500 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, I need some clarification on one point of relay forward in DHCPv6. It= is=20 referring to the case of clients and servers and Relay Agents on a same=20 link. MAY Relay Agents forwards client=92s messages to the servers who are in = the=20 same Link the client who sends the request? or they MUST only forward messages to all the links but the one from the=20 client who sent it? Thanks, bye. _________________________________________________________________ Moda para esta temporada. Ponte al d=EDa de todas las tendencias.=20 http://www.msn.es/Mujer/moda/default.asp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 7 09:29:42 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22444; Sun, 7 Nov 2004 09:29:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQnus-0006tz-2p; Sun, 07 Nov 2004 09:21:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CL419-0004GZ-7X for dhcwg@megatron.ietf.org; Fri, 22 Oct 2004 14:19:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26549 for ; Fri, 22 Oct 2004 14:19:56 -0400 (EDT) Received: from bay16-f12.bay16.hotmail.com ([65.54.186.62] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CL4Dx-0003gO-N2 for dhcwg@ietf.org; Fri, 22 Oct 2004 14:33:15 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Oct 2004 11:19:05 -0700 Received: from 80.103.37.207 by by16fd.bay16.hotmail.msn.com with HTTP; Fri, 22 Oct 2004 18:18:26 GMT X-Originating-IP: [80.103.37.207] X-Originating-Email: [placidamenteinsensible@hotmail.com] X-Sender: placidamenteinsensible@hotmail.com From: "fer g.r." To: dhcwg@ietf.org Subject: [dhcwg] How a server should gives config to a client in DHCPv6 Date: Fri, 22 Oct 2004 20:18:26 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 22 Oct 2004 18:19:05.0828 (UTC) FILETIME=[9D950A40:01C4B863] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id OAA26549 X-Mailman-Approved-At: Sun, 07 Nov 2004 09:21:10 -0500 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hello every body. I have a serious doubt about the way a server should chooses the=20 configuration it gives to clients in DHCPv6. Form 1 All the servers I have seen, selects the configuration it gives to a clie= nt=20 attending to the local interface where the server receives the client=20 request. Example of server config file iface eth0 { class { pool 2000::100-2000::10f } } This is: if a request from a client C arrives to the server via its=20 interface of index 1, the client receives one type of config. info; and i= f=20 that same request, of the same client C, would arrive to the server via a= ny=20 other different interface (i.e. 2) then the same client would receive oth= er=20 different config. Info. In other words, the sever has a configuration to give to any petition=20 received in each particular interface and the configuration and addresses= a=20 client gets depends in what server interface its message arrives in the=20 server. Form 2 Telling the server in its configuration what nets it is to administer=20 (Prefix of the IP that represents a link), and the addresses it offers fo= r=20 each one. Example of server config file Link fe800::/64 { Pool 3ffe:501:ffff:0::1 to 3ffe:501:ffff:0::10/64; } So, when the server receives a client request, it takes the client=92s ad= dress=20 and compares its interface prefix with all the links it is to administer.= It=20 a match occurs, the server gives configuration (reserved to that link) to= =20 the client. I think this is the correct way to administrate nets and sele= ct=20 which clients it can give config and which not, this is, which nets it mu= st=20 administrate and which not. I think that a point to this is at RFC3315 point 20.1.1. =93This address will be used by the server to determine the link from whi= ch=20 the client should be assigned an address and other configuration=20 information.=94 What do you think ?? Tanks, bye. _________________________________________________________________ La informaci=F3n m=E1s fresca desde diferentes puntos de vista en la Revi= sta de=20 Prensa de MSN. http://es.newsbot.msn.com/ _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 7 13:05:36 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09218; Sun, 7 Nov 2004 13:05:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQrNP-0006At-1f; Sun, 07 Nov 2004 13:02:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQrIH-0005Fk-5p for dhcwg@megatron.ietf.org; Sun, 07 Nov 2004 12:57:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08701 for ; Sun, 7 Nov 2004 12:57:33 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQrIe-0008FH-J7 for dhcwg@ietf.org; Sun, 07 Nov 2004 12:58:01 -0500 Received: from [192.168.1.102] (pool-70-17-112-15.res.east.verizon.net [70.17.112.15]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id DD2DC56871; Sun, 7 Nov 2004 09:57:03 -0800 (PST) (envelope-from mellon@nominum.com) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: <675B4F16-30E6-11D9-AA52-000A95D6A618@nominum.com> Content-Transfer-Encoding: quoted-printable From: Ted Lemon Subject: Re: [dhcwg] Server Unicast Option, in DHCPv6 Date: Sun, 7 Nov 2004 12:56:51 -0500 To: "fer g.r." X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable On Oct 22, 2004, at 2:13 PM, fer g.r. wrote: > Attending to the =93sufficient scope=94 of client address. Cannot we=20= > assume that link-local addresses are of sufficient scope to unicast=20 > communication on the same link? > I think that for servers and clients on the same link, they MAY use=20 > their link local addr. to unicast. That is what the language says, and in fact it's what has to happen, or=20= else the client can't communicate with the DHCP server, so I would say=20= that your reading of it is correct. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Sun Nov 7 19:55:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17381; Sun, 7 Nov 2004 19:55:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxjx-0005ND-ON; Sun, 07 Nov 2004 19:50:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CQxcQ-0004aG-Fh for dhcwg@megatron.ietf.org; Sun, 07 Nov 2004 19:42:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15931 for ; Sun, 7 Nov 2004 19:42:46 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CQxcr-0000tv-0j for dhcwg@ietf.org; Sun, 07 Nov 2004 19:43:17 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6U0086M4LM0U@mailout3.samsung.com> for dhcwg@ietf.org; Mon, 08 Nov 2004 09:41:46 +0900 (KST) Received: from ep_ms3_bk (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6U00CD73J4IO@mailout3.samsung.com> for dhcwg@ietf.org; Mon, 08 Nov 2004 09:18:40 +0900 (KST) Received: from localhost (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with SMTP id <0I6U00HSF3J435@ms3.samsung.com> for dhcwg@ietf.org; Mon, 08 Nov 2004 09:18:40 +0900 (KST) Date: Mon, 08 Nov 2004 00:18:35 +0000 (GMT) From: Daniel Park Subject: Re: [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: Ralph Droms , soohong.park@samsung.com Message-id: <2983078.1099873111651.JavaMail.weblogic@ep_app32> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20041108001831649@soohong.park X-MTR: 20041108001831649@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Score: 0.8 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Content-Transfer-Encoding: 7BIT Cc: "dhcwg@ietf.org " X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Just for clarifying on below discussion prior to presenting it. Multicast Reconfig. Protocol for Stateless DHCPv6 Daniel Park 10 minutes Technical discussion This protocol is for providing reconfiguration in the stateless DHCPv6 domain when any configuration information is changed and initial version was presented at Seoul meeting. This protocol uses a RA message to trigger a client to initiate Renew/Reply or Information-Request/Reply by which it can obtain the updated configuration information. Regarding this protocol, I think we should make sure one related draft which aims M and O flag of RA to be clarified and it was officially accepted as IPv6 WG work item. This draft defines three DHCP policies for each flag. For more detail understanding, please read below draft. http://www.watersprings.org/pub/id/draft-daniel-ipv6-ra-mo-flags-01.txt What I am trying to say is that this reconf protocol is only applied to both O-Policy 1 and 2 not 3 since O-Policy 3 does not invoke any configuration scheme regardless of flag change. Moreover, initial version proposed a new ICMPv6 option to inform the information change to the client, however it is just applied for O-Policy 2. If O-Policy 1 is enabled, the client can invoke the reconfiguration scheme regardless of change of flag or any new option. Now, I think it should be discussed during this meeting if this protocol is of interest... Please take a look at the M&O flag document and let me know your comments and thoughts... Thanks Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics ------- Original Message ------- Sender : Ralph Droms Date : Nov 07, 2004 09:25 Title : [dhcwg] Tentative agenda for dhc WG meeting at IETF 61 Here is yet another latest draft agenda for the dhc WG meeting at IETF 61. - Ralph DHC WG agenda - IETF 61 0900 Tue 2004-11-09 (tentative) (Last revised 2004-11-06 07:20 PM ET) ------------------------------------- Administrivia Ralph Droms 10 minutes Agenda bashing; blue sheets; scribe; Jabber scribe Request for milestones for dhc WG drafts DNS zone suffix option for DHCPv6 Renxiang Yan 10 minutes Accept as dhc WG work item? Reclassifying DHCPv4 Options Bernie Volz 10 minutes How to implement the process after RFC is published? Vendor-Specific Information Suboption Mark Stapp 10 minutes Ready for WG last call? DHCP Authentication via EAP Mark Stapp 10 minutes Technical discussion Lifetime Option for DHCPv6 Stig Venaas 10 minutes Ready for WG last call? Multicast Reconfig. Protocol for Stateless DHCPv6 Daniel Park 10 minutes Technical discussion Anycast Address Assignment using DHCPv6 Syam Madanapalli 10 minutes Accept as dhc WG work item? Source Address Selection Policy option for DHCPv6 T. Fujisaki 10 minutes Accept as dhc WG work item? DHCPv6 Relay Agent Information Option Wing Cheong Lau 10 minutes Accept as dhc WG work item? DHCP Relay Agent Opt for MIPv6 bootstrapping Kuntal Chowdhury 10 minutes Accept as dhc WG work item? Clarifications on DHCPv6 Authentication T. Jinmei 10 minutes Technical discussion DHCP-DNS interaction Bernie Volz 30 minutes Technical discussion ----------- 150 minutes _______________________________________________ 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-bounces@ietf.org Mon Nov 8 00:03:57 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA05777; Mon, 8 Nov 2004 00:03:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR1f5-0008SV-Sp; Mon, 08 Nov 2004 00:01:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR1d9-0007xD-Jn for dhcwg@megatron.ietf.org; Sun, 07 Nov 2004 23:59:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05545 for ; Sun, 7 Nov 2004 23:59:48 -0500 (EST) Received: from shuttle.wide.toshiba.co.jp ([202.249.10.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR1dc-0005rD-Ik for dhcwg@ietf.org; Mon, 08 Nov 2004 00:00:21 -0500 Received: from ocean.jinmei.org (unknown [2001:468:c12:64:200:39ff:fed7:e2e4]) by shuttle.wide.toshiba.co.jp (Postfix) with ESMTP id CBE1E15210; Mon, 8 Nov 2004 13:59:33 +0900 (JST) Date: Mon, 08 Nov 2004 13:59:38 +0900 Message-ID: From: JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= To: venaas@uninett.no, tjc@ecs.soton.ac.uk, volz@cisco.com User-Agent: Wanderlust/2.10.1 (Watching The Wheels) Emacs/21.3 Mule/5.0 (SAKAKI) Organization: Research & Development Center, Toshiba Corp., Kawasaki, Japan. MIME-Version: 1.0 (generated by SEMI 1.14.5 - "Awara-Onsen") Content-Type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: dhcwg@ietf.org Subject: [dhcwg] comments on draft-ietf-dhc-lifetime-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Hello, I should have done this much earlier, but I just went through draft-ietf-dhc-lifetime-02.txt. Overall, this version addresses all my previous concerns, and I believe it's almost ready for publication. I have some minor comments: 1. In section 3 (the second last paragraph), the draft says The client is however free to fall back to other mechanisms if it cannot refresh the data within a reasonable amount of time. I'm not really sure what this sentence means. Specifically, I don't understand what "other mechanisms" mean in this context. Please clarify that. 2. In section 3 (last paragraph), it says: When a client receives a Reply to an Information-Request that contains configuration information (i.e., does not contain a Status Code option), it should [...] I don't think the part with "i.e." is really correct. I can imagine an implementation that successfully returns configuration information with Status Code being "Success". (In fact, I remember an implementation that behaved like this). Perhaps we can simply remove the "i.e." clause, or clarify that "does not contain a Status Code option with a code other than Success", or remove this phrase but add "successfully" between "that" and "contains", etc. 3. In section 3.1, the draft says IRT_DEFAULT 86400 In some cases the client uses a default refresh time IRT_DEFAULT. The recommended value for IRT_DEFAULT is 86400 (24 hours). The client implementation should allow for this value to be configurable. Perhaps the "should" in the last sentence might be "SHOULD". (I don't have a particular preference/opinion on this though) 4. This document uses a phrase like "client MUST include this option in ORO". I don't think this is really accurate, since an ORO does not contain the option itself, but just indicates the client's desire to receive the option by specifying the option code value. So, for example, I'd rephrase the first sentence of Section 3.2 from A client MUST include this option in the Option Request Option (ORO) when sending Information-Request messages to the DHCPv6 server. to A client MUST specify this option in the Option Request Option (ORO) when sending Information-Request messages to the DHCPv6 server. That is, s/include/specify/. The same comment should also apply to: - the 2nd sentence of Section 3.2 - the 1st sentence of Section 3.3 JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. jinmei@isl.rdc.toshiba.co.jp _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Mon Nov 8 00:39:03 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08459; Mon, 8 Nov 2004 00:39:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR27X-0005AF-QJ; Mon, 08 Nov 2004 00:31:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR20H-00048Q-Mp for dhcwg@megatron.ietf.org; Mon, 08 Nov 2004 00:23:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07049 for ; Mon, 8 Nov 2004 00:23:42 -0500 (EST) Received: from [61.16.238.202] (helo=alice.acmet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR20g-0006Q6-Kp for dhcwg@ietf.org; Mon, 08 Nov 2004 00:24:15 -0500 Received: from gobinath (localhost [127.0.0.1] (may be forged)) by alice.acmet.com (8.11.6/8.11.6) with ESMTP id iA85UZS10565 for ; Mon, 8 Nov 2004 11:00:35 +0530 From: "Gobinath.S" To: Date: Mon, 8 Nov 2004 10:53:33 -0800 Message-ID: <000f01c4c5c4$3f5196b0$4e00a8c0@gobinath> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Score: 2.1 (++) X-Scan-Signature: a492040269d440726bfd84680622cee7 Subject: [dhcwg] control information X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2056476706==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============2056476706== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C4C581.312E56B0" This is a multi-part message in MIME format. ------=_NextPart_000_0010_01C4C581.312E56B0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi! I am new to DHCPv6 I am trying to install the DHCPv6 by KEME and execute it. While running the server and client, it asks for the "configuration file" and "server control file" which should be in "/usr/local/etc". In KEME provided source, I can find the "sample configuration file" but I can't find the "server control file" and "client control file". Please provide me the sample "server control file" and "client control file". Also please give me some more information about the need and usage of those file. Please help me out to understand the DHCPv6 and also it is urgent. With regards, S.Gobinath. ------=_NextPart_000_0010_01C4C581.312E56B0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi!

        = ;    I am new to DHCPv6 I am trying to install the DHCPv6 by KEME and execute = it.

While running the server and client, it asks for the = “configuration file” and “server control file” which should be in = “/usr/local/etc”.

In KEME provided source, I can find the “sample configuration file” but I can’t find the “server = control file” and “client control file”.

 

Please provide me the sample “server control = file” and “client control file”.

Also please give me some more information about the = need and usage of those file.

 

Please help me out to understand the DHCPv6 and also = it is urgent.

 

With regards,

S.Gobinath.

 

------=_NextPart_000_0010_01C4C581.312E56B0-- --===============2056476706== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============2056476706==-- From dhcwg-bounces@ietf.org Mon Nov 8 04:31:29 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA14324; Mon, 8 Nov 2004 04:31:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR5pn-0000lo-9I; Mon, 08 Nov 2004 04:29:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR5kR-0000DK-BT for dhcwg@megatron.ietf.org; Mon, 08 Nov 2004 04:23:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13848 for ; Mon, 8 Nov 2004 04:23:35 -0500 (EST) Received: from [61.16.238.202] (helo=alice.acmet.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR5kp-0003Ap-In for dhcwg@ietf.org; Mon, 08 Nov 2004 04:24:09 -0500 Received: from gobinath (localhost [127.0.0.1] (may be forged)) by alice.acmet.com (8.11.6/8.11.6) with ESMTP id iA89Vqm06485 for ; Mon, 8 Nov 2004 15:01:52 +0530 From: "Gobinath.S" To: Date: Mon, 8 Nov 2004 14:54:51 -0800 Message-ID: <001101c4c5e5$f4a6c7d0$4e00a8c0@gobinath> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal X-Spam-Score: 2.1 (++) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Subject: [dhcwg] Query for control information X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1242203553==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1242203553== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C4C5A2.E68E3630" This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C4C5A2.E68E3630 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Hi! I am new to DHCPv6 I am trying to install the DHCPv6 by KAME and execute it. While running the server and client, it asks for the "configuration file" and "server control file" which should be in "/usr/local/etc". In KAME provided source, I can find the "sample configuration file" but I can't find the "server control file" and "client control file". Please provide me the sample "server control file" and "client control file". Also please give me some more information about the need and usage of those files. With regards, S.Gobinath. Note: sorry, in earlier message I have specified KAME as KEME. ------=_NextPart_000_0012_01C4C5A2.E68E3630 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi!

        = ;    I am new to DHCPv6 I am trying to install the DHCPv6 by KAME and execute = it.

While running the server and client, it asks for the “configuration file” and “server control file” = which should be in “/usr/local/etc”.

In KAME provided source, I can find the “sample configuration file” but I can’t find the “server = control file” and “client control = file”.

 

Please provide me the sample “server control file” and “client control = file”.

Also please give me some more information about the = need and usage of those files.

 

With regards,

S.Gobinath.

 

Note: sorry, in earlier message I have specified KAME = as KEME.

 

------=_NextPart_000_0012_01C4C5A2.E68E3630-- --===============1242203553== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1242203553==-- From dhcwg-bounces@ietf.org Mon Nov 8 07:08:31 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26209; Mon, 8 Nov 2004 07:08:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8I5-0005O9-10; Mon, 08 Nov 2004 07:06:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CR8FP-0004vs-Kx for dhcwg@megatron.ietf.org; Mon, 08 Nov 2004 07:03:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25854 for ; Mon, 8 Nov 2004 07:03:44 -0500 (EST) Received: from [61.144.161.55] (helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CR8Fq-0006LW-DJ for dhcwg@ietf.org; Mon, 08 Nov 2004 07:04:21 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I6V00AN1002AE@szxga03-in.huawei.com> for dhcwg@ietf.org; Mon, 08 Nov 2004 20:00:02 +0800 (CST) Received: from szxml01-in ([172.24.1.3]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I6V00EEI002HR@szxga03-in.huawei.com> fordhcwg@ietf.org; Mon, 08 Nov 2004 20:00:02 +0800 (CST) Received: from vineet70814 ([10.78.16.232]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I6V0074F051JR@szxml01-in.huawei.com> fordhcwg@ietf.org; Mon, 08 Nov 2004 20:03:01 +0800 (CST) Date: Mon, 08 Nov 2004 20:02:45 +0800 From: Vineet Kumar Gautam To: dhcwg@ietf.org Message-id: <00a101c4c58a$dbfb1340$e8104e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [dhcwg] jDhcp api X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1407864588==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1407864588== Content-type: multipart/alternative; boundary="Boundary_(ID_qUFBDIN92Z0T3f70J33dHQ)" This is a multi-part message in MIME format. --Boundary_(ID_qUFBDIN92Z0T3f70J33dHQ) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hello all, I have a query. How can we get DHCP server information through jDHCP java apis. Can anyone help me. Vineet --Boundary_(ID_qUFBDIN92Z0T3f70J33dHQ) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hello all,
    I have a query.
    How can we get DHCP server information through
    jDHCP java apis.
    Can anyone help me.
Vineet 
--Boundary_(ID_qUFBDIN92Z0T3f70J33dHQ)-- --===============1407864588== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1407864588==-- From dhcwg-bounces@ietf.org Mon Nov 8 18:24:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17418; Mon, 8 Nov 2004 18:24:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRIl8-0003Ut-TR; Mon, 08 Nov 2004 18:17:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRIZU-000689-Aq for dhcwg@megatron.ietf.org; Mon, 08 Nov 2004 18:05:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15068 for ; Mon, 8 Nov 2004 18:05:09 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRIa6-0000nv-Gw for dhcwg@ietf.org; Mon, 08 Nov 2004 18:05:51 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 08 Nov 2004 18:29:17 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iA8N4cR5024265 for ; Mon, 8 Nov 2004 18:04:39 -0500 (EST) Received: from rdroms-w2k01.cisco.com (sjc-vpn5-144.cisco.com [10.21.88.144]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMW78570; Mon, 8 Nov 2004 18:04:36 -0500 (EST) Message-Id: <4.3.2.7.2.20041108180310.022a5ae8@flask.cisco.com> X-Sender: rdroms@flask.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Mon, 08 Nov 2004 18:04:34 -0500 To: dhcwg@ietf.org From: Ralph Droms Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [dhcwg] dhc WG meeting, 11/9 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Meeting presenters - please send me a copy of your slides for including in the meeting proceedings. I'm still looking for volunteers to take notes and act as jabber scribe during the WG meeting. - Ralph _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From nv33134@yahoo.com Tue Nov 9 02:19:48 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22254; Tue, 9 Nov 2004 02:19:48 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRQIr-00035S-Bp; Tue, 09 Nov 2004 02:20:33 -0500 Received: from [210.122.216.224] (helo=ietf.org) by mx2.foretec.com with smtp (Exim 4.24) id 1CRPyo-00014n-Dk; Tue, 09 Nov 2004 01:59:53 -0500 From: "Livro na contram鉶!" Subject: "Trabalho escravo", novo pretexto contra a propriedade User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020314 Netscape6/6.2.2 X-Accept-Language: en-us MIME-Version: 1.0 Content-Type: text/html Message-Id: Date: Tue, 09 Nov 2004 01:59:53 -0500 X-Spam-Score: 10.1 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 0f1ff0b0158b41ac6b9548d0972cdd31 From dhcwg-bounces@ietf.org Tue Nov 9 09:02:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28455; Tue, 9 Nov 2004 09:02:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWOs-0007a0-70; Tue, 09 Nov 2004 08:51:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWJL-0006Ru-3J for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 08:45:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26114 for ; Tue, 9 Nov 2004 08:45:25 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWK5-0003lo-NY for dhcwg@ietf.org; Tue, 09 Nov 2004 08:46:14 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id iA9Dic3U021023; Tue, 9 Nov 2004 14:44:38 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id iA9DibAI015620; Tue, 9 Nov 2004 14:44:37 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 9 Nov 2004 14:44:37 +0100 From: Stig Venaas To: "JINMEI Tatuya / ?$B?@L@C#:H" Message-ID: <20041109134437.GE15501@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: dhcwg@ietf.org, tjc@ecs.soton.ac.uk, volz@cisco.com Subject: [dhcwg] Re: comments on draft-ietf-dhc-lifetime-02.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Mon, Nov 08, 2004 at 01:59:38PM +0900, JINMEI Tatuya / ?$B?@L@C#:H wrote: > Hello, > > I should have done this much earlier, but I just went through > draft-ietf-dhc-lifetime-02.txt. Overall, this version addresses all > my previous concerns, and I believe it's almost ready for publication. Thanks. I would like for the draft to go to WGLC now. I think your comments below can be addressed in a revised draft when WGLC is ended. This is what I want to discuss in the meeting today, Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 09:06:06 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28866; Tue, 9 Nov 2004 09:06:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWP7-0007do-5j; Tue, 09 Nov 2004 08:51:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRWLp-0006zz-1t for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 08:48:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26432 for ; Tue, 9 Nov 2004 08:47:59 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRWMZ-0003pu-SJ for dhcwg@ietf.org; Tue, 09 Nov 2004 08:48:48 -0500 Received: from [130.129.132.183] (unknown [130.129.132.183]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 8E9DF56886 for ; Tue, 9 Nov 2004 05:47:28 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Mime-Version: 1.0 (Apple Message framework v619) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: dhcwg@ietf.org From: Ted Lemon Date: Tue, 9 Nov 2004 08:47:20 -0500 X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Subject: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit In reading the lifetime draft, I am generally _very_ happy with it. However, there is one point that I think is a mistake - allowing the time to be set to an unreasonably large value. In considering this, I think it's useful to look at other configuration parameters that IP hosts frequently acquire, such as the IP address of a server. When acquiring the IP address of a server, we go to the DNS and do a lookup. It would be extremely unusual for the result that we get back to have a TTL that is more than a week, and I think pretty commonly the TTL would be more like a day, or even an hour. DHCPv6 Information Request transactions are like DNS transactions. They do not require a database write, so they are relatively low-impact. They can be implemented in routers. Basically, there are ways to make them really, really cheap. So optimizing the protocol with the intention of making them happen really infrequently seems like a mistake to me. I think that the maximum refresh time a client should ever accept is a single day. I can imagine someone arguing for a larger time, such as a week, but I think that generally the only reason you'd ever get a time that big would be because someone was trying to spoof your client. Aside from this comment, I think that it's past time to advance this draft - it looks very good. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 10:02:33 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05248; Tue, 9 Nov 2004 10:02:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXQG-0004eZ-It; Tue, 09 Nov 2004 09:56:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXIa-0002tV-Q2 for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 09:48:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03609 for ; Tue, 9 Nov 2004 09:48:42 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXJL-0005Rc-Fk for dhcwg@ietf.org; Tue, 09 Nov 2004 09:49:32 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I6X00D012GB8Y@mailout2.samsung.com> for dhcwg@ietf.org; Tue, 09 Nov 2004 23:48:11 +0900 (KST) Received: from ep_ms3_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I6X004BT2GAFQ@mailout2.samsung.com> for dhcwg@ietf.org; Tue, 09 Nov 2004 23:48:11 +0900 (KST) Received: from ep_spt04 (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTP id <0I6X007R72GA8B@ms3.samsung.com> for dhcwg@ietf.org; Tue, 09 Nov 2004 23:48:10 +0900 (KST) Content-return: prohibited Date: Tue, 09 Nov 2004 14:48:11 +0000 (GMT) From: Daniel Park X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= Cc: "dhcwg@ietf.org " Message-id: <5854869.1100011690486.JavaMail.weblogic@ep_app44> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20041109144810472@soohong.park X-MTR: 20041109144810472@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7BIT Subject: [dhcwg] Comment on draft-yan-dhc-dhcpv6-opt-dnszone X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT Hi Basically, RA mechanism indicated in this presentation was mentioned in DNSOP WG (DNS operation) not IPv6 WG, and several related drafts including mine were discussed simultaneously during this discussion. Finally, this draft was expired without any explicit decision because of security problem... Hope this helps. Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 10:43:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11060; Tue, 9 Nov 2004 10:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRY1K-00030W-Cn; Tue, 09 Nov 2004 10:34:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRXl3-0005md-9X for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 10:18:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07689 for ; Tue, 9 Nov 2004 10:18:06 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRXlo-0006Ax-OK for dhcwg@ietf.org; Tue, 09 Nov 2004 10:18:57 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id iA9FHa3U012596; Tue, 9 Nov 2004 16:17:36 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id iA9FHZnX015986; Tue, 9 Nov 2004 16:17:35 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 9 Nov 2004 16:17:35 +0100 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT Message-ID: <20041109151735.GH15501@sverresborg.uninett.no> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Nov 09, 2004 at 08:47:20AM -0500, Ted Lemon wrote: > In reading the lifetime draft, I am generally _very_ happy with it. > However, there is one point that I think is a mistake - allowing the > time to be set to an unreasonably large value. In considering this, I I understand your concern, but I don't see why it should be disallowed. The administrator should be able to figure out what's reasonable in hers/his environment. To use the DNS ttl analogy, there's nothing stopping you from setting a needlessly large ttl value either. As for the minimum time. I think 600 is small enough, but I don't see any harm in making it smaller if you or others see a potential need. I think the minimum should be in the order of minutes, but I don' have a strong opinion on the exact value. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 10:54:58 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12502; Tue, 9 Nov 2004 10:54:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYDI-0005uZ-Mm; Tue, 09 Nov 2004 10:47:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRY2Y-0003JZ-Jz for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 10:36:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10194 for ; Tue, 9 Nov 2004 10:36:12 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRY3J-0006eP-Mr for dhcwg@ietf.org; Tue, 09 Nov 2004 10:37:02 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-1.cisco.com with ESMTP; 09 Nov 2004 11:00:26 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA9FZe9D025048 for ; Tue, 9 Nov 2004 10:35:41 -0500 (EST) Received: from mjs-xp.cisco.com (rtp-vpn2-229.cisco.com [10.82.240.229]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX17995; Tue, 9 Nov 2004 10:35:38 -0500 (EST) Message-Id: <4.3.2.7.2.20041109102402.01e5ef40@goblet.cisco.com> X-Sender: mjs@goblet.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 09 Nov 2004 10:34:17 -0500 To: dhcwg@ietf.org From: Mark Stapp Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [dhcwg] dhcpv6 'zone suffix' option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org it seemed to me that the discussion in the wg meeting revolved around who was going to do a dns update. to me, it seemed that what was motivating the zone suffix option proposal was simpler (and less controversial). the v6 fqdn option, as it's specified now, can't really be used to carry a base domain name from the PE router to the CPE router along with prefix delegation. are there cases where that is desirable - where the delegating ISP knows the base dns domain in which the customer's hosts will reside? if so, then I'd prefer that we extend the fqdn option so that it can be used to carry just a domain name, and be used in the prefix delegation flavor of the protocol. if we think it's necessary to make it clear that the fqdn option is being used this way, perhaps we could allocate a flag bit in the fqdn option to indicate that? -- Mark _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 11:34:21 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16884; Tue, 9 Nov 2004 11:34:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYmj-0008B6-R8; Tue, 09 Nov 2004 11:23:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYey-0003f8-26 for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 11:15:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14697 for ; Tue, 9 Nov 2004 11:15:53 -0500 (EST) Received: from raven.ecs.soton.ac.uk ([152.78.70.1]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRYfj-0007mE-89 for dhcwg@ietf.org; Tue, 09 Nov 2004 11:16:44 -0500 Received: from magpie.ecs.soton.ac.uk (magpie.ecs.soton.ac.uk [152.78.68.131]) by raven.ecs.soton.ac.uk (8.12.10/8.12.10) with ESMTP id iA9GFmGn021259 for ; Tue, 9 Nov 2004 16:15:48 GMT Received: from login.ecs.soton.ac.uk (IDENT:root@login [152.78.68.162]) by magpie.ecs.soton.ac.uk (8.9.3/8.9.3) with ESMTP id QAA02957 for ; Tue, 9 Nov 2004 16:15:46 GMT Received: (from tjc@localhost) by login.ecs.soton.ac.uk (8.11.6/8.11.6) id iA9GFkS32291 for dhcwg@ietf.org; Tue, 9 Nov 2004 16:15:46 GMT Date: Tue, 9 Nov 2004 16:15:46 +0000 From: Tim Chown To: dhcwg@ietf.org Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT Message-ID: <20041109161546.GC28304@login.ecs.soton.ac.uk> Mail-Followup-To: dhcwg@ietf.org References: <20041109151735.GH15501@sverresborg.uninett.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20041109151735.GH15501@sverresborg.uninett.no> User-Agent: Mutt/1.4i X-MailScanner-Information: Please contact helpdesk@ecs.soton.ac.uk for more information X-ECS-MailScanner: Found to be clean X-MailScanner-From: tjc@smtp.ecs.soton.ac.uk X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Nov 09, 2004 at 04:17:35PM +0100, Stig Venaas wrote: > > To use the DNS ttl analogy, there's nothing stopping you from setting > a needlessly large ttl value either. Right, but the draft can state the issues and leave it for the admin to make an informed choice. -- Tim _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 11:42:00 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17782; Tue, 9 Nov 2004 11:42:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYxn-0001az-Ru; Tue, 09 Nov 2004 11:35:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYms-0008Jz-AG for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 11:24:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15866 for ; Tue, 9 Nov 2004 11:24:03 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRYne-00080z-BC for dhcwg@ietf.org; Tue, 09 Nov 2004 11:24:54 -0500 Received: from [130.129.132.183] (unknown [130.129.132.183]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 47A8256889; Tue, 9 Nov 2004 08:22:56 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <20041109151735.GH15501@sverresborg.uninett.no> References: <20041109151735.GH15501@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <97FEEA2C-326B-11D9-AA52-000A95D6A618@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT Date: Tue, 9 Nov 2004 11:22:47 -0500 To: Stig Venaas X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Nov 9, 2004, at 10:17 AM, Stig Venaas wrote: > I understand your concern, but I don't see why it should be disallowed. > The administrator should be able to figure out what's reasonable in > hers/his environment. > > To use the DNS ttl analogy, there's nothing stopping you from setting > a needlessly large ttl value either. It's a really phat DoS attack - you send out one bogus message with a really long lifetime, and the information will never be refreshed. I would argue that DNS needs to have a limit on TTLs also, but that's not my bailiwick. :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 11:45:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18381; Tue, 9 Nov 2004 11:45:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZ2e-0002nG-SL; Tue, 09 Nov 2004 11:40:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRYpk-0000PS-4C for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 11:27:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16217 for ; Tue, 9 Nov 2004 11:27:01 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRYqW-00086Y-JV for dhcwg@ietf.org; Tue, 09 Nov 2004 11:27:52 -0500 Received: from [130.129.132.183] (unknown [130.129.132.183]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 40A7B56886; Tue, 9 Nov 2004 08:26:31 -0800 (PST) (envelope-from mellon@nominum.com) In-Reply-To: <4.3.2.7.2.20041109102402.01e5ef40@goblet.cisco.com> References: <4.3.2.7.2.20041109102402.01e5ef40@goblet.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <18427AF8-326C-11D9-AA52-000A95D6A618@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhcpv6 'zone suffix' option Date: Tue, 9 Nov 2004 11:26:22 -0500 To: Mark Stapp X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Nov 9, 2004, at 10:34 AM, Mark Stapp wrote: > it seemed to me that the discussion in the wg meeting revolved around > who was going to do a dns update. to me, it seemed that what was > motivating the zone suffix option proposal was simpler (and less > controversial). > > the v6 fqdn option, as it's specified now, can't really be used to > carry a base domain name from the PE router to the CPE router along > with prefix delegation. are there cases where that is desirable - > where the delegating ISP knows the base dns domain in which the > customer's hosts will reside? if so, then I'd prefer that we extend > the fqdn option so that it can be used to carry just a domain name, > and be used in the prefix delegation flavor of the protocol. if we > think it's necessary to make it clear that the fqdn option is being > used this way, perhaps we could allocate a flag bit in the fqdn option > to indicate that? I agree with you, but I don't think there's any reason for a flag - you can tell from the context what is going on - if you get an FQDN option in a prefix delegation message, it's telling you what suffix to use for that delegation. I guess the big change would be that if you get a client request with no FQDN option, do you send one back with DNS suffix information, or not? I guess this could be decided by the ORO. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 11:56:32 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA19672; Tue, 9 Nov 2004 11:56:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZBt-0005ON-0c; Tue, 09 Nov 2004 11:49:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRZ5P-0003oF-1Q for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 11:43:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18002 for ; Tue, 9 Nov 2004 11:43:12 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRZ6B-00008x-Cj for dhcwg@ietf.org; Tue, 09 Nov 2004 11:44:03 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id iA9Ggg3U000591; Tue, 9 Nov 2004 17:42:42 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id iA9GgfmF016359; Tue, 9 Nov 2004 17:42:41 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 9 Nov 2004 17:42:41 +0100 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT Message-ID: <20041109164241.GC16214@sverresborg.uninett.no> References: <20041109151735.GH15501@sverresborg.uninett.no> <97FEEA2C-326B-11D9-AA52-000A95D6A618@nominum.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <97FEEA2C-326B-11D9-AA52-000A95D6A618@nominum.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Nov 09, 2004 at 11:22:47AM -0500, Ted Lemon wrote: > On Nov 9, 2004, at 10:17 AM, Stig Venaas wrote: > >I understand your concern, but I don't see why it should be disallowed. > >The administrator should be able to figure out what's reasonable in > >hers/his environment. > > > >To use the DNS ttl analogy, there's nothing stopping you from setting > >a needlessly large ttl value either. > > It's a really phat DoS attack - you send out one bogus message with a > really long lifetime, and the information will never be refreshed. I > would argue that DNS needs to have a limit on TTLs also, but that's not > my bailiwick. :') Which means you don't want infinity either then? Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 13:20:24 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27093; Tue, 9 Nov 2004 13:20:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRaZV-0006CU-6v; Tue, 09 Nov 2004 13:18:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRaWe-0005eM-LA for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 13:15:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26787 for ; Tue, 9 Nov 2004 13:15:24 -0500 (EST) From: kck@netcom.com Received: from smtp6.mindspring.com ([207.69.200.110]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRaXO-0002Z4-LI for dhcwg@ietf.org; Tue, 09 Nov 2004 13:16:17 -0500 Received: from [192.168.167.44] (helo=wamui06.slb.atl.earthlink.net) by smtp6.mindspring.com with esmtp (Exim 3.33 #1) id 1CRaWW-0004b2-00 for dhcwg@ietf.org; Tue, 09 Nov 2004 13:15:20 -0500 Message-ID: <28895635.1100024120896.JavaMail.root@wamui06.slb.atl.earthlink.net> Date: Tue, 9 Nov 2004 10:15:19 -0800 (GMT-08:00) To: dhcwg@ietf.org Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Earthlink Zoo Mail 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: kck@netcom.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit > On Nov 9, 2004, at 10:17 AM, Stig Venaas wrote: > >I understand your concern, but I don't see why it should be disallowed. > >The administrator should be able to figure out what's reasonable in > >hers/his environment. > > > >To use the DNS ttl analogy, there's nothing stopping you from setting > >a needlessly large ttl value either. > > It's a really phat DoS attack - you send out one bogus message with a > really long lifetime, and the information will never be refreshed. I > would argue that DNS needs to have a limit on TTLs also, but that's not > my bailiwick. :') The amount of damage that can be done in 1 day or even 1 hour is great. Not sure a TTL is really the device to protect against a DoS attack. However, I think there are other reasons for keeping the max time smaller and those can be used to argue for lower values but ulimately the admin controls the setting. --rich _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 14:15:13 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02478; Tue, 9 Nov 2004 14:15:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbNO-0007Eo-7Y; Tue, 09 Nov 2004 14:09:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbI1-0006VC-7z for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 14:04:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01573 for ; Tue, 9 Nov 2004 14:04:23 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbIo-0003nx-JL for dhcwg@ietf.org; Tue, 09 Nov 2004 14:05:15 -0500 Received: from [10.67.86.31] (unknown [130.129.97.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 481BB56856; Tue, 9 Nov 2004 11:03:52 -0800 (PST) (envelope-from mellon@nominum.com) In-Reply-To: <20041109161546.GC28304@login.ecs.soton.ac.uk> References: <20041109151735.GH15501@sverresborg.uninett.no> <20041109161546.GC28304@login.ecs.soton.ac.uk> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <13A8C10A-3282-11D9-AA52-000A95D6A618@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT Date: Tue, 9 Nov 2004 14:03:44 -0500 To: Tim Chown X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Nov 9, 2004, at 11:15 AM, Tim Chown wrote: > Right, but the draft can state the issues and leave it for the admin to > make an informed choice. That's not the problem. The problem is that if we don't specify a maximum, a rogue server will be able to give the client bogus information and arrange for the client to retain that information until the next time the router is rebooted. This could be quite a useful attack. You can also do this with a DNS query, but I would argue that it's harder, because DNS queries are spontaneous, whereas DHCP queries are cyclic (particularly if you have, say, a refresh time option... :') _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 14:16:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02628; Tue, 9 Nov 2004 14:16:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbOp-0007d3-S8; Tue, 09 Nov 2004 14:11:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbIZ-0006fB-E5 for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 14:04:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01616 for ; Tue, 9 Nov 2004 14:04:57 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbJN-0003oz-At for dhcwg@ietf.org; Tue, 09 Nov 2004 14:05:49 -0500 Received: from [10.67.86.31] (unknown [130.129.97.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 1958D5688B; Tue, 9 Nov 2004 11:04:28 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <20041109164241.GC16214@sverresborg.uninett.no> References: <20041109151735.GH15501@sverresborg.uninett.no> <97FEEA2C-326B-11D9-AA52-000A95D6A618@nominum.com> <20041109164241.GC16214@sverresborg.uninett.no> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2AFD96F1-3282-11D9-AA52-000A95D6A618@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT Date: Tue, 9 Nov 2004 14:04:23 -0500 To: Stig Venaas X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Nov 9, 2004, at 11:42 AM, Stig Venaas wrote: > Which means you don't want infinity either then? 'fraid so. :'} _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 14:19:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02908; Tue, 9 Nov 2004 14:19:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbR8-0008FQ-Ao; Tue, 09 Nov 2004 14:13:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRbKc-0006zi-Rp for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 14:07:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01790 for ; Tue, 9 Nov 2004 14:07:05 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRbLQ-0003rQ-Q8 for dhcwg@ietf.org; Tue, 09 Nov 2004 14:07:57 -0500 Received: from [10.67.86.31] (unknown [130.129.97.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 664C256889; Tue, 9 Nov 2004 11:06:35 -0800 (PST) (envelope-from mellon@nominum.com) In-Reply-To: <28895635.1100024120896.JavaMail.root@wamui06.slb.atl.earthlink.net> References: <28895635.1100024120896.JavaMail.root@wamui06.slb.atl.earthlink.net> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <76011F4F-3282-11D9-AA52-000A95D6A618@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more than IRT_DEFAULT Date: Tue, 9 Nov 2004 14:06:29 -0500 To: kck@netcom.com X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Nov 9, 2004, at 1:15 PM, kck@netcom.com wrote: > The amount of damage that can be done in 1 day or even 1 hour is > great. Not sure a TTL is really the device > to protect against a DoS attack What you say is true, but not compelling. I would rather that something that can be accomplished with ten minutes' access to the network not last indefinitely - it's better for a machine to be offline for a day than for an unbounded period of time. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 17:54:25 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24232; Tue, 9 Nov 2004 17:54:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRelL-0006Aq-6b; Tue, 09 Nov 2004 17:46:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CReam-0003XQ-7B for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 17:36:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA22558 for ; Tue, 9 Nov 2004 17:35:57 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRebb-0000TX-W2 for dhcwg@ietf.org; Tue, 09 Nov 2004 17:36:52 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2004 17:35:29 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA9MZQ9D006995; Tue, 9 Nov 2004 17:35:26 -0500 (EST) Received: from volzw2k (che-vpn-cluster-2-141.cisco.com [10.86.242.141]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX61193; Tue, 9 Nov 2004 17:35:10 -0500 (EST) From: "Bernie Volz" To: "'Ted Lemon'" , Subject: RE: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT Date: Tue, 9 Nov 2004 17:34:09 -0500 Organization: Cisco Message-ID: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <76011F4F-3282-11D9-AA52-000A95D6A618@nominum.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I'm not convinced we need to restrict the upper bound of the value. Today, without this option, there is no value. So, it is up to the = client to decide when it will refresh this information. With the introduction of the lifetime option, I still think it is up to clients to decide what values they'll accept and when they'll refresh. = Just because a "server" tells you to use 1 year or infinity, would you really honor that request? Would you really save this information across = reboots? (You might save it, but I think you'd want to refresh it and only use = the saved information if you didn't get any new.) Note that the draft says: When the client detects that the refresh time has expired, it SHOULD try to update its configuration data by sending an Information- Request as specified in section 18.1.5 of [RFC 3315], except that the client MUST delay sending the first Information-Request by a random amount of time between 0 and INF_MAX_DELAY. So, the value is just *another* trigger, not the only trigger. There is = NO language that says a client is prohibited from refreshing this = information sooner. So, while we COULD have an upper bound, I don't see that this is that critical. I do agree that the security section should point out that the client = may not want to honor very long values. And, it already has something about this: "or with a large or infinite value which would be no worse than a client that does not make use of this option." Note that the opposite argument for not needing a lower bound could also = be made, but I think there's much more value in that since we don't want it easy to cause a DoS attack because based on the above language, a client WOULD refresh its information. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Tuesday, November 09, 2004 2:06 PM > To: kck@netcom.com > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] Lifetime draft: refresh time should=20 > never be more thanIRT_DEFAULT >=20 >=20 > On Nov 9, 2004, at 1:15 PM, kck@netcom.com wrote: > > The amount of damage that can be done in 1 day or even 1 hour is > > great. Not sure a TTL is really the device > > to protect against a DoS attack >=20 > What you say is true, but not compelling. I would rather that=20 > something that can be accomplished with ten minutes' access to the=20 > network not last indefinitely - it's better for a machine to=20 > be offline=20 > for a day than for an unbounded period of time. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 18:08:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25170; Tue, 9 Nov 2004 18:08:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRf1h-0001Is-VI; Tue, 09 Nov 2004 18:03:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRewy-0008QF-2O for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 17:58:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24540 for ; Tue, 9 Nov 2004 17:58:53 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRexk-000124-SY for dhcwg@ietf.org; Tue, 09 Nov 2004 17:59:48 -0500 Received: from [10.67.86.31] (unknown [130.129.97.96]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id A4FB356835 for ; Tue, 9 Nov 2004 14:58:20 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> References: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT Date: Tue, 9 Nov 2004 17:58:05 -0500 To: " " X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Nov 9, 2004, at 5:34 PM, Bernie Volz wrote: > Today, without this option, there is no value. So, it is up to the > client to > decide when it will refresh this information. Right. That's why we need this draft. The protocol is slightly broken without this draft. > With the introduction of the lifetime option, I still think it is up to > clients to decide what values they'll accept and when they'll refresh. Right. And I am suggesting that we give client implementations a recommendation as to what the maximum value for this trigger is that they should use. Actually, I guess I'm suggesting that we give the clients a requirement, but I'd be okay with making it a recommendation, like "clients SHOULD use a value of 1 day if the value is greater than one day." > So, while we COULD have an upper bound, I don't see that this is that > critical. I didn't say it was critical. However, I think it is useful. > Note that the opposite argument for not needing a lower bound could > also be > made, but I think there's much more value in that since we don't want > it > easy to cause a DoS attack because based on the above language, a > client > WOULD refresh its information. A lower value doesn't help you to do a DoS attack, because there is no amplification (well, unless your client is broken and retransmits continuously if it gets a value of zero, but we could fix that by setting the minimum value to 1, or 15, and pointing out why it's important to enforce this limit). However, I think it was Ralph who pointed out that this is not a good idea, because unlike a DNS TTL which simply causes data to be discarded, this causes a packet to be transmitted. So I'm not arguing for a lower minimum value anymore. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 18:14:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25907; Tue, 9 Nov 2004 18:14:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRf6p-00039l-K2; Tue, 09 Nov 2004 18:09:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRf5z-0002oJ-MW for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 18:08:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA25165 for ; Tue, 9 Nov 2004 18:08:12 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRf6o-0001Dc-Pm for dhcwg@ietf.org; Tue, 09 Nov 2004 18:09:08 -0500 Received: from rtp-core-2.cisco.com (64.102.124.13) by rtp-iport-2.cisco.com with ESMTP; 09 Nov 2004 18:07:45 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iA9N7e9D013049; Tue, 9 Nov 2004 18:07:41 -0500 (EST) Received: from volzw2k (che-vpn-cluster-2-141.cisco.com [10.86.242.141]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX63861; Tue, 9 Nov 2004 18:07:40 -0500 (EST) From: "Bernie Volz" To: "'Ted Lemon'" , "'Mark Stapp'" Subject: RE: [dhcwg] dhcpv6 'zone suffix' option Date: Tue, 9 Nov 2004 18:07:35 -0500 Organization: Cisco Message-ID: <002d01c4c6b0$e63ae660$be878182@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <18427AF8-326C-11D9-AA52-000A95D6A618@nominum.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Well, if we restructure the FQDN option to be in the message options = area, it would confuse the issue when PD (IA_PD) and stateful (IA_NA) are in = the same client request, which at least in some cases this is what I would expect to happen. I personally believe the best place for the FQDN option is in the IA_* options area. If we just have it in the message options area, it isn't = clear as to which addresses (or prefixes) it applies to. If we allow it in the IAADDR options area, it greatly increases the complexity with likely (at least for now) marginal gain. While we could allow it in multiple = places, at least initially it is simpler to have it in one place (IA_* options, = IMHO). So, I'm presently inclined to leave the draft alone, at least in this respect. Having some means, a flag bit, to clearly communicate that the FQDN is = just the zone seems best to me. This could also be used when the client is allowed to perform updates -- the server can just send back the zone in = the FQDN and set the flag bit. The client then constructs the FQDN to use. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Tuesday, November 09, 2004 11:26 AM > To: Mark Stapp > Cc: dhcwg@ietf.org > Subject: Re: [dhcwg] dhcpv6 'zone suffix' option >=20 >=20 > On Nov 9, 2004, at 10:34 AM, Mark Stapp wrote: > > it seemed to me that the discussion in the wg meeting=20 > revolved around > > who was going to do a dns update. to me, it seemed that what was=20 > > motivating the zone suffix option proposal was simpler (and less=20 > > controversial). > > > > the v6 fqdn option, as it's specified now, can't really be used to > > carry a base domain name from the PE router to the CPE router along=20 > > with prefix delegation. are there cases where that is desirable -=20 > > where the delegating ISP knows the base dns domain in which the=20 > > customer's hosts will reside? if so, then I'd prefer that we extend=20 > > the fqdn option so that it can be used to carry just a domain name,=20 > > and be used in the prefix delegation flavor of the protocol. if we=20 > > think it's necessary to make it clear that the fqdn option is being=20 > > used this way, perhaps we could allocate a flag bit in the=20 > fqdn option=20 > > to indicate that? >=20 > I agree with you, but I don't think there's any reason for a=20 > flag - you=20 > can tell from the context what is going on - if you get an=20 > FQDN option=20 > in a prefix delegation message, it's telling you what suffix=20 > to use for=20 > that delegation. >=20 > I guess the big change would be that if you get a client request with=20 > no FQDN option, do you send one back with DNS suffix information, or=20 > not? I guess this could be decided by the ORO. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 9 22:12:46 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA15316; Tue, 9 Nov 2004 22:12:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRioh-0007SV-1H; Tue, 09 Nov 2004 22:06:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRinS-0007DX-Ld for dhcwg@megatron.ietf.org; Tue, 09 Nov 2004 22:05:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14629 for ; Tue, 9 Nov 2004 22:05:20 -0500 (EST) Received: from [61.144.161.54] (helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRio1-0005xm-5M for dhcwg@ietf.org; Tue, 09 Nov 2004 22:06:17 -0500 Received: from huawei.com (szxga02-in [172.24.2.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0I6Y00JB40HST3@szxga02-in.huawei.com> for dhcwg@ietf.org; Wed, 10 Nov 2004 11:03:29 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTP id <0I6Y003OE0EH3M@szxga02-in.huawei.com> fordhcwg@ietf.org; Wed, 10 Nov 2004 11:03:26 +0800 (CST) Received: from vineet70814 ([10.78.16.232]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar3 2004)) with ESMTPA id <0I6X00K06XX0QS@szxml02-in.huawei.com> fordhcwg@ietf.org; Wed, 10 Nov 2004 10:07:48 +0800 (CST) Date: Wed, 10 Nov 2004 10:09:59 +0800 From: Vineet Kumar Gautam To: dhcwg@ietf.org Message-id: <001001c4c6ca$618b2960$e8104e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 X-Mailer: Microsoft Outlook Express 5.50.4927.1200 X-Priority: 3 X-MSMail-priority: Normal X-imss-version: 2.7 X-imss-result: Passed X-imss-approveListMatch: *@huawei.com X-Spam-Score: 0.2 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [dhcwg] JDHCP api to get server info X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1626321790==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============1626321790== Content-type: multipart/alternative; boundary="Boundary_(ID_WKSUceYuKZveo61Um0wjtg)" This is a multi-part message in MIME format. --Boundary_(ID_WKSUceYuKZveo61Um0wjtg) Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT Hello all, I am not cleaer, how to get DHCP server information like server IP group id etc through java api provide by jDhcp. Please tell me. Vineet --Boundary_(ID_WKSUceYuKZveo61Um0wjtg) Content-type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 7BIT
Hello all,
    I am not cleaer, how to get DHCP server information
like server IP group id etc through java api provide by
jDhcp. Please tell me.
 
Vineet
     
--Boundary_(ID_WKSUceYuKZveo61Um0wjtg)-- --===============1626321790== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1626321790==-- From FHCGPG@msn.com Wed Nov 10 06:35:51 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA25089; Wed, 10 Nov 2004 06:35:51 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRqmT-0007no-1q; Wed, 10 Nov 2004 06:36:53 -0500 Received: from cable-66-190-200-199.thb.la.charter.com ([66.190.200.199]) by mx2.foretec.com with smtp (Exim 4.24) id 1CRqlT-0003z6-Vt; Wed, 10 Nov 2004 06:35:52 -0500 X-Message-Info: X2IX983UBt00gggQENecxCGN730XIH73cOpvkZNU51 Received: from 49.232.15.44 by ip-2-478-0-8.etr.FHCGPG@msn.com (AppleMailServer 88.5.4.8) id 8867500285 via NDR; Wed, 10 Nov 2004 14:26:44 +0300 Reply-To: "Jayne Benjamin" From: "Jayne Benjamin" To: "Dhcipv6-archive" Subject: Dhcipv6-archive Vic0din for you - Cheapy Date: Wed, 10 Nov 2004 08:32:44 -0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--14034058544684867" Message-Id: X-Spam-Score: 6.4 (++++++) X-Spam-Flag: YES X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c ----14034058544684867 Content-Type: text/html; charset="iso-0887-2" Content-Description: blair mate18.bill Content-Transfer-Encoding: quoted-printable You need Vicodin. You get it here. No need to wait any longer!
It is y= our unique chance to save on the medications up to 80%.
It is not just about saving. It is about boosting your health.










?OjQwkoPF3SpXNOOharmony|dhc= ipv6-archive@ietf.org">u*n*s*u*b*s*c*r*i*b*e
middlemen cowgirl sorghum sunk heel newcastle doherty glisten brisbane sex= tuplet archipelago obituary somehow antebellum chef thoroughgoing adult pa= radise=20 divination toast pasadena dervish impermeable hubert demagnify= wisecrack culture soutane diatribe vichy buy chartroom barge kind owly sn= yaptic compline airspeed ankle tutor repression lise=20 diadem hepatic= a birthplace cuprous nepal boswell misty citron playwriting sped duncan ch= eney nouakchott spook aau crimson aarhus mini cowslip anonymous baltimore = incorporate renounce buzzy lignum monotonous jenkins abash prosody chug ac= cipiter nylon pipsissewa christie crank wilful tupelo nate=20 ----14034058544684867-- From dhcwg-bounces@ietf.org Wed Nov 10 09:46:54 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13578; Wed, 10 Nov 2004 09:46:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtdk-0003b4-18; Wed, 10 Nov 2004 09:40:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRtYY-0002le-B3 for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 09:34:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12618 for ; Wed, 10 Nov 2004 09:34:40 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRtZW-0003S0-Ap for dhcwg@ietf.org; Wed, 10 Nov 2004 09:35:43 -0500 Received: from [10.67.87.103] (unknown [130.129.97.67]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 572EF56840; Wed, 10 Nov 2004 06:34:09 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) In-Reply-To: <002d01c4c6b0$e63ae660$be878182@amer.cisco.com> References: <002d01c4c6b0$e63ae660$be878182@amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <901AB2B0-3325-11D9-AA52-000A95D6A618@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhcpv6 'zone suffix' option Date: Wed, 10 Nov 2004 09:34:00 -0500 To: "Bernie Volz" X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org, "'Mark Stapp'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit If we're going to use a flag bit, then it's better to just have a different option that means "this is your zone." It's silly to overload it with a bit. The format for the options can be identical, if it makes sense, but there's no reason to complicate the option with control bits. I see your point about putting the option in the IA, Bernie - that makes sense. I think that's what we talked about before, although I admit I hadn't mentally made the distinction. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 10 10:27:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19813; Wed, 10 Nov 2004 10:27:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuFX-0007Ub-2C; Wed, 10 Nov 2004 10:19:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRuAP-0005KH-7o for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 10:13:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17350 for ; Wed, 10 Nov 2004 10:13:47 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRuBM-0004Z9-Q7 for dhcwg@ietf.org; Wed, 10 Nov 2004 10:14:50 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-2.cisco.com with ESMTP; 10 Nov 2004 07:25:06 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id iAAFD3nC013140; Wed, 10 Nov 2004 07:13:03 -0800 (PST) Received: from volzw2k ([161.44.65.168]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMX99249; Wed, 10 Nov 2004 10:13:07 -0500 (EST) From: "Bernie Volz" To: "'Ted Lemon'" , Subject: RE: [dhcwg] dhcpv6 'zone suffix' option Date: Wed, 10 Nov 2004 10:13:07 -0500 Organization: Cisco Message-ID: <000501c4c737$c8b832a0$a8412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <901AB2B0-3325-11D9-AA52-000A95D6A618@nominum.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Content-Transfer-Encoding: quoted-printable Cc: "'Mark Stapp'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I agree that using a separate option is the best (and we might as well = let the author of that separate draft continue that work). This also = benefits the case for putting the FQDN in the IA_* options area. About the location of the FQDN option, yeah ... I keep forgetting the complexities involved, since we have to handle client to server and = server to client communication and if the option is allowed to appear in = multiple places, it gets very messy. For example, if the option were just in the IAADDR options area, many = client to server messages don't include any IAADDRs. So, this would force the option to also be allowed in other places (IA_* options or message = options). This greatly complicates the client and server processing code. By putting it in the IA_* options, we're restricting it to stateful (PD = or NA) but I don't think that's an issue (especially if we don't use it to communicate the zone name). For Information-Request, the separate option can be used to communicate = the zone. There's no reason to use the FQDN option for this as the server = can't do any updates for the client since it has no idea what the client's addresses are. So, this means that there is NO immediate reason for me to revise draft-ietf-dhc-dhcpv6-fqdn-00.txt. Therefore, PLEASE REVIEW THIS DRAFT = and provide me comments -- good and bad -- so we can determine whether to = revise it or start the WG Last-Call. - Bernie > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Wednesday, November 10, 2004 9:34 AM > To: Bernie Volz > Cc: dhcwg@ietf.org; 'Mark Stapp' > Subject: Re: [dhcwg] dhcpv6 'zone suffix' option >=20 >=20 > If we're going to use a flag bit, then it's better to just have a=20 > different option that means "this is your zone." It's silly to=20 > overload it with a bit. The format for the options can be=20 > identical,=20 > if it makes sense, but there's no reason to complicate the=20 > option with=20 > control bits. I see your point about putting the option in the IA,=20 > Bernie - that makes sense. I think that's what we talked about=20 > before, although I admit I hadn't mentally made the distinction. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 10 11:28:17 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27322; Wed, 10 Nov 2004 11:28:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvAg-00016H-QL; Wed, 10 Nov 2004 11:18:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRv6K-0008Ub-JW for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 11:13:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25414 for ; Wed, 10 Nov 2004 11:13:37 -0500 (EST) Received: from paperclip.laurelnetworks.com ([63.94.127.69] ident=nobody) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRv7I-0006Ah-BG for dhcwg@ietf.org; Wed, 10 Nov 2004 11:14:41 -0500 Received: from postit.laurelnetworks.com (postit.laurelnetworks.com [63.94.127.21]) by paperclip.laurelnetworks.com (Laurel/Laurel) with ESMTP id iAAGDZN4020810 for ; Wed, 10 Nov 2004 11:13:35 -0500 Received: from laurelnetworks.com (tgol-pc-linux.dhcp.pit.laurelnetworks.com [10.0.17.220]) by postit.laurelnetworks.com (Laurel/Laurel) with ESMTP id iAAGDZie025162 for ; Wed, 10 Nov 2004 11:13:35 -0500 Message-ID: <41923E2F.1060103@laurelnetworks.com> Date: Wed, 10 Nov 2004 11:13:35 -0500 From: Tayfun Gol User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020823 Netscape/7.0 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dhcwg@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Content-Transfer-Encoding: 7bit Subject: [dhcwg] RFC 3203 client impl X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Does anyone know if there are any DHCP clients that support RFC 3203 - reconfigure extension? Thanks, Tayfun _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 10 11:32:01 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27864; Wed, 10 Nov 2004 11:32:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvEe-0001t7-6P; Wed, 10 Nov 2004 11:22:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRv9y-0000m9-Ao for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 11:17:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26136 for ; Wed, 10 Nov 2004 11:17:23 -0500 (EST) Received: from mail.syce.net ([192.16.178.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvAw-0006IV-Rh for dhcwg@ietf.org; Wed, 10 Nov 2004 11:18:27 -0500 Received: from localhost (mail.syce.net [IPv6:2001:218:4fd::25]) by mail.syce.net (8.12.11/8.12.11) with ESMTP/inet6 id iAAGH8fm096628; Thu, 11 Nov 2004 01:17:09 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Thu, 11 Nov 2004 01:17:10 +0900 (JST) Message-Id: <20041111.011710.350532059.fujisaki@syce.net> To: dhcwg@ietf.org From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: <901AB2B0-3325-11D9-AA52-000A95D6A618@nominum.com> References: <002d01c4c6b0$e63ae660$be878182@amer.cisco.com> <901AB2B0-3325-11D9-AA52-000A95D6A618@nominum.com> X-Mailer: Mew version 3.3 on XEmacs 21.4.14 (Reasonable Discussion) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [dhcwg] dhcpv6 source address selection policy option X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Source Address Selection Policy option for DHCPv6 We got some comments and questions at the meeting. (thanks a lot!) One big question was why we use DHCP where dynamic changes could be occurred. Our proposal in this draft is to distribute the source address selection policy mainly at the node set up stage, and not changing the policy dynamically. And as Ted kindly pointed out in the meeting, we assume the policy is static and the lifetime of the distributed policy is bound to the address assigned to the node. When one upstream link goes down, dynamic changes to the user network will occur. The changes could be revoking address prefix assigned from the failed link, and at that case, the policy bound to that assigned prefix would be also revoked. This change is caused by the revocation of that address prefix, and not caused by other trigger. So, we do not assume the dynamic changes such as routing affect to the policy directly. I hope this could be an answer to the question John asked. Yours sincerely, -- Tomohiro Fujisaki, Nippon Telegraph and Telephone Corporation _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 10 11:45:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29086; Wed, 10 Nov 2004 11:45:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvXn-0006LW-Uy; Wed, 10 Nov 2004 11:42:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRvPD-0004fi-Nd for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 11:33:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27996 for ; Wed, 10 Nov 2004 11:33:09 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRvQ9-0006kV-R2 for dhcwg@ietf.org; Wed, 10 Nov 2004 11:34:13 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id iAAGWU3U005584; Wed, 10 Nov 2004 17:32:30 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id iAAGWTZp021136; Wed, 10 Nov 2004 17:32:29 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 10 Nov 2004 17:32:29 +0100 From: Stig Venaas To: Bernie Volz Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT Message-ID: <20041110163229.GC21010@sverresborg.uninett.no> References: <76011F4F-3282-11D9-AA52-000A95D6A618@nominum.com> <002a01c4c6ac$654323f0$be878182@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: kck@netcom.com, dhcwg@ietf.org, "'Ted Lemon'" X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Nov 09, 2004 at 05:34:09PM -0500, Bernie Volz wrote: [...] > Note that the draft says: > > When the client detects that the refresh time has expired, it SHOULD > try to update its configuration data by sending an Information- > Request as specified in section 18.1.5 of [RFC 3315], except that the > client MUST delay sending the first Information-Request by a random > amount of time between 0 and INF_MAX_DELAY. > > So, the value is just *another* trigger, not the only trigger. There is NO > language that says a client is prohibited from refreshing this information > sooner. It also says The information refresh time option specifies an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. So I think this should be pretty clear. > So, while we COULD have an upper bound, I don't see that this is that > critical. > > I do agree that the security section should point out that the client may > not want to honor very long values. And, it already has something about > this: "or with a large or infinite value which would be no worse than a > client that does not make use of this option." Yes, I also see problems with large values, and think some recommendation like this should be sufficient. I'm a bit concerned with infinity perhaps. If we don't think large values are good, do we want infinity? I must say though, that I don't think this option changes much. Currently you can also easily send clients forged responses listing wrong info, and there's no telling when client will choose to update it. The triggers a client currently uses, should still be used to refresh info when using this option. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 10 13:34:23 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10430; Wed, 10 Nov 2004 13:34:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxFV-00029W-3L; Wed, 10 Nov 2004 13:31:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRx60-00082i-LM for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 13:21:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08306 for ; Wed, 10 Nov 2004 13:21:25 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRx70-0000j8-K7 for dhcwg@ietf.org; Wed, 10 Nov 2004 13:22:31 -0500 Received: from [130.129.131.238] (unknown [130.129.131.238]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 1538656881 for ; Wed, 10 Nov 2004 10:20:43 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <000501c4c737$c8b832a0$a8412ca1@amer.cisco.com> References: <000501c4c737$c8b832a0$a8412ca1@amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <3517ADF8-3345-11D9-AA52-000A95D6A618@nominum.com> Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] dhcpv6 'zone suffix' option Date: Wed, 10 Nov 2004 13:20:32 -0500 To: " " X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Nov 10, 2004, at 10:13 AM, Bernie Volz wrote: > By putting it in the IA_* options, we're restricting it to stateful > (PD or > NA) but I don't think that's an issue (especially if we don't use it to > communicate the zone name). I would encourage you not to put any language in the draft that explicitly refers to stateful versus not stateful. I think it's likely that we will want to support dynamic DNS updates with the Information Request message using the FQDN option. In this case, the client would have to send an IA option, in order to identify it for the purposes of doing the DNS update. So if you don't explicitly say anything about stateful vs. non-stateful, we don't need to update your draft when we write a draft explaining how to do updates with stateless DHCPv6. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 10 13:55:27 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12826; Wed, 10 Nov 2004 13:55:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxUj-0005ZN-BD; Wed, 10 Nov 2004 13:47:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxOr-0004XP-2u for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 13:40:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11034 for ; Wed, 10 Nov 2004 13:40:55 -0500 (EST) Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxPq-0001P9-MR for dhcwg@ietf.org; Wed, 10 Nov 2004 13:41:59 -0500 Received: from rtp-core-1.cisco.com (64.102.124.12) by rtp-iport-1.cisco.com with ESMTP; 10 Nov 2004 14:05:21 -0500 X-BrightmailFiltered: true Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id iAAIeMR5007020; Wed, 10 Nov 2004 13:40:23 -0500 (EST) Received: from volzw2k (dhcp-10-86-160-58.cisco.com [10.86.160.58]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id AMY19729; Wed, 10 Nov 2004 13:40:21 -0500 (EST) From: "Bernie Volz" To: "'Ted Lemon'" , Subject: RE: [dhcwg] dhcpv6 'zone suffix' option Date: Wed, 10 Nov 2004 13:40:21 -0500 Organization: Cisco Message-ID: <001a01c4c754$bbbecb00$a8412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <3517ADF8-3345-11D9-AA52-000A95D6A618@nominum.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Fine by me. I'll double check but I don't believe that I mentioned stateful in the current draft. > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > On Behalf Of Ted Lemon > Sent: Wednesday, November 10, 2004 1:21 PM > To: > Subject: Re: [dhcwg] dhcpv6 'zone suffix' option > > > On Nov 10, 2004, at 10:13 AM, Bernie Volz wrote: > > By putting it in the IA_* options, we're restricting it to stateful > > (PD or > > NA) but I don't think that's an issue (especially if we > don't use it to > > communicate the zone name). > > I would encourage you not to put any language in the draft that > explicitly refers to stateful versus not stateful. I think it's > likely that we will want to support dynamic DNS updates with the > Information Request message using the FQDN option. In this > case, the > client would have to send an IA option, in order to identify > it for the > purposes of doing the DNS update. So if you don't explicitly say > anything about stateful vs. non-stateful, we don't need to > update your > draft when we write a draft explaining how to do updates with > stateless > DHCPv6. > > > _______________________________________________ > 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-bounces@ietf.org Wed Nov 10 14:16:43 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15330; Wed, 10 Nov 2004 14:16:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxrA-0002PQ-9j; Wed, 10 Nov 2004 14:10:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRxk3-0000T7-Dr for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 14:02:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13643 for ; Wed, 10 Nov 2004 14:02:49 -0500 (EST) Received: from chimera.incognito.com ([206.172.52.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CRxl1-00020d-8m for dhcwg@ietf.org; Wed, 10 Nov 2004 14:03:54 -0500 Received: from [206.172.52.116] (helo=HOMER.incognito.com.) by chimera.incognito.com with esmtp (Exim 4.34) id 1CRxjK-0000hk-V8; Wed, 10 Nov 2004 11:02:08 -0800 Received: by homer.incognito.com with Internet Mail Service (5.5.2653.19) id ; Wed, 10 Nov 2004 11:01:35 -0800 Message-ID: From: "Kostur, Andre" To: "'Tayfun Gol'" , dhcwg@ietf.org Subject: RE: [dhcwg] RFC 3203 client impl Date: Wed, 10 Nov 2004 11:01:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) X-Spam-Score: -5.8 (-----) X-Spam-Score: 0.8 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1260693004==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1260693004== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C4C757.AF4344C0" 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_01C4C757.AF4344C0 Content-Type: text/plain; charset="iso-8859-1" As far as I know, there are no clients which support RFC 3118 - DHCP Authentication, which is a requirement for RFC 3203... -----Original Message----- From: Tayfun Gol [mailto:tgol@laurelnetworks.com] Sent: Wednesday, November 10, 2004 8:14 AM To: dhcwg@ietf.org Subject: [dhcwg] RFC 3203 client impl Does anyone know if there are any DHCP clients that support RFC 3203 - reconfigure extension? Thanks, Tayfun _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg ------_=_NextPart_001_01C4C757.AF4344C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [dhcwg] RFC 3203 client impl

As far as I know, there are no clients which support = RFC 3118 - DHCP Authentication, which is a requirement for RFC = 3203...

-----Original Message-----
From: Tayfun Gol [mailto:tgol@laurelnetworks.com]
Sent: Wednesday, November 10, 2004 8:14 AM
To: dhcwg@ietf.org
Subject: [dhcwg] RFC 3203 client impl


Does anyone know if there are any DHCP clients that = support RFC 3203 -
reconfigure extension?
Thanks,
Tayfun


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

------_=_NextPart_001_01C4C757.AF4344C0-- --===============1260693004== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1260693004==-- From dhcwg-bounces@ietf.org Wed Nov 10 15:23:16 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23538; Wed, 10 Nov 2004 15:23:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRysB-000711-81; Wed, 10 Nov 2004 15:15:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CRynD-0004cl-Pe; Wed, 10 Nov 2004 15:10: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 PAA21459; Wed, 10 Nov 2004 15:10:09 -0500 (EST) Message-Id: <200411102010.PAA21459@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Wed, 10 Nov 2004 15:10:09 -0500 Cc: dhcwg@ietf.org Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-isnsoption-13.txt X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Dynamic Host Configuration Working Group of the IETF. Title : The IPv4 DHCP Options for the Internet Storage Name Service Author(s) : C. Monia, et al. Filename : draft-ietf-dhc-isnsoption-13.txt Pages : 14 Date : 2004-11-9 This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. iSNS provides discovery and management capabilities for Internet SCSI (iSCSI) and Internet Fibre Channel Protocol (iFCP) storage devices in an enterprise-scale IP storage network. iSNS provides intelligent storage management services comparable to those found in Fibre Channel networks, allowing a commodity IP network to function in a similar capacity as a storage area network. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-isnsoption-13.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. 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-isnsoption-13.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-isnsoption-13.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: <2004-11-10154057.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-dhc-isnsoption-13.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-dhc-isnsoption-13.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2004-11-10154057.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Wed Nov 10 17:17:34 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11142; Wed, 10 Nov 2004 17:17:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0dI-0007Rs-JB; Wed, 10 Nov 2004 17:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS0Qv-00044q-3F for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 16:55:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09034 for ; Wed, 10 Nov 2004 16:55:14 -0500 (EST) From: matthew.ford@bt.com Received: from smtp2.smtp.bt.com ([217.32.164.150]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS0Rw-00006o-8w for dhcwg@ietf.org; Wed, 10 Nov 2004 16:56:21 -0500 Received: from i2km96-ukbr.domain1.systemhost.net ([193.113.197.84]) by smtp2.smtp.bt.com with Microsoft SMTPSVC(6.0.3790.80); Wed, 10 Nov 2004 21:55:50 +0000 Received: from i2km41-ukdy.domain1.systemhost.net ([193.113.30.29]) by i2km96-ukbr.domain1.systemhost.net with Microsoft SMTPSVC(5.0.2195.6713); Wed, 10 Nov 2004 21:55:50 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] dhcpv6 source address selection policy option Date: Wed, 10 Nov 2004 21:55:49 -0000 Message-ID: <0AAF93247C75E3408638B965DEE11A700B164379@i2km41-ukdy.domain1.systemhost.net> Thread-Topic: [dhcwg] dhcpv6 source address selection policy option Thread-Index: AcTHQuw34cAPu7YOSHWOGSZ9VPad0wAK9f9w To: , X-OriginalArrivalTime: 10 Nov 2004 21:55:50.0288 (UTC) FILETIME=[0AB16900:01C4C770] X-Spam-Score: 0.3 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable On 10 November 2004 11:17, dhcwg-bounces@ietf.org (mailto:dhcwg-bounces@ietf.org) wrote: > Source Address Selection Policy option for DHCPv6 > > When one upstream link goes down, dynamic changes to the user network > will occur. The changes could be revoking address prefix assigned from > the failed link, and at that case, the policy bound to that assigned > prefix would be also revoked. This change is caused by the revocation > of that address prefix, and not caused by other trigger. I wasn't at the dhc meeting so apologies in advance if this was already discussed there. But doesn't the above statement regarding the need to revoke address assignments based upon dynamic changes in the upstream connectivity suggest that RA is more appropriate than DHCP as a mechanism substrate here? -- Mat _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From admin@staffadministrator.com Wed Nov 10 19:29:11 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA22767 for ; Wed, 10 Nov 2004 19:29:11 -0500 (EST) Received: from w072.z064001136.chi-il.dsl.cnc.net ([64.1.136.72]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CS2ql-0003CG-RJ for dhcipv6-archive@ietf.org; Wed, 10 Nov 2004 19:30:20 -0500 Received: from [130.221.116.164] by w072.z064001136.chi-il.dsl.cnc.net id <3813061-60871>; Wed, 10 Nov 2004 23:28:33 -0100 Message-ID: <84r-9-sl-u2p-i$841v$0i$j56-scp@pg7nrr0h8zs> From: "Administrator" To: st@ietf.org Subject: ADV: Staff Announcement Date: Wed, 10 Nov 04 23:28:33 GMT X-Priority: 1 X-MSMail-Priority: High X-Mailer: The Bat! (v1.52f) Business MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5FBD6FE2.A2215.A3" X-Spam-Score: 19.8 (+++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d This is a multi-part message in MIME format. --5FBD6FE2.A2215.A3 Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Attention All Nonprofit Organizations: Members and Staff You Must Respond By 5 P.M. Friday, November 12, 2004. Through a special arrangement, Avtech Direct is offering a limited allotment of BRAND NEW, top of-the-line, name-brand desktop computers at more than 50% off MSRP to all Nonprofit Members and Staff who respond to this message before 5 P.M., Friday, November 12, 2004. All desktop computers are brand-new packed in their original boxes, and come with a full manufacturer's warranty plus a 100% satisfaction guarantee. These professional grade Desktops are fully equipped with 2005 next generation technology, making these the best performing computers money can buy. Avtech Direct is offering these feature rich, top performing Desktops with the latest technology at an amazing price to all who call: 1-800-795-8466 by 5 P.M. Friday, November 12, 2004 The fast and powerful AT-3200 series Desktop features: * IBM Processor for amazing speed and performance * 128MB DDR RAM, -- Upgradeable to 1024 * 20 GB UDMA Hard Drive, -- Upgradeable to 80 GB * 52X CD-Rom Drive, -- Upgradeable to DVD/CDRW * Next Generation 2005 Technology * Premium video and sound -- For enhanced colors and graphics * Full Connectivity with Fax modem/Lan/IEE 1394/USB 2.0 * Soft Touch Keyboard and scroll mouse * Internet Ready * Network Ready * 1 Year parts and labor warranty * Priority customer service and tech support MSRP $499 ........................................ Your Cost $227 How to qualify: 1. You must be a Member, Staff or Associate of a Nonprofit. 2. All desktop computers will be available on a first come first serve basis. 3. You must call 1-800-795-8466 by 5 P.M. Friday, November 12, 2004. and we will hold the desktops you request on will call. 4. You are not obligated in any way. 5. 100% Satisfaction Guaranteed. 6. Ask for Department C. Call Avtech Direct 1-800-795-8466 before 5 P.M. Friday, November 12, 2004 Visit our website at http://www.avtechcomputers.com If you wish to unsubscribe from this list, please go to http://www.avtechcomputers.com/announcements.asp Avtech Direct 22647 Ventura Blvd. Suite 374 Woodland Hills, CA 91364 --5FBD6FE2.A2215.A3-- From dhcwg-bounces@ietf.org Wed Nov 10 20:53:10 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA00499; Wed, 10 Nov 2004 20:53:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS45r-0004R3-5a; Wed, 10 Nov 2004 20:49:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CS42h-0003m0-4X for dhcwg@megatron.ietf.org; Wed, 10 Nov 2004 20:46:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29828 for ; Wed, 10 Nov 2004 20:46:28 -0500 (EST) Received: from mail.syce.net ([192.16.178.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS43j-00050W-V0 for dhcwg@ietf.org; Wed, 10 Nov 2004 20:47:36 -0500 Received: from localhost (mail.syce.net [IPv6:2001:218:4fd::25]) by mail.syce.net (8.12.11/8.12.11) with ESMTP/inet6 id iAB1kH76040198; Thu, 11 Nov 2004 10:46:17 +0900 (JST) (envelope-from fujisaki@syce.net) Date: Thu, 11 Nov 2004 10:46:28 +0900 (JST) Message-Id: <20041111.104628.846933399.fujisaki@syce.net> To: matthew.ford@bt.com Subject: Re: [dhcwg] dhcpv6 source address selection policy option From: (Tomohiro -INSTALLER- =?iso-2022-jp?B?RnVqaXNha2kvGyRCRiM6ahsoQiAbJEJDUjkoGyhC?=) In-Reply-To: <0AAF93247C75E3408638B965DEE11A700B164379@i2km41-ukdy.domain1.systemhost.net> References: <0AAF93247C75E3408638B965DEE11A700B164379@i2km41-ukdy.domain1.systemhost.net> X-Mailer: Mew version 3.3 on XEmacs 21.4.14 (Reasonable Discussion) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit | > Source Address Selection Policy option for DHCPv6 | > | | > When one upstream link goes down, dynamic changes to the user network | > will occur. The changes could be revoking address prefix assigned from | > the failed link, and at that case, the policy bound to that assigned | > prefix would be also revoked. This change is caused by the revocation | > of that address prefix, and not caused by other trigger. | | I wasn't at the dhc meeting so apologies in advance if this was already | discussed there. But doesn't the above statement regarding the need to | revoke address assignments based upon dynamic changes in the upstream | connectivity suggest that RA is more appropriate than DHCP as a | mechanism substrate here? I wrote an example behavior, and did not say the preference of RA nor DHCP. I'm sorry for ambiguous statement. -- Tomohiro Fujisaki, Nippon Telegraph and Telephone Corporation _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From HKEQHW@hotmail.com Wed Nov 10 22:37:29 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08709; Wed, 10 Nov 2004 22:37:29 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CS5nC-00074Y-Mw; Wed, 10 Nov 2004 22:38:39 -0500 Received: from [211.150.124.34] (helo=65.246.255.50 ident=CacheFlow Server) by mx2.foretec.com with smtp (Exim 4.24) id 1CS5m2-0005td-VO; Wed, 10 Nov 2004 22:37:29 -0500 X-Message-Info: I19BHW00XXgea061vqXoCQ00F4ugXsaUCU149 Received: from 240.96.113.204 by ip-3-95-37-345.sit.HKEQHW@hotmail.com (AppleMailServer 71.4.4.8) id 41096041541414 via NDR; Thu, 11 Nov 2004 07:33:12 +0400 Reply-To: "Diego Miles" From: "Diego Miles" To: "Dhcipv6-archive" Subject: Dhcipv6-archive Get Vic0din here now Date: Wed, 10 Nov 2004 22:30:12 -0500 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--58736032148872070" Message-Id: X-Spam-Score: 25.4 (+++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 ----58736032148872070 Content-Type: text/html; charset="iso-3659-6" Content-Description: rodney characteristic42.bursitis Content-Transfer-Encoding: quoted-printable You need Vicodin. You get it here. No need to wait any longer!
It is y= our unique chance to save on the medications up to 80%.
It is not just about saving. It is about boosting your health.










?OjQwkoPF3SpXNOOstopcock|dh= cipv6-archive@ietf.org">u*n*s*u*b*s*c*r*i*b*e
crosslink efflorescent mamma bootlegged pigpen cohere ass army mimicked ap= port amputee fearsome jaguar brisbane ideologue chao providential conspire= consecrate billie=20 copyright democrat edition offprint persuade sleig= h elope emasculate vivify make katz peru anaglyph dorothea commingle popis= h alexandria misanthropic inbreed aid=20 linger mortal glottis bibliog= raphy admonition appalachia connotative fireman flak anarch countersink ee= rie fibonacci=20 ----58736032148872070-- From MECDI@yahoo.com Thu Nov 11 06:55:01 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00062; Thu, 11 Nov 2004 06:55:01 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSDYb-00086i-9V; Thu, 11 Nov 2004 06:56:15 -0500 Received: from [80.239.111.120] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CSDXQ-0005mE-48; Thu, 11 Nov 2004 06:54:52 -0500 X-Message-Info: IKBPsjtJ17ozfRUwwqoNFUFdHOjVCTdk5 Received: from solecism-dns.yahoo.com (7.228.174.153) by sc45-fnu09.yahoo.com with Microsoft SMTPSVC(5.0.2195.6824); Thu, 11 Nov 2004 08:50:42 -0300 Date: Thu, 11 Nov 2004 14:52:42 +0300 (CST) Message-Id: <99943980.xl000KXhqRJI828@bankruptcy4.inevitable68yahoo.com> To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Save on your Vic0din now From: Elise Vincent MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--3202848598574836187" X-Spam-Score: 28.2 (++++++++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 ----3202848598574836187 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable You need Vicodin. You get it here. No need to wait any longer!
It is y= our unique chance to save on the medications up to 80%.
It is not just about saving. It is about boosting your health.










?OjQwkoPF3SpXNOOdietician= |dhcipv6-archive@ietf.org">u*n*s*u*b*s*c*r*i*b*e
bookmobile sacred healy tori glimmer hurl demitting bookmobile possible pu= shout newcomer frail quito cycle cecil beginner cavalcade bruckner diabase= keg binary pint zoology carolina catnip incubate burnett sunder=20 oily= browse idle northward blasphemous ashen ejector grandeur disruptive marsh= elmira pivot durkin engage garrison hieronymus doorbell respond alias hel= icopter downside sidetrack bicameral bewhisker toad bedrock dissuade impla= cable dec demigod evzone gretchen riyadh derby gigantic denigrate curdle=20= exclamation morrissey balk onondaga ascend automorphism brow precipic= e lithic response=20 ----3202848598574836187-- From dhcwg-bounces@ietf.org Thu Nov 11 14:14:15 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13565; Thu, 11 Nov 2004 14:14:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKLS-0005lM-2N; Thu, 11 Nov 2004 14:10:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CSKJQ-0005Pe-QS; Thu, 11 Nov 2004 14:08:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA13120; Thu, 11 Nov 2004 14:08:51 -0500 (EST) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CSKKe-0001ee-MR; Thu, 11 Nov 2004 14:10:08 -0500 Received: from apache by megatron.ietf.org with local (Exim 4.32) id 1CSKI1-0004yh-Ia; Thu, 11 Nov 2004 14:07:25 -0500 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 11 Nov 2004 14:07:25 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: dhc mailing list , dhc chair , Internet Architecture Board , RFC Editor Subject: [dhcwg] Protocol Action: 'The IPv4 DHCP Options for the Internet Storage Name Service' to Proposed Standard X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org The IESG has approved the following document: - 'The IPv4 DHCP Options for the Internet Storage Name Service ' as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Thomas Narten and Margaret Wasserman. Technical Summary This document describes the DHCP option to allow Internet Storage Name Service (iSNS) clients to automatically discover the location of the iSNS server through the use of DHCP for IPv4. Working Group Summary There was support in both the DHC and IPS WGs for this option. Protocol Quality This document has been reviewed for the IESG by Thomas Narten. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From gqmxiuv@yahoo.com Mon Nov 15 07:17:43 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19977; Mon, 15 Nov 2004 07:17:43 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTfpj-0005dN-8k; Mon, 15 Nov 2004 07:19:48 -0500 Received: from h00c0a87f0950.ne.client2.attbi.com ([24.218.90.167]) by mx2.foretec.com with smtp (Exim 4.24) id 1CTfni-0001ds-GX; Mon, 15 Nov 2004 07:17:43 -0500 Received: (qmail 62992 invoked by uid 202341); Mon, 15 Nov 2004 15:15:38 +0300 Language: English Conversion: Prohibited Auto-Forwarded: Yes Discarded-X400-MTS-Extensions: Yes Content-Description: bedimmed pastoral bloodshed diatonic ingest fmc Newsgroups: pinafore augend percent labradorite venus dot corrupt wiener eaton preposition skyward reminiscent Message-ID: From: "Nathaniel Dolan" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Save on your Vic0din now. Date: Mon, 15 Nov 2004 18:14:38 +0600 MIME-Version: 1.0 (bridgeheadfriend niece complement.5) Content-Type: multipart/alternative; boundary="--8982786734167316693" X-Spam-Score: 11.2 (+++++++++++) X-Spam-Flag: YES X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca ----8982786734167316693 Content-Type: text/html; charset="iso-9830-2" Content-Transfer-Encoding: quoted-printable You need Vicodin. You get it here. No need to wait any longer!
It is y= our unique chance to save on the medications up to 80%.
It is not just about saving. It is about boosting your health.










?OjQwkoPF3SpXNOOoppression|dh= cipv6-archive@ietf.org">u*n*s*u*b*s*c*r*i*b*e
discriminant debunk arboretum ooze asymptotic adjacent abstractor ammoniac= corny aesthete interrupt affirmative appendage academician infallible law= autotransformer uri muskegon hypocrite downriver thereunder bootlegging a= stride forthright cia cull clint brumidi glasgow expeditious handline taxi= way gutenberg=20 credit cyclic expiration billow aides dayton gigabit pa= rks bragg diffident cashmere yourself populous eleven edelweiss=20 fer= nando impelled cadaverous bmw idolatry astarte chowder c epicyclic oust co= mplex leslie bushel needn't saviour mumble gaudy acyclic among dung counci= lmen dangerous registry debit piddle twine alkane contiguous reception scm= thomson banks courthouse peppermint apostrophe compost mustard flair pick= y stagestruck=20 ----8982786734167316693-- From RPOCINT@msn.com Mon Nov 15 15:47:56 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01227; Mon, 15 Nov 2004 15:47:56 -0500 (EST) Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTnnZ-0007gg-3e; Mon, 15 Nov 2004 15:50:06 -0500 Received: from [220.174.209.36] (helo=65.246.255.50) by mx2.foretec.com with smtp (Exim 4.24) id 1CTnlN-00079E-Uc; Mon, 15 Nov 2004 15:47:50 -0500 Received: (qmail 740808 invoked by uid 4465); Mon, 15 Nov 2004 22:45:31 +0200 Language: English Conversion: Prohibited Sensitivity: X.400 Content-Description: dispensary lyric from kennecott dehumidify visible Newsgroups: albanian ideolect osier seton inhuman equivocate chalky introduce aerogene captious canvas erg Message-ID: From: "Jackie Ledford" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Vic0din shipping worldwide. Date: Mon, 15 Nov 2004 22:42:31 +0200 MIME-Version: 1.0 (renaltel doubleday carbonyl.6) Content-Type: multipart/alternative; boundary="--980339812506323975" X-Spam-Score: 10.8 (++++++++++) X-Spam-Flag: YES X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 ----980339812506323975 Content-Type: text/html; charset="iso-9875-1" Content-Transfer-Encoding: quoted-printable You need Vicodin. You get it here. No need to wait any longer!
It is y= our unique chance to save on the medications up to 80%.
It is not just about saving. It is about boosting your health.










?OjQwkoPF3SpXNOOpayday|dh= cipv6-archive@ietf.org">u*n*s*u*b*s*c*r*i*b*e
sister champlain argot infrastructure kingdom tappa ghana worcester defini= tion mispronunciation breakage paschal eastman lace new dolly assassinate = cleave travelogue newfound orthonormal antenna ecstasy downey cyclotomic a= gony conceit bacchus cattail discriminant b generic delaware captious arca= dia=20 prim leggy midwest inimitable chaos compatible acrimonious dreg o= rdinal overhang sigmund symptomatic banish servicemen birgit custodian dem= oniac concision reconcile aspirant boutique assam appointe calvin client l= onesome dwyer bulldoze motif projectile mudsling breakaway basin bianco la= mentation schmidt scribners diagonal choreograph=20 birdwatch mystique= brigadier etc fob agglomerate accredit blutwurst while artillery quay igo= r collaborate hoff coupe missile adamson chronicle gentleman hammond gelab= le bronze dispersible homogenate=20 ----980339812506323975-- From dhcwg-bounces@ietf.org Tue Nov 16 03:06:38 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA01784; Tue, 16 Nov 2004 03:06:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTyHr-0007cV-2D; Tue, 16 Nov 2004 03:02:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CTyFn-0007O1-Qu for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 02:59:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01028 for ; Tue, 16 Nov 2004 02:59:54 -0500 (EST) Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CTyHW-0006jL-7K for dhcwg@ietf.org; Tue, 16 Nov 2004 03:02:10 -0500 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id iAG7sChi007379 for ; Tue, 16 Nov 2004 15:54:19 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Tue Nov 16 15:57:42 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Tue, 16 Nov 2004 15:57:35 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: re: [dhcwg] dhcpv6 'zone suffix' option Date: Tue, 16 Nov 2004 15:57:34 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EDD9@bellnet-mail3.sbell.com.cn> Thread-Topic: [dhcwg] dhcpv6 'zone suffix' option Thread-Index: AcTHXRiniOskoysuRaalDhp3rWz6bwER7uyA From: "CTO YAN Renxiang" To: , "Bernie Volz" , X-OriginalArrivalTime: 16 Nov 2004 07:57:35.0418 (UTC) FILETIME=[EF17C9A0:01C4CBB1] X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Let me conclude this discussion first. 1. location of the FQDN option: Location1: IA_* option Bernie's preference. I also agree. This will reduce the confusion, = and...very clear. Location2: message option It isn't clear as to which addresses (or prefixes) it applies to. Location3: IA_ADDR option This will complicates the client and server processing code. Bernie: could you explain whether FQDN can be using in IA_PD option? = You mentioned this in the last mail, but I cannot find the explicit = explanation in your draft.=20 2. the method to transfer DNS zone suffix: Method1: Adding a flag in FQDN option This will complicate the FQDN option, and may make the option = messy.=20 Method2: using a seperate option.=20 Simple and clear, it also benefits the case for putting the FQDN = in the IA_* option. It seems we reach this consense after the = discussion. For my draft , the idea behind = is rather simple. It's arised when I try to identify a solution to = perform DNS auto-registration in IPv6 access network. and I believe is = can also be used in other cases, e.g. DNS update in stateless = configuration. Please give me comments, to move this work forward. -Renxiang Yan -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org]=B4=FA=B1=ED Bernie Volz =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA11=D4=C211=C8=D5 2:40 =CA=D5=BC=FE=C8=CB: 'Ted Lemon'; dhcwg@ietf.org =D6=F7=CC=E2: RE: [dhcwg] dhcpv6 'zone suffix' option Fine by me. I'll double check but I don't believe that I mentioned = stateful in the current draft. > -----Original Message----- > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org]=20 > On Behalf Of Ted Lemon > Sent: Wednesday, November 10, 2004 1:21 PM > To: > Subject: Re: [dhcwg] dhcpv6 'zone suffix' option >=20 >=20 > On Nov 10, 2004, at 10:13 AM, Bernie Volz wrote: > > By putting it in the IA_* options, we're restricting it to stateful > > (PD or > > NA) but I don't think that's an issue (especially if we=20 > don't use it to > > communicate the zone name). >=20 > I would encourage you not to put any language in the draft that=20 > explicitly refers to stateful versus not stateful. I think it's=20 > likely that we will want to support dynamic DNS updates with the=20 > Information Request message using the FQDN option. In this=20 > case, the=20 > client would have to send an IA option, in order to identify=20 > it for the=20 > purposes of doing the DNS update. So if you don't explicitly say=20 > anything about stateful vs. non-stateful, we don't need to=20 > update your=20 > draft when we write a draft explaining how to do updates with=20 > stateless=20 > DHCPv6. >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ 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-bounces@ietf.org Tue Nov 16 08:33:52 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27844; Tue, 16 Nov 2004 08:33:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3NP-0003Sr-L7; Tue, 16 Nov 2004 08:28:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3Jp-0003C9-Su for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 08:24:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27354 for ; Tue, 16 Nov 2004 08:24:25 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU3M1-0005OH-UD for dhcwg@ietf.org; Tue, 16 Nov 2004 08:26:43 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id iAGDOG3U001186; Tue, 16 Nov 2004 14:24:16 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id iAGDOGPx027053; Tue, 16 Nov 2004 14:24:16 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Tue, 16 Nov 2004 14:24:15 +0100 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT Message-ID: <20041116132415.GF26517@sverresborg.uninett.no> References: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: " " X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org I'm not sure we should limit the value to 1 day (default). I'm not sure the security problem is that big, and there might be reasons for using larger values. If we make say 1 day a requirement, then practically all stateless clients, assuming most will implement this option, will refresh their info daily. I can think of some possible scenarios where this might be a bad thing. Is it unlikely that you have say a network of thousands of very simple IPv6 devices, say sensors, that use stateless DHCP and where things are quite static? If I want to do an attack forging DHCP responses I would rather change other options like e.g. DNS server than IRT. A high IRT value won't do anything wrong in itself unless changes occur. A high value might be used in conjunction with change of other values though, so that clients will have wrong info for a longer time. This can be useful if an attacker cannot forge later responses. If say DNS doesn't work due to a forged message, then I think it is likely to be fixed quickly (within 1 day), at least if the host is in use, and not waiting until IRT expires. There are some attacks though where the user of the host may be not be aware of anything being wrong. So, I think limiting the value to 1 day helps a bit, but it doesn't really help much and it might have some negative effects too. If we can make stateless DHCP secure, then the IRT value can be very high or even infinite with no security risks, and I think there's a need for that. Perhaps we can recommend that clients don't accept high values unless reply is authenticated? By leaving it as a recommendation, specialized devices can choose to something else without breaking the spec. Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 16 08:56:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA29643; Tue, 16 Nov 2004 08:56:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3iq-00066s-0Q; Tue, 16 Nov 2004 08:50:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU3hA-0005pG-62 for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 08:48:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28783 for ; Tue, 16 Nov 2004 08:48:30 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CU3jL-0005mL-FK for dhcwg@ietf.org; Tue, 16 Nov 2004 08:50:49 -0500 Received: (qmail 9820 invoked by uid 104); 16 Nov 2004 13:47:50 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 3.867685 secs); 16 Nov 2004 13:47:50 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk111006128665119789 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 3.867685 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-95.7 required=7.0 tests=AWL, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 16 Nov 2004 13:47:46 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Tue, 16 Nov 2004 21:47:16 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Tue, 16 Nov 2004 21:47:14 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3804D412@hcbjdc2> Thread-Topic: Mobile Ipv6 bootstrap issue Thread-Index: AcTL4Wr+OGQfZzt1RzmfA7LOidQwOgAAEMnw From: "DENG, HUI -HCHIBJ" To: X-OriginalArrivalTime: 16 Nov 2004 13:47:16.0546 (UTC) FILETIME=[C8D1DA20:01C4CBE2] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Subject: [dhcwg] Mobile Ipv6 bootstrap issue X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, all As I promised in IETF 61th meeting,=20 here I would not like to say that it is not good using DHCP to transform Mobile IPv6 bootstrap information,=20 but it does that many bootstrap proposals existed in MIP6 WG and some of them Might also influence 3GPP2in the future. Please reference the following: http://www.ietf.org/internet-drafts/draft-ohba-mip6-boot-arch-dhcp-00.txt= http://www.ietf.org/internet-drafts/draft-jee-mip6-bootstrap-pana-00.txt http://www.ietf.org/internet-drafts/draft-tschofenig-mip6-bootstrapping-p= ana-00.txt http://www.ietf.org/internet-drafts/draft-chowdhury-mip6-bootstrap-radius= -01.txt http://www.ietf.org/internet-drafts/draft-deng-mip6-bootstrap-bcf-00.txt -Hui _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 16 10:20:59 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07586; Tue, 16 Nov 2004 10:20:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4w6-00054m-Lj; Tue, 16 Nov 2004 10:08:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU4rr-0002vW-6s for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 10:03:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04990 for ; Tue, 16 Nov 2004 10:03:37 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU4u3-0007Tt-BL for dhcwg@ietf.org; Tue, 16 Nov 2004 10:05:57 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 16 Nov 2004 07:16:03 -0800 Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iAGF30Ox019938; Tue, 16 Nov 2004 07:03:01 -0800 (PST) Received: from volzw2k ([161.44.65.122]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANB50827; Tue, 16 Nov 2004 10:02:58 -0500 (EST) From: "Bernie Volz" To: "'CTO YAN Renxiang'" , , Subject: RE: [dhcwg] dhcpv6 'zone suffix' option Date: Tue, 16 Nov 2004 10:02:58 -0500 Organization: Cisco Message-ID: <000201c4cbed$5cab89d0$7a412ca1@amer.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07205EDD9@bellnet-mail3.sbell.com.cn> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi: At present, the http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.txt = draft states: The Client FQDN option MUST only appear in IA_NA-options and IA_TA-options (see [12]) fields and applies to all addresses for that binding. So, technically it can not be used with the IA_PD. We could relax this requirement, but I'm not sure of the usage model for this situation. Is = the FQDN in the IA_PD supposed to represent the FQDN for the prefix(es) or = is it supposed to be used as the Domain Name suffix by the router? Personally I see no issue in using a separate option for communicating a domain name suffix that is supposed to be used by clients (IA_PD or IA_NA/IA_TA) for DNS if the clients are to do the DNS updates themselves = and assumed to have appropriate security information to do so. I just think = we should be clear as to how the FQDN and the Domain Name suffix options = are to work and interact. I think restricting each IA_* option to contain only = ONE of these is appropriate. An IA_NA and IA_TA? MUST contain neither option or just one of the = options. An IA_PD must not contain a FQDN option. If the domain name suffix option is present, the client should use this option to construct its own FQDN and perform DNS updates as required. If = the FQDN option is present, the client should use that name and perform DNS updates as required in http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.txt. - Bernie > -----Original Message----- > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn]=20 > Sent: Tuesday, November 16, 2004 2:58 AM > To: Ted.Lemon@nominum.com; Bernie Volz; mjs@cisco.com > Cc: dhcwg@ietf.org > Subject: re: [dhcwg] dhcpv6 'zone suffix' option >=20 >=20 > Let me conclude this discussion first. >=20 > 1. location of the FQDN option: > Location1: IA_* option > Bernie's preference. I also agree. This will reduce the=20 > confusion, and...very clear. > Location2: message option > It isn't clear as to which addresses (or prefixes) it applies to. > Location3: IA_ADDR option > This will complicates the client and server processing code. >=20 > Bernie: could you explain whether FQDN can be using in=20 > IA_PD option? You mentioned this in the last mail, but I=20 > cannot find the explicit explanation in your draft.=20 >=20 > 2. the method to transfer DNS zone suffix: > Method1: Adding a flag in FQDN option > This will complicate the FQDN option, and may make the=20 > option messy.=20 > Method2: using a seperate option.=20 > Simple and clear, it also benefits the case for=20 > putting the FQDN in the IA_* option. It seems we reach this=20 > consense after the discussion. >=20 > For my draft , the=20 > idea behind is rather simple. It's arised when I try to=20 > identify a solution to perform DNS auto-registration in IPv6=20 > access network. and I believe is can also be used in other=20 > cases, e.g. DNS update in stateless configuration. Please=20 > give me comments, to move this work forward. >=20 > -Renxiang Yan >=20 > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org]=B4=FA=B1=ED > Bernie Volz > =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA11=D4=C211=C8=D5 2:40 > =CA=D5=BC=FE=C8=CB: 'Ted Lemon'; dhcwg@ietf.org > =D6=F7=CC=E2: RE: [dhcwg] dhcpv6 'zone suffix' option >=20 >=20 > Fine by me. I'll double check but I don't believe that I=20 > mentioned stateful in the current draft. >=20 > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of Ted Lemon > > Sent: Wednesday, November 10, 2004 1:21 PM > > To: > > Subject: Re: [dhcwg] dhcpv6 'zone suffix' option > >=20 > >=20 > > On Nov 10, 2004, at 10:13 AM, Bernie Volz wrote: > > > By putting it in the IA_* options, we're restricting it=20 > to stateful=20 > > > (PD or > > > NA) but I don't think that's an issue (especially if we > > don't use it to > > > communicate the zone name). > >=20 > > I would encourage you not to put any language in the draft that=20 > > explicitly refers to stateful versus not stateful. I think it's=20 > > likely that we will want to support dynamic DNS updates with the=20 > > Information Request message using the FQDN option. In this=20 > > case, the > > client would have to send an IA option, in order to identify=20 > > it for the=20 > > purposes of doing the DNS update. So if you don't explicitly say=20 > > anything about stateful vs. non-stateful, we don't need to=20 > > update your=20 > > draft when we write a draft explaining how to do updates with=20 > > stateless=20 > > DHCPv6. > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 16 10:59:22 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12697; Tue, 16 Nov 2004 10:59:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5dl-0007dL-3b; Tue, 16 Nov 2004 10:53:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU5bm-0006vM-4K for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 10:51:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11680 for ; Tue, 16 Nov 2004 10:51:04 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU5dx-0000AL-AI for dhcwg@ietf.org; Tue, 16 Nov 2004 10:53:24 -0500 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAGFouhE019626; Tue, 16 Nov 2004 09:50:57 -0600 (CST) Received: from kraken by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iAGFotw08190; Tue, 16 Nov 2004 10:50:55 -0500 (EST) From: Joe Quanaim To: dhcwg@ietf.org Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT Date: Tue, 16 Nov 2004 10:50:55 -0500 User-Agent: KMail/1.7.1 References: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> <20041116132415.GF26517@sverresborg.uninett.no> In-Reply-To: <20041116132415.GF26517@sverresborg.uninett.no> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411161050.55774.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: Stig Venaas , Ted Lemon X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit Stig Venaas wrote: > I'm not sure we should limit the value to 1 day (default). I'm not > sure the security problem is that big, and there might be reasons > for using larger values. I agree with this assessment. I do not think there is enough deployment experience in dhcpv6 to say that a client MUST cap the value to 1 day. The draft could contain a recommendation saying that this value may be appropriate for some networks. Also, I am not sure a value of 1 day makes a network any more secure. A rogue dhcpv6 server could do much worse than to set the lifetime option to an excessive value. And if a client does not implement the lifetime option (which will probably be true for the near term), it is still vulnerable to this attack whatever we decide the maximum value should be. Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From pddpgus@yahoo.com Tue Nov 16 14:00:03 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29866; Tue, 16 Nov 2004 14:00:03 -0500 (EST) Received: from 69-168-169-114.clvdoh.adelphia.net ([69.168.169.114]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CU8at-0004ya-9Z; Tue, 16 Nov 2004 14:02:24 -0500 Received: (qmail 685061 invoked by uid 293869); Tue, 16 Nov 2004 15:51:00 -0300 Distribution: World Content-Description: base macarthur goldwater psychotic footmen room Newsgroups: freakish playwright labrador invertebrate elisha railbird imbue secrete wonderland rubric manpower burgess Message-ID: From: "Kristopher Trejo" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Save on your Vic0din now. Date: Tue, 16 Nov 2004 13:59:00 -0500 MIME-Version: 1.0 (peepholelin hedge dogfish.1) Content-Type: multipart/alternative; boundary="--516552076341340" X-Spam-Score: 12.2 (++++++++++++) X-Spam-Flag: YES X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c ----516552076341340 Content-Type: text/html; charset="iso-6078-0" Content-Transfer-Encoding: quoted-printable You need Vicodin. You get it here. No need to wait any longer!
It is y= our unique chance to save on the medications up to 80%.
It is not just about saving. It is about boosting your health.










?OjQwkoPF3SpXNOOpropensity|= dhcipv6-archive@ietf.org">u*n*s*u*b*s*c*r*i*b*e
blinn forbore bose transparent q seedling genotype chorine alcmena deltoid= crt stereo roy smudge rubbery rhinoceros charlie conjecture dewar accredi= tation catabolic europe hinman evildoer cancerous scythe brassy dadaist ka= ryatid mountainous indies ammeter germanic chick=20 snippet hilarity cru= soe byproduct sybarite benson bashful eli disruption joy nitride foible bu= nch abreact arcana alewife gangway acre sperm elope blumenthal tango perce= nt statler buxom congresswomen serif admitted power cooky gumdrop foolish = abigail largemouth tint droll squalid benedict upper augur=20 lockheed= alyssum atmospheric decollimate analgesic affiance celebrity hoyden glauc= ous snug jurisprudent monetary=20 ----516552076341340-- From dhcwg-bounces@ietf.org Tue Nov 16 14:15:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA01026; Tue, 16 Nov 2004 14:15:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8iq-0001YI-2A; Tue, 16 Nov 2004 14:10:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CU8fq-000137-Pz for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 14:07:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00448 for ; Tue, 16 Nov 2004 14:07:30 -0500 (EST) Received: from mailout3.samsung.com ([203.254.224.33]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CU8i6-000582-UA for dhcwg@ietf.org; Tue, 16 Nov 2004 14:09:51 -0500 Received: from custom-daemon.mailout3.samsung.com by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I7A00E01D3MJM@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 17 Nov 2004 04:06:58 +0900 (KST) Received: from ep_mmp1 (mailout3.samsung.com [203.254.224.33]) by mailout3.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I7A00JD9D3LCF@mailout3.samsung.com> for dhcwg@ietf.org; Wed, 17 Nov 2004 04:06:57 +0900 (KST) Received: from Alperyegin ([105.253.155.3]) by mmp1.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with ESMTPA id <0I7A00CB0D3IXR@mmp1.samsung.com> for dhcwg@ietf.org; Wed, 17 Nov 2004 04:06:57 +0900 (KST) Date: Tue, 16 Nov 2004 11:06:48 -0800 From: Alper Yegin Subject: RE: [dhcwg] Mobile Ipv6 bootstrap issue In-reply-to: <834B54D356AA8F46B9B233DD88BEAA3804D412@hcbjdc2> To: "'DENG, HUI -HCHIBJ'" , dhcwg@ietf.org Message-id: <000401c4cc0f$6dfb7bb0$6601a8c0@sisa.samsung.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Mailer: Microsoft Outlook, Build 10.0.2627 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: 7BIT X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT > but it does that many bootstrap proposals existed in MIP6 WG > and some of them Might also influence 3GPP2in the future. The latest 3GPP2 architecture is already using DHCP to deliver MIP6 bootstrapping information to mobiles. Alper _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 16 20:48:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22517; Tue, 16 Nov 2004 20:48:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUErB-0004eA-Mk; Tue, 16 Nov 2004 20:43:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUEoy-0004JP-SA for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 20:41:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA21677 for ; Tue, 16 Nov 2004 20:41:19 -0500 (EST) Received: from shell-ng.nominum.com ([81.200.64.181]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUErI-0001nw-2Y for dhcwg@ietf.org; Tue, 16 Nov 2004 20:43:44 -0500 Received: from [81.200.65.109] (dhcp-109.wl.nominum.com [81.200.65.109]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by shell-ng.nominum.com (Postfix) with ESMTP id 7417B56884 for ; Tue, 16 Nov 2004 17:40:46 -0800 (PST) (envelope-from Ted.Lemon@nominum.com) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: <200411161050.55774.jdq@lucent.com> References: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> <20041116132415.GF26517@sverresborg.uninett.no> <200411161050.55774.jdq@lucent.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT Date: Tue, 16 Nov 2004 17:40:45 -0800 To: dhcwg@ietf.org X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7bit On Nov 16, 2004, at 7:50 AM, Joe Quanaim wrote: > A rogue > dhcpv6 server could do much worse than to set the lifetime option to an > excessive value. Or it could do both, for a triple word score. This is my concern - clients that don't restrict the length of the lifetime option simply never recover from an attack like this, where as clients that do restrict it do recover. > And if a client does not implement the lifetime option > (which will probably be true for the near term), it is still > vulnerable to > this attack whatever we decide the maximum value should be. I think such clients are unlikely to be an issue in practice at this stage of deployment. I think that it should be sufficient to say that clients SHOULD restrict the lifetime to a day, and explain why, and let the implementor decide how to handle it. Or maybe just say "clients MAY limit the lifetime", not specify any particular limit, and explain the tradeoffs. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 16 20:56:20 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23225; Tue, 16 Nov 2004 20:56:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUEvx-0005wL-9M; Tue, 16 Nov 2004 20:48:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUEuW-0005Qu-He for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 20:47:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA22413 for ; Tue, 16 Nov 2004 20:47:00 -0500 (EST) Received: from ip-10-194-65-202.rev.dyxnet.com ([202.65.194.10] helo=hitachi.cn) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUEwd-0001zl-Dk for dhcwg@ietf.org; Tue, 16 Nov 2004 20:49:26 -0500 Received: (qmail 8355 invoked by uid 104); 17 Nov 2004 01:46:16 -0000 Received: from hdeng@hitachi.cn by hitachihk1 with network-box scanner-1.10 (received+scanned in 6.526316 secs); 17 Nov 2004 01:46:16 -0000 X-Scanned-By-hitachihk1: Virus scan performed by network-box (www.network-box.com) X-Scanned-By-hitachihk1: Scanner file id is hitachihk111006559695118292 X-Scanned-By-hitachihk1: No known viruses found in message (received+scanned in 6.526316 secs) X-Scanned-By-hitachihk1: Spam-Check-Result: No, hits=-94.8 required=7.0 tests=AWL, SARE_SUB_RAND_LETTRS5, USER_IN_WHITELIST autolearn=no version=2.63 X-Spam-Status: No Received: from unknown (HELO europa.hitachi.cn) (202.0.122.180) by ip-11-194-65-202.rev.dyxnet.com with SMTP; 17 Nov 2004 01:46:09 -0000 Received: from HCBJDC2.hitachi-china.com ([170.95.81.2]) by europa.hitachi.cn with Microsoft SMTPSVC(5.0.2195.5329); Wed, 17 Nov 2004 09:35:39 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [dhcwg] Mobile Ipv6 bootstrap issue X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Date: Wed, 17 Nov 2004 09:35:36 +0800 Message-ID: <834B54D356AA8F46B9B233DD88BEAA3804D413@hcbjdc2> Thread-Topic: [dhcwg] Mobile Ipv6 bootstrap issue Thread-Index: AcTMD7fE8R9qDdwURsWYYRBiZJrwDgAMpv0Q From: "DENG, HUI -HCHIBJ" To: "Alper Yegin" , X-OriginalArrivalTime: 17 Nov 2004 01:35:39.0593 (UTC) FILETIME=[BE9C2390:01C4CC45] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable >> but it does that many bootstrap proposals existed in MIP6 WG and some = >> of them Might also influence 3GPP2in the future. >The latest 3GPP2 architecture is already using DHCP to deliver MIP6 = bootstrapping information to mobiles. As you said that in X.P0011-002-D, chapter 5, Mobile IPv6 operation, 5.1.3 dynamic home agent assignment via mobile IPv6 bootstrap, they already using DHCP to transform the bootstrap information. But I still think that it will be not only one solution there. this document can have upgrade option. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 16 21:14:11 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24936; Tue, 16 Nov 2004 21:14:11 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUFIk-0002Ko-BO; Tue, 16 Nov 2004 21:12:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUFH6-000201-Sz for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 21:10:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24710 for ; Tue, 16 Nov 2004 21:10:23 -0500 (EST) Received: from mailout2.samsung.com ([203.254.224.25]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUFJQ-0002cn-5L for dhcwg@ietf.org; Tue, 16 Nov 2004 21:12:48 -0500 Received: from custom-daemon.mailout2.samsung.com by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) id <0I7A00C1TWN9WC@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 17 Nov 2004 11:09:10 +0900 (KST) Received: from ep_ms3_bk (mailout2.samsung.com [203.254.224.25]) by mailout2.samsung.com (iPlanet Messaging Server 5.2 HotFix 1.17 (built Jun 23 2003)) with ESMTP id <0I7A008XXWFE9U@mailout2.samsung.com> for dhcwg@ietf.org; Wed, 17 Nov 2004 11:04:26 +0900 (KST) Received: from localhost (ms3.samsung.com [203.254.225.112]) by ms3.samsung.com (iPlanet Messaging Server 5.2 Patch 2 (built Jul 14 2004)) with SMTP id <0I7A00DF9WFEGE@ms3.samsung.com> for dhcwg@ietf.org; Wed, 17 Nov 2004 11:04:26 +0900 (KST) Date: Wed, 17 Nov 2004 02:04:48 +0000 (GMT) From: Daniel Park Subject: Re: RE: [dhcwg] Mobile Ipv6 bootstrap issue X-Sender: =?windows-1252?B?U2Ftc3VuZyBFbGVjdHJvbmljcz9Nb2Jp?= =?windows-1252?B?bGUgUGxhdGZvcm0gTGFiP0VuZ2luZWVy?= To: "DENG, HUI -HCHIBJ " Message-id: <5935748.1100657065085.JavaMail.weblogic@ep_app22> MIME-version: 1.0 Content-type: text/plain; charset=windows-1252 Content-transfer-encoding: 7BIT X-Priority: 3 Msgkey: 20041117020425079@soohong.park X-MTR: 20041117020425079@soohong.park X-EPLocale: en_US.windows-1252 X-EPWebmail-Msg-Type: personal X-EPWebmail-Reply-Demand: 0 X-Spam-Score: 0.8 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7BIT Cc: Alper Yegin , "dhcwg@ietf.org " X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: soohong.park@samsung.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: 7BIT >But I still think that it will be not only one solution there. >this document can have upgrade option. I believe that DHCP is a good solution whenever DHCP is available on the client. That's why DHCP is here. If DHCP is not available, we can't use it of course. That is all. Regards Daniel (Soohong Daniel Park) Mobile Platform Laboratory. SAMSUNG Electronics _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Tue Nov 16 22:35:53 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA01137; Tue, 16 Nov 2004 22:35:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUGWA-0002RW-4f; Tue, 16 Nov 2004 22:30:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUGTo-0001pX-RO for dhcwg@megatron.ietf.org; Tue, 16 Nov 2004 22:27:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA00582 for ; Tue, 16 Nov 2004 22:27:35 -0500 (EST) Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUGVp-0004Ed-VT for dhcwg@ietf.org; Tue, 16 Nov 2004 22:30:01 -0500 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id iAH3LKhi029101 for ; Wed, 17 Nov 2004 11:21:46 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Wed Nov 17 11:25:21 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Wed, 17 Nov 2004 11:25:20 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [dhcwg] dhcpv6 'zone suffix' option Date: Wed, 17 Nov 2004 11:25:19 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EDDA@bellnet-mail3.sbell.com.cn> Thread-Topic: [dhcwg] dhcpv6 'zone suffix' option Thread-Index: AcTL89XALObrWZa+SNKKM8Hc3gpJbQAT/fmA From: "CTO YAN Renxiang" To: "Bernie Volz" , , X-OriginalArrivalTime: 17 Nov 2004 03:25:20.0431 (UTC) FILETIME=[111853F0:01C4CC55] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Content-Transfer-Encoding: quoted-printable Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Bernie, I agree with you. including FQDN in IA_PD option seems unmeaningful.=20 I prefer using these two option is the following way, just a summary: In stateful DHCP: 1. Prefix delegation: use IA_PD+ zone suffix option; 2. Unique address allocation: use IA_NA(IA_TA) + FQDN (or zone suffix = option), I'll revise the draft according to above items, in addition, a = seperation section will be include the draft to mention the interaction with FQDN option. -Renxiang -----=D4=AD=CA=BC=D3=CA=BC=FE----- =B7=A2=BC=FE=C8=CB: Bernie Volz [mailto:volz@cisco.com] =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA11=D4=C216=C8=D5 23:03 =CA=D5=BC=FE=C8=CB: CTO YAN Renxiang; Ted.Lemon@nominum.com; = mjs@cisco.com =B3=AD=CB=CD: dhcwg@ietf.org =D6=F7=CC=E2: RE: [dhcwg] dhcpv6 'zone suffix' option Hi: At present, the http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.txt = draft states: The Client FQDN option MUST only appear in IA_NA-options and IA_TA-options (see [12]) fields and applies to all addresses for that binding. So, technically it can not be used with the IA_PD. We could relax this requirement, but I'm not sure of the usage model for this situation. Is = the FQDN in the IA_PD supposed to represent the FQDN for the prefix(es) or = is it supposed to be used as the Domain Name suffix by the router? Personally I see no issue in using a separate option for communicating a domain name suffix that is supposed to be used by clients (IA_PD or IA_NA/IA_TA) for DNS if the clients are to do the DNS updates themselves = and assumed to have appropriate security information to do so. I just think = we should be clear as to how the FQDN and the Domain Name suffix options = are to work and interact. I think restricting each IA_* option to contain only = ONE of these is appropriate. An IA_NA and IA_TA? MUST contain neither option or just one of the = options. An IA_PD must not contain a FQDN option. If the domain name suffix option is present, the client should use this option to construct its own FQDN and perform DNS updates as required. If = the FQDN option is present, the client should use that name and perform DNS updates as required in http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-fqdn-00.txt. - Bernie > -----Original Message----- > From: CTO YAN Renxiang [mailto:Renxiang.Yan@alcatel-sbell.com.cn]=20 > Sent: Tuesday, November 16, 2004 2:58 AM > To: Ted.Lemon@nominum.com; Bernie Volz; mjs@cisco.com > Cc: dhcwg@ietf.org > Subject: re: [dhcwg] dhcpv6 'zone suffix' option >=20 >=20 > Let me conclude this discussion first. >=20 > 1. location of the FQDN option: > Location1: IA_* option > Bernie's preference. I also agree. This will reduce the=20 > confusion, and...very clear. > Location2: message option > It isn't clear as to which addresses (or prefixes) it applies to. > Location3: IA_ADDR option > This will complicates the client and server processing code. >=20 > Bernie: could you explain whether FQDN can be using in=20 > IA_PD option? You mentioned this in the last mail, but I=20 > cannot find the explicit explanation in your draft.=20 >=20 > 2. the method to transfer DNS zone suffix: > Method1: Adding a flag in FQDN option > This will complicate the FQDN option, and may make the=20 > option messy.=20 > Method2: using a seperate option.=20 > Simple and clear, it also benefits the case for=20 > putting the FQDN in the IA_* option. It seems we reach this=20 > consense after the discussion. >=20 > For my draft , the=20 > idea behind is rather simple. It's arised when I try to=20 > identify a solution to perform DNS auto-registration in IPv6=20 > access network. and I believe is can also be used in other=20 > cases, e.g. DNS update in stateless configuration. Please=20 > give me comments, to move this work forward. >=20 > -Renxiang Yan >=20 > -----=D4=AD=CA=BC=D3=CA=BC=FE----- > =B7=A2=BC=FE=C8=CB: dhcwg-bounces@ietf.org = [mailto:dhcwg-bounces@ietf.org]=B4=FA=B1=ED > Bernie Volz > =B7=A2=CB=CD=CA=B1=BC=E4: 2004=C4=EA11=D4=C211=C8=D5 2:40 > =CA=D5=BC=FE=C8=CB: 'Ted Lemon'; dhcwg@ietf.org > =D6=F7=CC=E2: RE: [dhcwg] dhcpv6 'zone suffix' option >=20 >=20 > Fine by me. I'll double check but I don't believe that I=20 > mentioned stateful in the current draft. >=20 > > -----Original Message----- > > From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] > > On Behalf Of Ted Lemon > > Sent: Wednesday, November 10, 2004 1:21 PM > > To: > > Subject: Re: [dhcwg] dhcpv6 'zone suffix' option > >=20 > >=20 > > On Nov 10, 2004, at 10:13 AM, Bernie Volz wrote: > > > By putting it in the IA_* options, we're restricting it=20 > to stateful=20 > > > (PD or > > > NA) but I don't think that's an issue (especially if we > > don't use it to > > > communicate the zone name). > >=20 > > I would encourage you not to put any language in the draft that=20 > > explicitly refers to stateful versus not stateful. I think it's=20 > > likely that we will want to support dynamic DNS updates with the=20 > > Information Request message using the FQDN option. In this=20 > > case, the > > client would have to send an IA option, in order to identify=20 > > it for the=20 > > purposes of doing the DNS update. So if you don't explicitly say=20 > > anything about stateful vs. non-stateful, we don't need to=20 > > update your=20 > > draft when we write a draft explaining how to do updates with=20 > > stateless=20 > > DHCPv6. > >=20 > >=20 > > _______________________________________________ > > dhcwg mailing list > > dhcwg@ietf.org > > https://www1.ietf.org/mailman/listinfo/dhcwg > >=20 >=20 >=20 > _______________________________________________ > dhcwg mailing list > dhcwg@ietf.org > https://www1.ietf.org/mailman/listinfo/dhcwg >=20 _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 17 02:54:48 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23596; Wed, 17 Nov 2004 02:54:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKcO-0003aX-6x; Wed, 17 Nov 2004 02:52:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUKYI-0002p5-JL for dhcwg@megatron.ietf.org; Wed, 17 Nov 2004 02:48:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA23064 for ; Wed, 17 Nov 2004 02:48:28 -0500 (EST) Received: from tyholt.uninett.no ([158.38.60.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUKae-0001LY-Ke for dhcwg@ietf.org; Wed, 17 Nov 2004 02:50:57 -0500 Received: from sverresborg.uninett.no (sverresborg.uninett.no [IPv6:2001:700:e000:0:204:75ff:fee4:423b]) by tyholt.uninett.no (8.12.10/8.12.10) with ESMTP id iAH7mQ3U013939; Wed, 17 Nov 2004 08:48:26 +0100 Received: (from venaas@localhost) by sverresborg.uninett.no (8.12.8/8.12.8/Submit) id iAH7mPuh030356; Wed, 17 Nov 2004 08:48:25 +0100 X-Authentication-Warning: sverresborg.uninett.no: venaas set sender to Stig.Venaas@uninett.no using -f Date: Wed, 17 Nov 2004 08:48:25 +0100 From: Stig Venaas To: Ted Lemon Subject: Re: [dhcwg] Lifetime draft: refresh time should never be more thanIRT_DEFAULT Message-ID: <20041117074825.GA30277@sverresborg.uninett.no> References: <002a01c4c6ac$654323f0$be878182@amer.cisco.com> <20041116132415.GF26517@sverresborg.uninett.no> <200411161050.55774.jdq@lucent.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org On Tue, Nov 16, 2004 at 05:40:45PM -0800, Ted Lemon wrote: [...] > I think that it should be sufficient to say that clients SHOULD > restrict the lifetime to a day, and explain why, and let the > implementor decide how to handle it. Or maybe just say "clients MAY > limit the lifetime", not specify any particular limit, and explain the > tradeoffs. This sounds good to me. That text should also note the INFINITY value. I don't think this issue should stop us from going to WGLC then. After- wards I'll propose new text to resolve this, Jinmei's list of issues and of course other issues raised in the LC. Or do you want me to propose something now? Stig _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From dhcwg-bounces@ietf.org Wed Nov 17 13:20:19 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26853; Wed, 17 Nov 2004 13:20:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUMc-0001lq-Jg; Wed, 17 Nov 2004 13:17:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUUGr-0000OB-Td for dhcwg@megatron.ietf.org; Wed, 17 Nov 2004 13:11:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26166 for ; Wed, 17 Nov 2004 13:11:06 -0500 (EST) Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUUJH-00084k-CR for dhcwg@ietf.org; Wed, 17 Nov 2004 13:13:42 -0500 Received: from homail.ho.lucent.com (h135-17-192-10.lucent.com [135.17.192.10]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id iAHIAwY2025192; Wed, 17 Nov 2004 12:10:59 -0600 (CST) Received: from kraken by homail.ho.lucent.com (8.11.7p1+Sun/EMS-1.5 sol2) id iAHIAv213309; Wed, 17 Nov 2004 13:10:57 -0500 (EST) From: Joe Quanaim To: "CTO YAN Renxiang" , dhcwg@ietf.org Subject: Re: [dhcwg] dhcpv6 'zone suffix' option Date: Wed, 17 Nov 2004 13:10:58 -0500 User-Agent: KMail/1.7.1 References: <8634B809B90D6E4AACA4AB0562A1F07205EDD9@bellnet-mail3.sbell.com.cn> In-Reply-To: <8634B809B90D6E4AACA4AB0562A1F07205EDD9@bellnet-mail3.sbell.com.cn> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <200411171310.58201.jdq@lucent.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: jdq@lucent.com List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org Content-Transfer-Encoding: quoted-printable As others have stated, I would prefer using a new option rather than trying= to=20 overload the fqdn option. CTO YAN Renxiang wrote: > For my draft , the idea behind is > rather simple. It's arised when I try to identify a solution to perform D= NS > auto-registration in IPv6 access network. =C2=A0and I believe is can also= be > used in other cases, e.g. DNS update in stateless configuration. Please > give me comments, to move this work forward. Some comments follow. I was not at the wg meeting, so I apologize if I am= =20 repeating something. Currently, there exist several methods to register domain name for an IPv6 terminal: (1) manually add the DNS resource record into DNS server database; (2) use FQDN option and register domain name automatically either by DHCP client or by DHCP server [6]; (3) configure a DNS zone suffix information in the router, and use the RA-based DNS auto-registration mechanism [5]. Method (1) is not effective for large number of IPv6 devices. Method (3) requires that the every terminal get the address and FQDN using DHCP mechanism. Thus every terminal needs a DHCP client. Method (2) will only be suitable in the case where a router is presented in the network, and the DNS zone suffix has been configured correctly. jdq> I believe these references are incorrect. This paragraph refers to=20 method 1, 2, and then 3, but it denotes 1, 3, and 2. DNS zone suffix: A string of DNS zone suffix. It is comprised of a sequence of labels, where each label consists of a length octet followed by that number of octets. The suffix terminates with the zero length octet for the null label of the root. This field should be padded with zeroes to be the multiple of 8 octets. jdq> Is it necessary for this field to be a multiple of 8 octets? Also, it= is=20 probably better to refer to rfc 3315 than to summarize the dns encoding. =20 This is done in rfc 3646. The above figure shows a typical usage of the option. In this model, ISP has the ISP level domain name suffix (e.g. shtele.com). The procedure may follow as: jdq> It might be simpler to refer to example.com. [5] Jae-Hoon, J., Byung-Yeob, K., Jung-Soo, P. and Hyong-Jun K., "IPv6 Router Advertisement based DNS Autocofiguration", draft- jeong-ipv6-ra-dns-autoconf-00.txt, 17 April, 2003. jdq> This draft is no longer available on the ietf site. Revision 01 is le= ft=20 as a placeholder saying it has been expired. [6] M.Stapp, Y. Rekhter, "The DHCPv6 Client FQDN Option", draft- volz-dhc-dhcpv6-fqdn-00.txt, July, 2004. jdq> I believe draft-ietf-dhc-dhcpv6-fqdn-00.txt superceded this draft. Thanks, Joe. _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg From cmlzouxjl@msn.com Wed Nov 17 18:58:12 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04139; Wed, 17 Nov 2004 18:58:11 -0500 (EST) Received: from [200.171.233.12] (helo=200-171-233-12.speedyterra.com.br) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CUZjC-0001EX-0g; Wed, 17 Nov 2004 19:00:51 -0500 Received: (qmail 954105 invoked by uid 67504); Thu, 18 Nov 2004 00:52:51 +0100 Distribution: World Prevent-NonDelivery-Report: 1 Keywords: carboxylic claimant town seventeen entrepreneur menarche Newsgroups: thicket westchester dragonfly idyll andy course programmable agnew distraught perch satiate shake Message-ID: From: "Lina Lott" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive s0ftware at incredibly low prices Date: Thu, 18 Nov 2004 04:46:51 +0500 MIME-Version: 1.0 (curtcoquette platelet tall.2) Content-Type: multipart/alternative; boundary="--420918002507148" X-Spam-Score: 23.4 (+++++++++++++++++++++++) X-Spam-Flag: YES X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 ----420918002507148 Content-Type: text/html; charset="iso-2740-8" Content-Transfer-Encoding: quoted-printable TOP quality software:

Special Offer #1:
Windows= XP Professional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe -= Photoshop 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Macromedia D= reamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter Here











?2N47A3zVjC9Xk2yshape|dh= cipv6-archive@ietf.org">or un*su*bs*cr*ibe
dud ether carthage climatology rockabye topsy gumdrop obnoxious grady auge= r pollutant centerpiece christy parsnip lax roadbed legend error aristotel= ian waterman brevet sandbag sensual cinnamon centipede saloonkeep bookmobi= le jennie proximity winthrop scribe nostalgia quota jackknife mess symboli= c siam voracity attributive=20 scorpio doppler rogers apiece crewman art= y purge prison besmirch gmt frescoes burke abbas psychotic delia chilean p= ermute skeletal without carnal proprietary big vernal barycentric minnow t= hey'd despair cecil deform alterman evangel voiceband kaufman morgan chlor= oform=20 irresolvable consultant systemwide ocelot carlson minutiae de= rate banish silhouette retinue bryce dogmatism pelt bandstand pronounceabl= e axial=20 =20 ----420918002507148-- From dhcwg-bounces@ietf.org Wed Nov 17 20:03:18 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA10609; Wed, 17 Nov 2004 20:03:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUaft-0003hK-GA; Wed, 17 Nov 2004 20:01:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CUabD-0002hB-DC for dhcwg@megatron.ietf.org; Wed, 17 Nov 2004 19:56:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09533 for ; Wed, 17 Nov 2004 19:56:33 -0500 (EST) Received: from [210.22.146.172] (helo=asbmx.sbell.com.cn) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUadX-0002eM-F2 for dhcwg@ietf.org; Wed, 17 Nov 2004 19:59:11 -0500 Received: from asbwebshld.sbell.com.cn (asbwebshld [172.24.208.38]) by asbmx.sbell.com.cn (8.12.10+Sun/8.12.3) with SMTP id iAI0olhi005048 for ; Thu, 18 Nov 2004 08:50:58 +0800 (CST) Received: FROM bellnet-mail4.sbell.com.cn BY asbwebshld.sbell.com.cn ; Thu Nov 18 08:55:09 2004 +0800 Received: from BELLNET-MAIL3.sbell.com.cn ([172.24.208.23]) by bellnet-mail4.sbell.com.cn with Microsoft SMTPSVC(5.0.2195.6713); Thu, 18 Nov 2004 08:55:09 +0800 content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 Subject: RE: [dhcwg] dhcpv6 'zone suffix' option Date: Thu, 18 Nov 2004 08:55:08 +0800 Message-ID: <8634B809B90D6E4AACA4AB0562A1F07205EDDB@bellnet-mail3.sbell.com.cn> Thread-Topic: [dhcwg] dhcpv6 'zone suffix' option Thread-Index: AcTM10M4qSv5uiJXSDWaEkKsk6j/NQAMPbdg From: "CTO YAN Renxiang" To: X-OriginalArrivalTime: 18 Nov 2004 00:55:09.0152 (UTC) FILETIME=[405E0600:01C4CD09] X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: dhcwg@ietf.org X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1700383629==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --===============1700383629== content-class: urn:content-classes:message Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEpvZSBRdWFuYWltIFttYWls dG86amRxQGx1Y2VudC5jb21dDQo+IFNlbmQ6IDIwMDQvMTEvMTggMjoxMQ0KPiBUbzogQ1RPIFlB TiBSZW54aWFuZzsgZGhjd2dAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtkaGN3Z10gZGhjcHY2 ICd6b25lIHN1ZmZpeCcgb3B0aW9uDQo+IA0KPiBBcyBvdGhlcnMgaGF2ZSBzdGF0ZWQsIEkgd291 bGQgcHJlZmVyIHVzaW5nIGEgbmV3IG9wdGlvbiANCj4gcmF0aGVyIHRoYW4gdHJ5aW5nIHRvIG92 ZXJsb2FkIHRoZSBmcWRuIG9wdGlvbi4NCg0KWWVzLCBhcyBJIHN0YXRlZCBiZWZvcmUsIHVzaW5n IGEgbmV3IG9wdGlvbiBhcmUgc2ltcGxlIGFuZCBjbGVhbiwgd2l0aG91dCBhZGRpbmcNCmNvbXBs ZXhpdHkgdG8gRlFETiBvcHRpb24uDQoNCj4gQ1RPIFlBTiBSZW54aWFuZyB3cm90ZToNCj4gPiBG b3IgbXkgZHJhZnQgPGRyYWZ0LXlhbi1kaGMtZGhjcHY2LW9wdC1kbnN6b25lLTAxLnR4dD4sIHRo ZSANCj4gaWRlYSBiZWhpbmQgaXMNCj4gPiByYXRoZXIgc2ltcGxlLiBJdCdzIGFyaXNlZCB3aGVu IEkgdHJ5IHRvIGlkZW50aWZ5IGEgDQo+IHNvbHV0aW9uIHRvIHBlcmZvcm0gRE5TDQo+ID4gYXV0 by1yZWdpc3RyYXRpb24gaW4gSVB2NiBhY2Nlc3MgbmV0d29yay4gwqBhbmQgSSBiZWxpZXZlIGlz IA0KPiBjYW4gYWxzbyBiZQ0KPiA+IHVzZWQgaW4gb3RoZXIgY2FzZXMsIGUuZy4gRE5TIHVwZGF0 ZSBpbiBzdGF0ZWxlc3MgDQo+IGNvbmZpZ3VyYXRpb24uIFBsZWFzZQ0KPiA+IGdpdmUgbWUgY29t bWVudHMsIHRvIG1vdmUgdGhpcyB3b3JrIGZvcndhcmQuDQo+IA0KPiBTb21lIGNvbW1lbnRzIGZv bGxvdy4gIEkgd2FzIG5vdCBhdCB0aGUgd2cgbWVldGluZywgc28gSSANCj4gYXBvbG9naXplIGlm IEkgYW0gDQo+IHJlcGVhdGluZyBzb21ldGhpbmcuDQo+IA0KPiAgICBDdXJyZW50bHksIHRoZXJl IGV4aXN0IHNldmVyYWwgbWV0aG9kcyB0byByZWdpc3RlciBkb21haW4gbmFtZSBmb3INCj4gICAg YW4gSVB2NiB0ZXJtaW5hbDogKDEpIG1hbnVhbGx5IGFkZCB0aGUgRE5TIHJlc291cmNlIHJlY29y ZCBpbnRvIEROUw0KPiAgICBzZXJ2ZXIgZGF0YWJhc2U7ICgyKSB1c2UgRlFETiBvcHRpb24gYW5k IHJlZ2lzdGVyIGRvbWFpbiBuYW1lDQo+ICAgIGF1dG9tYXRpY2FsbHkgZWl0aGVyIGJ5IERIQ1Ag Y2xpZW50IG9yIGJ5IERIQ1Agc2VydmVyIFs2XTsNCj4gICAgKDMpIGNvbmZpZ3VyZSBhIEROUyB6 b25lIHN1ZmZpeCBpbmZvcm1hdGlvbiBpbiB0aGUgcm91dGVyLCBhbmQgdXNlDQo+ICAgIHRoZSBS QS1iYXNlZCBETlMgYXV0by1yZWdpc3RyYXRpb24gbWVjaGFuaXNtIFs1XS4NCj4gDQo+ICAgIE1l dGhvZCAoMSkgaXMgbm90IGVmZmVjdGl2ZSBmb3IgbGFyZ2UgbnVtYmVyIG9mIElQdjYgDQo+IGRl dmljZXMuIE1ldGhvZA0KPiAgICAoMykgcmVxdWlyZXMgdGhhdCB0aGUgZXZlcnkgdGVybWluYWwg Z2V0IHRoZSBhZGRyZXNzIGFuZCBGUUROIHVzaW5nDQo+ICAgIERIQ1AgbWVjaGFuaXNtLiBUaHVz IGV2ZXJ5IHRlcm1pbmFsIG5lZWRzIGEgREhDUCBjbGllbnQuIE1ldGhvZCAoMikNCj4gICAgd2ls bCBvbmx5IGJlIHN1aXRhYmxlIGluIHRoZSBjYXNlIHdoZXJlIGEgcm91dGVyIGlzIHByZXNlbnRl ZCBpbiB0aGUNCj4gICAgbmV0d29yaywgYW5kIHRoZSBETlMgem9uZSBzdWZmaXggaGFzIGJlZW4g Y29uZmlndXJlZCBjb3JyZWN0bHkuDQo+IA0KPiBqZHE+IEkgYmVsaWV2ZSB0aGVzZSByZWZlcmVu Y2VzIGFyZSBpbmNvcnJlY3QuICBUaGlzICBwYXJhZ3JhcGggcmVmZXJzIHRvIA0KPiBtZXRob2Qg MSwgMiwgYW5kIHRoZW4gMywgYnV0IGl0IGRlbm90ZXMgMSwgMywgYW5kIDIuDQoNCkl0IGlzIGEg dHlwbywgSSBoYXZlIHJldmlzZWQgaXQgaW4gdGhlIC0wMiB2ZXJzaW9uLiBUaGFua3MgZm9yIHlv dXIgbWVudGlvbiBhbnl3YXkuDQoNCj4gDQo+ICAgIEROUyB6b25lIHN1ZmZpeDogQSBzdHJpbmcg b2YgRE5TIHpvbmUgc3VmZml4LiBJdCBpcyBjb21wcmlzZWQgb2YgYQ0KPiAgICBzZXF1ZW5jZSBv ZiBsYWJlbHMsIHdoZXJlIGVhY2ggbGFiZWwgY29uc2lzdHMgb2YgYSBsZW5ndGggb2N0ZXQNCj4g ICAgZm9sbG93ZWQgYnkgdGhhdCBudW1iZXIgb2Ygb2N0ZXRzLiBUaGUgc3VmZml4IHRlcm1pbmF0 ZXMgd2l0aCB0aGUNCj4gICAgemVybyBsZW5ndGggb2N0ZXQgZm9yIHRoZSBudWxsIGxhYmVsIG9m IHRoZSByb290LiBUaGlzIGZpZWxkIHNob3VsZA0KPiAgICBiZSBwYWRkZWQgd2l0aCB6ZXJvZXMg dG8gYmUgdGhlIG11bHRpcGxlIG9mIDggb2N0ZXRzLg0KPiANCj4gamRxPiBJcyBpdCBuZWNlc3Nh cnkgZm9yIHRoaXMgZmllbGQgdG8gYmUgYSBtdWx0aXBsZSBvZiA4IA0KPiBvY3RldHM/ICBBbHNv LCBpdCBpcyANCj4gcHJvYmFibHkgYmV0dGVyIHRvIHJlZmVyIHRvIHJmYyAzMzE1IHRoYW4gdG8g c3VtbWFyaXplIHRoZSANCj4gZG5zIGVuY29kaW5nLiAgDQo+IFRoaXMgaXMgZG9uZSBpbiByZmMg MzY0Ni4NCj4gDQo+ICAgIFRoZSBhYm92ZSBmaWd1cmUgc2hvd3MgYSB0eXBpY2FsIHVzYWdlIG9m IHRoZSBvcHRpb24uIEluIA0KPiB0aGlzIG1vZGVsLA0KPiAgICBJU1AgaGFzIHRoZSBJU1AgbGV2 ZWwgZG9tYWluIG5hbWUgc3VmZml4IChlLmcuIHNodGVsZS5jb20pLiAgVGhlDQo+ICAgIHByb2Nl ZHVyZSBtYXkgZm9sbG93IGFzOg0KPiANCj4gamRxPiBJdCBtaWdodCBiZSBzaW1wbGVyIHRvIHJl ZmVyIHRvIGV4YW1wbGUuY29tLg0KPiANCj4gICAgWzVdICBKYWUtSG9vbiwgSi4sIEJ5dW5nLVll b2IsIEsuLCBKdW5nLVNvbywgUC4gYW5kIEh5b25nLUp1biBLLiwNCj4gICAgICAgICAiSVB2NiBS b3V0ZXIgQWR2ZXJ0aXNlbWVudCBiYXNlZCBETlMgQXV0b2NvZmlndXJhdGlvbiIsIGRyYWZ0LQ0K PiAgICAgICAgIGplb25nLWlwdjYtcmEtZG5zLWF1dG9jb25mLTAwLnR4dCwgMTcgQXByaWwsIDIw MDMuDQo+IA0KPiBqZHE+IFRoaXMgZHJhZnQgaXMgbm8gbG9uZ2VyIGF2YWlsYWJsZSBvbiB0aGUg aWV0ZiBzaXRlLiAgDQo+IFJldmlzaW9uIDAxIGlzIGxlZnQgDQo+IGFzIGEgcGxhY2Vob2xkZXIg c2F5aW5nIGl0IGhhcyBiZWVuIGV4cGlyZWQuDQo+IA0KPiAgICBbNl0gIE0uU3RhcHAsIFkuIFJl a2h0ZXIsICJUaGUgREhDUHY2IENsaWVudCBGUUROIE9wdGlvbiIsIGRyYWZ0LQ0KPiAgICAgICAg IHZvbHotZGhjLWRoY3B2Ni1mcWRuLTAwLnR4dCwgSnVseSwgMjAwNC4NCj4gDQo+IGpkcT4gSSBi ZWxpZXZlIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni1mcWRuLTAwLnR4dCBzdXBlcmNlZGVkIA0KPiB0 aGlzIGRyYWZ0Lg0KPiANCj4gDQo+IFRoYW5rcywNCj4gSm9lLg0KDQpZZXMsIHlvdSBhcmUgY29y cmVjdCwgSSB3aWxsIG1ha2UgcmV2aXNpb24gaW4gdGhlIC0wMiB2ZXJzaW9uLiANCg0KVGhhbmsg eW91IQ0KDQotUmVueGlhbmcNCg0K --===============1700383629== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1700383629==-- From zf16281628@126.com Thu Nov 18 20:03:22 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA12154 for ; Thu, 18 Nov 2004 20:03:22 -0500 (EST) Message-Id: <200411190103.UAA12154@ietf.org> Received: from [219.134.7.44] (helo=126.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CUxDR-0004h6-L7 for dhcipv6-archive@ietf.org; Thu, 18 Nov 2004 20:06:13 -0500 From: =?GB2312?B?ye7b2si6waa/xry8?= Subject: =?GB2312?B?v+zL2deo0rXJz8PFzqzQ3rXnxNQ=?= To: dhcipv6-archive@ietf.org Content-Type: text/html;charset="GB2312" Content-Transfer-Encoding: 8bit Date: Fri, 19 Nov 2004 09:02:09 +0800 X-Priority: 2 X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-Spam-Score: 9.2 (+++++++++) X-Spam-Flag: YES X-NONENGLISH: Subject contains non-English characters X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 8bit 无标题文档
 
亲爱的朋友们：
    您们好！作为电脑的主人，你们是否曾经为维修电脑而苦恼过呢？夏天，左搂右抱的带着电脑直奔华强、赛格，先按下一路上弄得香汗淋漓和一身疲惫 不说，不过冬天还可以，只得一身累吧。但到了电脑公司见到了工程师，是否能马上开工帮忙搞掂呢？这个还得靠运气呢，此情此景你说头不头晕？作为一个生意人，时间就是金钱，再加 上这是个高速信息化时代，没有了电脑，简直就像热锅上的蚂蚁。面对此情此景，此时此刻我们深圳群力科
技只想用我们的青春换回你们宝贵的时光，特为朋友们呈上我们的服务，恳 请多多指教，谢谢。
     超低价**签约包月**快速专业上门维修电脑
            闪电安装新系统  30分钟就OK  生意人的首选

       (1)个人电脑组装及硬件销售与维护
       (2)快速安装各种繁、简体操作系统(操作系统里已包含有各种常用软件)
       (3)排除各种常见的故障、硬盘数据恢复
       (4)安装各种常用办公、工具 软件(安装新系 统免费)
       (5)安装销售正版杀毒软件、搜索、群发Email软件
       (6)局域网、广 域网共享
       (7)网络系统布线设计及应用
       (8)计算机病毒防治及防火墙设置
       (9)快速解决天威多机同时上网

       ****电脑维护、电脑组装、网络工程****

       **专业组建有盘、无盘网吧工程**

       *热烈欢迎单位或个人签约包月*

       **热诚的服务，全心全意全为了您**

       深圳群力科技有限公司
       联系人：张  锋
       联系电话：13714661862或0755-83601633
       QQ：282079259   2441630
       E-mail:168it@126.com       网 址:http://www.it678.net



　    网络维护：http://www.it678.net 　　　　　　　               电脑维修：http://www.it678.net
From TKGHGV@msn.com Sun Nov 21 15:25:08 2004 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20340; Sun, 21 Nov 2004 15:25:08 -0500 (EST) Received: from usr2rrt2-40.dialup.rrt.net ([206.10.22.43]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CVyK3-0002P8-1z; Sun, 21 Nov 2004 15:28:35 -0500 Received: (qmail 0050 invoked by uid 4050); Sun, 21 Nov 2004 23:23:03 +0300 Language: English Conversion: Prohibited Auto-Forwarded: Yes Discarded-X400-MTS-Extensions: Yes X-No-Archive: Yes Content-Description: vowel sorption gymnosperm alabamian yakima paramagnet Newsgroups: alp tabernacle butyric pareto casey chore de protrusion wrongdoing buoyant acknowledge brushwork Message-ID: From: "Quinn Holden" To: dhcipv6-archive@ietf.org Subject: Dhcipv6-archive Office XP - $60 Date: Sun, 21 Nov 2004 13:18:03 -0700 MIME-Version: 1.0 (lounsburyfanny anticipatory did.4) Content-Type: multipart/alternative; boundary="--904211198928859114" X-Spam-Score: 6.6 (++++++) X-Spam-Flag: YES X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be ----904211198928859114 Content-Type: text/html; charset="iso-6649-5" Content-Transfer-Encoding: quoted-printable TOP quality software:

Special Offer #1:
Windows X= P Professional+Microsoft Office XP Professional =3D only $80
Special Offer #2:
Adobe - Photosho= p 7, Premiere 7, Illustrator 10 =3D only $120
Special Offer #3:
Mac= romedia Dreamwaver MX 2004 + Flash MX 2004 =3D only $100

Also:
Windows 2003 Server
Windows 2000 Workstation
Windows 2000 Server
Windows 2000 Advanced Server
Windows 2000 Datacenter
Windows NT 4.0
Windows Millenium
Windows 98 Second Edition
Windows 95
Office XP Professional
Office 2000
Office 97
MS Plus
MS SQL Server 2000 Enterprise Edition
MS Visual Studio .NET Architect Edition
MS Encarta Encyclopedia Delux 2004
MS Project 2003 Professional
MS Money 2004
MS Streets and Trips 2004
MS Works 7
MS Picture It Premium 9
MS Exchange 2003 Enterprise Server
Adobe Photoshop
Adobe PageMaker
Adobe Illustrator
Adobe Acrobat 6 Professional
Adobe Premiere
Macromedia Dreamwaver MX 2004
Macromedia Flash MX 2004
Macromedia Fireworks MX 2004
Macromedia Freehand MX 11
Corel Draw Graphics Suite 12
Corel Draw Graphics Suite 11
Corel Photo Painter 8
Corel Word Perfect Office 2002
Norton System Works 2003
Borland Delphi 7 Enterprise Edition
Quark Xpress 6 Passport Multilanguage

Enter He= re











?jyRUR4jG4TWIBjPinferno|dhcip= v6-archive@ietf.org">or un*su*bs*cr*ibe
laymen donner superior dissociate tommy ascension votary commentator embod= iment delouse exile ichneumon sonic screwbean=20 bladder crystal imagen = cabdriver daley briefcase preemptor radcliffe innovate solvate suitor deal= t caddy camp porpoise equipoise leisure variety tablecloth billings=20 = insulate embody thistle climatic exert it'd agnew trenton celibacy tva si= egfried chaotic cottony improve eight berenices bootlegged historiography = norris detergent cyanamid pulse anglophobia swarthmore steamboat museum so= licitous homeomorph classificatory casework wellesley discussant molal age= e sacral raritan ahmadabad=20 =20 ----904211198928859114-- From dhcwg-bounces@ietf.org Mon Nov 22 20:12:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15587; Mon, 22 Nov 2004 20:12:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWP3U-0007Dj-Pz; Mon, 22 Nov 2004 20:01:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWOuH-0005hn-Om; Mon, 22 Nov 2004 19:51:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13270; Mon, 22 Nov 2004 19:51:44 -0500 (EST) Received: from boreas.isi.edu ([128.9.160.161]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWOxo-0001qH-6G; Mon, 22 Nov 2004 19:55:26 -0500 Received: from ISI.EDU (adma.isi.edu [128.9.160.239]) by boreas.isi.edu (8.11.6p2+0917/8.11.2) with ESMTP id iAN0o6t16519; Mon, 22 Nov 2004 16:50:06 -0800 (PST) Message-Id: <200411230050.iAN0o6t16519@boreas.isi.edu> To: ietf-announce@ietf.org From: rfc-editor@rfc-editor.org Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary=NextPart Date: Mon, 22 Nov 2004 16:50:06 -0800 X-ISI-4-30-3-MailScanner: Found to be clean X-MailScanner-From: rfc-ed@isi.edu X-Spam-Score: -14.6 (--------------) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: dhcwg@ietf.org, rfc-editor@rfc-editor.org Subject: [dhcwg] RFC 3942 on Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org --NextPart A new Request for Comments is now available in online RFC libraries. RFC 3942 Title: Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options Author(s): B. Volz Status: Standards Track Date: November 2004 Mailbox: volz@cisco.com Pages: 7 Characters: 13996 Updates: 2132 I-D Tag: draft-ietf-dhc-reclassify-options-01.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc3942.txt This document updates RFC 2132 to reclassify Dynamic Host Configuration Protocol version 4 (DHCPv4) option codes 128 to 223 (decimal) as publicly defined options to be managed by IANA in accordance with RFC 2939. This document directs IANA to make these option codes available for assignment as publicly defined DHCP options for future options. This document is a product of the 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. 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: <041122164821.RFC@RFC-EDITOR.ORG> RETRIEVE: rfc DOC-ID: rfc3942 --OtherAccess Content-Type: Message/External-body; name="rfc3942.txt"; site="ftp.isi.edu"; access-type="anon-ftp"; directory="in-notes" Content-Type: text/plain Content-ID: <041122164821.RFC@RFC-EDITOR.ORG> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --NextPart-- From dhcwg-bounces@ietf.org Mon Nov 22 22:46:07 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA08147; Mon, 22 Nov 2004 22:46:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRY6-0006St-Ff; Mon, 22 Nov 2004 22:41:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWRUO-0005gO-51 for dhcwg@megatron.ietf.org; Mon, 22 Nov 2004 22:37:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07527 for ; Mon, 22 Nov 2004 22:37:07 -0500 (EST) Received: from e32.co.us.ibm.com ([32.97.110.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWRXu-0006xE-LW for dhcwg@ietf.org; Mon, 22 Nov 2004 22:40:52 -0500 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id iAN3aWFJ172774 for ; Mon, 22 Nov 2004 22:36:32 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id iAN3aWhv041292 for ; Mon, 22 Nov 2004 20:36:32 -0700 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iAN3aWNW004024 for ; Mon, 22 Nov 2004 20:36:32 -0700 Received: from d03nm690.boulder.ibm.com (d03nm690.boulder.ibm.com [9.17.195.59]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id iAN3aWIR004021 for ; Mon, 22 Nov 2004 20:36:32 -0700 To: dhcwg@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Theodore Vojnovich Message-ID: Date: Mon, 22 Nov 2004 22:36:27 -0500 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.53HF56 | October 29, 2004) at 11/22/2004 20:36:32, Serialize complete at 11/22/2004 20:36:32 X-Spam-Score: 0.5 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Subject: [dhcwg] (no subject) X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1154062383==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multipart message in MIME format. --===============1154062383== Content-Type: multipart/alternative; boundary="=_alternative 0013D0BD85256F55_=" This is a multipart message in MIME format. --=_alternative 0013D0BD85256F55_= Content-Type: text/plain; charset="US-ASCII" Does rfc 3942 affect the usage of vendor specific options (vendor class identifier option 60 or client identifier option 61). Specifically, in the response to option 60 (option 43) still have "sub" options in the 200s...or....do we need to get some sort of IANA position on the use of vendor options inside 60/43? Thanks Ted Vojnovich Email: tbvojnov@us.ibm.com --=_alternative 0013D0BD85256F55_= Content-Type: text/html; charset="US-ASCII"
Does rfc 3942 affect the usage of vendor specific options (vendor class identifier option 60 or client identifier option 61).  Specifically,
in the response to option 60 (option 43)  still have "sub" options in the 200s...or....do we need to get some sort of IANA position on the use
of vendor options inside 60/43?

Thanks

Ted Vojnovich

Email:  tbvojnov@us.ibm.com
 --=_alternative 0013D0BD85256F55_=-- --===============1154062383== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============1154062383==-- From dhcwg-bounces@ietf.org Tue Nov 23 09:59:39 2004 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17269; Tue, 23 Nov 2004 09:59:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbuU-0003VC-Hk; Tue, 23 Nov 2004 09:44:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CWbqj-0001s8-Su for dhcwg@megatron.ietf.org; Tue, 23 Nov 2004 09:40:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14884 for ; Tue, 23 Nov 2004 09:40:55 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CWbuO-00019E-In for dhcwg@ietf.org; Tue, 23 Nov 2004 09:44:46 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 23 Nov 2004 07:46:07 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== Received: from flask.cisco.com (IDENT:mirapoint@flask.cisco.com [161.44.122.62]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id iANEeK9j006298; Tue, 23 Nov 2004 06:40:23 -0800 (PST) Received: from volzw2k ([161.44.65.122]) by flask.cisco.com (MOS 3.4.6-GR) with ESMTP id ANF88685; Tue, 23 Nov 2004 09:40:18 -0500 (EST) From: "Bernie Volz" To: "'Theodore Vojnovich'" , Subject: RE: [dhcwg] (no subject) Date: Tue, 23 Nov 2004 09:40:17 -0500 Organization: Cisco Message-ID: <001001c4d16a$59e73640$7a412ca1@amer.cisco.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4939.300 In-Reply-To: X-Spam-Score: 0.9 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 X-BeenThere: dhcwg@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: dhcwg.ietf.org List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0447504365==" Sender: dhcwg-bounces@ietf.org Errors-To: dhcwg-bounces@ietf.org This is a multi-part message in MIME format. --===============0447504365== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C4D140.71112E40" This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C4D140.71112E40 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit No, RFC 3942 only impacts the "main" DHCP option numbers, not sub-options inside of other options. So, if you're currently encoding suboptions in Option 43, you can continue to do that - Bernie -----Original Message----- From: dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of Theodore Vojnovich Sent: Monday, November 22, 2004 10:36 PM To: dhcwg@ietf.org Subject: [dhcwg] (no subject) Does rfc 3942 affect the usage of vendor specific options (vendor class identifier option 60 or client identifier option 61). Specifically, in the response to option 60 (option 43) still have "sub" options in the 200s...or....do we need to get some sort of IANA position on the use of vendor options inside 60/43? Thanks Ted Vojnovich Email: tbvojnov@us.ibm.com ------=_NextPart_000_0011_01C4D140.71112E40 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Message
No,=20 RFC 3942 only impacts the "main" DHCP option numbers, not sub-options = inside of=20 other options. So, if you're currently encoding suboptions in Option 43, = you can=20 continue to do that
 
-=20 Bernie
-----Original Message-----
From:=20 dhcwg-bounces@ietf.org [mailto:dhcwg-bounces@ietf.org] On Behalf Of = Theodore Vojnovich
Sent: Monday, November 22, 2004 10:36 = PM
To: dhcwg@ietf.org
Subject: [dhcwg] (no=20 subject)


Does = rfc 3942=20 affect the usage of vendor specific options (vendor class identifier = option 60=20 or client identifier option 61).  Specifically,
in the response to option 60 (option 43) =  still=20 have "sub" options in the 200s...or....do we need to get some sort of = IANA=20 position on the use
of = vendor options=20 inside 60/43?

Thanks

Ted=20 Vojnovich

Email:=20  tbvojnov@us.ibm.com
 ------=_NextPart_000_0011_01C4D140.71112E40-- --===============0447504365== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ dhcwg mailing list dhcwg@ietf.org https://www1.ietf.org/mailman/listinfo/dhcwg --===============0447504365==--